[NNTP] 64-bit article counter extension strawman

[Russ Allbery]

Steve Walker <nntp at nntpserver.com> writes:

> Two commands that do the exact same thing are redundant.  The existing
> 64 bit clean software works fine with the existing command set.

I would be curious to see a list of software known to already be able to
handle 64-bit article numbers.  You mentioned earlier that you know of at
least one client, but you didn't say what client that was.

> What is needed is a method to tell the 32 bit software that it won't
> work and it should go away or accept what happens.

> It's common practice for servers to zero-pad article numbers. What if we
> just said something like:

> Servers that have the capability to handle article numbers greater than
> 2^32-1 MUST zero pad the ranges published by the list and group
> commands.  Clients should expect article numbers greater than 2^32-1 if
> they receive article number responses with a text length greater than 10
> digits.

(You only want to do this for groups that actually have large article
numbers; there's no reason to prevent 32-bit software from reading all the
groups that haven't needed such large numbers.  Plus, zero-padding all of
LIST ACTIVE would noticably increase the size of the response
unnecessarily.)

This doesn't do what you say is needed above, as existing 32-bit software
will have no idea that additional zero padding means this.  The software
would have to be modified to add this interpretation, which means it will
be years, perhaps decades, before one can be reasonably assured that all
client software will recognize this signal.

I think it would be far better to have a signal that's recognized by
existing software without requiring any modifications.  Both of Ken's
proposals would do that.

> The number 2^32-1 fits in a 10 digit text string.  Any zero padded
> number larger than 10 digits is already implying a potential article
> number greater than 10 billion.  Zero padding numbers in the list and
> group output is a very easy and simple way to inform the client that
> article numbers may be given that exceed 2^32-1.

> As a bonus it fixes the problem without specify any new absolute limit,
> which IMO, a text protocol shouldn't.  If any existing 32 bit software
> zero pads greater than 10 digits we could increase this number with
> causing any problems up to 20 digits (64 bit number).

This *is* a nice property, and this part of it I do like.

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