[NNTP] 32 bit article counters

Ken Murchison ken at oceana.com
Sat Jul 9 09:13:07 PDT 2005


If no current server/group has exhausted the 32-bit space as of yet, I 
don't see the problem in expanding the space to 64-bits now in NNTPv2. 
Let's get implementations moving forward *before* we run into a problem.

If I change my server to use 64-bits today (actually it might be 
already, I'd have to look), its not going to break any existing clients, 
since all article numbers returned by the server will still be below the 
32-bit threshold.  Conversely, if a client uses 64-bits to fetch 
articles from a 32-bit server, it will still work because all existing 
article numbers will still be below the 32-bit threshold.

I'd propose that NNTPv2 use language such as:

"Clients and servers MUST support article numbers between 1 and 
4,294,967,295 inclusive, but SHOULD support article numbers between 1 
and 18,446,744,073,709,551,615 inclusive."

This documents existing practice via the 32-bit limit but urges 
implementations to upgrade to 64-bit for the future.  Obviously the 
language in the current draft regarding a maximum of 16 digits would 
have to change.

Or we just mandate that NNTPv2 implementations use 64-bits, since it 
won't break existing implementations for at least 2 years and possibly 
longer, depending on implementation and the growth of Usenet.

I've spent a little bit of time thinking about how this could be handled 
by an extension, but it just seems too messy.  IMO, the best course of 
action is to urge client/server authors to start rolling out 64-bit 
implementations now, before the problem occurs.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



More information about the ietf-nntp mailing list