From: Bruce Lilly (blilly@erols.com)
Date: Mon Apr 21 2003 - 12:28:24 CDT
Charles Lindsey wrote:
> The following summary shows all the differences between the usages in
> RFC 2822 and in Usefor, as they stand in the current draft.
[...]
> 1.5 Body lines are restricted to 998 characters plus CRLF (as in RFC
> 2822). However, all agents SHOULD, and relaying agents MUST, process
> lines of arbitrary length.
MIME requires that any header line containing an encoded-word be no longer
than 76 octets.
[...]
> 1.10 BUG. We probabl;y should accept the (mis-named) "obsolete" syntax for
> phrase from RFC 2822 which allows for 'John D. Smith' to remain
> unquoted.
Note, however, that that MUST NOT be generated (at this time).
[...]
> 2. Differences enforced by verbiage.
> ------------------------------------
[...]
> 2.3 The content of the first line of a header MUST NOT consist of WSP only
> (though such SHOULD be accepted). Observe that continuation lines
> of headers also MUST NOT consist of WSP only, as in RFC 2822.
The first part of that may be a problem (see above and below re. encoded-words -- it
may be necessary to fold).
> 2.5 All agents MUST support header lines up to 998. The limit of 79
> characters (as opposed to 78 in RFC 2822) is purely advisory - there
> is no SHOULD about it.
As noted above, lines containing encoded-words MUST NOT be longer than 76 octets.
> 2.7 There must not be more than one header with a given header-name,
> except where explicitly sanctioned by the appropriate standard. In
> particular, there MUST NOT be more than one Keywords-header.
But multiple Keywords fields are "explicitly sanctioned by" RFC 2822.
> 2.10 A Subject-header MUST NOT begin with "Re: Re: ".
I think we should avoid the Subject hacks entirely. Subject is supposed
to be an unstructured field. Once one starts saying things like (in some
circumstances) the field body MUST begin with "Re: " and/or it MUST NOT
begin with "Re: Re: ", it's no longer unstructured. Ditto for "cmsg".
> 3. Rules specific to Netnews headers.
> -------------------------------------
>
> 3.1 All headers have MIME-style extension-parameters, with x-attributes
> or to be defined in future standards. Some have explicit parameters
> defined in this standard. However, this does not apply to headers
> which are taken from RFC 2822 or other mail standards, nor to the
> Mail-Copies-To, Complaints-to and Supersedes-header defined in this
> standard. Nevertheless, such parameters SHOULD be recognized (and
> ignored) in all headers.
[...]
> 3.3.1 MIME-style parameters in headers defined prior to this standard.
No, we've had this discussion before. One cannot have parameters with *any*
unstructured field (e.g. Organization), and there may well be other cases
where the syntax is incompatible. "MIME-style parameters" only make sense
for MIME and MIME extension fields; they are currently only used with
Content-Type (a MIME field) and Content-Disposition (a MIME extension field).
Moreover, as header fields defined elsewhere which do not permit such
parameters (e.g. Date) are never generated with such parameters, it is
unreasonable to require every agent to be able to accept them. It is
impossible for any agent to do so for any unstructured field.