From: Ralph Babel (rbabel@babylon.pfm-mainz.de)
Date: Fri Jun 23 2000 - 10:04:32 CDT
Russ Allbery wrote:
> Dirk Nimmich wrote:
>
>> <sarcasm>
>> Yeah, and we'll change that limit if NNTP or any other
>> "default" transport mechanism changes it, don't we? And
>> of course we know about any other transport protocol for
>> usenet messages and can propose limits that match all of
>> them. Changes are easy, since this working group is now
>> doing only three years without any result being even
>> near an RFC.
>> </sarcasm>
>
> The main reason why I think it's reasonable to limit the
> size of a message ID is that there really is no earthly
> reason to generate a message ID longer than 70-odd
> characters. You can easily create a message ID that will
> be forever unique within that constraint. Given that, a
> limit of 250 characters seems perfectly reasonable to me
> and a limit of 497 characters is more than generous.
>
> Anything generating >250 character message IDs on a
> regular basis would be seriously annoying, bloating
> overview databases and article headers badly.
Russ, I think that you - and many others on this list -
are missing the point of Dirk's message. While we probably
all agree that short IDs are desirable and that the limits
need to be _documented_ somehow, these limits are _not_
an intrinsic part of the netnews message _format_ - which,
after all and contrary to popular belief, is still what
we're working on.
Not NNTP. Not INN. Not Usenet.
(Yes, "USEFOR" is a misnomer.)
If, however, we are going to _define_ an artificial limit
in the _format_ spec itself, how can the transport layer (or
other layers or particular implementations thereof) ever get
rid of _their_ artificial limits?
Take, for instance, the maximum length of a "line" in the
message body. Even though there's a well-known NNTP limit,
it is completely pointless to define one in the _format_
spec as well. If we did (we used to; maybe we still do; I
haven't checked the most recent draft; IMO, 1036ter is bound
to be ignored anyway for the political junk it contains),
implementors of the transport layer will keep dragging their
feet and (rightfully) claim that the underlying _format_
doesn't require support for pure binary articles anyway.
What's worse: by defining a limit of 998 characters, we are
basically _outlawing_ "Content-Transfer-Encoding: binary"
for news, even for environments that are not making use of
NNTP.
Therefore: no artificial limits, restrictions, policies etc.
in the base standard (i.e. netnews article _format_). Once
we've defined that, let's write another RFC - a BCP - to
_document_ current limits. (Of course, some participants in
this group may find it much more exciting to _impose_ such
limits themselves instead of "merely" documenting them.)
This should also help us speed up our current work.
So, to cut a long story short: yes, the length
of a message ID _is_ an interoperability issue.
But not ours.