Internationalized Email Headers
RFC 5335
| Document | Type |
RFC - Experimental
(September 2008; Errata)
Obsoleted by RFC 6532
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Reviews | |||
| Stream | WG state | WG Document | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 5335 (Experimental) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Chris Newman | ||
| Send notices to | draft-ietf-eai-smtpext@ietf.org | ||
Network Working Group Y. Abel, Ed.
Request for Comments: 5335 TWNIC
Updates: 2045, 2822 September 2008
Category: Experimental
Internationalized Email Headers
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.
Abstract
Full internationalization of electronic mail requires not only the
capabilities 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 the 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.
This form is permitted in transmission only if authorized by an SMTP
extension, as specified in an associated specification. This
specification Updates section 6.4 of RFC 2045 to conform with the
requirements.
Abel Experimental [Page 1]
RFC 5335 I18N Email Headers September 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of This Specification . . . . . . . . . . . . . . . . 3
1.2. Relation to Other Standards . . . . . . . . . . . . . . . 3
2. Background and History . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Changes on Message Header Fields . . . . . . . . . . . . . . . 5
4.1. UTF-8 Syntax and Normalization . . . . . . . . . . . . . . 5
4.2. Changes on MIME Headers . . . . . . . . . . . . . . . . . 6
4.3. Syntax Extensions to RFC 2822 . . . . . . . . . . . . . . 6
4.4. Change on addr-spec Syntax . . . . . . . . . . . . . . . . 8
4.5. Trace Field Syntax . . . . . . . . . . . . . . . . . . . . 9
4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Abel Experimental [Page 2]
RFC 5335 I18N Email Headers September 2008
1. Introduction
1.1. Role of This Specification
Full internationalization of electronic mail requires several
capabilities:
o The capability to transmit non-ASCII content, provided for as part
of the basic MIME specification [RFC2045], [RFC2046].
o The capability to use international characters in envelope
addresses, discussed in [RFC4952] and specified in [RFC5336].
o The capability to express those addresses, and information related
to them and based on them, in mail header fields, defined in this
document.
This document specifies an experimental variant of Internet mail that
permits the use of Unicode encoded in UTF-8 [RFC3629], rather than
ASCII, as the base form for Internet email header fields. This form
is permitted in transmission, if authorized by the SMTP extension
specified in [RFC5336] or by other transport mechanisms capable of
processing it.
1.2. Relation to Other Standards
This document updates Section 6.4 of RFC 2045. It removes the
blanket ban on applying a content-transfer-encoding to all subtypes
of message/, and instead specifies that a composite subtype MAY
specify whether or not a content-transfer-encoding can be used for
that subtype, with "cannot be used" as the default.
This document also updates [RFC2822] and MIME ([RFC2045]), and the
fact that an Experimental specification updates a Standards-Track
specification means that people who participate in the experiment
have to consider those standards updated.
Allowing use of a content-transfer-encoding on subtypes of messages
is not limited to transmissions that are authorized by the SMTP
extension specified in [RFC5336]. Message/global permits use of a
content-transfer-encoding.
Show full document text