[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