[NNTP] AD approval needed for RFC 3977 AUTH48 changes

[Russ Allbery]

> This is your LAST CHANCE to make changes to your RFC to be:
> draft-ietf-nntpext-base-27.txt, once the document is published as
> an RFC we *WILL NOT* make any changes.

> Please check your document at:

> ftp://ftp.rfc-editor.org/in-notes/authors/rfc3977.txt

ADs,

This is a heads-up that, based on working group discussion following the
approval of these documents by the IESG, we intend to request the
following protocol-level changes to this document before publication.
These changes were discussed with consensus on the former working group
mailing list with no dissenters.

 * Keywords (which include capability names) are limited to 12 characters,
   but we already have a keyword ("IMPLEMENTATION") which is longer than
   that, making the document internally inconsistant.  We will instead
   remove this limit, as it serves no useful protocol purpose and was not
   present in RFC977.

 * The limit on article numbers was stated as 2^32-1, but later
   investigation of widely deployed news clients revealed substantial use
   of signed integer types to hold article numbers in ways that would
   break with any article number over 2^31-1.  Accordingly, given our
   charter to prioritize documenting existing behavior over new work, we
   are requesting that the limit be stated as 2^31-1 in the final standard
   to maximize interoperability.  How best to address this limit going
   forward will be a topic for follow-on standards work.

 * In order not to give implementors any false sense of security about the
   article number limit, we are requesting that the following paragraph be
   added to the relevant section:

     Note that it is likely that the article number limit of 2,147,483,647
     will be increased by a future revision or extension to this
     specification.  While servers MUST NOT send article numbers greater
     than this current limit, client and server developers are advised to
     use internal structures and datatypes capable of handling larger
     values in anticipation of such a change.

The exact proposed changes are attached below.  Please let me know if
there's any additional information that I can provide about these changes.


NOTE: quoted text will, in general, not include the entire paragraph, so as
to ensure that the changes are not lost in the noise.
   
Section 2, paragraph 6:               
OLD:  
   Keywords MUST be at least three characters and MUST NOT exceed 12
   characters in length. 
NEW:
   Keywords MUST be at least three characters in length.
                                              ^

Section 9.8, paragraph 3:
OLD:     
   keyword = ALPHA 2*11(ALPHA / DIGIT / "." / "-")
NEW:
   keyword = ALPHA 2*(ALPHA / DIGIT / "." / "-")
                     ^^

ection 6, last paragraph:
OLD:
   Article numbers MUST lie between 1 and 4,294,967,295, inclusive.
NEW:
   Article numbers MUST lie between 1 and 2,147,483,647, inclusive.
                                          ^^^^^^^^^^^^^

Section 6, new paragraph to be added at the end (before 6.1):
NEW:
   Note that it is likely that the article number limit of 2,147,483,647
   will be increased by a future revision or extension to this
   specification.  While servers MUST NOT send article numbers greater than
   this current limit, client and server developers are advised to use
   internal structures and datatypes capable of handling larger values in
   anticipation of such a change.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>