[NNTP] Consensus?

[Clive D.W. Feather]

Thomas Gschwind said:
> C> The reason for keeping a limit is that it describes existing practice, and
> C> that's what our charter talks about. Recent discussion has shown that some
> C> existing practice uses signed int for this, so 2^31-1 is a genuine limit on
> C> those systems.
> 
> The problem I see with setting a limit means that the limit will be
> reached and as soon as the limit IS reached everybody WILL start
> implementing a different solution to the problem.  And then we can again
> catch up and document standard practice which would be painful.

Not if we start the work now. I have no objection to starting the work, but
we shouldn't hold up the base document because of it.

> K> there is a relatively simple solution which will push the 
> K> problem out far enough where most, if not all, of us on this list won't 
> K> have to worry about it.  ;)
> I could not agree any more with this.

I don't accept that just telling people to use 2^64-1 is a solution.
Existing clients *ARE NOT* going to be updated "just like that", and any
proper solution needs to work reasonably well with such clients.

This is not "a minor change" and I don't believe we can just sneak it into
the document without wider review.

> C> However, something like:
> C> 
> C>     While servers MUST NOT send article numbers greater than this limit,
> C>     client and server developers are advised to use internal structures
> C>     and datatypes capable of handling larger values in anticipation of
> C>     such a change.
> C> 
> C> might work.
> 
> This would be trade-off that I could easily live with.  Everybody
> capable of writing any client software will understand the hint.

Right. That gives us the breathing space we need.

> C> Finally, think how it actually would go into the wording.

> That's only a wording issue and surely can be fixed.

Yes, but I want to see real proposals.

>   News server implementors SHOULD be aware that if they generate
>   article numbers above 2^32-1, some news clients will break in an
>   unexpected manner.

I *really* don't think wording like this belongs in the document. "Break in
an unexpected manner" should be restricted to clients that violate a MUST.

>   Until "all" clients have been upgraded to handle
>   the larger article number range,

Which is when? IETF frowns on "flag days".

>   news server administrators should be
>   provided with a configuration option to have the article numbers
>   reset (within the newsgroup in question).

This would need expanding somewhat.

> For a fair treatment of this subject, this should be done for any
> option.

Agreed.

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

Right.

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

That's not interoperability.

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

BIGNUM is very similar to "generate larger numbers", except that it
provides defined behaviour for clients that haven't been upgraded.

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