Email Address Internationalization (eai) Internet Drafts
| SMTP extension for internationalized email address | |||||||||||||||||
|
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952. | ||||||||||||||||
| Downgrading mechanism for Email Address Internationalization | |||||||||||||||||
|
Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid rejecting internationalized Email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. | ||||||||||||||||
| IMAP Support for UTF-8 | |||||||||||||||||
|
This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. This is an early draft and intended as a framework for discussion. Please do not deploy implementations of this draft. | ||||||||||||||||
| Internationalized Email Headers | |||||||||||||||||
|
Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. And this specification updates section 6.4 of [RFC2045] to conform with the requirements. | ||||||||||||||||
| POP3 Support for UTF-8 | |||||||||||||||||
|
This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. | ||||||||||||||||
| Internationalized Delivery Status and Disposition Notifications | |||||||||||||||||
|
Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing draft standard is presently limited to US-ASCII text in the machine readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document experimentally extends RFC 3461, RFC 3464 and RFC 3798. | ||||||||||||||||
 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
Email Address Internationalization (eai)
Last Modified: 2008-08-21
Additional information is available at tools.ietf.org/wg/eai
Chair(s):
Applications Area Director(s):
Applications Area Advisor:
Mailing Lists:
General Discussion: ima@ietf.orgTo Subscribe: https://www1.ietf.org/mailman/listinfo/ima
Archive: http://www1.ietf.org/mail-archive/web/ima/index.html
Description of Working Group:
Since early in the effort to internationalize domain names, whichresulted in the standards associated with IDNA, it has been
understood that internationalization of email address local parts is
required. At the same time, email address internationalization poses
a series of special problems. Constraints on the interpretation of
local-parts by any system other than the final delivery one make
address encoding nearly impossible. The need to use addresses in both
the email envelope and in header fields, and to do so in ways that are
at least compatible, suggests that this is not a simple and isolated
problem.
This working group will address one basic approach to email
internationalization. That approach is based on the use of an SMTP
extension to enable both the use of UTF-8 in envelope address local-
parts and optionally in domain-parts and the use of UTF-8 in mail
headers -- both in address contexts and wherever encoded-words are
permitted today. Its initial target will be a set of experimental
RFCs that specify the details of this approach and provide the basis
for generating and testing interoperable implementations. Its work
will include examining whether "downgrading" -- transforming an
internationalized message to one that is compatible with unextended
SMTP clients and servers and unextended MUAs -- is feasible and
appropriate and, if it is, specifying a way to do so. If it is not,
the WG will evaluate whether the effort is worth taking forward.
Other approaches may be considered by the formation of other
working groups.
Key parts of this effort include extended analyses and, if necessary,
proof of concept in three areas in addition to smooth operation when
all systems and components along a message path have been upgraded to
support the new facilities. They are
o Examination of scenarios for the appearance of these facilities to
users, including ways in which alternate addresses may be
specified if those are needed for downgrading.
o Examination of different locations at which downgrading might be
required and accomplished, differentiating between requirements
and capabilities at the point of origin (at or before the
submission server), those that exist while the message is in
transit, and those that apply after SMTP "final delivery" or in
the logical vicinity or an IMAP or POP server.
o Examination of the "mailing list question", i.e., how a mixture of
traditional and internationalized addresses on a mailing list will
impact message flows, error reports, and delivery notifications in
all plausible combinations of servers and addresses, including
internationalizated and traditional reverse paths.
Once the Experimental RFCs are completed and implemented, the
experience gathered will be evaluated. If the approach is found to
have been successful (using criteria the WG will establish as an
early work item), the WG will be rechartered to update the documents
for processing onto the standards track.
1.6. Deliverables
The following deliverables are foreseen in this charter. The WG
chairs may structure the deliverables into specific documents
or document sets as needed. Adding or removing documents
outside of these deliverables will require a charter update.
o Overview and architecture (Info)
o Interworking scenarios, including the "mailing list question"
(Info)
o SMTP extensions specification (Exp)
o Header format specification (Exp)
o Downgrading specification in SMTP (Exp)
o Downgrading specification in POP servers (Exp)
o Downgrading specificatio
n in IMAP servers (Exp)
o Results and evaluation of experiment (Info)
Going forward, it is possible that the SMTP downgrading specification
will go for Informational due to the difficulty of fully specifying
all necessary behavior.
Additional possible documents suggested:
Advice for MUA implementors (Info)
Goals and Milestones:
| Done | Overview/architecture draft first | |
| Done | Interworking scenarios first draft | |
| Done | SMTP Extensions first draft | |
| Done | Header format first draft | |
| Done | Downgrading in IMAP first draft | |
| Done | Downgrading in SMTP first draft | |
| Jun 2006 | Overview/architecture draft to IESG | |
| Jun 2006 | Interworking scenarios to IESG | |
| Done | Downgrading in POP first draft | |
| Sep 2006 | SMTP Extensions to IESG | |
| Sep 2006 | Header format to IESG | |
| Sep 2006 | Downgrading in SMTP to IESG | |
| Sep 2006 | Downgrading in POP to IESG | |
| Sep 2006 | Downgrading in IMAP to IESG | |
| Dec 2006 | Results and evaluation first draft | |
| Mar 2007 | Results and evaluation to IESG | |
| Mar 2007 | Group recharter for standards track |
Internet-Drafts:
SMTP extension for internationalized email address (55798 bytes)Downgrading mechanism for Email Address Internationalization (48499 bytes)
IMAP Support for UTF-8 (30874 bytes)
Internationalized Email Headers (33300 bytes)
POP3 Support for UTF-8 (24834 bytes)
Internationalized Delivery Status and Disposition Notifications (39496 bytes)
Request For Comments:
Overview and Framework for Internationalized Email (RFC 4952) (48409 bytes)IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.
Return to working group directory. 
