Protocol Action: 'Simplified POP/IMAP Downgrading for Internationalized Email' to Proposed Standard (draft-ietf-eai-simpledowngrade-07.txt)
The IESG <iesg-secretary <at> ietf.org>
2012-11-21 19:33:04 GMT
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.
RSS Feed