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
