Subject: Re: [NNTP] Consensus?

From: Richard Clayton <[email-masked]>
Date: Sat, 13 Aug 2005 16:55:46 +0100

In message <[email-masked]>, Matthias
Andree <[email-masked]> writes

>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.

it allows software that is not bothering with recasting their database
format (and fixing up all possible parts of their code) to negotiate
with the server to correctly understand what the situation is -- and
thereby arrange to provide informative error messages : viz it permits
gracefulness, which is not to be sneezed at

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

---

From: Matthias Andree <[email-masked]>
Date: Sat, 13 Aug 2005 01:45:43 +0200

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).

-- 
Matthias Andree