nntp at nntpserver.com
Sun Aug 14 03:23:38 PDT 2005
Charles Lindsey wrote:
> In <20050810120636.GE14499 at infosys.tuwien.ac.at> tom at infosys.tuwien.ac.at (Thomas Gschwind) writes:
>>What would be the problem with recommending a 64-bit counter? So far we
>>know there are some people having problems if we specified a 32-bit
> I can think of two problems.
> 1. After a while, the numbers typically used for articles will become
> excessively long. Any time one needs to look at one manually (which I do
This is a very poor reason to allow a complete break down of the
protocol. If this was a valid reason then why are Message-ID's,
which are hand typed much more often, allowed to be 500+ bytes
long. By the way, a 4 billing number and a 9 billion number have
the same length. Even adding one more digit allows for many more
years of life to the protocol.
> 2. Existing clients simply will not cope. And existing clients are not
> going to go away, and there will be howls of protest and accusations that
> the IETF has allowed a non-interooperable change to the basic protocol.
> Reason #1 may be simply elegance, but IMO #2 is a show stopper.
You keep forgetting that RFC977 was completely text based and did
not specify any binary limits. The current 32 bit limit is the
new non-interoperable change to the protocol. I would be happy
with just getting the new limit removed as any software that
really matters is already or will soon be 64 bit compatible.
While a 32 bit limit may have sounded reasonable 8 years ago, it
is not a reasonable limit today.
If you can justify breaking existing software and forcing
everything to use 32 bit binary numbers then you can just as
easily force everyone to use 64 bit numbers. There is no
difference with the exception that one of the choices (64 bit)
will actually solve a future problem.
More information about the ietf-nntp