[NNTP] 64-bit article counter extension strawman

[Forrest J. Cavalier III]

Russ Allbery wrote:

> 
> I'd like Clive and, ideally, Andrew to weigh in, and would love to hear
> from other working group members as well, but that sounds good to me.
> (Andrew's input would be very useful on this.)
> 

I dislike specified limits in standards.

At the time this WG group started, the 32 bit rollover seemed like a
good way of dealing with article number that are too high.  I do not
agree that it is appropriate now.  It seems that people are willing
to declare software that overflows at 31-bits as "poor implementations
we don't support" but they are not willing to declare software that
overflows at 32 bits in the same class.  That seems a hard position
to hold rationally.

MSVC has 64 bit integer types for what, 8 years now, and that generates
code that runs on 386's.  GCC has supported "long long" for just about
that long or longer.

A note about breakage seems appropriate.  Servers MAY roll over at
31 bits seems appropriate to me.

Now that we see GigE common, TCP sequence numbers of 32 bits are
kind of uncomfortable, due to the blind RST and similar spoofs.
32 bits seemed like a good idea at the time, then, I'm sure, and
there is the advantage of saving bits in the TCP header.

But we don't need to save bits in NNTP, so I'd not even specify
64 bits...except that leaving it open-ended seems to promote abuse of
article number as a structured number, instead of a plain sequence
number.  (E.g. some scheme that gives you filtered articles if
you add 2^56 to the article number, or other kludges.)