[NNTP] Consensus?

[Clive D.W. Feather]

Ken Murchison said:
>> It doesn't represent current practice, which is what we're supposed to be
>> documenting.
> True, but it sounds like current practice is all over the place (2^31, 
> 2^32, 2^64), so we need to standardize on something.

"Least common denominator" or "be conservative in what you send" is the
usual guideline.

> Standardizing on 
> something that we *know* will break in a few years doesn't seem like the 
> best move when there is a relatively simple solution which will push the 
> problem out far enough where most, if not all, of us on this list won't 
> have to worry about it.  ;)

I am not ocnvinced that it is "a relatively simple solution". It's
basically saying "an unknown number of existing implementations are hereby
declared non-conforming".

>> It introduces an interoperability issue. What happens if the server
>> supports the SHOULD and the client doesn't?
> Then the client chokes

You find that acceptable?

Most protocols with options in are phrased so that the recipient MUST
accept the transaction using the option, even if it then sends back a
rejection. In this case that would require the support of numbers above
2^32 by clients. But we know that isn't current practice.

> and can't read the group.
>
> They are no worse off 
> then if the server supports your BIGNUM strawman (which I like BTW) and 
> the client doesn't.

The big difference there is that the client gets a "there's a problem"
response code rather than bad data.

> You must have missed my post on this:
> 
> http://lists.eyrie.org/pipermail/ietf-nntp/2005-July/001612.html

I did.

+   Article numbers MUST be positive integers.  Clients and servers
+   MUST support article numbers up to, and including 4,294,967,295
+   (2^32 - 1).  However, due to the exponential growth of Netnews
+   traffic, it is RECOMMENDED that clients and servers support article
+   numbers up to, and including 18,446,744,073,709,551,615 (2^64 - 1).

Again, this doesn't explicitly address what happens if one end doesn't
implement the RECOMMENDED (which, incidentally, means exactly the same as
SHOULD).

> Having said all of this, if we can't reach a consensus on 2^64 
> relatively quickly, then lets just go with 2^32 and be done with it.

As I said, I don't think that changing to 2^64-1 is the sort of thing that
should be "sneaked in" at this late stage.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |