[NNTP] Article number wording

Ruud H.G. van Tol rvtol at isolution.nl
Fri Jul 29 16:05:17 PDT 2005


Russ Allbery:
> Ruud H G van Tol:
>> Russ Allbery:

>>> [article numbers, limits]
>>> It's not acceptable to leave it unspecified.  RFC 977 was deficient
>>> in this regard.  Whatever we do, we have to be clear and specific
>>> about it; that's the whole point of a standard.
>
>> I would just mention in a side-note that in 2005 it is no longer
>> good to have a limit in the software that is less than 2^64, and
>> that any limit will be proven too small some time.
>
> Making this statement specifically about article numbers is a valid,
> or at least arguable, point.

Yes, that was mainly how I meant it.


> The statement as you made it, as a
> general statement about all standards, makes no sense to me.  The
> above would argue, for example, that Unicode is not an acceptable
> standard because it has a 2^32 bit limit on the code space, when so
> far as I can tell pretty much everyone involved in character set
> issues believes that will be sufficient for the forseeable future.

Unicode escapes 2^32 with a mechanism for modifying character shape,
such as combining diacritical marks. The result does not need to have a
codepoint as a precomposed character. And who knows how many other
writing systems there are in the universe, so a better name for it is
Terracode.

Maybe it is the moment to give article number 2^32 a special meaning.
;)


> In other words, it depends on what the limit is for and how much
> utility is gained by having a limit.

I agree.


>> [charter]
>> The first concern of this working group shall be for the
>> interoperability of the various NNTP implementations, and therefore
>> for clear and explicit specification of the protocol. It is very
>> important that we document the existing situation before taking up
>> any new work.
>
> Article number handling falls into point 1, and the caveats in the
> final paragraph applies.  I think the first sentence of the last
> paragraph makes it clear (in reference to other messages in this
> thread) why leaving the limit unspecified is not acceptable.  (Which
> is not the same thing as specifying that there is no limit -- that
> solution may have other problems, but it would be clear and explicit.)

I would specify that there is no limit in the standard, but that 2^31
and 2^32 (actually 2^31-1 and 2^32-1) have been (and still are)
practical limits in a lot of existing software, and that it is time to
move on to at least support of 2^64-1.

-- 
Grtz, Ruud




More information about the ietf-nntp mailing list