In
<200212302116(_dot_)gBULGUDX015952(_at_)smtp5(_dot_)andrew(_dot_)cmu(_dot_)edu>
Lawrence Greenfield <leg+(_at_)andrew(_dot_)cmu(_dot_)edu> writes:
From: "Charles Lindsey" <chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk>
Date: Mon, 30 Dec 2002 14:50:09 GMT
[...]
Anyway, the Usefor list is the place to discuss these issues. All we are
concerned with here is whether my text covers the use of RFC 2047/2231
well enough.
I think a document that encourages people to send non-RFC 2822
messages as "message/rfc822" is well in scope here.
To quote from RFC 2046:
A media type of "message/rfc822" indicates that the body contains an
encapsulated message, with the syntax of an RFC 822 message.
^^^^^^^^^^^^^^^
...............
It should be noted that, despite the use of the numbers "822", a
"message/rfc822" entity isn't restricted to material in strict conformance
to RFC822, nor are the semantics of "message/rfc822" objects restricted to
the semantics defined in RFC822. More specifically, a "message/rfc822"
message could well be a News article or a MIME message.
If you want to update RFC 2822 to allow unencoded UTF-8 in headers, do
so. Don't try to slip it in the backdoor.
But I don't. The text I posted made it quite clear that, on the Email side
of the gateway, all UTF-8 would have been removed, by one means or
another,
from the headers of the article
from the headers of any contained message/rfc822
from the headers of any contained MIME body part
and that if a particular implementor chose not to do that, and thus
produced a non-compliant Email object, then that would be his risk and
responsibility.
--
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(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)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