[Please note: This document is one a set of four interdependent
documents:
draft-ietf-eai-5738bisdraft-ietf-eai-popimap-downgradedraft-ietf-eai-rfc5721bisdraft-ietf-eai-simpledowngrade
These documents should be reviewed, evaluated, and understood
together.]
Technical Summary
These four EAI documents make up a set that are interdependent
and should be reviewed, evaluated, and understood together. Their
abstracts have been examined and verified to sufficiency to
describe the individual documents.
The abstract for this particular document reads:
This specification extends the Internet Message Access Protocol
version 4rev1 (IMAP4rev1) to support UTF-8 encoded
international characters in user names, mail addresses and
message headers. This specification replaces RFC 5738.
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
Note that Pete Resnick is listed as a co-author on this
document as a result of contributions well before he became AD
(and primarily to its the Experimental predecessor. He has not
been actively involved in an author or editor role since
joining the IESG.
RFC Editor Notes (late addition; sorry, IESG Secretary)
The document contains the pre-5378 disclaimer, but that isn't necessary; please
remove it.
Also, please add an informative reference to RFC 5530, and add a citation to it in
Section 6:
OLD
A server that
advertises "UTF8=ONLY" will reject with a "NO [CANNOT]" response any
command that might require UTF-8 support and is not preceded by an
"ENABLE UTF8=ACCEPT" command.
NEW
A server that
advertises "UTF8=ONLY" will reject with a "NO [CANNOT]" response [RFC5530]
any command that might require UTF-8 support and is not preceded by an
"ENABLE UTF8=ACCEPT" command.