[NNTP] Article number wording

[Clive D.W. Feather]

[Typically, this would blow up while I'm on holiday. My apologies for
starting a separate thread, but there are several points scattered around
that I want to address.]

Firstly, I believe we *MUST* get this document out without any more delays.
It is ridiculous how long it has taken already. If major changes are
needed, we can address them in the next review cycle.

Secondly, I don't accept the "977 had no limits" argument. RFC 977 was
written at a time when people were far more sloppy about specifications
than they are now. There are lots of places where it failed to make matters
clear enough, and this is one of them. In those days everyone would have
seen 32 bits as being "obvious". The lack of Bignum implementations within
news software is evidence of this.

Thirdly, I do actually sympathise with those who want something done. When
we agreed that wording 8 or so years ago, we decided that the 32 bit limit
would be hit rarely enough that local "flag days" would be acceptable. Had
this topic been raised a year ago, I would have been very much in favour of
solving it before publication (given we were waiting on plenty of other
things). But it's been dormant for many years; now is not the time. This is
*not* the same as saying "never fix it".

Fourthly, it isn't "a simple matter of programming", as Ken implies with:
> If I change my server to use 64-bits today (actually it might be
> already, I'd have to look), its not going to break any existing clients,

What you'll be left with is a problem waiting to happen *silently*, as old
clients that thought they conformed suddenly run into servers that use
large numbers. Or vice versa (though that's rather less likely).

Fifthly, when we worked on the text originally, nobody noted the signed
versus unsigned problem. The limit we have in the text is 2^32-1 (spelled
out, of course). Should this be changed to 2^31-1 before publication
(presuming it's acceptable as a minor change)?

Russ suggested the wording:
> Implementors are encouraged
> to support arbitrarily large article numbers and SHOULD use at least
> the largest integer type their software can support.  However, note
> that many widely deployed NNTP clients cannot handle article numbers
> larger than 2,147,483,647 or 4,294,967,295 and article numbers higher
> than that are likely to cause interoperability problems.

I don't think this helps. A maximally portable server will have to limit
itself to 2^31-1. Better to find a way for the two parties to negotiate the
maximum they can cope with and have a defined way to deal with overflow. An
extension is then the right way to do it.

[Incidentally, "can support" should be "can support efficiently", because
everyone *can* support bignums with enough effort.]

For now, put in some wording like:

    It is likely that at some stage at least one NNTP server will reach the
    limit of 4,294,967,295 in at least one newsgroup. Ways to deal with
    this while not gratuitously breaking compatibility are still being
    investigated and are likely to result in publication of a revision or
    extension to this specification at some future date.

and let that be a warning to implementers.

[Rather than making this message any longer, I'll address the extension
idea separately.]

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |