Internet Engineering Task Force (IETF) M. Duerst
Request for Comments: 6068 Aoyama Gakuin University
Obsoletes: 2368 L. Masinter
Category: Standards Track Adobe Systems Incorporated
ISSN: 2070-1721 J. Zawinski
DNA Lounge
October 2010
Internet Engineering Task Force (IETF) M. Duerst
Request for Comments: 6068 Aoyama Gakuin University
Obsoletes: 2368 L. Masinter
Category: Standards Track Adobe Systems Incorporated
ISSN: 2070-1721 J. Zawinski
DNA Lounge
October 2010
The 'mailto' URI Scheme
“mailto”URI方案
Abstract
摘要
This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368).
本文档定义了统一资源标识符（URI）的格式，以标识使用Internet邮件访问的资源。它将更好的国际化和与国际化资源标识符（IRIs；RFC 3987）的兼容性添加到以前的“mailto”URI（RFC 2368）语法中。
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/rfc6068.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6068.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Syntax of a 'mailto' URI . . . . . . . . . . . . . . . . . . . 3
3. Semantics and Operations . . . . . . . . . . . . . . . . . . . 7
4. Unsafe Header Fields . . . . . . . . . . . . . . . . . . . . . 7
5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Examples of Complicated Email Addresses . . . . . . . . . 10
6.3. Examples Using UTF-8-Based Percent-Encoding . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. Update of the Registration of the 'mailto' URI Scheme . . 14
8.2. Registration of the Body Header Field . . . . . . . . . . 15
9. Main Changes from RFC 2368 . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Syntax of a 'mailto' URI . . . . . . . . . . . . . . . . . . . 3
3. Semantics and Operations . . . . . . . . . . . . . . . . . . . 7
4. Unsafe Header Fields . . . . . . . . . . . . . . . . . . . . . 7
5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Examples of Complicated Email Addresses . . . . . . . . . 10
6.3. Examples Using UTF-8-Based Percent-Encoding . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. Update of the Registration of the 'mailto' URI Scheme . . 14
8.2. Registration of the Body Header Field . . . . . . . . . . 15
9. Main Changes from RFC 2368 . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
The 'mailto' URI scheme is used to identify resources that are reached using Internet mail. In its simplest form, a 'mailto' URI contains an Internet mail address. For interactions that require message headers or message bodies to be specified, the 'mailto' URI scheme also allows providing mail header fields and the message body.
“mailto”URI方案用于标识使用Internet邮件访问的资源。最简单的形式是，“mailto”URI包含一个Internet邮件地址。对于需要指定消息头或消息体的交互，“mailto”URI方案还允许提供邮件头字段和消息体。
This specification extends the previous scheme definition to also allow character data to be percent-encoded based on UTF-8 [STD63], which offers a better and more consistent way of dealing with non-ASCII characters for internationalization.
本规范扩展了先前的方案定义，允许字符数据基于UTF-8[STD63]进行百分比编码，这为国际化处理非ASCII字符提供了更好、更一致的方法。
This specification does not address the needs of the ongoing Email Address Internationalization effort (see [RFC4952]). In particular, this specification does not include syntax for fallback addresses.
本规范不满足正在进行的电子邮件地址国际化工作的需要（请参见[RFC4952]）。特别是，本规范不包括回退地址的语法。
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]中所述进行解释。
In this document, URIs are enclosed in '<' and '>' as described in Appendix C of [STD66]. Extra whitespace and line breaks are added to present long URIs -- they are not part of the actual URI.
在本文件中，URI包含在“<”和“>”中，如[STD66]附录C所述。额外的空格和换行符被添加到当前的长URI中——它们不是实际URI的一部分。
The syntax of a 'mailto' URI is described using the ABNF of [STD68], non-terminal definitions from [RFC5322] (dot-atom-text, quoted-string), and non-terminal definitions from [STD66] (unreserved, pct-encoded):
“mailto”URI的语法使用[STD68]的ABNF、来自[RFC5322]的非终端定义（点原子文本，带引号的字符串）和来自[STD66]的非终端定义（无保留，pct编码）进行描述：
mailtoURI = "mailto:" [ to ] [ hfields ]
to = addr-spec *("," addr-spec )
hfields = "?" hfield *( "&" hfield )
hfield = hfname "=" hfvalue
hfname = *qchar
hfvalue = *qchar
addr-spec = local-part "@" domain
local-part = dot-atom-text / quoted-string
domain = dot-atom-text / "[" *dtext-no-obs "]"
dtext-no-obs = %d33-90 / ; Printable US-ASCII
%d94-126 ; characters not including
; "[", "]", or "\"
qchar = unreserved / pct-encoded / some-delims
some-delims = "!" / "$" / "'" / "(" / ")" / "*"
/ "+" / "," / ";" / ":" / "@"
mailtoURI = "mailto:" [ to ] [ hfields ]
to = addr-spec *("," addr-spec )
hfields = "?" hfield *( "&" hfield )
hfield = hfname "=" hfvalue
hfname = *qchar
hfvalue = *qchar
addr-spec = local-part "@" domain
local-part = dot-atom-text / quoted-string
domain = dot-atom-text / "[" *dtext-no-obs "]"
dtext-no-obs = %d33-90 / ; Printable US-ASCII
%d94-126 ; characters not including
; "[", "]", or "\"
qchar = unreserved / pct-encoded / some-delims
some-delims = "!" / "$" / "'" / "(" / ")" / "*"
/ "+" / "," / ";" / ":" / "@"
<addr-spec> is a mail address as specified in [RFC5322], but excluding <comment> from [RFC5322]. However, the following changes apply:
<addr spec>是[RFC5322]中指定的邮件地址，但不包括[RFC5322]中的<comment>。但是，以下更改适用：
1. A number of characters that can appear in <addr-spec> MUST be percent-encoded. These are the characters that cannot appear in a URI according to [STD66] as well as "%" (because it is used for percent-encoding) and all the characters in gen-delims except "@" and ":" (i.e., "/", "?", "#", "[", and "]"). Of the characters in sub-delims, at least the following also have to be percent-encoded: "&", ";", and "=". Care has to be taken both when encoding as well as when decoding to make sure these operations are applied only once.
1. 可以出现在<addr spec>中的许多字符必须进行百分比编码。根据[STD66]以及“%”（因为它用于百分比编码）以及gen delims中除“@”和“：”（即“/”、“？”、“#”、“和“]）之外的所有字符，这些字符不能出现在URI中。在子文件中的字符中，至少以下字符也必须进行百分比编码：“&”、“；”和“=”。在编码和解码时都必须小心，以确保这些操作只应用一次。
2. <obs-local-part> and <NO-WS-CTL> as defined in [RFC5322] MUST NOT be used.
2. 不得使用[RFC5322]中定义的<obs local part>和<NO-WS-CTL>。
3. Whitespace and comments within <local-part> and <domain> MUST NOT be used. They would not have any operational semantics.
3. 不能使用<local part>和<domain>中的空格和注释。它们没有任何操作语义。
4. Percent-encoding can be used in the <domain> part of an <addr-spec> in order to denote an internationalized domain name. The considerations for <reg-name> in [STD66] apply. In particular, non-ASCII characters MUST first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence MUST be percent-encoded to be represented as URI characters. URI-producing applications MUST NOT use percent-encoding in domain names unless it is used to represent a UTF-8 character sequence. When the internationalized domain name is used to compose a message, the name MUST be transformed to the Internationalizing Domain Names in Applications (IDNA) encoding [RFC5891] where appropriate. URI producers SHOULD provide these domain names in the IDNA encoding, rather than percent-encoded, if they wish to maximize interoperability with legacy 'mailto' URI interpreters.
4. 百分比编码可用于<addr spec>的<domain>部分，以表示国际化域名。[STD66]中的<reg name>注意事项适用。特别是，必须首先根据UTF-8[STD63]对非ASCII字符进行编码，然后对相应UTF-8序列的每个八位字节进行百分比编码，以表示为URI字符。生成URI的应用程序不得在域名中使用百分比编码，除非它用于表示UTF-8字符序列。当使用国际化域名撰写消息时，必须在适当情况下将该名称转换为应用程序中的国际化域名（IDNA）编码[RFC5891]。如果URI生产者希望最大限度地提高与旧版“mailto”URI解释器的互操作性，他们应该以IDNA编码而不是百分比编码的方式提供这些域名。
5. Percent-encoding of non-ASCII octets in the <local-part> of an <addr-spec> is reserved for the internationalization of the <local-part>. Non-ASCII characters MUST first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence MUST be percent-encoded to be represented as URI characters. Any other percent-encoding of non-ASCII characters is prohibited. When a <local-part> containing non-ASCII characters will be used to compose a message, the <local-part> MUST be transformed to conform to whatever encoding may be defined in a future specification for the internationalization of email addresses.
5. <addr spec>的<local part>中非ASCII八位字节的百分比编码保留用于<local part>的国际化。必须首先根据UTF-8[STD63]对非ASCII字符进行编码，然后对相应UTF-8序列的每个八位字节进行百分比编码，以表示为URI字符。禁止对非ASCII字符进行任何其他百分比编码。当包含非ASCII字符的<local part>将用于编写消息时，必须将<local part>转换为符合未来电子邮件地址国际化规范中可能定义的任何编码。
<hfname> and <hfvalue> are encodings of an [RFC5322] header field name and value, respectively. Percent-encoding is needed for the same characters as listed above for <addr-spec>. <hfname> is case-insensitive, but <hfvalue> in general is case-sensitive. Note that [RFC5322] allows all US-ASCII printable characters except ":" in optional header field names (Section 3.6.8), which is the reason why <pct-encoded> is part of the header field name production.
<hfname>和<hfvalue>分别是[RFC5322]头字段名和值的编码。对于上面为<addr spec>列出的相同字符，需要百分比编码<hfname>不区分大小写，但通常<hfvalue>区分大小写。请注意，[RFC5322]允许在可选标题字段名（第3.6.8节）中使用除“：”以外的所有US-ASCII可打印字符，这就是为什么<pct encoded>是标题字段名生成的一部分。
The special <hfname> "body" indicates that the associated <hfvalue> is the body of the message. The "body" field value is intended to contain the content for the first text/plain body part of the message. The "body" pseudo header field is primarily intended for the generation of short text messages for automatic processing (such as "subscribe" messages for mailing lists), not for general MIME bodies. Except for the encoding of characters based on UTF-8 and percent-encoding, no additional encoding (such as e.g., base64 or quoted-printable; see [RFC2045]) is used for the "body" field value. As a consequence, header fields related to message encoding (e.g., Content-Transfer-Encoding) in a 'mailto' URI are irrelevant and MUST be ignored. The "body" pseudo header field name has been registered with IANA for this special purpose (see Section 8.2).
特殊的<hfname>“body”表示关联的<hfvalue>是消息的正文。“正文”字段值旨在包含消息的第一个文本/纯正文部分的内容。“body”伪头字段主要用于生成用于自动处理的短文本消息（例如邮件列表的“subscribe”消息），而不是一般的MIME正文。除了基于UTF-8和百分比编码的字符编码外，“正文”字段值不使用其他编码（例如base64或带引号的可打印；请参见[RFC2045]）。因此，与“mailto”URI中的消息编码（例如，内容传输编码）相关的头字段是不相关的，必须忽略。“body”伪头字段名已为此特殊目的向IANA注册（见第8.2节）。
Within 'mailto' URIs, the characters "?", "=", and "&" are reserved, serving as delimiters. They have to be escaped (as "%3F", "%3D", and "%26", respectively) when not serving as delimiters.
在“mailto”URI中，字符“？”、“=”和“&”是保留的，用作分隔符。当它们不用作分隔符时，必须进行转义（分别为“%3F”、“3D”和“%26”）。
Additional restrictions on what characters are allowed might apply depending on the context where the URI is used. Such restrictions can be addressed by context-specific escaping mechanisms. For example, because the "&" (ampersand) character is reserved in HTML and XML, any 'mailto' URI that contains an ampersand has to be written with an HTML/XML entity ("&") or numeric character reference ("&" or "&").
根据URI使用的上下文，可能会应用关于允许哪些字符的附加限制。这种限制可以通过上下文特定的转义机制来解决。例如，由于“&”（与符号）字符在HTML和XML中保留，因此任何包含与符号的“mailto”URI都必须使用HTML/XML实体（“&；”）或数字字符引用（“&；”或“&；”来编写。
Non-ASCII characters can be encoded in <hfvalue> as follows:
非ASCII字符可以在<hfvalue>中编码，如下所示：
1. MIME encoded words (as defined in [RFC2047]) are permitted in header field values, but not in an <hfvalue> of a "body" <hfname>. Sequences of characters that look like MIME encoded words can appear in an <hfvalue> of a "body" <hfname>, but in that case have no special meaning. Please note that the '=' and '?' characters used as delimiters in MIME encoded words have to be percent-encoded. Also note that the use of MIME encoded words differs slightly for so-called structured and unstructured header fields.
1. MIME编码字（定义见[RFC2047]）允许出现在标题字段值中，但不允许出现在“body”<hfname>的<hfvalue>中。看起来像MIME编码单词的字符序列可以出现在“body”<hfname>的<hfvalue>中，但在这种情况下没有特殊意义。请注意，MIME编码字中用作分隔符的“=”和“？”字符必须采用百分比编码。还请注意，对于所谓的结构化和非结构化头字段，MIME编码字的使用略有不同。
2. Non-ASCII characters can be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence is percent-encoded to be represented as URI characters. When header field values encoded in this way are used to compose a message, the <hfvalue> has to be suitably encoded (transformed into MIME encoded words [RFC2047]), except for an <hfvalue> of a "body" <hfname>, which has to be encoded according to [RFC2045]. Please note that for MIME encoded words and for bodies in composed email messages, encodings other than UTF-8 MAY be used as long as the characters are properly transcoded.
2. 非ASCII字符可以根据UTF-8[STD63]进行编码，然后对应UTF-8序列的每个八位字节都进行百分比编码，以表示为URI字符。当以这种方式编码的报头字段值用于编写消息时，必须对<hfvalue>进行适当编码（转换为MIME编码字[RFC2047]），但“body”<hfname>的<hfvalue>除外，该“body”<hfname>必须根据[RFC2045]进行编码。请注意，对于MIME编码的单词和合成电子邮件中的正文，只要字符正确转码，就可以使用UTF-8以外的编码。
Also note that it is syntactically valid to specify both <to> and an <hfname> whose value is "to". That is,
还请注意，在语法上可以同时指定<to>和<hfname>，其值为“to”。就是，
<mailto:addr1@an.example,addr2@an.example>
<mailto:addr1@an.example,addr2@an.example>
is equivalent to
相当于
<mailto:?to=addr1@an.example,addr2@an.example>
<mailto:?to=addr1@an.example,addr2@an.example>
is equivalent to
相当于
<mailto:addr1@an.example?to=addr2@an.example>
<mailto:addr1@an.example?to=addr2@an.example>
However, the latter form is NOT RECOMMENDED because different user agents handle this case differently. In particular, some existing clients ignore "to" <hfvalue>s.
但是，不建议使用后一种形式，因为不同的用户代理处理这种情况的方式不同。特别是，一些现有客户机忽略了“to”<hfvalue>s。
Implementations MUST NOT produce two "To:" header fields in a message; the "To:" header field may occur at most once in a message ([RFC5322], Section 3.6). Also, creators of 'mailto' URIs MUST NOT include other message header fields multiple times if these header fields can only be used once in a message.
实现不能在消息中产生两个“To:”头字段；“收件人：”标题字段在消息中最多出现一次（[RFC5322]，第3.6节）。此外，“mailto”URI的创建者不得多次包含其他消息头字段，如果这些消息头字段在消息中只能使用一次。
To avoid interoperability problems, creators of 'mailto' URIs SHOULD NOT use the same <hfname> multiple times in the same URI. If the same <hfname> appears multiple times in a URI, behavior varies widely for different user agents, and for each <hfname>. Examples include using only the first or last <hfname>/<hfvalue> pair, creating multiple header fields, and combining each <hfvalue> by simple concatenation or in a way appropriate for the corresponding header field.
为避免互操作性问题，“mailto”URI的创建者不应在同一URI中多次使用相同的<hfname>。如果同一个<hfname>在URI中多次出现，则不同的用户代理以及每个<hfname>的行为会有很大差异。示例包括仅使用第一个或最后一个<hfname>/<hfvalue>对，创建多个标题字段，并通过简单的连接或以适合相应标题字段的方式组合每个<hfvalue>。
Note that this specification, like any URI scheme specification, does not define syntax or meaning of a fragment identifier (see [STD66]), because these depend on the type of a retrieved representation. In the currently known usage scenarios, a 'mailto' URI cannot be used to retrieve such representations. Therefore, fragment identifiers are
请注意，与任何URI方案规范一样，该规范没有定义片段标识符的语法或含义（请参见[STD66]），因为它们取决于检索到的表示的类型。在当前已知的使用场景中，“mailto”URI不能用于检索此类表示。因此，片段标识符是
meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be ignored upon resolution. The character "#" in <hfvalue>s MUST be escaped as %23.
无意义，不应在“mailto”URI上使用，在解析时应忽略。<hfvalue>s中的字符“#”必须作为%23转义。
A 'mailto' URI designates an "Internet resource", which is the mailbox specified in the address. When additional header fields are supplied, the resource designated is the same address but with an additional profile for accessing the resource. While there are Internet resources that can only be accessed via electronic mail, the 'mailto' URI is not intended as a way of retrieving such objects automatically.
“mailto”URI指定“Internet资源”，即地址中指定的邮箱。当提供额外的头字段时，指定的资源是相同的地址，但具有用于访问资源的额外配置文件。虽然存在只能通过电子邮件访问的Internet资源，“mailto”URI并不是自动检索此类对象的一种方式。
The operation of how any URI scheme is resolved is not mandated by the URI specifications. In current practice, resolving URIs such as those in the 'http' URI scheme causes an immediate interaction between client software and a host running an interactive server. The 'mailto' URI has unusual semantics because resolving such a URI does not cause an immediate interaction with a server. Instead, the client creates a message to the designated address with the various header fields set as default. The user can edit the message, send the message unedited, or choose not to send the message.
URI规范不强制执行如何解析任何URI方案的操作。在当前实践中，解析诸如“http”URI方案中的URI会导致客户端软件和运行交互式服务器的主机之间的即时交互。“mailto”URI具有不同寻常的语义，因为解析这样的URI不会导致与服务器的即时交互。相反，客户端创建一条到指定地址的消息，并将各种头字段设置为默认值。用户可以编辑邮件、未经编辑发送邮件或选择不发送邮件。
The <hfname>/<hfvalue> pairs in a 'mailto' URI, although syntactically equivalent to header fields in a mail message, do not directly correspond to the header fields in a mail message. In particular, the To, Cc, and Bcc <hfvalue>s don't necessarily result in a header field containing the specified value. Mail client software MAY eliminate duplicate addresses. Creators of 'mailto' URIs SHOULD avoid using the same address twice in a 'mailto' URI.
“mailto”URI中的<hfname>/<hfvalue>对虽然在语法上等同于邮件消息中的头字段，但并不直接对应于邮件消息中的头字段。特别是，To、Cc和Bcc<hfvalue>s不一定会生成包含指定值的头字段。邮件客户端软件可以消除重复地址。“mailto”URI的创建者应避免在“mailto”URI中使用同一地址两次。
Originator fields like From and Date, fields related to routing (Apparently-To, Resent-*, etc.), trace fields, and MIME header fields (MIME-Version, Content-*), when present in the URI, MUST be ignored. The mail client MUST create new fields when necessary, as it would for any new message. Unrecognized header fields and header fields with values inconsistent with those the mail client would normally send SHOULD be treated as especially suspect. For example, there may be header fields that are totally safe but not known to the MUA, so the MUA MAY choose to show them to the user.
当URI中存在发起者字段（如From和Date）、与路由相关的字段（显然是to、Recent-*等）、跟踪字段和MIME头字段（MIME版本、内容-*）时，必须忽略这些字段。邮件客户端必须在必要时创建新字段，这与创建任何新邮件一样。无法识别的头字段和值与邮件客户端通常发送的头字段不一致的头字段应被视为特别可疑。例如，可能存在完全安全但MUA不知道的标题字段，因此MUA可以选择向用户显示它们。
The user agent interpreting a 'mailto' URI SHOULD NOT create a message if any of the header fields are considered dangerous; it MAY also choose to create a message with only a subset of the header fields given in the URI. Only a limited set of header fields such as
如果任何头字段被认为是危险的，则解释“mailto”URI的用户代理不应创建消息；它还可以选择仅使用URI中给定的头字段的子集创建消息。只有一组有限的标题字段，例如
Subject and Keywords, as well as Body, are believed to be both safe and useful in the general case. In cases where the source of a URI is well known, and/or specific header fields are limited to specific well-known values, other header fields MAY be considered safe, too.
在一般情况下，主题和关键词以及主体都被认为是安全和有用的。在URI的源是众所周知的，和/或特定的头字段被限制为特定的已知值的情况下，其他头字段也可能被认为是安全的。
The creator of a 'mailto' URI cannot expect the resolver of a URI to understand more than the "subject" header field and "body". Clients that resolve 'mailto' URIs into mail messages MUST be able to correctly create [RFC5322]-compliant mail messages using the "subject" header field and "body".
“mailto”URI的创建者不能期望URI的解析程序理解的内容超过“subject”头字段和“body”。将“mailto”URI解析为邮件消息的客户端必须能够使用“subject”头字段和“body”正确创建符合[RFC5322]的邮件消息。
[STD66] requires that many characters in URIs be encoded. This affects the 'mailto' URI scheme for some common characters that might appear in addresses, header fields, or message contents. One such character is space (" ", ASCII hex 20). Note the examples below that use "%20" for space in the message body. Also note that line breaks in the body of a message MUST be encoded with "%0D%0A". Implementations MAY add a final line break to the body of a message even if there is no trailing "%0D%0A" in the body <hfield> of the 'mailto' URI. Line breaks in other <hfield>s SHOULD NOT be used.
[STD66]要求对URI中的许多字符进行编码。这会影响可能出现在地址、标题字段或消息内容中的某些常见字符的“mailto”URI方案。一个这样的字符是空格（“，ASCII十六进制20）。请注意下面使用“%20”表示消息正文中空格的示例。还要注意，邮件正文中的换行符必须用“%0D%0A”编码。即使“mailto”URI的正文<hfield>中没有尾随“%0D%0A”，实现也可能会在消息正文中添加最后一行分隔符。不应使用其他<hfield>s中的换行符。
When creating 'mailto' URIs, any reserved characters that are used in the URIs MUST be encoded so that properly written URI interpreters can read them. Also, client software that reads URIs MUST decode strings before creating the mail message so that the mail message appears in a form that the recipient software will understand. These strings SHOULD be decoded before showing the message to the sending user.
创建“mailto”URI时，必须对URI中使用的所有保留字符进行编码，以便正确编写的URI解释器能够读取它们。此外，读取URI的客户端软件必须在创建邮件消息之前对字符串进行解码，以便邮件消息以收件人软件能够理解的形式显示。在向发送用户显示消息之前，应先对这些字符串进行解码。
Software creating 'mailto' URIs likewise has to be careful to encode any reserved characters that are used. HTML forms are one kind of software that creates 'mailto' URIs. Current implementations encode a space as '+', but this creates problems because such a '+' standing for a space cannot be distinguished from a real '+' in a 'mailto' URI. When producing 'mailto' URIs, all spaces SHOULD be encoded as %20, and '+' characters MAY be encoded as %2B. Please note that '+' characters are frequently used as part of an email address to indicate a subaddress, as for example in <bill+ietf@example.org>.
创建“mailto”uri的软件同样必须小心对使用的任何保留字符进行编码。HTML表单是一种创建“mailto”URI的软件。当前的实现将空间编码为“+”，但这会产生问题，因为这样的“+”表示空间，无法与“mailto”URI中的实际“+”区分开来。生成“mailto”URI时，所有空格都应编码为%20，“+”字符可以编码为%2B。请注意，“+”字符经常用作电子邮件地址的一部分，以表示子地址，例如在<bill中+ietf@example.org>.
The 'mailto' URI scheme is limited in that it does not provide for substitution of variables. Thus, it is impossible to create a 'mailto' URI that includes a user's email address in the message body. This limitation also prevents 'mailto' URIs that are signed with public keys and other such variable information.
“mailto”URI方案的局限性在于它不提供变量替换。因此，不可能创建在消息正文中包含用户电子邮件地址的“mailto”URI。此限制还阻止使用公钥和其他此类变量信息签名的“mailto”URI。
A URI for an ordinary individual mailing address:
普通个人邮寄地址的URI：
<mailto:chris@example.com>
<mailto:chris@example.com>
A URI for a mail response system that requires the name of the file to be sent back in the subject:
邮件响应系统的URI，要求在主题中返回文件名：
<mailto:infobot@example.com?subject=current-issue>
<mailto:infobot@example.com?subject=current-issue>
A mail response system that requires a "send" request in the body:
要求正文中有“发送”请求的邮件响应系统：
<mailto:infobot@example.com?body=send%20current-issue>
<mailto:infobot@example.com?body=send%20current-issue>
A similar URI, with two lines with different "send" requests (in this case, "send current-issue" and, on the next line, "send index"):
一个类似的URI，有两行不同的“发送”请求（在本例中为“发送当前问题”，在下一行为“发送索引”）：
<mailto:infobot@
example.com?body=send%20current-issue%0D%0Asend%20index>
<mailto:infobot@
example.com?body=send%20current-issue%0D%0Asend%20index>
An interesting use of 'mailto' URIs occurs when browsing archives of messages. A link can be provided that allows replying to a message and conserving threading information. This is done by adding an In-Reply-To header field containing the Message-ID of the message where the link is added, for example:
浏览邮件存档时，会出现“mailto”URI的有趣用法。可以提供允许回复消息和保存线程信息的链接。这是通过添加一个In Reply To header字段来完成的，该字段包含添加链接的消息的消息ID，例如：
<mailto:list@example.org?In-Reply-To=%3C3469A91.D10AF4C@
example.com%3E>
<mailto:list@example.org?In-Reply-To=%3C3469A91.D10AF4C@
example.com%3E>
A request to subscribe to a mailing list:
订阅邮件列表的请求：
<mailto:majordomo@example.com?body=subscribe%20bamboo-l>
<mailto:majordomo@example.com?body=subscribe%20bamboo-l>
A URI that is for a single user and that includes a CC of another user:
用于单个用户且包含另一用户的CC的URI：
<mailto:joe@example.com?cc=bob@example.com&body=hello>
<mailto:joe@example.com?cc=bob@example.com&body=hello>
Note the use of the "&" reserved character above. The following example, using "?" twice, is incorrect:
注意上面使用的“&”保留字符。以下示例两次使用“？”是不正确的：
<mailto:joe@example.com?cc=bob@example.com?body=hello> ; WRONG!
<mailto:joe@example.com?cc=bob@example.com?body=hello> ; WRONG!
According to [RFC5322], the characters "?", "&", and even "%" may occur in addr-specs. The fact that they are reserved characters is not a problem: those characters may appear in 'mailto' URIs -- they just may not appear in unencoded form. The standard URI encoding mechanisms ("%" followed by a two-digit hex number) MUST be used in these cases.
根据[RFC5322]，字符“？”、“&”甚至“%”可能出现在addr规范中。它们是保留字符这一事实并不是问题：这些字符可能出现在“mailto”URI中——它们可能不会以未编码的形式出现。在这些情况下，必须使用标准URI编码机制（“%”后跟两位十六进制数）。
To indicate the address "gorby%kremvax@example.com" one would use:
表示地址“gorby%kremvax@example.com“可以使用：
<mailto:gorby%25kremvax@example.com>
<mailto:gorby%25kremvax@example.com>
To indicate the address "unlikely?address@example.com", and include another header field, one would use:
表示地址“不太可能？address@example.com，并包括另一个标题字段，可以使用：
<mailto:unlikely%3Faddress@example.com?blat=foop>
<mailto:unlikely%3Faddress@example.com?blat=foop>
As described above, the "&" (ampersand) character is reserved in HTML and has to be replaced, e.g., with "&". Thus, a URI with an internal ampersand might look like:
如上所述，HTML中保留了“&”（符号）字符，必须将其替换为“&；”。因此，带有内部符号AND的URI可能如下所示：
Click <a href="mailto:joe@an.example?cc=bob@an.example&body=hello" >mailto:joe@an.example?cc=bob@an.example&body=hello</a> to send a greeting message to Joe and Bob.
单击<a href=“mailto:joe@an.example？抄送=bob@an.example&；body=hello“>邮件收件人：joe@an.example？抄送=bob@an.example&；body=hello</a>向Joe和Bob发送问候信息。
When an email address itself includes an "&" (ampersand) character, that character has to be percent-encoded. For example, the 'mailto' URI to send mail to "Mike&family@example.org" is <mailto:Mike%26family@example.org>.
当电子邮件地址本身包含“&”（和）字符时，必须对该字符进行百分比编码。例如，要向“Mike”发送邮件的“mailto”URI&family@example.org“是<mailto:Mike%26family@example.org>.
Following are a few examples of how to treat email addresses that contain complicated escaping syntax.
下面是一些如何处理包含复杂转义语法的电子邮件地址的示例。
Email address: "not@me"@example.org; corresponding 'mailto' URI:
电子邮件地址：“not@me“@example.org；对应的“mailto”URI：
<mailto:%22not%40me%22@example.org>.
<mailto:%22不是%40me%22@example.org>.
Email address: "oh\\no"@example.org; corresponding 'mailto' URI:
电子邮件地址：“oh\\no”@example.org；对应的“mailto”URI：
<mailto:%22oh%5C%5Cno%22@example.org>.
<mailto:%22oh%5C%5Cno%22@example.org>.
Email address: "\\\"it's\ ugly\\\""@example.org; corresponding 'mailto' URI:
电子邮件地址：“\\\”它是\sugger\\\”“@example.org；对应的“mailto”URI：
<mailto:%22%5C%5C%5C%22it's%5C%20ugly%5C%5C%5C%22%22@example.org>.
<mailto:%22%5C%5C%5C%22这是%5C%20丑陋的%5C%5C%5C%5C%22%22@example.org>.
Sending a mail with the subject "coffee" in French, i.e., "cafe" where the final e is an e-acute, using UTF-8 and percent-encoding:
使用UTF-8和百分比编码，以法语发送主题为“coffee”的邮件，即“cafe”，其中最后一个e是e-acute：
<mailto:user@example.org?subject=caf%C3%A9>
<mailto:user@example.org?subject=caf%C3%A9>
The same subject, this time using an encoded-word (escaping the "=" and "?" characters used in the encoded-word syntax, because they are reserved):
同一主题，这次使用编码字（转义编码字语法中使用的“=”和“？”字符，因为它们是保留的）：
<mailto:user@
example.org?subject=%3D%3Futf-8%3FQ%3Fcaf%3DC3%3DA9%3F%3D>
<mailto:user@
example.org?subject=%3D%3Futf-8%3FQ%3Fcaf%3DC3%3DA9%3F%3D>
The same subject, this time encoded as iso-8859-1:
同一主题，这次编码为iso-8859-1：
<mailto:user@
example.org?subject=%3D%3Fiso-8859-1%3FQ%3Fcaf%3DE9%3F%3D>
<mailto:user@
example.org?subject=%3D%3Fiso-8859-1%3FQ%3Fcaf%3DE9%3F%3D>
Going back to straight UTF-8 and adding a body with the same value:
返回到直线UTF-8并添加具有相同值的实体：
<mailto:user@example.org?subject=caf%C3%A9&body=caf%C3%A9>
<mailto:user@example.org?subject=caf%C3%A9&body=caf%C3%A9>
This 'mailto' URI may result in a message looking like this:
此“mailto”URI可能会导致出现如下消息：
From: sender@example.net
To: user@example.org
Subject: =?utf-8?Q?caf=C3=A9?=
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: sender@example.net
To: user@example.org
Subject: =?utf-8?Q?caf=C3=A9?=
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
caf=C3=A9
caf=C3=A9
The software sending the email is not restricted to UTF-8, but can use other encodings. The following shows the same email using iso-8859-1 two times:
发送电子邮件的软件不限于UTF-8，但可以使用其他编码。以下显示了两次使用iso-8859-1的同一电子邮件：
From: sender@example.net
To: user@example.org
Subject: =?iso-8859-1?Q?caf=E9?=
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
From: sender@example.net
To: user@example.org
Subject: =?iso-8859-1?Q?caf=E9?=
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
caf=E9
caf=E9
Different content transfer encodings (i.e., "8bit" or "base64" instead of "quoted-printable") and different encodings in encoded words (i.e., "B" instead of "Q") can also be used.
还可以使用不同的内容传输编码（即，“8bit”或“base64”而不是“引用的可打印”）和编码字中的不同编码（即，“B”而不是“Q”）。
For more examples of encoding the word coffee in different languages, see [RFC2324].
有关用不同语言编码单词coffee的更多示例，请参见[RFC2324]。
The following example uses the Japanese word "natto" (Unicode characters U+7D0D U+8C46) as a domain name label, sending a mail to a user at "natto".example.org:
以下示例使用日语单词“natto”（Unicode字符U+7D0D U+8C46）作为域名标签，向位于“natto”的用户发送邮件。example.org：
<mailto:user@%E7%B4%8D%E8%B1%86.example.org?subject=Test&body=NATTO>
<mailto:user@%E7%B4%8D%E8%B1%86.example.org?subject=Test&body=NATTO>
When constructing the email, the domain name label is converted to punycode. The resulting message may look as follows:
构建电子邮件时，域名标签将转换为punycode。结果消息可能如下所示：
From: sender@example.net
To: user@xn--99zt52a.example.org
Subject: Test
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: sender@example.net
To: user@xn--99zt52a.example.org
Subject: Test
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
NATTO
纳托
The 'mailto' URI scheme can be used to send a message from one user to another, and thus can introduce many security concerns. Mail messages can be logged at the originating site, the recipient site, and intermediary sites along the delivery path. If the messages are not encrypted, they can also be read at any of those sites.
“mailto”URI方案可用于从一个用户向另一个用户发送消息，因此可能会带来许多安全问题。邮件消息可以沿传递路径记录在原始站点、收件人站点和中间站点。如果这些消息没有加密，也可以在这些站点中的任何一个读取它们。
A 'mailto' URI gives a template for a message that can be sent by mail client software. The contents of that template may be opaque or difficult to read by the user at the time of specifying the URI, as well as being hidden in the user interface (for example, a link on an HTML Web page might display something other than the content of the corresponding 'mailto' URI that would be used when clicked). Thus, a mail client SHOULD NOT send a message based on a 'mailto' URI without first disclosing and showing to the user the full message that will be sent (including all header fields that were specified by the 'mailto' URI), fully decoded, and asking the user for approval to send the message as electronic mail. The mail client SHOULD also make it clear that the user is about to send an electronic mail message, since the user may not be aware that this is the result of a 'mailto' URI. Users are strongly encouraged to ensure that the 'mailto' URI presented to them matches the address included in the "To:" line of the email message.
“mailto”URI为邮件客户端软件发送的邮件提供了模板。该模板的内容在指定URI时可能不透明或难以被用户读取，并且隐藏在用户界面中（例如，HTML网页上的链接可能显示与单击时使用的相应“mailto”URI内容不同的内容）。因此，邮件客户端不应基于“mailto”URI发送消息，除非首先向用户披露并显示将要发送的完整消息（包括“mailto”URI指定的所有头字段）、完全解码并请求用户批准将消息作为电子邮件发送。邮件客户端还应明确用户即将发送电子邮件，因为用户可能不知道这是“mailto”URI的结果。强烈鼓励用户确保提供给他们的“mailto”URI与电子邮件“to:”行中包含的地址匹配。
Some header fields are inherently unsafe to include in a message generated from a URI. For details, please see Section 3. In general, the fewer header fields interpreted from the URI, the less likely it is that a sending agent will create an unsafe message.
某些标头字段包含在从URI生成的消息中本质上是不安全的。有关详细信息，请参见第3节。通常，从URI解释的头字段越少，发送代理创建不安全消息的可能性就越小。
Examples of problems with sending unapproved mail include:
发送未批准邮件的问题示例包括：
mail that breaks laws upon delivery, such as making illegal threats;
邮寄时违法的邮件，如进行非法威胁；
mail that identifies the sender as someone interested in breaking laws;
将发件人标识为对违法行为感兴趣的人的邮件；
mail that identifies the sender to an unwanted third party;
向不需要的第三方发送标识发件人的邮件；
mail that causes a financial charge to be incurred by the sender;
导致发件人产生财务费用的邮件；
mail that causes an action on the recipient machine that causes damage that might be attributed to the sender.
在收件人计算机上导致可能归因于发件人的损坏的操作的邮件。
Programs that interpret 'mailto' URIs SHOULD ensure that the SMTP envelope return path address, which is given as an argument to the SMTP MAIL FROM command, is set and correct, and that the resulting email is a complete, workable message.
解释“mailto”URI的程序应确保SMTP信封返回路径地址（作为SMTP MAIL FROM命令的参数提供）已设置并正确，并且生成的电子邮件是完整的、可行的邮件。
'mailto' URIs on public Web pages expose mail addresses for harvesting. This applies to all mail addresses that are part of the 'mailto' URI, including the addresses in a "bcc" <hfvalue>. Those addresses will not be sent to the recipients in the 'to' field and in the "to" and "cc" <hfvalue>s, but will still be publicly visible in the URI. Addresses in a "bcc" <hfvalue> may also leak to other addresses in the same <hfvalue> or become known otherwise, depending on the mail user agent used.
公共网页上的“mailto”URI公开了用于获取的邮件地址。这适用于作为“mailto”URI一部分的所有邮件地址，包括“bcc”<hfvalue>中的地址。这些地址不会发送到“收件人”字段以及“收件人”和“抄送”字段中的收件人，但仍将在URI中公开可见。“bcc”<hfvalue>中的地址也可能泄漏到同一<hfvalue>中的其他地址，或者以其他方式被知道，具体取决于所使用的邮件用户代理。
Programs manipulating 'mailto' URIs have to take great care to not inadvertently double-escape or double-unescape 'mailto' URIs, and to make sure that escaping and unescaping conventions relating to URIs and relating to mail addresses are applied in the right order.
操作“mailto”uri的程序必须非常小心，不要无意中双重转义或双重取消转义“mailto”uri，并确保以正确的顺序应用与uri和邮件地址相关的转义和取消转义约定。
Implementations parsing 'mailto' URIs must take care to sanity check 'mailto' URIs in order to avoid buffer overflows and problems resulting from them (e.g., execution of code specified by the attacker).
解析“mailto”uri的实现必须注意对“mailto”uri进行健全检查，以避免缓冲区溢出和由此产生的问题（例如，攻击者指定的代码的执行）。
The security considerations of [STD66], [RFC5890], [RFC5891], and [RFC3987] also apply. Implementers and users are advised to check them carefully.
[STD66]、[RFC5890]、[RFC5891]和[RFC3987]的安全注意事项也适用。建议实施者和用户仔细检查。
This document changes the definition of the 'mailto' URI scheme; the registry of URI schemes has been updated to refer to this document rather than its predecessor, [RFC2368]. The registration template is as follows:
本文档更改了“mailto”URI方案的定义；URI方案注册表已更新，以参考本文档，而不是其前身[RFC2368]。注册模板如下：
URI scheme name: 'mailto'
URI方案名称：“mailto”
Status: permanent
地位：永久
URI scheme syntax: See the syntax section of RFC 6068.
URI方案语法：请参阅RFC6068的语法部分。
URI scheme semantics: See the semantics section of RFC 6068.
URI方案语义：请参阅RFC6068的语义部分。
Encoding considerations: See the syntax and encoding sections of RFC 6068.
编码注意事项：请参阅RFC6068的语法和编码部分。
Applications/protocols that use this URI scheme name: The 'mailto' URI scheme is widely used since the start of the Web.
使用此URI方案名称的应用程序/协议：“mailto”URI方案从Web开始就被广泛使用。
Interoperability considerations: Interoperability for 'mailto' URIs with UTF-8-based percent-encoding might be somewhat lower than interoperability for 'mailto' URIs with US-ASCII only.
互操作性注意事项：“mailto”URI与基于UTF-8的百分比编码的互操作性可能略低于“mailto”URI与仅US-ASCII的互操作性。
Security considerations: See the security considerations section of RFC 6068.
安全注意事项：请参阅RFC 6068的安全注意事项部分。
Contact: IETF
联系人：IETF
Author/Change controller: IETF
作者/变更控制员：IETF
References: RFC 6068
参考文献：RFC6068
IANA has registered the Body header field in the Message Header Fields Registry ([RFC3864]) as follows:
IANA已在消息头字段注册表（[RFC3864]）中注册了正文头字段，如下所示：
Header field name: Body
标题字段名称：正文
Applicable protocol: None. This registration is made to assure that this header field name is not used at all, in order to not create any problems for 'mailto' URIs.
适用协议：无。进行此注册是为了确保根本不使用此标头字段名，以免对“mailto”URI造成任何问题。
Status: reserved
状态：保留
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document(s): RFC 6068
规范文件：RFC 6068
Related information: none
相关信息：无
The main changes from RFC 2368 are as follows:
RFC 2368的主要变化如下：
o Changed syntax from RFC 2822 <mailbox> to [RFC5322] <addr-spec>.
o 将语法从RFC 2822<mailbox>更改为[RFC5322]<addr spec>。
o Allowed UTF-8-based percent-encoding for domain names and in <hfvalue>.
o 允许对域名和<hfvalue>中的基于UTF-8的百分比编码。
o Nailed down percent-encoding in <local-part> to be based on UTF-8, reserved for if and when there is a specification for the internationalization of email addresses.
o <local part>中明确的百分比编码基于UTF-8，保留用于电子邮件地址国际化规范的情况下。
o Removed prohibition against "Bcc:" header fields, but added a warning about their visibility and harvesting for spam.
o 删除了对“密件抄送：”标题字段的禁止，但添加了有关其可见性和垃圾邮件捕获的警告。
o Added clarifications for escaping.
o 增加了逃逸的澄清。
This document was derived from [RFC2368]; the acknowledgments from that specification still apply. In addition, we thank Paul Hoffman for his work on [RFC2368].
本文件来源于[RFC2368]；该规范的确认仍然适用。此外，我们感谢Paul Hoffman在[RFC2368]方面所做的工作。
Valuable input on this document was received from (in no particular order): Alexey Melnikov, Paul Hoffman, Charles Lindsey, Tim Kindberg, Frank Ellermann, Etan Wexler, Michael Haardt, Michael Anthony Puls II, Eliot Lear, Dave Crocker, Dan Harkins, Nevil Brownlee, John Klensin, Alfred Hoenes, Ned Freed, Sean Turner, Peter Saint-Andre, Adrian Farrel, Avshalom Houri, Robert Sparks, and many others.
本文件的宝贵意见来自（无特定顺序）：阿列克谢·梅尔尼科夫、保罗·霍夫曼、查尔斯·林赛、蒂姆·金德伯格、弗兰克·埃勒曼、埃坦·韦克斯勒、迈克尔·哈尔德、迈克尔·安东尼·普尔斯二世、艾略特·李尔、戴夫·克罗克、丹·哈金斯、内维尔·布朗利、约翰·克莱辛、阿尔弗雷德·霍恩斯、内德·弗里德、肖恩·特纳、彼得·圣安德烈、阿德里安·法雷尔、，阿夫沙洛姆·胡里、罗伯特·斯帕克斯和许多其他人。
[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月。
[RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME第三部分：非ASCII文本的消息头扩展”，RFC 20471996年11月。
[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月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[RFC5322] Resnik, P., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnik，P.，“互联网信息格式”，RFC5222008年10月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月。
[STD63] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[STD63]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[STD66]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[STD68] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[STD68]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, April 1998.
[RFC2324]Masinter，L.，“超文本咖啡壶控制协议（HTCPCP/1.0）”，RFC 23241998年4月。
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[RFC2368]Hoffman，P.，Masinter，L.，和J.Zawinski，“邮件URL方案”，RFC 2368，1998年7月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC 49522007年7月。
Authors' Addresses
作者地址
Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever possible, for example as "Dürst" in XML and HTML.) Aoyama Gakuin University 5-10-1 Fuchinobe Sagamihara, Kanagawa 229-8558 Japan
Martin Duerst（注：请尽可能用u-umlaut写“Duerst”，例如用XML和HTML写“Dü；rst”）。青山学院大学5-10-1 Fuchinobe Sagamihara，神奈川229-8558日本
Phone: +81 42 759 6329
Fax: +81 42 759 6495
EMail: duerst@it.aoyama.ac.jp
URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
Phone: +81 42 759 6329
Fax: +81 42 759 6495
EMail: duerst@it.aoyama.ac.jp
URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA
美国加利福尼亚州圣何塞公园大道345号Larry Masinter Adobe系统公司，邮编95110
Phone: +1-408-536-3024
EMail: LMM@acm.org
URI: http://larry.masinter.net/
Phone: +1-408-536-3024
EMail: LMM@acm.org
URI: http://larry.masinter.net/
Jamie Zawinski DNA Lounge 375 Eleventh Street San Francisco, CA 94103 USA
Jamie Zawinski DNA休息室375旧金山第十一街，CA 94103美国
EMail: jwz@jwz.org
EMail: jwz@jwz.org