Internet Engineering Task Force (IETF) A. Yang
Request for Comments: 6532 TWNIC
Obsoletes: 5335 S. Steele
Updates: 2045 Microsoft
Category: Standards Track N. Freed
ISSN: 2070-1721 Oracle
February 2012
Internet Engineering Task Force (IETF) A. Yang
Request for Comments: 6532 TWNIC
Obsoletes: 5335 S. Steele
Updates: 2045 Microsoft
Category: Standards Track N. Freed
ISSN: 2070-1721 Oracle
February 2012
Internationalized Email Headers
国际化电子邮件标题
Abstract
摘要
Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content.
Internet邮件最初仅限于7位ASCII码。MIME增加了对在正文部分使用8位字符集的支持，还定义了一个编码字结构，以便在某些头字段值中可以使用其他字符集。然而，电子邮件的完全国际化需要额外的增强，以允许在邮件地址中使用Unicode，包括ASCII指令表之外的字符，以及在“发件人”、“收件人”和“主题：”等标题字段中直接使用Unicode，而无需使用复杂的编码字结构。本文档指定了对Internet消息格式和MIME的增强，允许在邮件地址和大多数标题字段内容中使用Unicode。
This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer-encodings on subtypes of "message/".
本规范更新了RFC 2045第6.4节，以消除禁止在“message/”子类型上使用非身份内容传输编码的限制。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6532.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6532.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology Used in This Specification . . . . . . . . . . . . 3
3. Changes to Message Header Fields . . . . . . . . . . . . . . . 4
3.1. UTF-8 Syntax and Normalization . . . . . . . . . . . . . . 4
3.2. Syntax Extensions to RFC 5322 . . . . . . . . . . . . . . 5
3.3. Use of 8-bit UTF-8 in Message-IDs . . . . . . . . . . . . 5
3.4. Effects on Line Length Limits . . . . . . . . . . . . . . 5
3.5. Changes to MIME Message Type Encoding Restrictions . . . . 6
3.6. Use of MIME Encoded-Words . . . . . . . . . . . . . . . . 6
3.7. The message/global Media Type . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology Used in This Specification . . . . . . . . . . . . 3
3. Changes to Message Header Fields . . . . . . . . . . . . . . . 4
3.1. UTF-8 Syntax and Normalization . . . . . . . . . . . . . . 4
3.2. Syntax Extensions to RFC 5322 . . . . . . . . . . . . . . 5
3.3. Use of 8-bit UTF-8 in Message-IDs . . . . . . . . . . . . 5
3.4. Effects on Line Length Limits . . . . . . . . . . . . . . 5
3.5. Changes to MIME Message Type Encoding Restrictions . . . . 6
3.6. Use of MIME Encoded-Words . . . . . . . . . . . . . . . . 6
3.7. The message/global Media Type . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Internet mail distinguishes a message from its transport and further divides a message between a header and a body [RFC5322]. Internet mail header field values contain a variety of strings that are intended to be user-visible. The range of supported characters for these strings was originally limited to [ASCII] in 7-bit form. MIME [RFC2045] [RFC2046] [RFC2047] provides the ability to use additional character sets, but this support is limited to body part data and to special encoded-word constructs that were only allowed in a limited number of places in header field values.
Internet mail将消息与其传输区分开来，并进一步将消息分为头和正文[RFC5322]。Internet邮件标题字段值包含各种用户可见的字符串。这些字符串支持的字符范围最初限制为7位形式的[ASCII]。MIME[RFC2045][RFC2046][RFC2047]提供了使用其他字符集的能力，但这种支持仅限于正文部分数据和仅允许在标题字段值的有限位置使用的特殊编码字结构。
Globalization of the Internet requires support of the much larger set of characters provided by Unicode [RFC5198] in both mail addresses and most header field values. Additionally, complex encoding schemes like encoded-words introduce inefficiencies as well as significant opportunities for processing errors. And finally, native support for the UTF-8 charset is now available on most systems. Hence, it is strongly desirable for Internet mail to support UTF-8 [RFC3629] directly.
互联网的全球化要求在邮件地址和大多数头字段值中支持Unicode[RFC5198]提供的更大的字符集。此外，复杂的编码方案（如编码字）会导致效率低下以及处理错误的重大机会。最后，对UTF-8字符集的本机支持现在可以在大多数系统上使用。因此，强烈希望Internet邮件直接支持UTF-8[RFC3629]。
This document specifies an enhancement to the Internet Message Format [RFC5322] and to MIME that permits the direct use of UTF-8, rather than only ASCII, in header field values, including mail addresses. A new media type, message/global, is defined for messages that use this extended format. This specification also lifts the MIME restriction on having non-identity content-transfer-encodings on any subtype of the message top-level type so that message/global parts can be safely transmitted across existing mail infrastructure.
本文档规定了对Internet消息格式[RFC5322]和MIME的增强，允许在头字段值（包括邮件地址）中直接使用UTF-8，而不仅仅是ASCII。为使用此扩展格式的邮件定义了新的媒体类型message/global。该规范还取消了对消息顶级类型的任何子类型使用非标识内容传输编码的MIME限制，以便消息/全局部分可以跨现有邮件基础结构安全传输。
This specification is based on a model of native, end-to-end support for UTF-8, which depends on having an "8-bit-clean" environment assured by the transport system. Support for carriage across legacy, 7-bit infrastructure and for processing by 7-bit receivers requires additional mechanisms that are not provided by these specifications.
本规范基于UTF-8的本机端到端支持模型，这取决于传输系统所保证的“8位清洁”环境。支持传统7位基础设施上的传输和7位接收器的处理需要这些规范未提供的其他机制。
This specification is a revision of and replacement for [RFC5335]. Section 6 of [RFC6530] describes the change in approach between this specification and the previous version.
本规范是对[RFC5335]的修订和替换。[RFC6530]第6节描述了本规范与先前版本之间方法的变化。
A plain ASCII string is fully compatible with [RFC5321] and [RFC5322]. In this document, non-ASCII strings are UTF-8 strings if they are in header field values that contain at least one <UTF8-non-ascii> (see Section 3.1).
普通ASCII字符串与[RFC5321]和[RFC5322]完全兼容。在本文档中，如果非ASCII字符串位于至少包含一个<UTF8非ASCII>（参见第3.1节）的标题字段值中，则非ASCII字符串为UTF-8字符串。
Unless otherwise noted, all terms used here are defined in [RFC5321], [RFC5322], [RFC6530], or [RFC6531].
除非另有说明，此处使用的所有术语均在[RFC5321]、[RFC5322]、[RFC6530]或[RFC6531]中定义。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The term "8-bit" means octets are present in the data with values above 0x7F.
术语“8位”表示数据中存在值高于0x7F的八位字节。
To permit non-ASCII Unicode characters in field values, the header definition in [RFC5322] is extended to support the new format. The following sections specify the necessary changes to RFC 5322's ABNF.
为了在字段值中允许使用非ASCII Unicode字符，扩展了[RFC5322]中的标题定义以支持新格式。以下章节规定了RFC 5322 ABNF的必要变更。
The syntax rules not mentioned below remain defined as in [RFC5322].
下文未提及的语法规则仍按[RFC5322]中的定义定义。
Note that this protocol does not change rules in RFC 5322 for defining header field names. The bodies of header fields are allowed to contain Unicode characters, but the header field names themselves must consist of ASCII characters only.
请注意，此协议不会更改RFC 5322中定义标头字段名称的规则。头字段的主体可以包含Unicode字符，但头字段名称本身必须仅由ASCII字符组成。
Also note that messages in this format require the use of the SMTPUTF8 extension [RFC6531] to be transferred via SMTP.
还请注意，此格式的邮件需要使用SMTPUTF8扩展名[RFC6531]通过SMTP传输。
UTF-8 characters can be defined in terms of octets using the following ABNF [RFC5234], taken from [RFC3629]:
UTF-8字符可以使用取自[RFC3629]的以下ABNF[RFC5234]以八位字节定义：
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <Defined in Section 4 of RFC3629>
UTF8-2 = <Defined in Section 4 of RFC3629>
UTF8-3 = <Defined in Section 4 of RFC3629>
UTF8-3 = <Defined in Section 4 of RFC3629>
UTF8-4 = <Defined in Section 4 of RFC3629>
UTF8-4 = <Defined in Section 4 of RFC3629>
See [RFC5198] for a discussion of Unicode normalization; normalization form NFC [UNF] SHOULD be used. 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 to mailboxes as well. The NFKC normalization form [UNF] SHOULD NOT be used because it may lose information that is needed to correctly spell some names in some unusual circumstances.
有关Unicode规范化的讨论，请参见[RFC5198]；应使用标准化表格NFC[UNF]。事实上，如果要正确地进行国际化，最常被引用的目标之一就是允许人们正确拼写自己的名字。由于许多邮箱本地部分反映了个人姓名，因此该原则也适用于邮箱。不应使用NFKC规范化表单[UNF]，因为它可能会丢失在某些异常情况下正确拼写某些名称所需的信息。
The following rules extend the ABNF syntax defined in [RFC5322] and [RFC5234] in order to allow UTF-8 content.
以下规则扩展了[RFC5322]和[RFC5234]中定义的ABNF语法，以允许UTF-8内容。
VCHAR =/ UTF8-non-ascii
VCHAR=/UTF8非ascii
ctext =/ UTF8-non-ascii
ctext=/UTF8非ascii码
atext =/ UTF8-non-ascii
atext=/UTF8非ascii码
qtext =/ UTF8-non-ascii
qtext=/UTF8非ascii码
text =/ UTF8-non-ascii ; note that this upgrades the body to UTF-8
text=/UTF8非ascii码；请注意，这将阀体升级为UTF-8
dtext =/ UTF8-non-ascii
dtext=/UTF8非ascii码
The preceding changes mean that the following constructs now allow UTF-8:
前面的更改意味着以下结构现在允许UTF-8：
1. Unstructured text, used in header fields like "Subject:" or "Content-description:".
1. 非结构化文本，用于标题字段，如“主题：”或“内容描述：”。
2. Any construct that uses atoms, including but not limited to the local parts of addresses and Message-IDs. This includes addresses in the "for" clauses of "Received:" header fields.
2. 使用原子的任何构造，包括但不限于地址和消息ID的本地部分。这包括“Received:”标题字段的“for”子句中的地址。
3. Quoted strings.
3. 带引号的字符串。
4. Domains.
4. 域名。
Note that header field names are not on this list; these are still restricted to ASCII.
请注意，标题字段名称不在此列表中；这些仍然限于ASCII。
Implementers of Message-ID generation algorithms MAY prefer to restrain their output to ASCII since that has some advantages, such as when constructing "In-reply-to:" and "References:" header fields in mailing-list threads where some senders use internationalized addresses and others do not.
消息ID生成算法的实现者可能更喜欢将其输出限制为ASCII，因为这有一些优点，例如在邮件列表线程中构造“回复：”和“引用：”头字段时，其中一些发送者使用国际化地址，而另一些则不使用。
Section 2.1.1 of [RFC5322] limits lines to 998 characters and recommends that the lines be restricted to only 78 characters. This specification changes the former limit to 998 octets. (Note that, in
[RFC5322]第2.1.1节将行限制为998个字符，并建议将行限制为仅78个字符。本规范将以前的限制更改为998个八位字节。（注意，在
ASCII, octets and characters are effectively the same, but this is not true in UTF-8.) The 78-character limit remains defined in terms of characters, not octets, since it is intended to address display width issues, not line-length issues.
ASCII、八位字节和字符实际上是相同的，但在UTF-8中并非如此。）78个字符的限制仍然是根据字符而不是八位字节定义的，因为它旨在解决显示宽度问题，而不是行长度问题。
This specification updates Section 6.4 of [RFC2045]. [RFC2045] prohibits applying a content-transfer-encoding to any subtypes of "message/". This specification relaxes that rule -- it allows newly defined MIME types to permit content-transfer-encoding, and it allows content-transfer-encoding for message/global (see Section 3.7).
本规范更新了[RFC2045]第6.4节。[RFC2045]禁止对“message/”的任何子类型应用内容传输编码。该规范放宽了该规则——它允许新定义的MIME类型允许内容传输编码，并且允许消息/全局的内容传输编码（参见第3.7节）。
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.
背景：通常情况下，消息/全局的传输将在8位干净通道中完成，身体部位将有“身份”编码，即不需要解码。
But in the case where a message containing a message/global is downgraded from 8-bit to 7-bit as described in [RFC6152], an encoding might have to be applied to the message. If the message travels multiple times between a 7-bit environment and an environment implementing these extensions, 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 is thought to be larger than the complexity of allowing nested encodings where necessary.
但是，如果包含message/global的消息如[RFC6152]中所述从8位降级为7位，则可能必须对该消息应用编码。如果消息在7位环境和实现这些扩展的环境之间多次传输，则可能会出现多个编码级别。这在实践中是很少见的，其他处理该问题的方法的潜在复杂性被认为比必要时允许嵌套编码的复杂性更大。
The MIME encoded-words facility [RFC2047] provides the ability to place non-ASCII text, but only in a subset of the places allowed by this extension. Additionally, encoded-words are substantially more complex since they allow the use of arbitrary charsets. Accordingly, encoded-words SHOULD NOT be used when generating header fields for messages employing this extension. Agents MAY, when incorporating material from another message, convert encoded-word use to direct use of UTF-8.
MIME编码字工具[RFC2047]提供了放置非ASCII文本的能力，但只能放置在此扩展允许的位置子集中。此外，编码字实质上更复杂，因为它们允许使用任意字符集。因此，在为使用此扩展的消息生成头字段时，不应使用编码字。代理在合并来自另一条消息的材料时，可以将编码字的使用转换为UTF-8的直接使用。
Note that care must be taken when decoding encoded-words because the results after replacing an encoded-word with its decoded equivalent in UTF-8 may be syntactically invalid. Processors that elect to decode encoded-words MUST NOT generate syntactically invalid fields.
请注意，在解码编码字时必须小心，因为在UTF-8中用其解码等价物替换编码字后的结果可能在语法上无效。选择解码编码字的处理器不得生成语法无效的字段。
Internationalized messages in this format MUST only be transmitted as authorized by [RFC6531] or within a non-SMTP environment that supports these messages. A message is a "message/global message" if:
此格式的国际化邮件只能在[RFC6531]授权或支持这些邮件的非SMTP环境中传输。如果出现以下情况，则消息为“消息/全局消息”：
o it contains 8-bit UTF-8 header values as specified in this document, or
o 它包含本文档中指定的8位UTF-8标头值，或
o it contains 8-bit UTF-8 values in the header fields of body parts.
o 它在车身零件的标题字段中包含8位UTF-8值。
The content of a message/global part is otherwise identical to that of a message/rfc822 part.
消息/全局部分的内容在其他方面与消息/rfc822部分的内容相同。
If an object of this type is sent to a 7-bit-only system, it MUST have an appropriate content-transfer-encoding applied. (Note that a system compliant with MIME that doesn't recognize message/global is supposed to treat it as "application/octet-stream" as described in Section 5.2.4 of [RFC2046].)
如果将此类型的对象发送到7位纯系统，则必须应用适当的内容传输编码。（请注意，与MIME兼容但不识别消息/全局的系统应将其视为[RFC2046]第5.2.4节所述的“应用程序/八位字节流”。）
The registration is as follows:
登记情况如下：
Type name: message
类型名称：消息
Subtype name: global
子类型名称：全局
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: Any content-transfer-encoding is permitted. The 8-bit or binary content-transfer-encodings are recommended where permitted.
编码注意事项：允许任何内容传输编码。如果允许，建议使用8位或二进制内容传输编码。
Security considerations: See Section 4.
安全注意事项：见第4节。
Interoperability considerations: This media type provides functionality similar to the message/rfc822 content type for email messages with internationalized 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. Each 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
互操作性注意事项：此媒体类型为具有国际化电子邮件标题的电子邮件提供了类似于message/rfc822内容类型的功能。当需要在另一条消息中嵌入或返回此类内容时，通常可以选择使用此媒体类型，保持内容不变，或将内容向下转换为消息/rfc822。这些选项中的每一个都将与已安装的基础互操作，但具有不同的属性。不知道国际化标头的系统通常会将消息/全局正文部分视为未知附件，同时它们会理解消息/rfc822的结构。但是，理解消息/全局的系统
will provide functionality superior to the result of a down-conversion to message/rfc822. The most interoperable choice depends on the deployed software.
将提供优于消息/rfc822下转换结果的功能。最具互操作性的选择取决于部署的软件。
Published specification: RFC 6532
已发布规范：RFC 6532
Applications that use this media type: SMTP servers and email clients that support multipart/report generation or parsing. Email clients that forward messages with internationalized headers as attachments.
使用此媒体类型的应用程序：支持多部分/报告生成或分析的SMTP服务器和电子邮件客户端。转发带有国际化标题作为附件的邮件的电子邮件客户端。
Additional information:
其他信息：
Magic number(s): none
幻数：无
File extension(s): The extension ".u8msg" is suggested.
文件扩展名：建议使用扩展名“.u8msg”。
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".
Macintosh文件类型代码：建议使用“public.utf8电子邮件”的统一类型标识符（UTI）。这符合“public.message”和“public.composite content”，但不一定符合“public.utf8纯文本”。
Person & email address to contact for further information: See the Authors' Addresses section of this document.
联系人和电子邮件地址以了解更多信息：请参阅本文档的作者地址部分。
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This is a structured media type that embeds other MIME media types. An 8-bit or binary content-transfer-encoding SHOULD be used unless this media type is sent over a 7-bit-only transport.
使用限制：这是一种嵌入其他MIME媒体类型的结构化媒体类型。除非此媒体类型通过仅7位传输发送，否则应使用8位或二进制内容传输编码。
Author: See the Authors' Addresses section of this document.
作者：请参阅本文档的作者地址部分。
Change controller: IETF Standards Process
变更控制员：IETF标准流程
Because UTF-8 often requires several octets to encode a single character, internationalization may cause header field values (in general) and mail addresses (in particular) to become longer. As specified in [RFC5322], each line of characters MUST be no more than 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.
由于UTF-8通常需要几个八位字节来编码单个字符，国际化可能会导致标题字段值（通常）和邮件地址（特别是）变长。按照[RFC5322]中的规定，除CRLF外，每行字符不得超过998个八位字节。另一方面，解析、存储或处理电子邮件地址或本地部分的MDA（邮件传递代理）进程必须格外小心，以免缓冲区溢出、地址截断或超出存储分配。此外，在比较时，他们必须注意使用地址的整个长度。
There are lots of ways to use UTF-8 to represent something equivalent or similar to a particular displayed character or group of characters; see the security considerations in [RFC3629] for details on the problems this can cause. The normalization process described in Section 3.1 is recommended to minimize these issues.
有很多方法可以使用UTF-8来表示与特定显示字符或字符组等效或相似的内容；有关可能导致的问题的详细信息，请参阅[RFC3629]中的安全注意事项。建议采用第3.1节中描述的标准化过程，以尽量减少这些问题。
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 Section 14 of [RFC6530].
[RFC6530]第14节讨论了UTF-8头对电子邮件签名系统（如域密钥识别邮件（DKIM）、S/MIME和OpenPGP）的安全影响。
If a user has a non-ASCII mailbox address and an ASCII mailbox address, a digital certificate that identifies that user might have both addresses in the identity. Having multiple email addresses as identities in a single certificate is already supported in PKIX (Public Key Infrastructure using X.509) [RFC5280] and OpenPGP [RFC3156], but there may be user-interface issues associated with the introduction of UTF-8 into addresses in this context.
如果用户具有非ASCII邮箱地址和ASCII邮箱地址，则标识该用户的数字证书可能在标识中同时具有这两个地址。PKIX（使用X.509的公钥基础设施）[RFC5280]和OpenPGP[RFC3156]已经支持在单个证书中使用多个电子邮件地址作为身份，但在这种情况下，可能存在与将UTF-8引入地址相关的用户界面问题。
IANA has updated the registration of the message/global MIME type using the registration form contained in Section 3.7.
IANA已使用第3.7节中包含的注册表格更新了消息/全局MIME类型的注册。
This document incorporates many ideas first described in a draft document by Paul Hoffman, although many details have changed from that earlier work.
本文件包含了保罗·霍夫曼（Paul Hoffman）在一份文件草案中首次描述的许多想法，尽管许多细节与之前的工作有所不同。
The authors especially thank Jeff Yeh for his efforts and contributions on editing previous versions.
作者特别感谢Jeff Yeh在编辑之前版本方面所做的努力和贡献。
Most of the content of this document was provided by John C Klensin and Dave Crocker. Significant comments and suggestions were received from Martin Duerst, Julien Elie, Arnt Gulbrandsen, Kristin Hubner, Kari Hurtta, Yangwoo Ko, Charles H. Lindsey, Alexey Melnikov, Chris Newman, Pete Resnick, Yoshiro Yoneya, and additional members of the Joint Engineering Team (JET) and were incorporated into the document. The authors wish to sincerely thank them all for their contributions.
本文件的大部分内容由John C Klensin和Dave Crocker提供。从Martin Duerst、Julien Elie、Arnt Gulbrandsen、Kristin Hubner、Kari Hurta、Yangwoo Ko、Charles H.Lindsey、Alexey Melnikov、Chris Newman、Pete Resnick、Yoshiro Yoneya以及联合工程团队（JET）的其他成员处收到了重要的意见和建议，并纳入了本文件。作者衷心感谢他们的贡献。
[ASCII] "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[ASCII]“编码字符集——信息交换用7位美国标准代码”，ANSI X3.41986。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 51982008年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
[RFC6530]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC6530，2012年2月。
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, February 2012.
[RFC6531]Yao，J.和W.Mao，“国际化电子邮件的SMTP扩展”，RFC 65312012年2月。
[UNF] Davis, M. and K. Whistler, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2010, <http://www.unicode.org/reports/tr15/>.
[UNF]Davis，M.和K.Whistler，“Unicode标准附件#15：Unicode规范化格式”，2010年9月<http://www.unicode.org/reports/tr15/>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3156]Elkins，M.，Del Torto，D.，Levien，R.，和T.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5335] Yang, A., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335]Yang，A.“国际化电子邮件标题”，RFC 53352008年9月。
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.
[RFC6152]Klensin，J.，Freed，N.，Rose，M.，和D.Crocker，“8位MIME传输的SMTP服务扩展”，STD 71，RFC 6152，2011年3月。
Authors' Addresses
作者地址
Abel Yang TWNIC 4F-2, No. 9, Sec 2, Roosevelt Rd. Taipei 100 Taiwan
台湾台北市罗斯福路2段9号亚伯杨TWNIC 4F-2
Phone: +886 2 23411313 ext 505
EMail: abelyang@twnic.net.tw
Phone: +886 2 23411313 ext 505
EMail: abelyang@twnic.net.tw
Shawn Steele Microsoft
肖恩·斯蒂尔微软公司
EMail: Shawn.Steele@microsoft.com
EMail: Shawn.Steele@microsoft.com
Ned Freed Oracle 800 Royal Oaks Monrovia, CA 91016-6347 USA
美国加利福尼亚州蒙罗维亚皇家橡树园800号，邮编91016-6347
EMail: ned+ietf@mrochek.com
EMail: ned+ietf@mrochek.com