Dave Crocker wrote:
As for I8N, I believe that doing more in the document requires some
rather compelling consensus among the community -- ie, you folk.
Proposed text, insert in chapter 6 between "Security" and "IANA":
Internationalization
The core email architecture is still based on US-ASCII headers in
message/rfc822 objects including any MIME part headers. Other
charsets and the indication of languages in headers require US ASCII
compatible MIME encodings as specified in RFC 2047 and RFC 2231.
Similar MIME content-transfer encodings allow to use other charsets
in message bodies, and to indicate any language, even for text/plain
bodies with a Content-Language header field as specified in RFC 3282
and RFC 4646, or similar techniques for other content types such as
text/html.
The 8BITMIME extension of SMTP [STD 10] allows to use many charsets
"as is" in message/rfc822 bodies without the overhead of a MIME
content transfer encoding.
Ongoing work on Email Address Internationalization (EAI) is expected
to introduce message/global objects allowing to use UTF-8 [STD 63]
in email addresses and message/global headers, see RFC 4952.
---
Missing references for this text: RFC 1869 (8BITMIME in STD 10, for
rebels ignoring 2821bis), RFC 4952 (EAI), RFC 4646 (language tags),
RFC 3282 (content-language), RFC 2231 (lang tags in header fields).
Frank