[NNTP] Consensus?
Matthias Andree
matthias.andree at gmx.de
Fri Aug 12 16:45:43 PDT 2005
Thomas Gschwind schrieb am 2005-08-12:
> Historically, article numbers lie in the range between 1 and 2^32-1
wrong tense. Replay lie by lay or perhaps better (as it's still true)
have lain.
> inclusive. In the future, however, this range likely will not be
> sufficient. In anticipation of an increase of this range news client
> implementors SHOULD be able to deal with an article number range
> between 1 and 2^6[34]-1.
If it's a SHOULD, I'd be more inclined to write 2^64-1. Negative article
numbers don't make sense in the current model, so let's use up all the
bits.
[...]
> For a fair treatment of this subject, this should be done for any
> option. Basically the options are:
> * reset => I guess most of us agree that this is not a great thing to
> do since many clients will be confused about the articles they have
> read and not read and people would have at least to "re-read" their
> newsgroup.
> * wrap-around => Clients do not implement this hence for them it has the
> same effect as a reset.
Ah well. Leafnode's NNTP client, fetchnews, for one detects if the
article counter drops by more than a small amount and resets its
internal counter as well, assuming all articles are in the range 1 - N.
Date: and Message-ID: information from overview will make sure we're not
fetching stuff we've already seen or expired. So it's expecting "reset"
as a matter of the current implementation.
> * generate larger numbers (as soon as necessary) => in a couple of years
> (2 if someone uses Steve's broken server) "old" clients will start
> breaking. But IMHO, they had enough time to upgrade. In case their
> are too many of those around they should complain at their news
> provider who might reset the newsgroup if there are too many of "old"
> clients.
Software that uses a "long" type or similar has chances of simply
working with large numbers - recompiling code that uses the "unsigned
long" C/C++ type in a 64-bit compilation environment will magically fix
everything.
> * BIGNUM extension => Current clients won't be helped by it, how does it
> deal with current clients? "Old" clients won't be able to read any
> articles >2^32-1. A benefit is that they won't crash. I guess we
> have different opinions on the acceptability of this (ie
> likelihood/badness of this).
Has anyone brought forward a compelling reason for BIGNUM that outweighs
the implementation complexity? Otherwise this is likely to be boycotted
by NNTP software authors.
--
Matthias Andree
More information about the ietf-nntp
mailing list