[NNTP] 64-bit article counter extension strawman

[Russ Allbery]

Steve Walker <nntp at nntpserver.com> writes:

> The same thing can be said for mandating 32 bit support.  I don't think
> you can even claim that most software is 32 bit clean as anything that
> used 'int' is going to break at 31 bits.

And either change requires changing all the printf formats, so there is
something to what you say.  However, fixing the 31-bit issue only requires
changing int to unsigned int, which doesn't change the size of the
variable and therefore makes quite a bit of the work easier.  One also
doesn't have to deal with the portability issues around 64-bit types, nor
does one have to figure out how to deal with systems that don't have a
64-bit type.

> We currently have a mix of 31, 32 and 64 bit software.  You would be
> better off leaving out any limit if your plans are to address the issue
> latter.  No matter what limit is used, most software needs to be
> reviewed and updated.

I don't agree.  At the most, software that deals with exceptionally
high-volume groups (read: software that deals with binary groups) will
have to be reviewed and updated sometime in the next ten years or so.
Even 31-bit implementations that are used for reading text groups are
probably fine for the lifetime of Usenet as a protocol.

>> further changes to the document at this point, now that we're *finally*
>> done.  There's always going to be just one more thing.

> That's just being lazy.

You're certainly entitled to your opinion, but insulting me is unlikely to
change mine.  :)

> This is a major problem that is guaranteed to cause the complete
> malfunction of the Usenet system at some point.

Well, it is a major problem for your particular implementation.  It is not
a major problem for the rest of Usenet and will not be for at least
another 10-20 years.

Part of the job of working group chair is to be a release manager.  Part
of the job of a release manager is to recognize that there's always going
to be one more bug fix and apply increasing pressure to stop doing work
and start releasing work.  The way I view this, it's not a veto -- it's
accelerating pressure, which means that the farther we go along, the more
strongly I argue against making changes, but if the group consensus says
make the changes anyway, we still do that.

> It's irresponsible to call this a completed protocol if it adds a new
> article number limit and doesn't specify what to do when it's reached.

We aren't calling it a completed protocol.  That would be the Standard
phase, whereas this is only at the Proposed Standard phase.

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