cmsg (again)

From: Bruce Lilly (blilly@erols.com)
Date: Mon Jun 28 2004 - 19:44:27 CDT


Frank Ellermann wrote:

> I've already named one "real" news server (news.t-online.de),
> where "Subject: cmsg cancel" works (or at least it did that
> the last time I tested it, about 2002)

Yes, it's hard-coded into some news software. But it is generally
regarded as a disaster for various reasons, it is never necessary
"Control: ..." always suffices, and it has long since disappeared
from our draft. Now, certainly there are issues (e.g. how to get
from RFC 1036's "must treat it as a control message" to the desired
case "MUST NOT treat it as a control message"), but I don't think
there's much desire here to turn back the clock. Indeed, it was once
proposed (June 17, 1997 by Simon Lyall) to forbid Subject field
bodies starting with "cmsg " (further expounded by Ian Davis on
June 30, 1997, and subsequently). A poll on various topics
including "cmsg " support was taken several years ago; results are
reported in a May 3, 2001 message posted to this WG's mailing
list by Jonathan Grobe -- all, repeat *all* persons expressing
an opinion on the matter voted in favor of not treating "cmsg "
as a control message. There was no, repeat *no* support for
continued treatment as a control message. If that's what you're
proposing, a) it's a bit late, that decision has already been made,
and b) you're unlikely to find much support.

Now if you want to discuss the issue of how to gracefully get from
1036 to where we have generally agreed that we want to go w.r.t.
"cmsg ", that's another matter.

> In some cases like the Web interface to this list there are
> either no References: and no In-Reply-To:, or the latter may
> be present but wrong (that's a bug in the Web interface).

I have never seen a good implementation of mailing list to WWW
translation; there is always something botched. I'm not sure
if any In-Reply-To issues you're seeing are symptoms of that
general malady or something else -- I've seen botched fields
due to broken UA software used by contributors to this mailing
list. But that's yet another matter.

> In these cases a "Subject: Re: topic" is the last hope for
> any kind of threading.

It isn't any kind of threading -- at best it's sorting, and "Re: "
and other embellishments only make that more difficult than would
be the case without those embellishments.

> That's like "quasi-pregnant". It worked in RfC 1036 before
> MIME, because then the difference wasn't very important, and
> a formal BNF definition was a waste of time.

Note that in every relevant RFC where Subject is defined (with
the possible exception of RFC 680, which isn't on line), there
*has* been BNF, EBNF, or ABNF accompanying the definition -- right
back to RFC 561 where it was first defined more than 30 years ago.
RFC 561 predated MIME by quite a large margin, as did RFCs 724,
733, and 822. So your argument about MIME vs. BNF simply doesn't
hold water.

> But today
> structured vs. unstructured is a major difference

It has been a major difference since at least RFC 724 (probably
680); structured fields (except where explicitly prohibited) can
have parenthesized comments, whereas that is not the case for
unstructured fields (precisely because they *are* unstructured).
That was certainly the case in RFC 822, which discusses comments
and related structural issues at great length, and RFCs 850 and
1036 also discuss comments. So there has been no major change
regarding structured vs. unstructured -- another argument that
holds no water.

> Oops, this follow-up bounces at the gateway. That's stupid.
> And it's not the problem of the gateway

It's one of many problems caused by trying to overload Control
message semantics and structure on an unstructured field. A
problem that we are trying to rectify.




This archive was generated by hypermail 2.1.7.