datatracker.ietf.org
Sign in
Version 5.6.1.p1, 2014-07-16
Report a bug

Internationalized Email Headers
RFC 5335

Document type: RFC - Experimental (September 2008; Errata)
Obsoleted by RFC 6532
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: WG Document
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 5335 (Experimental)
Responsible AD: Chris Newman
Send notices to: eai-chairs@tools.ietf.org, draft-ietf-eai-smtpext@tools.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.

[include full document text]