[NNTP] 64-bit article counter extension strawman

Chin Chee-Kai cheekai at softml.net
Mon Jul 18 10:29:50 PDT 2005


Hi,

Sorry for jumping in, but I was having some interest reading about
the 32bit/64bit discussion.  I thought I'd give a view from a 
bit of different angle hopefully it could help.

Basically I think RFC977 gives more freedom in terms of number
range than a specific limit as proposed (either 32bit, 64bit, 128bit,
etc).  To be specific, RFC977 doesn't really say "no limit".
It does restrict command line to a usable of 510 bytes.
So ignoring some 4 to 10+ bytes of command word and using all 510 bytes
to print a decimal number, RFC977 implies a number that is no
more than 1,695 bits (about 212 bytes).  Technically, if you
have a fixed precision counter package that can hold that size
(rather than a more elaborate arbitrary precision package), it 
would suffice to be compliant with the RFC's number size requirement.

So all 31bit, 32bit, 64bit etc implementations are approximations
to deal with this 1,695bit requirement.  And like Steve said,
they need to be reviewed from time to time.  And when that happens,
a 10-year-old client might just be upgraded to 64bit in preparation
for future, and an 8-year-old server might be armed with 128bit
counter to take care of "just-in-cases", for example.

So the "problem" isn't so much with the standard, the protocol or 
limits, but with the way implementations have somewhat arbitrarily 
taken their own approximation methods to cope with the size requirement.
So assuming with me this for a moment, then, trying to "fix the
problem" by adding commands, options, changing semantics of existing 
commands, etc wouldn't seem to be a right approach.

I agree with Russ on the need for stable specs and with 
interoperability in mind, if there's really any thing that needs
to be done.  It might be the case that clients that have implemented
with only 31bits of 'int' (using Steve's example) would be a 
"too bad" case - the user would notice lesser articles and
start to upgrade or change.  This is reminiscent of Y2K changeoever.

If, just if, there's anything that needs to be done, I think it
would have to be a non-obliging signal.  "Non-obliging" in the
sense that the server/client sends out this signal of >32bit number
voluntarily, such as MAY respond with an unused 2xx success code.
The receiving client/server that is cognizant of the code would
either deal with it, or prompt user that it can't handle large
articles and give a graceful termination.

Just some thoughts.


Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai at SoftML.Net
http://SoftML.Net/






More information about the ietf-nntp mailing list