Overview and Framework for Internationalized Email
RFC 4952
Document | Type |
RFC - Informational
(July 2007; Errata)
Obsoleted by RFC 6530
Updated by RFC 5336
|
|
---|---|---|---|
Authors | John Klensin , YangWoo Ko | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4952 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ted Hardie | ||
Send notices to | (None) |
Network Working Group J. Klensin Request for Comments: 4952 Category: Informational Y. Ko ICU July 2007 Overview and Framework for Internationalized Email Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. Klensin & Ko Informational [Page 1] RFC 4952 EAI Framework July 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Role of This Specification . . . . . . . . . . . . . . . . 3 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview of the Approach . . . . . . . . . . . . . . . . . . . 6 3. Document Plan . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview of Protocol Extensions and Changes . . . . . . . . . 7 4.1. SMTP Extension for Internationalized Email Address . . . . 7 4.2. Transmission of Email Header Fields in UTF-8 Encoding . . 8 4.3. Downgrading Mechanism for Backward Compatibility . . . . . 9 5. Downgrading before and after SMTP Transactions . . . . . . . . 10 5.1. Downgrading before or during Message Submission . . . . . 10 5.2. Downgrading or Other Processing After Final SMTP Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 11 6.2. Interaction with Delivery Notifications . . . . . . . . . 12 6.3. Use of Email Addresses as Identifiers . . . . . . . . . . 12 6.4. Encoded Words, Signed Messages, and Downgrading . . . . . 12 6.5. Other Uses of Local Parts . . . . . . . . . . . . . . . . 13 6.6. Non-Standard Encapsulation Formats . . . . . . . . . . . . 13 7. Experimental Targets . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 Klensin & Ko Informational [Page 2] RFC 4952 EAI Framework July 2007 1. Introduction In order to use internationalized email addresses, we need to internationalize both the domain part and the local part of email addresses. The domain part of email addresses is already internationalized [RFC3490], while the local part is not. Without the extensions specified in this document, the mailbox name is restricted to a subset of 7-bit ASCII [RFC2821]. Though MIME [RFC2045] enables the transport of non-ASCII data, it does not provide a mechanism for internationalized email addresses. In RFC 2047 [RFC2047], MIME defines an encoding mechanism for some specific message header fields to accommodate non-ASCII data. However, it does not permit the use of email addresses that include non-ASCII characters. Without the extensions defined here, or some equivalent set, the only way to incorporate non-ASCII characters in any part of email addresses is to use RFC 2047 coding to embed them in what RFC 2822 [RFC2822] calls the "display name" (known as a "name phrase" or by other terms elsewhere) of the relevant headers. Information coded into the display name is invisible in the message envelope and, for many purposes, is not part of the address at all. 1.1. Role of This Specification This document presents the overview and framework for an approach to the next stage of email internationalization. This new stageShow full document text