[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