[NNTP] 32 bit article counters

[Chris Caputo]

On Fri, 8 Jul 2005, Russ Allbery wrote:
> 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.

I tend to stand by what I wrote in 1997 - copied below.

But I'd also be fine with an extension being defined which allows for 
numbers greater than 2^32-1.

Maybe the fix for now should just be to say that client software should 
assume a 32-bit wrap-around has occurred if the high article number is 
more than one less than the low article number.  The would allow servers 
using more than 32-bits to use a MOD 2^32 to create an standards compliant 
number.  For that to work we'd also have to adjust the draft to say that 
zero is a valid article number.

Chris

---

Date: Mon, 6 Jan 1997 10:40:02 -0800 (PST)
From: Chris Caputo <ccaputo at alt.net>
To: ietf-nntp at academ.com
Subject: Re: ietf-nntp New wording on article numbers - draft 2

On Mon, 6 Jan 1997, Brian Kantor wrote:
> Is that one's-complement, two's-complement, Burroughs mantissa/exponent,
> or double-precision IEEE-FP bits?
> The whole world isn't Microsoft/Intel yet, thank God.

On Mon, 6 Jan 1997, Clive D.W. Feather wrote:
> Because the protocol sends decimal digits, not binary numbers. The actual
> *value* is limited to 2^32-1 (so if you send 16 digits, the first five will
> all be zero).

The preceeding two comments have really got me thinking we shouldn't place
any limitations on decimal length or range of article numbers.  Why don't
we just let the market decide how many decimal digits to use?  Since this
is a text based protocol, it seems we shouldn't even worry about what
range a 32-bit number will allow.  I certainly am thankful Brian and
others didn't limit article numbers to 16-bits in RFC977, a bit length
that might have been appropriate for the market when the rfc was drafted.
We'd all be having flag days several times a year, if they did.  In this
same light, let's not limit RFC977bis.  The market will decide when it is
time to grow the range.

I propose we change the draft to not place limitations on decimal length
or range.  Coders can make their code handle whatever they feel is
appropriate.  Ie, Metscape may go off and make it so they can handle
infinite numbers (memory allowing), while Nicrosoft may decide to limit
their code to 64-bits.  Who knows...  The implementors get to decide what
trade-offs to take, and users make a decision of what to use based on this
kind of thing.  When a server and client get a conflict, it becomes an
issue of one side needing to upgrade to more timely code.  I think it's
reasonable that a newsreader from 1997 won't be able to handle a server
from 2017 without some upgrades.  The 1997 reader would become obsolete,
while modern readers handle the ranges that are seen in 2017.

Further, if I am a server operator of a server that can handle a range
more than some of my clients, I would like it to be up to me to be able to
decide whether to have a flag day or whether to encourage/force users to
upgrade their clients.

Therefore, I recommend a change in the draft from:

     Article numbers MUST lie between 1 and 4 294 967 295 inclusive. The
     client and server SHOULD NOT use leading zeroes in specifying article
     numbers, and MUST NOT use more than 16 digits. In some situations the
     value zero replaces an article number to show some special situation.

to:

     Article numbers MUST lie between 1 and infinity inclusive. The
     client and server SHOULD NOT use leading zeroes in specifying article
     numbers. In some situations the value zero replaces an article number
     to show some special situation. The actual article number range
     supported by an implementation is up to the implementor, but it is
     intended that the implementor will choose a range that corresponds to
     modern needs, while maximizing interoperability.

Chris Caputo
President, Altopia Corporation