[NNTP] 32 bit article counters

Russ Allbery rra at stanford.edu
Fri Jul 8 11:59:05 PDT 2005


I think this needs general discussion by the group.  I'll go ahead and
state my opinion for the record and then stay quiet and let people talk it
over, since Steve has already heard my view on this.

There are definitely some reasons to want to move to either 64-bit article
IDs or require that software deal with arbitrary length article IDs:

 * A news configuration like Steve's that files all articles in a single
   group for one reason or another will interact poorly with a limited
   article ID space, or at least a 32-bit limited article ID space, given
   current traffic.  I was personally unaware that anyone was doing this.

 * It's likely that eventually some newsgroup will, in a normal
   configuration, overflow a 32-bit counter.  My calculations indicate
   that it's likely to take another 20 years or so, but assuming that
   Usenet persists and certain groups remain popular, both fairly
   reasonable assumptions in my opinion, it will happen eventually and
   there's no good way of dealing with it at present.

 * Arbitrary limits are bad and should be avoided wherever possible.

There are also sound reasons why the working group originally took the
course of action it did and restricted the article ID space to 32 bits:

 * This is widespread existing practice.  Lots and lots of news software
   uses article IDs as numbers to do numeric comparisons (in fact, one has
   to do so to reasonably implement some portions of the NNTP protocol),
   and that software overwhelmingly uses 32-bit integers to do so.
   Requiring 64-bit article IDs would immediately declare out of
   compliance quite a lot of existing software and using them in practice
   would break quite a bit of software.  (Let alone arbitrary numbers.
   Adding a bignum library to news software to be able to do range
   calculations and range compaction seems like it's asking a lot to me.)

 * The article ID space is not being exhausted quickly for normal usage.
   The most heavily used regular group has probably exhausted around 5%
   of the available article ID space.  While I think it's likely that some
   group will eventually overflow, it's not certain, and it's quite some
   distance into the future.  *Assuming* that one doesn't care about the
   configuration that puts all articles into a single group (a very large
   assumption), it's not clear that this is a problem we should be
   worrying about right now, as opposed to getting out a better starting
   point for future work.

 * Large article IDs may be better handled by an extension than a revision
   of the base specification, since that leaves an out for older software
   that hasn't been revised to support larger article IDs by forcing the
   server to make some accomodation.

 * Availability of 64-bit integers is only now becoming widespread, and
   weren't widespread when this question was first considered by the
   working group.

My personal preference (not speaking as chair) would be to leave this
limit as is and deal with large article numbers via an extension.  The
details of how that extension would work would have to be worked out; the
simplest approach would be to make groups with large article numbers
inaccessible to clients that don't declare that extension, but there may
be a more elegant solution.  However, that's just my personal preference,
and if the working group reaches a different conclusion, I'm not going to
stand in the way of that.

Steve is entirely correct in his statement that RFC 977 puts no limit on
the article IDs.  RFC 977 did not reflect what people implemented in a
number of details, this being one of them.  While I'm sure there is
software out there that supports arbitrarily large article IDs, I'm not
personally aware of any and have not seen any; 32-bit article IDs are
universal in my experience.  The charter of this working group was to
produce a revision to RFC 977 that documents the existing situation.  I
believe that specification of a 32-bit article ID space makes sense within
that charter.  However, I can also see the objection that it represents a
regression of sorts from what RFC 977 says on paper.

On the question of timing, while it is in theory possible to put the
brakes on publication of the revised document at this stage, I believe it
would be a fairly serious thing to do.  So that everyone is aware, my
current intention is to take a few months break after we get all of our
documents out, put the work into INN to bring it up to snuff with the
specification, and then start gathering information and start the process
for a revision to draft standard.  We could certainly revisit topics like
this at that time.  (Somewhere in that range we should probably also do
the informational revision of RFC 2980.)

Note that this is a long-standing point of discussion for this working
group.  We first reached consensus on the current text about eight years
ago; Clive was the one who drafted it originally.  Since then, the topic
has been revisited every couple of years or so, and consensus was tested
and re-established each time.  However, this is the first time that I
recall someone bringing up a configuration that files all articles into a
single group.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the ietf-nntp mailing list