[NNTP] 32 bit article counters

[Clive D.W. Feather]

Russ Allbery said:
> 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.

I'm also not entirely sure how they're conformant to Usefor, unless this is
a "secret" group that's being added as well as those in the article header.

>  * 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.

Agreed, which is something that we knew at the time.

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

A good principle, but not always practical.

>  * 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.

This was, as I recall, why we did it this way. We did, as I recall, spend a
little time looking at ways to address this and decided that none were
worth the complexity - on the rare occasion that a group wrapped round,
server operators could declare a flag day.

>  * 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.

That would be a sensible transition approach. Then at a later point we make
the 64-bit behaviour mandatory.

> 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.

I also strongly suspect that "nobody expected anything other than 32 bits".
I really don't accept the "RFC 977 didn't have a limit" argument, because
stuff written in those days tended to be much looser than would be
acceptable today.

> I
> believe that specification of a 32-bit article ID space makes sense within
> that charter.

Agreed.

> 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.

True. I'm going to say more in another message.

My overriding view on this is "this discussion MUST NOT hold up publication
of the document". Since it's already at the RFC Editor (and IANA have
already done their actions) I don't believe we can address it in this
version.

-- 
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            |                            |