One document matched: draft-ietf-eai-rfc5335bis-02.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY % rfc1652 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1652.xml'>
<!ENTITY % rfc2119 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY % rfc2045 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml'>
<!ENTITY % rfc2046 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2046.xml'>
<!ENTITY % rfc2047 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2047.xml'>
<!ENTITY % rfc2231 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2231.xml'>
<!ENTITY % rfc5321 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml'>
<!ENTITY % rfc5322 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml'>
 <!ENTITY % rfc2821 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2821.xml'>
<!ENTITY % rfc2822 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2822.xml'>
<!ENTITY % rfc3629 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'>
<!ENTITY % rfc4952 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4952.xml'>
<!ENTITY % rfc1652 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1652.xml'>
<!ENTITY % rfc5198 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5198.xml'>
<!ENTITY % rfc5234 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml'>
<!ENTITY % rfc5721 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5721.xml'>
<!ENTITY % rfc5738 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5738.xml'>
<!ENTITY % rfc5863 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5863.xml'>
<!ENTITY % rfc5504 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5504.xml'>
<!ENTITY % I-D.yao-eai-rfc5336bis PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.yao-eai-rfc533
6bis.xml'>
<!ENTITY % I-D.ietf-eai-frmwrk-4952bis PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-eai
-frmwrk-4952bis-02.xml'>
]>

<?rfc rfcedstyle='yes' subcompact='no'  toc='yes' symrefs="yes"
sortrefs="yes" ?>

<rfc  ipr='trust200902' category="std" updates="2045, 5322"
	obsoletes="5335" docName="draft-ietf-eai-rfc5335bis-02">

<workgroup>Eail Address Internationalization (EAI)</workgroup>

<front>
<title abbrev="I18N Email Headers">
Internationalized Email Headers
</title>


<author initials="A." surname="Yang" fullname="Abel YANG">

	<organization>TWNIC</organization>
	<address>
		<postal>

			<street>4F-2, No. 9, Sec 2, Roosvelt Rd.</street>
			<city>Taipei</city>
			<region/>
			<code>100</code>
			<country>Taiwan</country>
		</postal>
		<phone>+886 2 23411313 ext 505 </phone>

		<email>abelyang@twnic.net.tw</email>
	</address>
</author>

<author initials="S.S" surname="Steele" fullname="Shawn Steele">
  <organization>Microsoft</organization>
- <address>
  <email>Shawn.Steele@microsoft.com</email>
  </address>
  </author>

<date month="August" day="19" year="2010" />

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on http://www.rfc-editor.org/rfcsearch.html. -->
<area>Applications</area>
<workgroup>Email Address Internationalization (EAI)</workgroup>

<keyword>I18N Email Header</keyword>
<keyword>UTF-8 Email Header</keyword>
<keyword>internationalization Email Header</keyword>

<abstract>
<t>
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 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 <xref
target="RFC2045"/>
to conform with the requirements.


</t>
</abstract>
</front>

<middle>
<section title="Introduction">
<section title="Role of This Specification">
<t>
Full internationalization of electronic mail requires several
capabilities:
</t>
<t>
<list style="symbols">
	<t>The capability to transmit non-ASCII content, provided for as part of
	the basic MIME specification <xref target="RFC2045"/>, <xref
target="RFC2046"/>.</t>

	<t>The capability to use international characters in envelope addresses,
	discussed in <xref target="I-D.ietf-eai-frmwrk-4952bis"/> and specified in
	<xref target="I-D.yao-eai-rfc5336bis" />.  </t>

	<t>The capability to express those addresses, and information related to
	them and based on them, in mail header fields, defined in this
document.</t>
</list>
</t>

<t>This document specifies an variant of Internet mail that
permits the use of Unicode encoded in UTF-8 <xref target="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 <xref target="I-D.yao-eai-rfc5336bis"/> or by other transport
mechanisms capable of processing it.
</t>
</section>


<section title="Relation to Other Standards" anchor="relations">
<t>
This document updates Section 6.4 of <xref target="RFC2045" />. 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.
</t>

<t>
This document also updates <xref target="RFC5322" /> and MIME (<xref
target="RFC2045" />), and
people who participate in the experiment have to swich to this document.
</t>

<t>
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 <xref target="I-D.yao-eai-rfc5336bis"/>.
Message/global (see <xref target="utf8smtp" />) permits use of a
content-transfer-encoding.

</t>
</section>
</section>

<section title="Background and History">
<t>Mailbox names often represent the names of human users. Many of these
users throughout the world have names that are not normally expressed
with just the ASCII repertoire of characters, and would like to use more
or less their real names in their mailbox names. These users
are also likely to use non-ASCII text in their common names and subjects
of email messages, both received and sent.
This protocol specifies UTF-8 as the encoding to represent email header
field bodies.</t>

<t>The traditional format of email messages

<xref target="RFC5322"/> allows only ASCII characters in the
header fields of messages. This prevents users from having email addresses
that contain non-ASCII characters. It further forces non-ASCII text in
common names, comments, and in free text (such as in the Subject: field)
to be encoded (as required by MIME format <xref target="RFC2047" />). This
specification describes a change to the email message format that is related
to the SMTP message transport change described in the  associated document
<xref target="I-D.ietf-eai-frmwrk-4952bis"/> and <xref
target="I-D.yao-eai-rfc5336bis"/>, and that
allows non-ASCII characters in most email header fields. These changes
affect
SMTP clients, SMTP servers, mail user agents (MUAs), list expanders,
gateways to other media, and all other processes that parse or handle
email messages.</t>

<t>As specified in <xref target="I-D.yao-eai-rfc5336bis"/>,
an SMTP protocol extension "UTF8SMTPbis" is used to prevent the
transmission of messages with UTF-8 header fields to systems that
cannot handle such messages.
[[Note in Draft: Keyword related to UTF8SMTP  will be decided by WG before
publication.]]

</t>

<t>
Use of this SMTP extension helps prevent the introduction of such
messages into message stores that might misinterpret, improperly display,
or mangle such messages. It should be noted that using an ESMTP extension
does not prevent transferring email messages with UTF-8 header fields to
other systems that use the email format for messages and that may not be
upgraded,  such as unextended POP and IMAP servers. Changes to these
protocols to handle UTF-8 header fields are addressed in <xref
target="RFC5721"/>-bis
and <xref target="RFC5738"/>-bis.
</t>

<t>The objective for this protocol is to allow UTF-8 in email header fields.
<!--
    Issues such as how to handle messages containing UTF-8 header fields
that
    have to be delivered to systems that have not been upgraded to support
    this capability are discussed in <xref target="RFC5504"/>.
	-->
</t>

</section>

<section title="Terminology">
<t>A plain ASCII string is also a valid UTF-8 string; see <xref
target="RFC3629"/>.
In this document, ordinary ASCII characters are UTF-8 characters
if they are in headers which contain <utf8-xtra-char>s.</t>
<t>
Unless otherwise noted, all terms used here are defined in
<xref target="RFC5321"/>, <xref target="RFC5322"/>,
<xref target="I-D.ietf-eai-frmwrk-4952bis" />,or <xref
target="I-D.yao-eai-rfc5336bis"/>.
</t>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119" />.
</t>
</section>


<section title="Changes on Message Header Fields">
<t>SMTP clients can send header fields in UTF-8 format, if the
UTF8SMTPbis extension is advertised by the SMTP server or is permitted by
other
transport mechanisms. </t>

<t>

This protocol does NOT change the <xref target="RFC5322"/> rules for
defining header field
names. The bodies of header fields are allowed to contain UTF-8 characters,
but the header field names themselves must contain only ASCII characters.
</t>
<t>
	To permit UTF-8 characters in field values, the header definition in
<xref target="RFC5322"/> must be extended to support the new format.  The
following ABNF is defined to substitute those definitions in <xref
target="RFC5322"/>.
</t>
<t>
	The syntax rules not covered in this section remain as defined in <xref
target="RFC5322"/>.
</t>

<section title="UTF-8 Syntax and Normalization">
<t>UTF-8 characters can be defined in terms of octets using the following
ABNF <xref target="RFC5234"/>, taken from <xref target="RFC3629"/>:
<figure>
  <artwork><![CDATA[
UTF8-xtra-char  =   UTF8-2 / UTF8-3 / UTF8-4

UTF8-2          =   %xC2-DF UTF8-tail

UTF8-3          =   %xE0 %xA0-BF UTF8-tail /
                    %xE1-EC 2(UTF8-tail) /
                    %xED %x80-9F UTF8-tail /
                    %xEE-EF 2(UTF8-tail)

UTF8-4          =   %xF0 %x90-BF 2( UTF8-tail ) /
                    %xF1-F3 3( UTF8-tail ) /
                    %xF4 %x80-8F 2( UTF8-tail )

UTF8-tail       =   %x80-BF
  ]]></artwork>
</figure>
These are normatively defined in <xref target="RFC3629"/>, but kept in this
document for reasons of convenience.
</t>
<t>
See <xref target="RFC5198"/> for a discussion of normalization; the use of
normalization form
NFC is RECOMMENDED. Actually, if one is going to do internationalization
properly, one of
the most often-cited goals is to permit people to spell their names
correctly. Since many
mailbox local parts reflect personal names, that principle applies as well.
And NFKC is
not recommended because it may lose information that is needed to correctly
spell some names
except in unusual circumstances.
</t>
</section>

<section title="Changes on MIME Headers" anchor="change_on_mime_header">
<t>
   This specification updates Section 6.4 of <xref target="RFC2045"/>.
   <xref target="RFC2045"/> prohibits applying a content-transfer-encoding
   to all subtypes of message/.  This specification relaxes the rule -- it
allows
   newly defined MIME types to permit content-transfer-encoding, and it
allows
   content-transfer-encoding for message/global (see <xref
target="utf8smtp"/>).
</t>



<t>
   Background: Normally, transfer of message/global will be done in
   8-bit-clean channels, and body parts will have "identity" encodings,
   that is, no decoding is necessary.

   In the case where a message containing a message/global is downgraded
   from 8-bit to 7-bit as described in <xref target="RFC1652"/>, an encoding
   may be applied to the message; if the message travels multiple times
   between a 7-bit environment and an environment implementing UTF8SMTPbis,
   multiple levels of encoding may occur. This is expected to be rarely
   seen in practice, and the potential complexity of other ways of dealing
   with the issue are thought to be larger than the complexity of allowing
   nested encodings where necessary.
</t>

</section>
<section title="Syntax Extensions to RFC 5322" anchor="syntax_change">
<t>The following rules are intended to extend the corresponding rules in
<xref target="RFC5322"/> in order to allow UTF-8 characters.
<figure>
  <artwork><![CDATA[
FWS     =  <see [RFC5322], folding white space>

CFWS    =  <see [RFC5322], folding white space>

ctext   =/  UTF8-xtra-char

utext   =/  UTF8-xtra-char

comment =   "(" *([FWS] uCcontent) [FWS] ")"

word    =   uAtom / uQuoted-String
  ]]></artwork>
</figure>
This means that all the <xref target="RFC5322"/> constructs that build upon
these will
permit UTF-8 characters, including comments and quoted strings. We do not
change the syntax
of <atext> in order to allow UTF-8 characters in <addr-spec>.
This would
also allow UTF-8 characters in <message-id>, which is not allowed due
to the limitation
described in <xref target="TraceFieldLimit" />. Instead, <uAtext> is
added to meet this requirement.


<figure>
  <artwork><![CDATA[
uText   =  %d1-9 /         ; all UTF-8 characters except
               %d11-12 /       ; US-ASCII NUL, CR, and LF
               %d14-127 /
               UTF8-xtra-char

uQuoted-Pair   = ("\" uText) / obs-qp

uQcontent      = uQtext / uQuoted-Pair

uQuoted-String = [CFWS]
                     DQUOTE *([FWS] uQcontent) [FWS] DQUOTE
                     [CFWS]

uCcontent =     ctext / uQuoted-Pair / comment
uQtext =        qtext / UTF8-xtra-char


uAtext   =  ALPHA / DIGIT /
                "!" / "#" /     ; Any character except
                "$" / "%" /     ; controls, SP, and specials.
                "&" / "'" /     ; Used for atoms.
                "*" / "+" /
                "-" / "/" /
                "=" / "?" /
                "^" / "_" /
                "`" / "{" /
                "|" / "}" /
                "~" /
                UTF8-xtra-char

uAtom     =	[CFWS] 1*uAtext [CFWS]

uDot-Atom =	[CFWS] uDot-Atom-text [CFWS]

uDot-Atom-text = 1*uAtext *("." 1*uAtext)

qcontent      = uQcontent
  ]]></artwork>
</figure>

</t>
<t>
To allow the use of UTF-8 in a Content-Description header field
<xref target="RFC2045" />, the following syntax is used:
<figure>
  <artwork><![CDATA[
description   = "Content-Description:" unstructured CRLF
  ]]></artwork>
</figure>
The <utext>  syntax is extended above to allow UTF-8 in all

<unstructured> header fields.</t>

<t>
Note, however, this does not remove any constraint on the
character set of protocol elements;
for instance, all the allowed values for timezone in the Date: headers
are still expressed in ASCII.
And also, none of this revised syntax changes what is allowed in a
<message-id>, which will still remain in pure ASCII.
</t>



</section>
<section title="Change on addr-spec Syntax" anchor="change_addr_spec">
<t>Internationalized email addresses are represented in UTF-8. Thus,
all header fields containing <mailbox>es are updated to permit
UTF-8 addresses.
<!--
as well as an additional, optional all-ASCII alternate
address. Note that Message Submission Servers ("MSAs") and Message
Transfer Agents (MTAs) may downgrade internationalized messages as needed.
The procedure for doing so is described in <xref target="RFC5504"/>.
-->

<!--
The procedure for doing so is described in <xref target="RFC5504" />.
-->

<figure>
  <artwork><![CDATA[
mailbox            =  name-addr / addr-spec / uAddr-Spec

angle-addr         =/ [CFWS] "<" uAddr-Spec">" [CFWS] /
                     obs-angle-addr

uAddr-Spec     =  uLocal-Part "@" uDomain

uLocal-Part    =  uDot-String / uQuoted-String

uQuoted-String =  DQUOTE *uQcontent DQUOTE uDomain
               =  (sub-uDomain 1*("." sub-uDomain)) / address-literal

  ]]></artwork>
</figure>
Below are a few examples of possible <mailbox> representations.
<figure>
<artwork>
<![CDATA[

      "DISPLAY_NAME" <ASCII@ASCII>
         ; traditional mailbox format
      "DISPLAY_NAME" <non-ASCII@non-ASCII>
          ; message will bounce if UTF8SMTPbis extension is not supported
      <non-ASCII@non-ASCII>
         ; without DISPLAY_NAME and quoted string
         ; message will bounce if UTF8SMTPbis extension is not supported

  ]]></artwork>
</figure>
</t>
</section>

<section title="Trace Field Syntax" anchor="TraceFieldLimit">

<t>
	"For" fields containing internationalized addresses are allowed, by use
	of the new uFor syntax. UTF-8 information may be needed in Received
fields.
	Such information is therefore allowed to preserve the integrity of those
	fields. The uFor syntax retains the original UTF-8 email address between
	email address internationalization EAI-aware MTAs.
	<!-- Note that, no downgrading be required, the uFor parameter
	is dropped per the procedure specified in <xref target="RFC5504"/>.
	-->
</t>
<t>
	The "Return-Path" header field provides the email return address
	in the mail delivery. Thus, the header is augmented to carry UTF-8
addresses
	(see the revised syntax of <angle-addr> in <xref
target="change_addr_spec"/> of this document).
	This will not break the rule of trace field integrity, because
	the header field is added at the last MTA and described in <xref
target="RFC5321"/>.
</t>

<t>

	The <item-value> on "Received:" syntax is augmented to allow
	UTF-8 email address in the "For" field. <angle-addr> is augmented
	to include UTF-8 email address. In order to allow UTF-8
	email addresses in an <addr-spec>, <uAddr-Spec> is added to
<item-value>.

<figure>
<artwork>

<![CDATA[
item-value      =/      uAddr-Spec
  ]]></artwork>
</figure>
</t>
</section>

<section title="message/global" anchor="utf8smtp">
<t>
   Internationalized messages must only be transmitted as authorized by
<xref target="I-D.yao-eai-rfc5336bis" />
   or within a non-SMTP environment which supports these messages.
   A message is a "message/global message", if

   <list style="symbols">
		<t>it contains UTF-8 header values as specified	in this document,
or</t>
		<t>it contains UTF-8 values in the headers fields of body parts. </t>

   </list>

</t>
<t>
 The type message/global is similar to message/rfc822, except that it
contains a message that can
   contain UTF-8 characters in the headers of the message or body parts.
   If this type is sent to a 7-bit-only system, it
   has to be encoded in MIME <xref target="RFC2045" />.  (Note that a system
compliant with
   MIME that doesn't recognize message/global would treat it as
   "application/octet-stream" as described in Section 5.2.4 of
  <xref target="RFC2046" />.)
</t>
<!--
<t>
Alternatively, SMTP servers and other systems which transfer a
message/global body part MAY choose to down-convert it to a
message/rfc822 body part using the rules described in <xref
target="RFC5504"/>.
</t>
-->


<t><list style="hanging">
<t hangText="Type name:">message</t>
<t hangText="Subtype name:">global</t>
<t hangText="Required parameters:">none</t>
<t hangText="Optional parameters:">none</t>
<t hangText="Encoding considerations:">Any content-transfer-encoding is
permitted.
The 8-bit or binary content-transfer-encodings are recommended where
permitted.</t>
<t hangText="Security considerations:">See <xref target="security" />.</t>
<t hangText="Interoperability considerations:">The media type provides
functionality similar to the message/rfc822 content type for email
messages with international email headers.  When there is a need to
embed or return such content in another message, there is generally an
option to use this media type and leave the content unchanged or
down-convert the content to message/rfc822.  Both of these choices will
interoperate with the installed base, but with different properties.
Systems unaware of international headers will typically treat a
message/global body part as an unknown attachment, while they will
understand the structure of a message/rfc822.  However, systems that
understand message/global will provide functionality superior to the
result of a down-conversion to message/rfc822.  The most interoperable
choice depends on the deployed software.</t>

<t hangText="Published specification:">RFC &rfc.number;</t>
<t hangText="Applications that use this media type:">SMTP servers and
email clients that support multipart/report generation or parsing.
Email clients which forward messages with international headers as
attachments.</t>
<t hangText="Additional information:"></t>
<t hangText="Magic number(s):">none</t>
<t hangText="File extension(s):">The extension ".u8msg" is suggested.</t>
<t hangText="Macintosh file type code(s):">A uniform type identifier
(UTI) of "public.utf8-email-message" is suggested.  This conforms to
"public.message" and "public.composite-content", but does not necessarily
conform to "public.utf8-plain-text".</t>
<t hangText="Person & email address to contact for further
information:">See the Author's Address section of this document.</t>
<t hangText="Intended usage:">COMMON</t>
<t hangText="Restrictions on usage:">This is a structured media type
which embeds other MIME media types.  The 8-bit or binary
content-transfer-encoding MUST be used unless this media type is sent
over a 7-bit-only transport.</t>

<t hangText="Author:">See the Author's Address section of this document.</t>
<t hangText="Change controller:">IETF Standards Process</t>
</list></t>
</section>
</section>

<section title="Security Considerations" anchor="security">
<t>
	If a user has a non-ASCII mailbox address and an ASCII mailbox
	address, a digital certificate that identifies that user may have
	both addresses in the identity. Having multiple email addresses as
	identities in a single certificate is already supported in
	PKIX (Public Key Infrastructure for X.509 Certificates) and
	OpenPGP.
</t>


<t>
	Because UTF-8 often requires several octets to encode a single
	character, internationalized local parts may cause mail addresses to
	become longer.
	As specified in <xref target="RFC5322"/>, each line of characters MUST be
no more 998 octets,
	excluding the CRLF.

</t>

<t>
	Because internationalized local parts may cause email addresses to be
longer,
	processes that parse, store, or handle email addresses or local parts must
	take extra care not to overflow buffers, truncate addresses,
	or exceed storage
	allotments. Also, they must take care, when comparing, to use the entire
	lengths of the addresses.
</t>
<t>
	In this specification, a user could provide an ASCII alternative address
	for a non-ASCII address. However, it is possible these two addresses go to
	different mailboxes, or even different people.
	This configuration may be based on a user's personal choice or on
	administration policy. We recognize that if ASCII and non-ASCII email is
	delivered to two different destinations, based on MTA capability, this may
	violate the principle of least astonishment, but this is not a "protocol
problem".
</t>

<t>

The security impact of UTF-8 headers on email signature systems such as
Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is discussed in
<xref target="I-D.ietf-eai-frmwrk-4952bis"/>, Section 14.
<!--
A subsequent
document <xref target="RFC5504"/> will cover the impact of downgrading on
these systems.
-->
</t>

</section>


<section title="IANA Considerations" anchor="IANA">
<t>
IANA has registered the message/global MIME type
using the registration form contained in <xref target="change_addr_spec" />.
</t>

</section>

<section title="Acknowledgements">

<t>
This document incorporates many ideas first described in
Internet-Draft form by Paul Hoffman, although many details have
changed from that earlier work.
</t>

<t>
The author especially thanks Jeff Yeh for his efforts and contributions
on editing previous versions.
</t>
<t>
Most of the content of this document is provided by John C Klensin.
Also, some significant comments and suggestions were received from Charles
H. Lindsey,
Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris Newman, Yangwoo Ko,
Yoshiro Yoneya,
and other members of the JET team (Joint Engineering Team) and were
incorporated into the document.
The editor sincerely thanks them for their contributions.
</t>
</section>
<section title="Edit history">
<t>This section is used for tracking the update of this document. Will be
removed after finalize.</t>

<section title="draft-ietf-eai-rfc5335bis-00">
<t>
<list style="numbers">
<t>Applied Errata suggested by Alfred Hoenes.</t>
<t>Adjust [RFC2821] and [RFC2822] to <xref target="RFC5321"/> and <xref
target="RFC5322"/>.</t>
<t>Abrogate <alt-address> in ABNF of <angle-addr>.</t>
<t>Revoke <xref target="RFC5504"/> from this document.</t>
<t>Upgrade some references from I-Ds to RFC.</t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-01">
<t>
<list style="numbers">
<t>Author name revised.</t>
</list>
</t>
</section>

<section title="draft-ietf-eai-rfc5335bis-02">
<t>
<list style="numbers">
<t>ABNF revised.</t>
</list>
</t>
</section>

</section>

</middle>

<back>
<references title="Normative References">
<!-- SMTP Service Extension for 8bit-MIMEtransport  -->

<!-- ietf-eai-smtpext became RFC 5336 -->


&rfc1652;
&rfc2119;

&rfc5321;
&rfc5322;
<!-- UTF-8 -->
&rfc3629;
&I-D.ietf-eai-frmwrk-4952bis;
&I-D.yao-eai-rfc5336bis;
&rfc5198;
&rfc5234;
</references>

<references title="Informative References">
<!--ietf-eai-RFC5504 -->


<!-- MIME (parts 1, 2, 3) -->
&rfc2045;
&rfc2046;
&rfc2047;
&rfc5504;
&rfc5721;
&rfc5738;
</references>

</back>
</rfc>