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.