One document matched: draft-ietf-eai-rfc5335bis-05.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 % I-D.ietf-eai-5378bis PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-eai-5378bis-00.xml'>
<!ENTITY % I-D.ietf-eai-rfc5721bis PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-eai-rfc5721bis-00.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 % 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 % 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'>
<!-- PKIX -->
<!ENTITY % rfc5280 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml'>
<!-- openPGP -->
<!ENTITY % rfc3156 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3156.xml'>
<!ENTITY % rfc5863 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5863.xml'>
<!ENTITY % rfc5335 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5335.xml'>
<!ENTITY % rfc5504 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5504.xml'>
<!ENTITY % I-D.ietf-eai-rfc5336bis PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-eai-rfc5336bis-05.xml'>
<!ENTITY % I-D.ietf-eai-frmwrk-4952bis PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-eai-frmwrk-4952bis-10.xml'>
]>
<?rfc rfcedstyle='yes' subcompact='no' toc='yes' symrefs="yes" sortrefs="yes" ?>
<rfc ipr='trust200902' category="std" updates="2045,5321,5322"
obsoletes="5335" docName="draft-ietf-eai-rfc5335bis-05">
<workgroup>Eail Address Internationalization (EAI)</workgroup>
<front>
<title abbrev="I18N Email Headers">
Internationalized Email Headers
</title>
<author initials="Y" surname="Abel" fullname="Abel Yang">
<organization>TWNIC</organization>
<address>
<postal>
<street>4F-2, No. 9, Sec 2, Roosevelt 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="December" day="04" 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 a 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.ietf-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 a 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.ietf-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>
<!--
****************
* Sections 1.2 and 4.2
blanket ban on applying a content-transfer-encoding to all subtypes
of message/.
=> I do not find it satisfying to read "message/." at the end of
a sentence. I believe it should be quoted. RFC 2045 uses
quotes for "message/rfc822".
Anyway, it is just a remark, and it should be homogenized
according to the current trend for that.
-->
<t>
This document also updates Section 3.4 of <xref target="RFC5322" />.
It Extended mailbox address syntax to permit UTF-8 character in <xref target="syntax_change" />.
</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.ietf-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 display<!-- 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
display <!-- 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 documents
<xref target="I-D.ietf-eai-frmwrk-4952bis"/> and <xref target="I-D.ietf-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.ietf-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="I-D.ietf-eai-rfc5721bis" /> and
<xref target="I-D.ietf-eai-5378bis" />.
</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 full compatible with <xref target="RFC5321" /> and <xref target="RFC5322" />.
In this document, non-ASCII strings are UTF-8 strings if they are in header which contain at least one <UTF8-non-ascii>.
<!-- Original paragraph
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-non-ascii>s.</t>
-->
</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.ietf-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"/> is 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-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <See Section 4 of RFC3629>
UTF8-3 = <See Section 4 of RFC3629>
UTF8-4 = <See Section 4 of RFC3629>
]]></artwork>
</figure>
</t>
<t>
See <xref target="RFC5198"/> for a discussion of normalization; the use of normalization form
<xref target="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 any 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] Section 3.2.2, folding white space>
CFWS = <see [RFC5322] Section 3.2.2>
ctext =/ UTF8-non-ascii
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.
<!--
uQuoted-Pair = ("\" uText) / obs-qp
-->
<figure>
<artwork><![CDATA[
uText = %d1-9 / ; all UTF-8 characters except
%d11-12 / ; US-ASCII NUL, CR, and LF
%d14-127 /
UTF8-non-ascii
uQuoted-Pair = ("\" (VCHAR / WSP / UTF8-non-ascii )) / obs-qp
VCHAR = <See appendix B.1 of RFC 5234>
WSP = <See appendix B.1 of RFC 5234>
uQcontent = uQtext / uQuoted-Pair
uQuoted-Pair = ("\" uText) / obs-qp
DQUOTE = <See appendix B.1 of RFC 5234>
uCcontent = ctext / uQuoted-Pair / comment
uQtext = qtext / UTF8-non-ascii
uAtext = ALPHA / DIGIT /
"!" / "#" / ; Any character except
"$" / "%" / ; controls, SP, and specials.
"&" / "'" / ; Used for atoms.
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~" /
UTF8-non-ascii
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:
<!--
description = "Content-Description:" unstructured CRLF
-->
<figure>
<artwork><![CDATA[
description = "Content-Description" ":" *uText
; Replace description in Section 8 of [RFC2045]
]]></artwork>
</figure>
<!--
The <uText> syntax is extended above to allow UTF-8 in all <unstructured> header fields.</t>
-->
The <uText> syntax is extended above to allow UTF-8 in all <description> 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:" header fields are still expressed in ASCII.
And also, none of this revised syntax changes what is allowed in a <msg-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 from
<xref target="RFC5321" /> Section 4.1.2 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
; Replace mailbox in Section 3.4 of RFC 5322
angle-addr =/ [CFWS] "<" uAddr-Spec ">" [CFWS]
; Replace angle-addr in Section 3.4 of RFC 5322
uAddr-Spec = uLocal-Part "@" uDomain
uLocal-Part = uDot-Atom / uQuoted-String / obs-local-part
; Replace Local-Part in Section 3.4.1 of RFC 5322
uDomain = uDot-Atom / domain-literal / obs-domain
domain-literal = <See Section 3.4.1 of RFC 5322>
]]></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 be rejected if UTF8SMTPbis extension is not supported
<non-ASCII@non-ASCII>
; without DISPLAY_NAME and quoted string
; message will be rejected if UTF8SMTPbis extension is not supported
]]></artwork>
</figure>
</t>
</section>
<section title="Trace Field Syntax" anchor="TraceFieldLimit">
<t>
The 'uFor' clause in "Received:" fields has been allowed the use of internationalized addresses in "For" fields.
It described in <xref target="I-D.ietf-eai-rfc5336bis" />, Section 3.6.3.
<!--
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" designates the address to which messages indicating
non-delivery or other mail system failures are to be sent.
<!-- SM's comments
The "Return-Path:" 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 <received-token> on "Received:" field ( described in Section 3.6.7 of <xref target="RFC5322" />)
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 <received-token>.
<figure>
<artwork>
<![CDATA[
received-token =/ 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.ietf-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
specifies that a message can contain UTF-8 characters in the headers
of the message or body parts.
<!-- SM's comments to be removed
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 SHOULD treat it as "application/octet-stream" as
described in Section 5.2.4 of <xref target="RFC2046" />.)
<!-- SM's comments
(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 internationalized 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 SHOULD 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) <xref target="RFC5280" />
and OpenPGP <xref target="RFC3156" />.
</t>
<t>
Because UTF-8 often requires several octets to encode a single character,
internationalized local parts and header value 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. On the other
hand, MDA (Mail Delivery Agent) 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>
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 [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 title="draft-ietf-eai-rfc5335bis-03">
<t>
<list style="numbers">
<t>Fix typos </t>
<t>ABNF revised </t>
<t>Improve sentence</t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-04">
<t>
<list style="numbers">
<t>improve sentences and ABNF revised based on AD and Co-chairs </t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-05">
<t>
<list style="numbers">
<t>ABNF revised in <xref target="change_addr_spec" /> based on AD comments </t>
</list>
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<!-- SMTP Service Extension for 8bit-MIMEtransport -->
<!-- ietf-eai-smtpext became RFC 5336 -->
&rfc2119;
&rfc5321;
&rfc5322;
<!-- UTF-8 -->
&rfc3629;
&I-D.ietf-eai-frmwrk-4952bis;
&I-D.ietf-eai-rfc5336bis;
&I-D.ietf-eai-5378bis;
&I-D.ietf-eai-rfc5721bis;
&rfc5198;
&rfc5234;
</references>
<references title="Informative References">
<!-- 8bitmime -->
&rfc1652;
<!-- MIME (parts 1, 2, 3) -->
&rfc2045;
&rfc2046;
&rfc2047;
<!-- openPGP -->
&rfc3156;
<!-- PKIX -->
&rfc5280;
<reference anchor="NFC" target="http://www.unicode.org/reports/tr15/">
<front>
<title>Unicode Standard Annex #15: Unicode Normalization Forms</title>
<author initials="M." surname="Davis" fullname="Mark Davis" />
<author initials="K." surname="Whistler" fullname="Ken Whistler" />
<date day='17' month='September' year='2010' />
</front>
</reference>
<!--
&rfc5504; given up
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:19:34 |