ietf-nntp New wording on article numbers - draft 2

Chris Caputo ccaputo at alt.net
Mon Jan 6 10:40:02 PST 1997


On Mon, 6 Jan 1997, Brian Kantor wrote:
> Is that one's-complement, two's-complement, Burroughs mantissa/exponent,
> or double-precision IEEE-FP bits?
> The whole world isn't Microsoft/Intel yet, thank God.

On Mon, 6 Jan 1997, Clive D.W. Feather wrote:
> Because the protocol sends decimal digits, not binary numbers. The actual
> *value* is limited to 2^32-1 (so if you send 16 digits, the first five will
> all be zero).

The preceeding two comments have really got me thinking we shouldn't place
any limitations on decimal length or range of article numbers.  Why don't
we just let the market decide how many decimal digits to use?  Since this
is a text based protocol, it seems we shouldn't even worry about what
range a 32-bit number will allow.  I certainly am thankful Brian and
others didn't limit article numbers to 16-bits in RFC977, a bit length
that might have been appropriate for the market when the rfc was drafted.
We'd all be having flag days several times a year, if they did.  In this
same light, let's not limit RFC977bis.  The market will decide when it is
time to grow the range. 

I propose we change the draft to not place limitations on decimal length
or range.  Coders can make their code handle whatever they feel is
appropriate.  Ie, Metscape may go off and make it so they can handle
infinite numbers (memory allowing), while Nicrosoft may decide to limit
their code to 64-bits.  Who knows...  The implementors get to decide what
trade-offs to take, and users make a decision of what to use based on this
kind of thing.  When a server and client get a conflict, it becomes an
issue of one side needing to upgrade to more timely code.  I think it's
reasonable that a newsreader from 1997 won't be able to handle a server
from 2017 without some upgrades.  The 1997 reader would become obsolete,
while modern readers handle the ranges that are seen in 2017. 

Further, if I am a server operator of a server that can handle a range
more than some of my clients, I would like it to be up to me to be able to
decide whether to have a flag day or whether to encourage/force users to
upgrade their clients. 

Therefore, I recommend a change in the draft from: 

    Article numbers MUST lie between 1 and 4 294 967 295 inclusive. The
    client and server SHOULD NOT use leading zeroes in specifying article
    numbers, and MUST NOT use more than 16 digits. In some situations the
    value zero replaces an article number to show some special situation.

to:

    Article numbers MUST lie between 1 and infinity inclusive. The
    client and server SHOULD NOT use leading zeroes in specifying article
    numbers. In some situations the value zero replaces an article number
    to show some special situation. The actual article number range
    supported by an implementation is up to the implementor, but it is
    intended that the implementor will choose a range that corresponds to
    modern needs, while maximizing interoperability. 

Chris Caputo
President, Altopia Corporation




More information about the ietf-nntp mailing list