Document Action: 'IMAP Support for UTF-8' to Experimental RFC

[The IESG <[e-mail]>]

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.