From: Charles Lindsey (chl@cs.man.ac.uk)
Date: Thu Apr 24 2003 - 16:28:58 CDT
On Mon, 21 Apr 2003 13:28:24 -0400
Bruce Lilly <blilly@erols.com> said...
>
> 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.
Yes, but agents must not use that as an excuse to truncate lines that
are shorter. That requirement is aimed mainly at transports (which are
not going to look inside encoded-words anyway).
If a line longer than 76 octets and containing an encoded-word arrives
at some reading agent, it is still a valid line. The reading agent may
look at it, decide it is non-RFC-2047-compliant and decline to decode
it, but in that case it should still display it in its undecoded-form
(even RFC 2822 requires that behaviour).
>
> > 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).
Agreed.
>
> > 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).
But I don't see why it would be required to fold in such a way that
there was nothing on the first line - Dirk has explained how it can
always be folded in some suitable way.
Note that responsibility for enforcing this restriction lies with
posting agents. They MUST NOT generate them. If a subsequent agent sees
a violation, it is quite entitled to reject the article (though we do
say that it SHOULD accept it and pass it on).
>
> > 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.
Yes, that was a deliberate restriction wrt RFC 2822 (and it was a stupid
provision in RFC 2822). If keywords are useful for anything, it is for
indexing articles against them, and that gets just too complicated if
more than one Keywords header has to be looked at.
RFC 1036 is, as usual, a little vague on the matter, but it does seem
to imply that this header should occur only once. That is certainly
the case in son-of-1036. Does anyone know whether Keywords was first
invented as a News header, or as an Email header?
>
> > 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".
I think it is important that followup-agents should process Re: as we
have specified. However, some of the other stuff in that section might
be hived off into the #3 document. But remember that the purpose of my
memo was to document the _present_ state of our draft.
>
> > 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.
Yes, I should have said this applied only to structured headers, and I
have amended my copy of the text accordingly. But there are no other
incompatibilities because, as I said, it only applies to headers defined
for Netnews (and there are exceptions even there). And they are all
SHOULD NOT generate (yet) for existing headers, so no existing user
agent should have a problem.
But it is a useful feature to have for future expansibility, and I
hope it might be taken up by the Mail people one day (but would, of
course, take a long time to phase in). Which is why we say they SHOULD
be accepted in all headers.
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl@clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5