Charles Lindsey wrote:
In <200212302116(_dot_)gBULGUDX015952(_at_)smtp5(_dot_)andrew(_dot_)cmu(_dot_)edu>
Lawrence Greenfield <leg+(_at_)andrew(_dot_)cmu(_dot_)edu> writes:
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.
It is insufficient to say "comply with 2822 / 2047 / 2231); there is
a design defect which prevents that, unless a specific mechanism is
provided to ensure compliance. As it stands,
1. it is impossible for a gateway to determine the syntax of an
experimental header which the gateway author is unaware of
2. Without header field syntax information, it is impossible to
encode non-ASCII "header" content.
The design defect can be eliminated by:
a. forbidding non-ASCII content in all but a well-defined set which
all gateways are required to recognize, *and* providing a practical
transition plan so that existing gateways can be upgraded while
ensuring that the mail protocols are not violated
or
b. simply using the RFC 822 / 2822 / 2047 / 2231 Internet text message
format, which avoids the encoding problem in gateways and adds no
new restrictions on gateway transformations (thereby obviating that
aspect of a transition plan).
or
c. require that unrecognized "headers" with non-ASCII content be elided
or moved to an encoded attachment.