[NNTP] Article number wording

[Steve Walker]

Clive D.W. Feather wrote:

>Firstly, I believe we *MUST* get this document out without any more delays.
>It is ridiculous how long it has taken already. If major changes are
>needed, we can address them in the next review cycle.
>
>  
>
There isn't time.  People will be pushing >32 bit number before V3 could 
be released.  V2 is the perfect time to fix it before it happens.  Any 
more delays and it will be too late. Why push something forward knowing 
it has a major flaw what will prevent many people from using this 
proposed standard.  You are also adding wording that will require many 
clients to choose from downgrading to 31/32 bits or not be compliant.  
Keep in mind that there are 64 bit clients in use today.

>Thirdly, I do actually sympathise with those who want something done. When
>we agreed that wording 8 or so years ago, we decided that the 32 bit limit
>would be hit rarely enough that local "flag days" would be acceptable. Had
>  
>

That "flag day" is forbidden by the new proposal.  It explicitly forbids 
rolling over.

>this topic been raised a year ago, I would have been very much in favour of
>solving it before publication (given we were waiting on plenty of other
>things). But it's been dormant for many years; now is not the time. This is
>*not* the same as saying "never fix it".
>  
>
Waiting until it's too late to avoid a problem is not the correct way to 
release a new RFC.

>Fourthly, it isn't "a simple matter of programming", as Ken implies with:
>  
>
>>If I change my server to use 64-bits today (actually it might be
>>already, I'd have to look), its not going to break any existing clients,
>>    
>>
>
>What you'll be left with is a problem waiting to happen *silently*, as old
>clients that thought they conformed suddenly run into servers that use
>large numbers. Or vice versa (though that's rather less likely).
>
>  
>
Leaving the new 32 bit limit will certainly break much more.  Servers 
have no choice but to either roll over or exceed 64 bits.  You can't 
make both a MUST NOT and expect it to work knowing that it will happen.

>Fifthly, when we worked on the text originally, nobody noted the signed
>versus unsigned problem. The limit we have in the text is 2^32-1 (spelled
>out, of course). Should this be changed to 2^31-1 before publication
>(presuming it's acceptable as a minor change)?
>
>  
>
Programmers will always do the minimum required to get the job done.  
That is why we now have 31, 32, 63 and 64 bit clients/servers.  Changing 
the wording to 64 bits is the least likely to cause major problems.

>I don't think this helps. A maximally portable server will have to limit
>itself to 2^31-1. Better to find a way for the two parties to negotiate the
>maximum they can cope with and have a defined way to deal with overflow. An
>extension is then the right way to do it.
>
>  
>
How does negotiating solve anything other than the client knows it won't 
work.  It won't make anything work that wouldn't have already worked.  
Servers that exceed 31 bits will have problems with broken clients, but 
it's the clients that need fixed.  We should not re-write 977 to the 
lowest common denominator knowing that it will break good software. No 
matter what is done many clients will have to be fixed.  Why not really 
fix them instead of just adding a one/two year band-aid.

Steve.