From: Bruce Lilly (blilly@erols.com)
Date: Mon Jun 28 2004 - 18:51:50 CDT
Frank Ellermann wrote:
> Bruce Lilly wrote:
>
>
>>Given the fact that the Subject field is unstructured
>
>
> RfC 1036 clearly defines a structure:
RFC 1036 has no authority to [re]define the Structure field. It is
defined in RFC 822 (and its predecessors and successor), and was
specifically adopted by RFCs 850 and 1036 to replace "Title". And
both 850 and 1036 clearly state that in cases of conflict, 822 is
deemed to be authoritative and 850 and 1036 are deemed to be in error.
So even if 1036 had attempted to define structure, such a definition
would be null and void.
> | Also for upward compatibility, if the first 4 characters of the
> | "Subject:" line are "cmsg", the rest of the "Subject:" line should
> | be interpreted as a control message.
You may note that that has been dropped from the usefor-draft.
> | If the message is submitted in response to another message
> | (e.g., is a follow-up) the default subject should begin with
> | the four characters "Re:", and the "References" line is required.
"the default subject should" is hardly a definition. It appears to
be a mere suggestion for reading agents preparing followups. As
opposed to the References field, which is clearly indicated as a
requirement.
> MIME-encoding of unstructured headers differs from a similar
> encoding of structured headers
Yes.
> For the same reason you can't encode a Subject: cmsg whatever,
> and in "Subject: Re: text" you can only encode the text but
> not the "Re: ".
Since the Subject field is defined formally as an unstructured field
(and always has been so defined, even before Usenet adopted its use),
any text in the field may be encoded according to the rules laid out
in RFC 2047.