[NNTP] 32 bit article counters

[Steve Walker]

Russ has already heard most of this in private, but I thought I 
would post it here.

Russ Allbery wrote:
>  * 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

There can be many theories on how to estimate the point of 
collapse (I calculate <8 years), but I think everyone can agree 
that it will happen at some point.  NNTP V2 is the correct place 
to solve this problem.  If we solve it now, everyone can quit 
wasting their time talking about it.

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

Which is how RFC977 solved it.

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

They are already non RFC977 compliant.  The developers choose to 
use 32 bit counters and they saw it as an acceptable trade off. 
In the real world, nothing changes if we declare no limits or 
even 64 bit limits.  Their software breaks at 2^32 regardless of 
what the protocol says.  If the protocol specifies 64 bit 
counters we have the hope that software will be updated in time. 
  If the new protocol specifies 32 bit counters we have no hope 
and the existing RFC977 compliant software become non-complaint. 
  This is very similar to Y2K problems.  Had software developers 
used 4 digit years in the first place there wouldn't have been 
any Y2K issues.

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

Personally, I feel that any protocol that deals with text based 
numbers should not place any restrictions other than line length. 
    If people feel some overwhelming need to place limits in the 
protocol then either 1) use a limit that is large enough that it 
doesn't matter or 2) specify what should happen when the limit is 
reached.

The current protocol specifies that high counters can't be less 
than low counters and you can't exceed 2^32-1.  You can't have 
both without breaking stuff.

> 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

It is more logical to not change RFC977 limits in a non 
compatible way.  Nothing changed means nothing broken.

> 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

Making a major non-RFC977 compatible change is serious enough to 
warrant removing one line and leaving the existing RFC977 rules 
unchanged.

> 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

Eight years ago no one thought there would be 6 million articles 
posted each day, year here we are and still growing.  In another 
eight years you can expect that number to be over 100+ million 
per day.  Protocols need to consider the future, not just what 
happens today.  Which is why the RFC977 didn't place a limit and 
allowed the software developers the freedom to adapt to current 
needs.

Steve Walker
NNTPServer.com