IMAP Support for UTF-8
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, eai mailing list <firstname.lastname@example.org>, eai chair <email@example.com> Subject: Document Action: 'IMAP Support for UTF-8' to Experimental RFC The IESG has approved the following document: - 'IMAP Support for UTF-8 ' <draft-ietf-eai-imap-utf8-09.txt> as an Experimental RFC This document is the product of the Email Address Internationalization Working Group. The IESG contact persons are Alexey Melnikov and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-imap-utf8-09.txt
Technical Summary This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. Working Group Summary The WG has consensus on the mechanisms described in this document. Document Quality Alexey Melnikov has reviewed this document most carefully before he became AD. One implementation of the document is known. Personnel Harald Alvestrand is the document shepherd. Alexey Melnikov is the Responsible Area Director. RFC Editor Note In Section 2, the last sentence: OLD: This specification creates five new IMAP capabilities to allow servers to advertise these new extensions, along with two new IMAP list ^^^^ extensions and a new IMAP list return option. NEW: This specification creates five new IMAP capabilities to allow servers to advertise these new extensions, along with two new IMAP LIST selection ^^^^^^^^^^^^^^ options and a new IMAP list return option. ^^^^^^^ In Section 3, 2nd paragraph, the last 2 sentences: OLD: (Note that the "UTF8=ONLY" capability described in Section 7 implies the "UTF8=ACCEPT" capability. See additional information in that section.) NEW: (Note that the "UTF8=ONLY" capability described in Section 7 and the "UTF8=ALL" capability described in Section 6 imply the "UTF8=ACCEPT" capability. See additional information in these sections.) Section 3.1., paragraph 7: > would be the same as if other syntacticly valid but semantically Nit: s/syntacticly/syntactically/ Section 3.4., paragraph 1: > "LIST-EXTENEDED" [RFC5258] capability, the server MUST support the Nit: s/"LIST-EXTENEDED"/"LIST-EXTENDED"/ In Section 5, please change the last sentence to read: OLD: The server MUST reject UTF-8 which fails to comply with the formal syntax in RFC 3629 [RFC3629]. NEW: The server MUST reject UTF-8 which fails to comply with the formal syntax in RFC 3629 [RFC3629] or if it encounters a Unicode characters listed in section 2.3 of SASLprep [RFC4013]. In Section 6 add another paragraph to the end: NEW: Note that the "UTF8=ALL" capability implies the "UTF8=ACCEPT" capability. In Section 8, change the last sentence of the 3rd paragraph to read: OLD: Other widely deployed MIME charsets SHOULD be supported. NEW: If the server supports other charsets in IMAP SEARCH or IMAP CONVERT [RFC5259], it SHOULD also support those charsets in this conversion. and also add [RFC5259] to the list of Normative References. Add a new Appendix B "Examples demonstrating relationships between UTF8= capabilities": UTF8=ACCEPT UTF8=USER UTF8=APPEND UTF8=ACCEPT UTF8=ALL UTF8=ALL ; Note, same as above UTF8=ACCEPT UTF8=USER UTF8=APPEND UTF8=ALL UTF8=ONLY UTF8=USER UTF8=ONLY ; Note, same as above In the IANA Considerations section please replace "RFC XXXX" with the RFC number of this document.