Subject: [Tools-discuss] Idnits-2.16.02 feedback: -latest pattern

From: Carsten Bormann <[email-masked]>
Date: Sat, 6 Apr 2019 18:43:41 +0200

Idnits should recognize the -latest pattern that Martin Thomson’s template uses and turn these four messages into one (or maybe even fix the fourth, because that very much can be figured out based on the pattern):

Grüße, Carsten

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  ** Missing revision: the document name given in the document,
     'draft-ietf-core-multipart-ct-latest', does not give the document
     revision number

  ~~ Missing draftname component: the document name given in the document,
     'draft-ietf-core-multipart-ct-latest', does not seem to contain all the
     document name components required ('draft' prefix, document source,
     document name, and revision) -- see
     https://www.ietf.org/id-info/guidelines#naming for more information.

  == Mismatching filename: the document gives the document name as
     'draft-ietf-core-multipart-ct-latest', but the file name used is
     'draft-ietf-core-multipart-ct'

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Couldn't figure out when the document was first submitted -- there may
     comments or warnings related to the use of a disclaimer for pre-RFC5378
     work that could not be issued because of this.  Please check the Legal
     Provisions document at https://trustee.ietf.org/license-info to determine
     if you need the pre-RFC5378 disclaimer.

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 6 Apr 2019 18:58:04 +0200

Hi Carsten,

On 2019-04-06 18:43, Carsten Bormann wrote:
> Idnits should recognize the -latest pattern that Martin Thomson’s
> template uses and turn these four messages into one (or maybe even
> fix the fourth, because that very much can be figured out based on
> the pattern):

I don't see that from the information given.

 1) If idnits was made more permissive to accept these, and they actually
    occurred in a submitted document by mistake, they would not be flagged

 2) I don't see why idnits should be run on something which hasn't been
    processed all the way through to exact submission state, which seems to
    be what's happening here -- if the processing pipeline is able to produce
    something ready for submission, why is idnits run on something else?

Regards,

	Henrik

> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 6 Apr 2019 19:03:53 +0200

>    occurred in a submitted document by mistake, they would not be flagged

They would be, in one message instead of four (that all need to be actively ignored by a human each time an idnits check is made).

>    something ready for submission, why is idnits run on something else?

Because it is expedient.  Documents spend most of their time in the -latest stage; doing a quick kdrfc/idnits is a good thing to do after not having touched a document for a couple of weeks.

Grüße, Carsten

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 6 Apr 2019 13:04:11 -0400

I would be in favor of the submission process assigning a number based on previous state. New documents get -00 and subsequent versions are assigned the next revision number. That way, the document doesn’t have to specify a version number.

Tom

> On Apr 6, 2019, at 12:43 PM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 6 Apr 2019 20:35:20 +0200

> I would be in favor of the submission process assigning a number based on previous state. New documents get -00 and subsequent versions are assigned the next revision number. That way, the document…

The current scheme is a little more resilient in the face of co-author confusion of who is supposed to submit.  If this were less of a real problem, I’d probably agree that maintaining that version number by hand is a bit of busywork I don’t really need.  But then, I’d need to backport the assigned version number to my source revision control…

Grüße, Carsten