[NNTP] 64-bit article counter extension strawman

[Russ Allbery]

Steve Walker <nntp at nntpserver.com> writes:
> Russ Allbery wrote:

>> Support of the 64-bit type itself is, as previously noted, not really
>> the gating factor.  It's the supporting library functions that are more
>> of a problem, and GCC can't help with your printf implementation (for
>> example).

> Glibc supports 64 bit numbers as does the Microsoft stuff as far as I'm
> aware.  There really isn't much out there that couldn't support at least
> 64 bit numbers.

I just refuted this statement in the paragraph immediately above your
response.  If you want more details or have questions about the specifics
of what I said, could you please ask them, rather than simply asserting
that I'm wrong without any additional support?

>> Saying "there's no limit and you should be prepared for any length of
>> article number" says to client authors "you must include a bignum
>> library."  That seems a little excessive, and in practice I doubt
>> clients will actually do this.  I think we need to be very careful
>> about what we say about allowed or recommended client behavior if we
>> really don't specify any limit.

> It worked for 977 so why wouldn't it continue to work.

No one actually implemented this aspect of RFC 977 that I am aware of.  If
you know of a client implementation that supports arbitrarily long article
numbers, I'd love to hear about it.  If not, then saying that it worked
for 977 isn't a particularly useful statement, since RFC 977 itself didn't
actually work as a standard in this area.

One of the things that we're trying to *not* do is emulate RFC 977's
problems, one of which being that portions of it are tacitly ignored by
all known implementations without any warning in the standard for future
implementors that this is the case.

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