Spam:****, [NNTP] Thoughts on article number resetting/rollover

[Steve Walker]

Ken Murchison wrote:

> The whole discussion of the 2^32 limit for article numbers and 
> rollover got me thinking a little.  Rolling the numbers over is really 
> no different than if the server unilaterally resets the article 
> numbers for some reason (server crash, software change/upgrade).  
> Obviously admins try to avoid this at all cost, but I'm sure it 
> happens.  In either case, the server should have some mechanism to 
> tell the client that the article numbers have changed, and that any 
> cached data that it has is invalid.

The wording in the current proposal expressly forbids reseting the 
article numbers....

>6. The final type of key is the arrival timestamp, giving the time that
>   the article arrived at the server.  The server MUST ensure that
>   article numbers are issued in order of arrival timestamp; that is,
>   articles arriving later MUST have higher numbers than those that
>   arrive earlier.  The server SHOULD allocate the next sequential
>   unused number to each new article.

Any reset or wrapping is a violation of the MUST above.  This is why I said
this RFC is completely broken.  People are forced to violate it in one 
way or the other.

>   Article numbers MUST lie between 1 and 4,294,967,295 inclusive.  The
>   client and server MAY use leading zeros in specifying article
>   numbers, but MUST NOT use more than 16 digits.  In some situations,
>   the value zero replaces an article number to show some special
>   situation.

The two MUST's together cause a deadlock.

Personally I really can't see why anyone would have a problem with just 
changing the limit above to 2^64-1. It doesn't break anything that 
wasn't already going to eventually be break and it allows everyone the 
chance to prepare for the future.

Clive ask for wording so here goes:

>   Software MUST be able to correctly process article numbers between 1 and 
>   4,294,967,295 inclusive and SHOULD be capable of processing article 
>   numbers up to 2^64-1.  The client and server MAY use leading zeros 
>   in specifying article numbers, but MUST NOT use more than 20 digits.
>   In some situations, the value zero replaces an article number to show 
>   some special situation.

If anyone is really worried about detecting if a server is using 64 bit 
numbers you could add something like
this so a client knows as soon as it issues a GROUP command if the range 
is beyond it's capabilities.

 > Clients that convert article numbers into internal binary data should 
use 64 bit unsigned
 > integers if the server returns any zero padded article number or 
range component with a
 > length greater than 16 octets and less than or equal to 20 octets.
 >
 > Servers that offer articles with numbers greater than 2^32-1 MUST 
zero pad all
 > article numbers or ranges in command responses to a total  length 
greater than 16 octets
 > and less than or equal to 20 octets.

A 32 bit client still can't read 64 bit article numbers, but at least 
one person seem concerned
that a client would not know if their internal binary conversion was 
invalid.  I personally think a
good atoi function that returned MAXINT as an overflow error would be 
simpler.

Steve Walker