[NNTP] Consensus?

[Thomas Gschwind]

On Wed, Aug 10, 2005 at 04:53:16PM +0100, Clive D.W. Feather wrote:
C> > For (1), the discussion has been wide-ranging enough that I'm not sure on
C> > (a).  I know some folks here would like the limit removed entirely, but I
C> > don't have a good feeling on what people think about 2^32-1 versus 2^31-1
C> > assuming that we keep a limit.  More discussion would be valuable there, I
C> > believe.
C> 
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.

On Thu, Aug 11, 2005 at 09:30:20AM -0400, Ken Murchison wrote:
K> Clive D.W. Feather wrote:
K> >It doesn't represent current practice, which is what we're supposed to be
K> >documenting.
K> 
K> True, but it sounds like current practice is all over the place (2^31, 
K> 2^32, 2^64), so we need to standardize on something.  Standardizing on 
K> something that we *know* will break in a few years doesn't seem like the 
K> best move when 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.

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.

On Thu, Aug 11, 2005 at 09:27:04AM +0100, Clive D.W. Feather wrote:
C> Russ Allbery said:
C> >> Personally I would like the wording changed to require (a MUST) 32 bit
C> >> support and suggest (a SHOULD) 64 bit support.
C> > That's two people supporting that option.  What does everyone else think
C> > about that?
C> 
C> I seriously don't like it.
C> 
C> It doesn't represent current practice, which is what we're supposed to be
C> documenting.
C> 
C> It introduces an interoperability issue. What happens if the server
C> supports the SHOULD and the client doesn't?

As long as no newsgroup has reached the 2^31-1 (or 32) limit nothing.
Afterwards, the client won't be able to read news and will be forced to
upgrade the news client (or switch to a different one).  While forced
upgrades are typically a bad idea, I think in this case it is acceptable
since
1) Clients have >> 2 years time to upgrade their software which should
   be enough time for people to upgrade (cannot be backwards compatible
   forever).
2) 2 years with Steve's scheme which I agree is broken since it breaks
   all kinds of assumptions made by news clients.
3) If too many clients are affected they will complain at their news
   service provider which
   a) will either change the software (ie throw out Steve's software)
   b) or reset the article numbering if they have a sane server that
      exceeded the high limit (which with the current draft would be the
      only option anyways).

C> Finally, think how it actually would go into the wording. To remind you,
C> this is what the text currently says:
C>    [...original deleted...]
C>    [...nonsense version deleted...]
C> because that's a nonsense. Do they mean the inverse?
C> 
C>    Article numbers MUST lie between 1 and 2^64-1 inclusive and SHOULD
C>    lie between 1 and 2^32-1 inclusive.

That's only a wording issue and surely can be fixed.  What about (please
feel free to tear it apart ;) so that we can fix any bugs)?

  Historically, article numbers lie in the range between 1 and 2^32-1
  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.
  
  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.  Until "all" clients have been upgraded to handle
  the larger article number range, news server administrators should be
  provided with a configuration option to have the article numbers
  reset (within the newsgroup in question).
  
C> What is the effect of breaching the SHOULD?
C> 
C> Let's see some actual wording proposals here, including addressing the
C> inter-operability issues when any SHOULD or MAY is breached.

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.
* 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.
* not accept new articles => not an option.
* 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).

Regards,
Thomas
-- 
Thomas Gschwind                      Email: thomasg at ieee.org
IBM Zurich Research Lab
Saeumerstrasse 4                     Tel: +41-1-724-8990
CH-8803 Rueschlikon, Switzerland     Fax: +41-1-724-8953