Downgrading Mechanism for Email Address Internationalization
RFC 5504
Document | Type |
RFC - Experimental
(March 2009; No errata)
Obsoleted by RFC 6530
|
|
---|---|---|---|
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text pdf html bibtex | ||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5504 (Experimental) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Chris Newman | ||
Send notices to | (None) |
Network Working Group K. Fujiwara, Ed. Request for Comments: 5504 Y. Yoneya, Ed. Category: Experimental JPRS March 2009 Downgrading Mechanism for Email Address Internationalization Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract 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. Fujiwara & Yoneya Experimental [Page 1] RFC 5504 UTF8SMTP Downgrade March 2009 Table of Contents 1. Introduction ....................................................3 2. Terminology .....................................................4 3. New Header Fields Definition ....................................5 3.1. Envelope Information Preservation Header Fields ............5 3.2. Address Header Fields' Preservation Header Fields ..........6 3.3. Unknown Header Fields' Preservation Header Fields ..........6 4. SMTP Downgrading ................................................7 4.1. Path Element Downgrading ...................................7 4.2. ORCPT downgrading ..........................................8 5. Email Header Fields Downgrading .................................8 5.1. Downgrading Method for Each ABNF Element ...................8 5.1.1. RECEIVED Downgrading ................................9 5.1.2. UNSTRUCTURED Downgrading ............................9 5.1.3. WORD Downgrading ....................................9 5.1.4. COMMENT Downgrading .................................9 5.1.5. MIME-VALUE Downgrading ..............................9 5.1.6. DISPLAY-NAME Downgrading ............................9 5.1.7. MAILBOX Downgrading .................................9 5.1.8. ENCAPSULATION Downgrading ..........................10 5.1.9. TYPED-ADDRESS Downgrading ..........................10 5.2. Downgrading Method for Each Header Field ..................10 5.2.1. Address Header Fields That Contain <address>s ......10 5.2.2. Address Header Fields with Typed Addresses .........11 5.2.3. Downgrading Non-ASCII in Comments ..................11 5.2.4. Received Header Field ..............................11 5.2.5. MIME Content Header Fields .........................12 5.2.6. Non-ASCII in <unstructured> ........................12 5.2.7. Non-ASCII in <phrase> ..............................12 5.2.8. Other Header Fields ................................12 6. MIME Body-Part Header Field Downgrading ........................12 7. Security Considerations ........................................13 8. Implementation Notes ...........................................14 8.1. RFC 2047 Encoding .........................................14 8.2. Trivial Downgrading .......................................15 8.3. 7bit Transport Consideration ..............................15 9. IANA Considerations ............................................16 10. Acknowledgements ..............................................18 11. References ....................................................18 11.1. Normative References .....................................18 11.2. Informative References ...................................19 Appendix A. Examples .............................................20Show full document text