Henry Spencer wrote:
On Mon, 24 Feb 2003, Mark Crispin wrote:
I observe that wherever message-ids are used, they are inside a <> bracket
pair. It is possible to define this as a quoting rule which would allow
embedded spaces.
Either way, this doesn't belong in the header format specification. It
belongs in the NNTP specification, and a "best common practices" type
document.
This contention utterly baffles me. Please explain.
Mark can certainly speak for himself, but my interpretation of
what he wrote is that NNTP could choose to use the bracketing
as a way around the lack of general quoting for command
parameters to work around the specific case of a backslash-
quoted space inside a no-fold-quote in a msg-id. Of course,
then there would be \> to deal with... It would have been
nice if a quoting mechanism had been part of the NNTP protocol,
but it wasn't and isn't so here we are, trying to work around
that omission.
The length limitation of 250
I don't particularly worry about this, although as a practical header
format limitation it belongs an a "best common practices" type document
rather than the header format document itself.
Sorry, this is flatly proposterous. Again, it's a major interoperability
matter, not just a "good practice" issue: news systems will very probably
be unable to exchange news successfully if it is violated.
I wouldn't want to see the issue put in a separate document.
It is part and parcel of the definition of a msg-id, and we
have all suffered from the bit-of-specification-here,
another-bit-there that led to the consolidation that became
2822. If somebody wants to put forward the proposition that
things were better with the message format specification
spread through a dozen or more documents, some contradicting
others...
And certainly the definition of msg-id -- including any length
limit -- should apply uniformly with one possible exception.
I.e. It should apply not only to Message-ID, but also to
Resent-Message-ID, References, Supersedes, and In-Reply-To
for obvious reasons. [and to MDN Original-Message-ID, but that's
not a header field] The one possible exception is in Received
fields, where one option for the id is a msg-id, but that's
not reused in any of the other fields mentioned. If there's
a pressing need to exempt Received, its syntax could use a
production which does not have a length restriction.
The contention that "news and mail are the same" starts to sound odd when
major interoperability issues for news are casually brushed off as being
of no importance and not meriting mention in a standard, but detailed
foibles of mail like the 7-bit restriction are expected to be considered
sacrosanct. One gets the distinct impression that "news and mail are the
same" is being used to mean "so news's problems are of no importance".
I'm not brushing off the issue, nor am I claiming that it is
of no importance, so I feel no need to defend those particular
straw men. But I would point out that none of RFCs 822, 850,
or 1036 mentioned any sort of message-id upper length limit;
indeed both 850 and 1036 caution against assumptions of a bound
on the length. So it appears that we are now considering
introducing a formal limit lower than the inherent limit of
997 octets because those explicit cautions were disregarded.
OK, let's not fix the blame, let's fix the problem.
By analogy, it would seem a fine idea to move mail's 7-bit restriction
into a BCP. Do you agree? If not, why not? Surely such an antiquated
and mail-specific limitation doesn't belong in "the header format
specification".
Bad analogy. In the first place, the restriction didn't come
about because an explicit caution was disregarded; it is part
of the history and nature of the beast. In the second
place, most of what appears in header fields consists of
protocol elements, and RFC 1958 is quite clear that those
should be in ASCII (actually it says case-independent ASCII).
In the third place, if your contention is that syntax issues
affecting interoperability belong in the format specification
(and I agree), then surely the restriction is appropriate
where it is. In the fourth place, the restriction is not
mail-specific per se; it resulted from the origins of
messaging in telnet and ftp, and the protocol elements
themselves (e.g. domain names), which are widely used in
contexts other than mail, are limited to a subset of ASCII.