Simplified POP and IMAP Downgrading for Internationalized Email
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, eai mailing list <firstname.lastname@example.org>, eai chair <email@example.com> Subject: Protocol Action: 'Simplified POP/IMAP Downgrading for Internationalized Email' to Proposed Standard (draft-ietf-eai-simpledowngrade-07.txt) The IESG has approved the following document: - 'Simplified POP/IMAP Downgrading for Internationalized Email' (draft-ietf-eai-simpledowngrade-07.txt) as Proposed Standard This document is the product of the Email Address Internationalization Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-eai-simpledowngrade/
[Please note: This document is one a set of four interdependent documents: draft-ietf-eai-5738bis draft-ietf-eai-popimap-downgrade draft-ietf-eai-rfc5721bis draft-ietf-eai-simpledowngrade These documents should be reviewed, evaluated, and understood together.] Technical Summary This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement and provides only rudimentary results. Working Group Summary No particular process issues of note. The WG had extensive and constructive discussions about the role of "downgrading" (e.g., converting a message stored on the server that contains non-ASCII header or envelope information) in the transition to an all-i18n environment. Some of those issues and tradeoffs are discussed in draft-ietf-eai-popimap-downgrade and draft-ietf-eai-simpledowngrade. In some cases, the best strategy may be to "hide" those messages that cannot be delivered without change to legacy clients either with or without some attempt at an error message. A complete treatment of those options is impossible because the optimal strategies will depend considerably on local circumstances. Consequently the base IMAP and POP3 documents are no longer dependent on particular downgrading choices and that two methods presented are, to a considerable extent, just examples. They are recommended as alternative Standards Track documents because they are protocol specifications and their sometimes-subtle details have have been carefully worked out, even though the WG has no general recommendation to make between them (or other strategies). While opinions differ in the WG about which downgrading mechanisms are likely to see the most use, if any, consensus is strong that these four documents represent the correct output. Document Quality Some development and interoperability testing has occurred and is progressing. There are strong commitments in various countries to implement and deploy the EAI (more properly, SMTPUTF8) messages and functions specified in RFCs 6530 through 6533. Those messages will be inaccessible to many users without POP3 and IMAP support, so these specifications are quite likely to be implemented and deployed in a timely fashion. Reviewers who made particular contributions prior to IETF Last Call are acknowledged in the documents. See Section 3 for additional information. Personnel Document Shepherd: John C Klensin Responsible Area Director: Pete Resnick RFC Editor Notes: OLD (Section 1) containing internationalized messages, or even attempt to read NEW containing internationalized messages, or even attempts to read --- OLD (Section 1) proper support for [RFC5721] and/or [RFC5738]. NEW: proper support for [I-D.ietf-eai-rfc5721bis] and/or [I-D.ietf-eai-5738bis]. --- OLD (Section 2) encouraged to implement [RFC5738]. NEW encouraged to implement [I-D.ietf-eai-rfc5721bis] and/or [I-D.ietf-eai-5738bis]. --- OLD (Section 7) If the internationalized message uses any sort of signature, the synthetic message's signature almost certainly is invalid. This is a necessary limitation of displaying internationalized messages in conventional clients, since the client does not support internationalized addresses. NEW If the internationalized message uses any sort of signature that covers header fields, the synthetic message's signature almost certainly is invalid and may be invalid in other cases. This is a necessary limitation of displaying internationalized messages in legacy clients, since those clients do not support internationalized header fields. These cases are discussed in somewhat more detail in [I-D.ietf-eai-popimap-downgrade]. Even though invalid, these signatures should not be removed from the synthetic message, preserving as much of the information as possible from the original message. --- OLD (Section 9) [RFC5721] Gellens, R., and C. Newman, "POP3 Support for UTF-8", RFC 5721, February 2010. [RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8", RFC 5738, March 2010. NEW [I-D.ietf-eai-rfc5721bis] Gellens, R., Newman, C., Yao, J., and K. Fujiwara, "POP3 Support for UTF-8", draft-ietf-eai-rfc5721bis-08 (work in progress), October 2012. [I-D.ietf-eai-5738bis] Resnick, P., Newman, C., and S. Shen, "IMAP Support for UTF-8", draft-ietf-eai-5738bis-09 (work in progress), August 2012. [I-D.ietf-eai-popimap-downgrade] Fujiwara, K., "Post-delivery Message Downgrading for Internationalized Email Messages", draft-ietf-eai-popimap-downgrade-08 (work in progress), October 2012.