[NNTP] Re: Nearly there

[Ken Murchison]

Clive D.W. Feather wrote:
> Russ Allbery said:
>>> I'm very nervous about raising this, after all the arguments this time
>>> last year, but I believe that changing it to 2^31-1 is the correct thing
>>> to do *FOR THIS VERSION OF THE NNTP SPECIFICATION*.
>> I won't argue against either 2^31-1 or 2^32-1, but I'm not sure how much
>> we can get away with changing at this stage in the actual protocol
>> requirements.
> 
> If I understood what Scott said, we can make such changes at AUTH48
> provided it's been through the working group.
> 
>>>     It is likely that at some stage at least one NNTP server will reach
>>>     the limit of [4,294,967,295] in at least one newsgroup. Ways to deal
>>>     with this while not gratuitously breaking compatibility are still
>>>     being investigated and are likely to result in publication of a
>>>     revision or extension to this specification at some future date.
>>>     While servers MUST NOT send article numbers greater than this limit,
>>>     client and server developers are advised to use internal structures
>>>     and datatypes capable of handling larger values in anticipation of
>>>     such a change.
>> I'm not sure what to think about this.  I think overall it's not a bad
>> idea, though, and might be helpful.  Since the above doesn't change the
>> protocol specification, it's more palatable during AUTH48 to me.
> 
> The first part was in lieu of anyone coming up with a mutually acceptable
> proposal in the timescale. The second part is a blatant hint to developers
> not to use 32-bit variables in the future.

The first part seems too wordy to me and gets into more detail than I 
think is necessary.  How about something like this instead:

"Note that it is likely that the article number limit of [4,294,967,295] 
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."


-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University