[NNTP] Article number wording

[Forrest J. Cavalier III]

Russ Allbery wrote:
> Forrest J Cavalier <forrest at mibsoftware.com> writes:
> 
>>Russ Allbery wrote:
> 
> 
>>>+   This standard imposes no maximum limit on article numbers other than
>>>+   the maximum length of an NNTP command.  Implementors are encouraged
>>>+   to support arbitrarily large article numbers and SHOULD use at least
>>>+   the largest integer type their software can support.  However, note
>>>+   that many widely deployed NNTP clients cannot handle article numbers
>>>+   larger than 2,147,483,647 or 4,294,967,295 and article numbers higher
>>>+   than that are likely to cause interoperability problems.
> 
> 
>>Yes, as an implementor, I'd read that as indicating bignums.  It doesn't
>>give any indication of Steve Walker's implementation being in the wild.
> 
> 
>>How about....
> 
> 
>>+   This standard imposes no maximum limit on article numbers other than
>>+   the maximum length of an NNTP command.  Note that many widely deployed
>>+   NNTP clients do not handle article numbers larger than 2,147,483,647 or
>>+   4,294,967,295, and no widely known clients or servers handle article
>>+   numbers larger than 18,446,744,073,709,551,615.
> 
> 
> You lost the only SHOULD in the paragraph, as well as any idea of using
> the largest native integer type.  

Dropped, not lost.  It was not an accident.

 > I don't like this as well; it doesn't
> seem to give the implementor any real guidance.
> 

I think it replaces a sentence which did not give real guidance.

I wrote to give the server implementor an idea of what to expect in client
behavior at the time we write it, and the client implementor an idea of
what to expect in server behavior.

I don't like "SHOULD" here at all. Interoperating Article numbering is waaay
more important than what the "extra features" you typically get by following
a SHOULD.   SHOULD doesn't say anything definite about what to expect from
the other side.

It would be cleaner to provide a hard limit in the protocol, with
a MUST, but there's no consensus.  There are rational voices here to not
break clients by rollover at 2^31, and there are rational voices here to
support 2^64.

I think they both have good arguments.  It certainly isn't clear to me what's
the right solution.

So, I say punt, outline the problem-space and then implementors will do
the right thing.  No need for the RFC2119 language, because it doesn't
really help, unless it is MUST, (and even then that might not help define
what legacy clients will do.)