From: Bruce Lilly (blilly@erols.com)
Date: Sat Jul 03 2004 - 10:14:56 CDT
John Stanley wrote:
> Henry Spencer (henry@spsystems.net):
>
>
>>We don't want to
>>sanction its continuing use -- it *is* a botch -- but forbidding Subject
>>content to begin with "cmsg " is desirable.
>
>
> We have already banned a news agent from treating an article as a control
> article just because its subject starts with "cmsg". What possible reason
> do we need to ban that string from subjects? Oh, I remember, to protect
> broken software from needing to be replaced with something that functions
> up to spec.
>
> Sorry to interrupt. Protecting bad software is the goal. My bad for
> forgetting.
An important distinction needs to be made; we're not talking about "bad
software" -- the software in question is doing exactly what RFC 1036 says
it should do. The issue is bad protocol design; RFC 1036 shouldn't have
attempted to overload protocol content on an unstructured field reserved
for only human-readable content. We're in agreement that the 1036 design
was bad, and that we wish to reverse it. The issue is how to go about
doing so while recognizing the existence of good-faith implementations
deployed in the field.
Once again, I think Mark Crispin was on the right track; we can deal with
this in an implementation considerations section:
"Some implementations based on RFC 1036 interpret a a Subject field
containing the string 'cmsg ' following whitespace at the beginning
of the field body interpret such a message as a control message.
Implementors may prevent such interpretation by encoding the string
'cmsg ' using the methods specified in [RFC 2047]."
That provides a mechanism to prevent misinterpretation (according to
the new regime) without unduly placing restrictions on (human-generated)
unstructured field content.