chl at clerew.man.ac.uk
Sat Aug 13 14:14:25 PDT 2005
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
occasionally, as when I look at some Xref header and them go find the
article in some group), then I have to transcribe a huge number. Huge
numbers are clumsy, and should only be used where there is a need to
distinguish that many objects at one time - but who has a news spool that
actually contains of the order of 2^32 articles, or even has a group where
the high and low water marks differ by that sort of amount? In fact, the
number of articles stored at any one time is many orders of magnitude less
Yes, this is an appeal to elegance, and I suppose elegance was lost when
article numbers were invented in the first place - but there we are.
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.
So the proper way forward is to leave it as it is, and then embark on a
reasoned discussion of alternatives. If we ask the IETF nicely, and point
out that there is an issue which needs resolution in the next few years,
then I am sure they will permit us to recharter so as to start immediate
work on what should be a fairly small extension.
Ideally, what we want is a solution that allows existing clients to
continue in use indefinitely. That means a solution with two propoerties:
a) When the problem hits, clients that are aware of our extension will
recognise "it" (whatever "it" is) and will do the "right thing".
b) Existing clients will require some manual attention. If we design it
carefully, the action needed will be no more than unsubscribing from the
group and resubscribing to it. That is a thing even the most naive of
users can probably manage to do (more sophisticated users can try manual
editing of their .newsrc files, or other such hacks).
I note that various interesting ideas are now being floated. They will
take time to evaluate, and time is what we do not have at the moment.
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
More information about the ietf-nntp