Network Working Group P. Resnick
Request for Comments: 5738 Qualcomm Incorporated
Updates: 3501 C. Newman
Category: Experimental Sun Microsystems
March 2010
Network Working Group P. Resnick
Request for Comments: 5738 Qualcomm Incorporated
Updates: 3501 C. Newman
Category: Experimental Sun Microsystems
March 2010
IMAP Support for UTF-8
对UTF-8的IMAP支持
Abstract
摘要
This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers.
本规范扩展了Internet消息访问协议版本4rev1（IMAP4rev1），以支持用户名、邮件地址和消息头中的UTF-8编码国际字符。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc5738.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5738.
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. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. UTF8=ACCEPT IMAP Capability . . . . . . . . . . . . . . . . . 3
3.1. IMAP UTF-8 Quoted Strings . . . . . . . . . . . . . . . . 3
3.2. UTF8 Parameter to SELECT and EXAMINE . . . . . . . . . . . 5
3.3. UTF-8 LIST and LSUB Responses . . . . . . . . . . . . . . 5
3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions . . . 6
3.4.1. UTF8 and UTF8ONLY LIST Selection Options . . . . . . . 6
3.4.2. UTF8 LIST Return Option . . . . . . . . . . . . . . . 6
4. UTF8=APPEND Capability . . . . . . . . . . . . . . . . . . . . 7
5. UTF8=USER Capability . . . . . . . . . . . . . . . . . . . . . 7
6. UTF8=ALL Capability . . . . . . . . . . . . . . . . . . . . . 7
7. UTF8=ONLY Capability . . . . . . . . . . . . . . . . . . . . . 8
8. Up-Conversion Server Requirements . . . . . . . . . . . . . . 8
9. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 14
Appendix B. Examples Demonstrating Relationships between
UTF8= Capabilities . . . . . . . . . . . . . . . . . 15
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. UTF8=ACCEPT IMAP Capability . . . . . . . . . . . . . . . . . 3
3.1. IMAP UTF-8 Quoted Strings . . . . . . . . . . . . . . . . 3
3.2. UTF8 Parameter to SELECT and EXAMINE . . . . . . . . . . . 5
3.3. UTF-8 LIST and LSUB Responses . . . . . . . . . . . . . . 5
3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions . . . 6
3.4.1. UTF8 and UTF8ONLY LIST Selection Options . . . . . . . 6
3.4.2. UTF8 LIST Return Option . . . . . . . . . . . . . . . 6
4. UTF8=APPEND Capability . . . . . . . . . . . . . . . . . . . . 7
5. UTF8=USER Capability . . . . . . . . . . . . . . . . . . . . . 7
6. UTF8=ALL Capability . . . . . . . . . . . . . . . . . . . . . 7
7. UTF8=ONLY Capability . . . . . . . . . . . . . . . . . . . . . 8
8. Up-Conversion Server Requirements . . . . . . . . . . . . . . 8
9. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 14
Appendix B. Examples Demonstrating Relationships between
UTF8= Capabilities . . . . . . . . . . . . . . . . . 15
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . . 15
This specification extends IMAP4rev1 [RFC3501] to permit UTF-8 [RFC3629] in headers as described in "Internationalized Email Headers" [RFC5335]. It also adds a mechanism to support mailbox names, login names, and passwords using the UTF-8 charset. This specification creates five new IMAP capabilities to allow servers to advertise these new extensions, along with two new IMAP LIST selection options and a new IMAP LIST return option.
本规范扩展了IMAP4rev1[RFC3501]，允许在“国际化电子邮件头”[RFC5335]中所述的头中使用UTF-8[RFC3629]。它还添加了一种机制来支持使用UTF-8字符集的邮箱名称、登录名和密码。此规范创建了五个新的IMAP功能，允许服务器公布这些新扩展，以及两个新的IMAP列表选择选项和一个新的IMAP列表返回选项。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照“RFC中用于指示需求水平的关键词”中的定义进行解释[RFC2119]。
The formal syntax uses the Augmented Backus-Naur Form (ABNF)
[RFC5234] notation including the core rules defined in Appendix B of
[RFC5234]. In addition, rules from IMAP4rev1 [RFC3501], UTF-8
[RFC3629], "Collected Extensions to IMAP4 ABNF" [RFC4466], and IMAP4
LIST Command Extensions [RFC5258] are also referenced.
The formal syntax uses the Augmented Backus-Naur Form (ABNF)
[RFC5234] notation including the core rules defined in Appendix B of
[RFC5234]. In addition, rules from IMAP4rev1 [RFC3501], UTF-8
[RFC3629], "Collected Extensions to IMAP4 ABNF" [RFC4466], and IMAP4
LIST Command Extensions [RFC5258] are also referenced.
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。如果单个“C:”或“S:”标签适用于多行，则这些行之间的换行符仅用于编辑清晰性，不属于实际协议交换的一部分。
The "UTF8=ACCEPT" capability indicates that the server supports UTF-8 quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and UTF-8 responses from the LIST and LSUB commands.
“UTF8=ACCEPT”功能表示服务器支持UTF-8带引号的字符串、“UTF8”参数进行选择和检查，以及列表和LSUB命令中的UTF-8响应。
A client MUST use the "ENABLE UTF8=ACCEPT" command (defined in [RFC5161]) to indicate to the server that the client accepts UTF-8 quoted-strings. The "ENABLE UTF8=ACCEPT" command MUST only be used in the authenticated state. (Note that the "UTF8=ONLY" capability described in Section 7 and the "UTF8=ALL" capability described in Section 6 imply the "UTF8=ACCEPT" capability. See additional information in these sections.)
客户端必须使用“ENABLE UTF8=ACCEPT”命令（在[RFC5161]中定义）向服务器指示客户端接受UTF-8带引号的字符串。“ENABLE UTF8=ACCEPT”命令只能在经过身份验证的状态下使用。（请注意，第7节中描述的“UTF8=ONLY”功能和第6节中描述的“UTF8=ALL”功能意味着“UTF8=ACCEPT”功能。请参阅这些章节中的其他信息。）
The IMAP4rev1 [RFC3501] base specification forbids the use of 8-bit characters in atoms or quoted strings. Thus, a UTF-8 string can only be sent as a literal. This can be inconvenient from a coding standpoint, and unless the server offers IMAP4 non-synchronizing
IMAP4rev1[RFC3501]基本规范禁止在原子或带引号的字符串中使用8位字符。因此，UTF-8字符串只能作为文本发送。从编码的角度来看，这可能不方便，除非服务器提供IMAP4非同步
literals [RFC2088], this requires an extra round trip for each UTF-8 string sent by the client. When the IMAP server advertises the "UTF8=ACCEPT" capability, it informs the client that it supports native UTF-8 quoted-strings with the following syntax:
文本[RFC2088]，这需要为客户端发送的每个UTF-8字符串提供额外的往返。当IMAP服务器播发“UTF8=ACCEPT”功能时，它会通知客户端它支持本机UTF-8引号字符串，语法如下：
string =/ utf8-quoted
字符串=/utf8引号
utf8-quoted = "*" DQUOTE *UQUOTED-CHAR DQUOTE
utf8-quoted = "*" DQUOTE *UQUOTED-CHAR DQUOTE
UQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4
; UTF8-2, UTF8-3, and UTF8-4 are as defined in RFC 3629
UQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4
; UTF8-2, UTF8-3, and UTF8-4 are as defined in RFC 3629
When this quoting mechanism is used by the client (specifically an octet sequence beginning with *" and ending with "), then the server MUST reject octet sequences with the high bit set that fail to comply with the formal syntax in [RFC3629] with a BAD response.
当客户端使用这种引用机制（特别是以“*”开头并以“*”结尾的八位字节序列）时，服务器必须拒绝高位设置不符合[RFC3629]中正式语法的八位字节序列，并给出错误的响应。
The IMAP server MUST NOT send utf8-quoted syntax to the client unless the client has indicated support for that syntax by using the "ENABLE UTF8=ACCEPT" command.
IMAP服务器不得向客户端发送utf8引号语法，除非客户端使用“ENABLE utf8=ACCEPT”命令指示支持该语法。
If the server advertises the "UTF8=ACCEPT" capability, the client MAY use utf8-quoted syntax with any IMAP argument that permits a string (including astring and nstring). However, if characters outside the US-ASCII repertoire are used in an inappropriate place, the results would be the same as if other syntactically valid but semantically invalid characters were used. For example, if the client includes UTF-8 characters in the user or password arguments (and the server has not advertised "UTF8=USER"), the LOGIN command will fail as it would with any other invalid user name or password. Specific cases where UTF-8 characters are permitted or not permitted are described in the following paragraphs.
如果服务器宣传“UTF8=ACCEPT”功能，则客户端可以将UTF8引号语法与允许字符串的任何IMAP参数（包括astring和nstring）一起使用。但是，如果在不适当的位置使用US-ASCII指令集之外的字符，结果将与使用其他语法有效但语义无效的字符相同。例如，如果客户机在用户参数或密码参数中包含UTF-8字符（并且服务器没有公布“UTF8=user”），则登录命令将失败，因为它将与任何其他无效用户名或密码一样失败。以下段落描述了允许或不允许使用UTF-8字符的具体情况。
All IMAP servers that advertise the "UTF8=ACCEPT" capability SHOULD accept UTF-8 in mailbox names, and those that also support the "Mailbox International Naming Convention" described in RFC 3501, Section 5.1.3 MUST accept utf8-quoted mailbox names and convert them to the appropriate internal format. Mailbox names MUST comply with the Net-Unicode Definition (Section 2 of [RFC5198]) with the specific exception that they MUST NOT contain control characters (0000-001F, 0080-009F), delete (007F), line separator (2028), or paragraph separator (2029).
所有宣传“UTF8=ACCEPT”功能的IMAP服务器都应接受邮箱名称中的UTF-8，并且那些还支持RFC 3501第5.1.3节中描述的“邮箱国际命名约定”的服务器必须接受UTF8引用的邮箱名称，并将其转换为适当的内部格式。邮箱名称必须符合净Unicode定义（RFC5198第2节），但具体的例外情况是它们不得包含控制字符（0000-001F、0080-009F）、删除（007F）、行分隔符（2028）或段落分隔符（2029）。
An IMAP client MUST NOT issue a SEARCH command that uses a mixture of utf8-quoted syntax and a SEARCH CHARSET other than UTF-8. If an IMAP server receives such a SEARCH command, it SHOULD reject the command with a BAD response (due to the conflicting charset labels).
IMAP客户端不得发出混合使用utf8引号语法和UTF-8以外的搜索字符集的搜索命令。如果IMAP服务器收到这样的搜索命令，它应该以错误响应拒绝该命令（由于字符集标签冲突）。
The "UTF8=ACCEPT" capability also indicates that the server supports the "UTF8" parameter to SELECT and EXAMINE. When a mailbox is selected with the "UTF8" parameter, it alters the behavior of all IMAP commands related to message sizes, message headers, and MIME body headers so they refer to the message with UTF-8 headers. If the mailstore is not UTF-8 header native and the SELECT or EXAMINE command with UTF-8 header modifier succeeds, then the server MUST return results as if the mailstore were UTF-8 header native with upconversion requirements as described in Section 8. The server MAY reject the SELECT or EXAMINE command with the [NOT-UTF-8] response code, unless the "UTF8=ALL" or "UTF8=ONLY" capability is advertised.
“UTF8=ACCEPT”功能还表示服务器支持选择和检查“UTF8”参数。当使用“UTF8”参数选择邮箱时，它会更改与邮件大小、邮件标题和MIME正文标题相关的所有IMAP命令的行为，以便它们引用具有UTF-8标题的邮件。如果邮件存储不是UTF-8报头本机，并且使用UTF-8报头修饰符选择或检查命令成功，则服务器必须返回结果，就像邮件存储是UTF-8报头本机，具有上转换要求，如第8节所述。服务器可能会拒绝带有[NOT-UTF-8]响应代码的SELECT或EXAME命令，除非公布了“UTF8=ALL”或“UTF8=ONLY”功能。
Servers MAY include mailboxes that can only be selected or examined if the "UTF8" parameter is provided. However, such mailboxes MUST NOT be included in the output of an unextended LIST, LSUB, or equivalent command. If a client attempts to SELECT or EXAMINE such mailboxes without the "UTF8" parameter, the server MUST reject the command with a [UTF-8-ONLY] response code. As a result, such mailboxes will not be accessible by IMAP clients written prior to this specification and are discouraged unless the server advertises "UTF8=ONLY" or the server implements IMAP4 LIST Command Extensions [RFC5258].
服务器可能包括只有在提供“UTF8”参数的情况下才能选择或检查的邮箱。但是，此类邮箱不得包含在未展开列表、LSUB或等效命令的输出中。如果客户端尝试在没有“UTF8”参数的情况下选择或检查此类邮箱，则服务器必须使用[UTF-8-ONLY]响应代码拒绝该命令。因此，在本规范之前编写的IMAP客户端将无法访问此类邮箱，除非服务器播发“UTF8=ONLY”或服务器实现IMAP4 LIST命令扩展[RFC5258]，否则不建议使用此类邮箱。
utf8-select-param = "UTF8"
;; Conforms to <select-param> from RFC 4466
utf8-select-param = "UTF8"
;; Conforms to <select-param> from RFC 4466
C: a SELECT newmailbox (UTF8)
S: ...
S: a OK SELECT completed
C: b FETCH 1 (SIZE ENVELOPE BODY)
S: ... < UTF-8 header native results >
S: b OK FETCH completed
C: a SELECT newmailbox (UTF8)
S: ...
S: a OK SELECT completed
C: b FETCH 1 (SIZE ENVELOPE BODY)
S: ... < UTF-8 header native results >
S: b OK FETCH completed
C: c EXAMINE legacymailbox (UTF8)
S: c NO [NOT-UTF-8] Mailbox does not support UTF-8 access
C: c EXAMINE legacymailbox (UTF8)
S: c NO [NOT-UTF-8] Mailbox does not support UTF-8 access
C: d SELECT funky-new-mailbox
S: d NO [UTF-8-ONLY] Mailbox requires UTF-8 client
C: d SELECT funky-new-mailbox
S: d NO [UTF-8-ONLY] Mailbox requires UTF-8 client
After an IMAP client successfully issues an "ENABLE UTF8=ACCEPT" command, the server MUST NOT return in LIST results any mailbox names to the client following the IMAP4 Mailbox International Naming Convention. Instead, the server MUST return any mailbox names with characters outside the US-ASCII repertoire using utf8-quoted syntax.
IMAP客户端成功发出“ENABLE UTF8=ACCEPT”命令后，服务器不得在列表结果中按照IMAP4邮箱国际命名约定向客户端返回任何邮箱名称。相反，服务器必须使用utf8引号语法返回任何带有US-ASCII指令表以外字符的邮箱名称。
(The IMAP4 Mailbox International Naming Convention has proved problematic in the past, so the desire is to make this syntax obsolete as quickly as possible.)
（事实证明，IMAP4邮箱国际命名约定在过去是有问题的，因此我们希望尽快淘汰这种语法。）
When an IMAP server advertises both the "UTF8=ACCEPT" capability and the "LIST-EXTENDED" [RFC5258] capability, the server MUST support the LIST extensions described in this section.
当IMAP服务器同时播发“UTF8=ACCEPT”功能和“列表扩展”[RFC5258]功能时，服务器必须支持本节中描述的列表扩展。
The "UTF8" LIST selection option tells the server to include mailboxes that only support UTF-8 headers in the output of the list command. The "UTF8ONLY" LIST selection option tells the server to include all mailboxes that support UTF-8 headers and to exclude mailboxes that don't support UTF-8 headers. Note that "UTF8ONLY" implies "UTF8", so it is not necessary for the client to request both. Use of either selection option will also result in UTF-8 mailbox names in the result as described in Section 3.3 and implies the "UTF8" List return option described in Section 3.4.2.
“UTF8”列表选择选项告诉服务器在LIST命令的输出中包括仅支持UTF-8头的邮箱。“UTF8ONLY”列表选择选项告诉服务器包括所有支持UTF-8头的邮箱，并排除不支持UTF-8头的邮箱。请注意，“UTF8ONLY”意味着“UTF8”，因此客户端不必同时请求这两个选项。如第3.3节所述，使用任一选择选项也将在结果中产生UTF-8邮箱名称，并暗示第3.4.2节所述的“UTF8”列表返回选项。
If the client supplies the "UTF8" LIST return option, then the server MUST include either the "\NoUTF8" or the "\UTF8Only" mailbox attribute as appropriate. The "\NoUTF8" mailbox attribute indicates that an attempt to SELECT or EXAMINE that mailbox with the "UTF8" parameter will fail with a [NOT-UTF-8] response code. The "\UTF8Only" mailbox attribute indicates that an attempt to SELECT or EXAMINE that mailbox without the "UTF8" parameter will fail with a [UTF-8-ONLY] response code. Note that computing this information may be expensive on some server implementations, so this return option should not be used unless necessary.
如果客户端提供“UTF8”列表返回选项，则服务器必须酌情包含“\NoUTF8”或“\UTF8Only”邮箱属性。“\NoUTF8”邮箱属性表示使用“UTF8”参数选择或检查该邮箱的尝试将失败，并返回[NOT-UTF-8]响应代码。“\UTF8Only”邮箱属性表示尝试选择或检查不带“UTF8”参数的邮箱将失败，并返回[UTF-8-ONLY]响应代码。请注意，在某些服务器实现上计算此信息可能会很昂贵，因此除非必要，否则不应使用此返回选项。
The ABNF [RFC5234] for these LIST extensions follows:
这些列表扩展的ABNF[RFC5234]如下所示：
list-select-independent-opt =/ "UTF8"
列表选择独立选项=/“UTF8”
list-select-base-opt =/ "UTF8ONLY"
列表选择基本选项=/“仅限UTF8”
mbx-list-oflag =/ "\NoUTF8" / "\UTF8Only"
mbx-list-oflag =/ "\NoUTF8" / "\UTF8Only"
return-option =/ "UTF8"
返回选项=/“UTF8”
resp-text-code =/ "NOT-UTF-8" / "UTF-8-ONLY"
resp-text-code =/ "NOT-UTF-8" / "UTF-8-ONLY"
If the "UTF8=APPEND" capability is advertised, then the server accepts UTF-8 headers in the APPEND command message argument. A client that sends a message with UTF-8 headers to the server MUST send them using the "UTF8" APPEND data extension. If the server also advertises the CATENATE capability (as specified in [RFC4469]), the client can use the same data extension to include such a message in a CATENATE message part. The ABNF for the APPEND data extension and CATENATE extension follows:
如果公布了“UTF8=APPEND”功能，则服务器在APPEND命令消息参数中接受UTF-8头。向服务器发送带有UTF-8头的消息的客户端必须使用“UTF8”追加数据扩展名发送它们。如果服务器还公布连锁功能（如[RFC4469]中所述），则客户机可以使用相同的数据扩展将此类消息包含在连锁消息部分中。APPEND data扩展和CATENATE扩展的ABNF如下所示：
utf8-literal = "UTF8" SP "(" literal8 ")"
utf8 literal=“utf8”SP”（“literal8”）”
append-data =/ utf8-literal
追加数据=/utf8文本
cat-part =/ utf8-literal
cat零件=/utf8文字
A server that advertises "UTF8=APPEND" has to comply with the requirements of the IMAP base specification and [RFC5322] for message fetching. Mechanisms for 7-bit downgrading to help comply with the standards are discussed in Downgrading mechanism for Internationalized eMail Address (IMA) [RFC5504].
播发“UTF8=APPEND”的服务器必须符合IMAP基本规范和[RFC5322]的消息获取要求。国际电子邮件地址（IMA）降级机制[RFC5504]中讨论了7位降级机制，以帮助遵守标准。
IMAP servers that do not advertise the "UTF8=APPEND" or "UTF8=ONLY" capability SHOULD reject an APPEND command that includes any 8-bit in the message headers with a "NO" response.
未公布“UTF8=APPEND”或“UTF8=ONLY”功能的IMAP服务器应拒绝在消息头中包含任何8位且响应为“NO”的APPEND命令。
Note that the "UTF8=ONLY" capability described in Section 7 implies the "UTF8=APPEND" capability. See additional information in that section.
注意，第7节中描述的“UTF8=ONLY”功能意味着“UTF8=APPEND”功能。请参阅该部分中的其他信息。
If the "UTF8=USER" capability is advertised, that indicates the server accepts UTF-8 user names and passwords and applies SASLprep [RFC4013] to both arguments of the LOGIN command. The server MUST reject UTF-8 that fails to comply with the formal syntax in RFC 3629 [RFC3629] or if it encounters Unicode characters listed in Section 2.3 of SASLprep RFC 4013 [RFC4013].
如果公布了“UTF8=USER”功能，则表示服务器接受UTF-8用户名和密码，并将SASLprep[RFC4013]应用于LOGIN命令的两个参数。如果UTF-8不符合RFC 3629[RFC3629]中的正式语法，或者遇到SASLprep RFC 4013[RFC4013]第2.3节中列出的Unicode字符，则服务器必须拒绝该UTF-8。
The "UTF8=ALL" capability indicates all server mailboxes support UTF-8 headers. Specifically, SELECT and EXAMINE with the "UTF8" parameter will never fail with a [NOT-UTF-8] response code.
“UTF8=ALL”功能表示所有服务器邮箱都支持UTF-8头。具体地说，选择并检查“UTF8”参数将永远不会失败，并显示[NOT-UTF-8]响应代码。
Note that the "UTF8=ONLY" capability described in Section 7 implies the "UTF8=ALL" capability. See additional information in that section.
请注意，第7节中描述的“UTF8=ONLY”功能意味着“UTF8=ALL”功能。请参阅该部分中的其他信息。
Note that the "UTF8=ALL" capability implies the "UTF8=ACCEPT" capability.
请注意，“UTF8=ALL”功能意味着“UTF8=ACCEPT”功能。
The "UTF8=ONLY" capability permits an IMAP server to advertise that it does not support the international mailbox name convention (modified UTF-7), and does not permit selection or examination of any mailbox unless the "UTF8" parameter is provided. As this is an incompatible change to IMAP, a clear warning is necessary. IMAP clients that find implementation of the "UTF8=ONLY" capability problematic are encouraged to at least detect the "UTF8=ONLY" capability and provide an informative error message to the end-user.
“UTF8=ONLY”功能允许IMAP服务器公布其不支持国际邮箱名称约定（修改的UTF-7），并且不允许选择或检查任何邮箱，除非提供了“UTF8”参数。由于这是对IMAP的不兼容更改，因此有必要发出明确警告。建议发现“UTF8=ONLY”功能实现有问题的IMAP客户端至少检测“UTF8=ONLY”功能，并向最终用户提供信息性错误消息。
When an IMAP mailbox internally uses UTF-8 header native storage, the down-conversion step is necessary to permit selection or examination of the mailbox in a backwards compatible fashion will become more difficult to support. Although it is hoped that deployed IMAP servers will not advertise "UTF8=ONLY" for some years, this capability is intended to minimize the disruption when legacy support finally goes away.
当IMAP邮箱在内部使用UTF-8头本机存储时，需要执行下转换步骤，以允许以向后兼容的方式选择或检查邮箱，这将变得更加难以支持。尽管希望已部署的IMAP服务器在几年内不会发布“UTF8=ONLY”广告，但此功能旨在最大限度地减少遗留支持最终消失时的中断。
The "UTF8=ONLY" capability implies the "UTF8=ACCEPT" capability, the "UTF8=ALL" capability, and the "UTF8=APPEND" capability. A server that advertises "UTF8=ONLY" need not advertise the three implicit capabilities.
“UTF8=ONLY”功能意味着“UTF8=ACCEPT”功能、“UTF8=ALL”功能和“UTF8=APPEND”功能。播发“UTF8=ONLY”的服务器不需要播发这三种隐式功能。
When an IMAP4 server uses a traditional mailbox format that includes 7-bit headers and it chooses to permit access to that mailbox with the "UTF8" parameter, it MUST support minimal up-conversion as described in this section.
当IMAP4服务器使用包含7位标头的传统邮箱格式，并选择使用“UTF8”参数允许访问该邮箱时，它必须支持本节所述的最小上转换。
The server MUST support up-conversion of the following address header-fields in the message header: From, Sender, To, CC, Bcc, Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and Reply-To. This up-conversion MUST include address local-parts in fields downgraded according to [RFC5504], address domains encoded according to Internationalizing Domain Names in Applications (IDNA) [RFC3490], and MIME header encoding [RFC2047] of display-names and any [RFC5322] comments.
服务器必须支持邮件标头中以下地址标头字段的上转换：发件人、发件人、收件人、抄送、密件抄送、重新发送发件人、重新发送至、重新发送抄送、重新发送密件抄送和回复至。此上转换必须包括根据[RFC5504]降级的字段中的地址本地部分、根据应用程序中的国际化域名（IDNA）[RFC3490]编码的地址域以及显示名称和任何[RFC5322]注释的MIME头编码[RFC2047]。
The following charsets MUST be supported for up-conversion of MIME header encoding [RFC2047]: UTF-8, US-ASCII, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-14, and ISO-8859-15. If the server supports other charsets in IMAP SEARCH or IMAP CONVERT [RFC5259], it SHOULD also support those charsets in this conversion.
MIME头编码[RFC2047]的上转换必须支持以下字符集：UTF-8、US-ASCII、ISO-8859-1、ISO-8859-2、ISO-8859-3、ISO-8859-4、ISO-8859-5、ISO-8859-6、ISO-8859-7、ISO-8859-8、ISO-8859-9、ISO-8859-10、ISO-8859-14和ISO-8859-15。如果服务器支持IMAP SEARCH或IMAP CONVERT[RFC5259]中的其他字符集，则它还应支持此转换中的这些字符集。
Up-conversion of MIME header encoding of the following headers MUST also be implemented: Subject, Date ([RFC5322] comments only), Comments, Keywords, and Content-Description.
还必须实现以下标头的MIME标头编码的上转换：主题、日期（仅限[RFC5322]注释）、注释、关键字和内容描述。
Server implementations also SHOULD up-convert all MIME body headers [RFC2045], SHOULD up-convert or remove the deprecated (and misused) "name" parameter [RFC1341] on Content-Type, and MUST up-convert the Content-Disposition [RFC2183] "filename" parameter, except when any of these are contained within a multipart/signed MIME body part (see below). These parameters can be encoded using the standard MIME parameter encoding [RFC2231] mechanism, or via non-standard use of MIME header encoding [RFC2047] in quoted strings.
服务器实现还应该向上转换所有MIME正文头[RFC2045]，应该向上转换或删除内容类型上不推荐使用（和误用）的“名称”参数[RFC1341]，并且必须向上转换内容处置[RFC2183]“文件名”参数，除非其中任何一个包含在多部分/签名MIME正文部分中（请参见下文）。这些参数可以使用标准MIME参数编码[RFC2231]机制进行编码，或者通过非标准使用带引号的字符串中的MIME头编码[RFC2047]进行编码。
The IMAP server MUST NOT perform up-conversion of headers and content of multipart/signed, as well as Original-Recipient and Return-Path.
IMAP服务器不得对多部分/已签名的邮件头和内容以及原始收件人和返回路径执行上转换。
When an IMAP server uses a mailbox format that supports UTF-8 headers and it permits selection or examination of that mailbox without the "UTF8" parameter, it is the responsibility of the server to comply with the IMAP4rev1 base specification [RFC3501] and [RFC5322] with respect to all header information transmitted over the wire. Mechanisms for 7-bit downgrading to help comply with the standards are discussed in "Downgrading Mechanism for Email Address Internationalization" [RFC5504].
当IMAP服务器使用支持UTF-8报头的邮箱格式，并且允许在不使用“UTF8”参数的情况下选择或检查该邮箱时，服务器有责任遵守IMAP4rev1基本规范[RFC3501]和[RFC5322]中通过线路传输的所有报头信息。“电子邮件地址国际化的降级机制”[RFC5504]中讨论了帮助遵守标准的7位降级机制。
An IMAP server with a mailbox that supports UTF-8 headers MUST comply with the protocol requirements implicit from Section 8. However, the code necessary for such compliance need not be part of the IMAP server itself in this case. For example, the minimal required up-conversion could be performed when a message is inserted into the IMAP-accessible mailbox.
带有支持UTF-8头的邮箱的IMAP服务器必须符合第8节中隐含的协议要求。但是，在这种情况下，这种遵从性所需的代码不必是IMAP服务器本身的一部分。例如，将邮件插入IMAP可访问邮箱时，可以执行所需的最小上转换。
This adds five new capabilities ("UTF8=ACCEPT", "UTF8=USER", "UTF8=APPEND", "UTF8=ALL", and "UTF8=ONLY") to the IMAP4rev1 Capabilities registry [RFC3501].
这将向IMAP4rev1功能注册表[RFC3501]添加五个新功能（“UTF8=ACCEPT”、“UTF8=USER”、“UTF8=APPEND”、“UTF8=ALL”和“UTF8=ONLY”）。
This adds two new IMAP4 list selection options and one new IMAP4 list return option.
这将添加两个新的IMAP4列表选择选项和一个新的IMAP4列表返回选项。
1. LIST-EXTENDED option name: UTF8
1. 列表扩展选项名称：UTF8
LIST-EXTENDED option type: SELECTION
列表扩展选项类型：选择
Implied return options(s): UTF8
隐含回报选项：UTF8
LIST-EXTENDED option description: Causes the LIST response to include mailboxes that mandate the UTF8 SELECT/EXAMINE parameter.
LIST-EXTENDED选项说明：使列表响应包括强制使用UTF8 SELECT/EXAMINE参数的邮箱。
Published specification: RFC 5738, Section 3.4.1
已发布规范：RFC 5738，第3.4.1节
Security considerations: RFC 5738, Section 11
安全注意事项：RFC 5738，第11节
Intended usage: COMMON
预期用途：普通
Person and email address to contact for further information: see the Authors' Addresses at the end of this specification
联系人和电子邮件地址以获取更多信息：请参阅本规范末尾的作者地址
Owner/Change controller: iesg@ietf.org
Owner/Change controller: iesg@ietf.org
2. LIST-EXTENDED option name: UTF8ONLY
2. 列表扩展选项名称：仅限UTF8
LIST-EXTENDED option type: SELECTION
列表扩展选项类型：选择
Implied return options(s): UTF8
隐含回报选项：UTF8
LIST-EXTENDED option description: Causes the LIST response to include mailboxes that mandate the UTF8 SELECT/EXAMINE parameter and exclude mailboxes that do not support the UTF8 SELECT/EXAMINE parameter.
LIST-EXTENDED选项说明：使列表响应包括强制使用UTF8选择/检查参数的邮箱，并排除不支持UTF8选择/检查参数的邮箱。
Published specification: RFC 5738, Section 3.4.1
已发布规范：RFC 5738，第3.4.1节
Security considerations: RFC 5738, Section 11
安全注意事项：RFC 5738，第11节
Intended usage: COMMON
预期用途：普通
Person and email address to contact for further information: see the Authors' Addresses at the end of this specification
联系人和电子邮件地址以获取更多信息：请参阅本规范末尾的作者地址
Owner/Change controller: iesg@ietf.org
Owner/Change controller: iesg@ietf.org
3. LIST-EXTENDED option name: UTF8
3. 列表扩展选项名称：UTF8
LIST-EXTENDED option type: RETURN
列表扩展选项类型：返回
Implied return options(s): none
隐含回报选项：无
LIST-EXTENDED option description: Causes the LIST response to include \NoUTF8 and \UTF8Only mailbox attributes.
LIST-EXTENDED选项说明：导致列表响应仅包含\n0TF8和\uTF8邮箱属性。
Published specification: RFC 5738, Section 3.4.1
已发布规范：RFC 5738，第3.4.1节
Security considerations: RFC 5738, Section 11
安全注意事项：RFC 5738，第11节
Intended usage: COMMON
预期用途：普通
Person and email address to contact for further information: see the Authors' Addresses at the end of this specification
联系人和电子邮件地址以获取更多信息：请参阅本规范末尾的作者地址
Owner/Change controller: iesg@ietf.org
Owner/Change controller: iesg@ietf.org
The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] apply to this specification, particularly with respect to use of UTF-8 in user names and passwords. Otherwise, this is not believed to alter the security considerations of IMAP4rev1.
UTF-8[RFC3629]和SASLprep[RFC4013]的安全注意事项适用于本规范，特别是在用户名和密码中使用UTF-8方面。否则，这不会改变IMAP4rev1的安全考虑。
[RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, June 1992.
[RFC1341]Borenstein，N.和N.Freed，“MIME（多用途Internet邮件扩展）：指定和描述Internet邮件正文格式的机制”，RFC 13411992年6月。
[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 (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月。
[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月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183]Troost，R.，Dorner，S.，和K.Moore，“在Internet消息中传递表示信息：内容处置头字段”，RFC 2183，1997年8月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年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月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC40113，2005年2月。
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[RFC4466]Melnikov，A.和C.Daboo，“IMAP4 ABNF的收集扩展”，RFC4466，2006年4月。
[RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, April 2006.
[RFC4469]Resnick，P.，“互联网消息访问协议（IMAP）连锁扩展”，RFC4469，2006年4月。
[RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE Extension", RFC 5161, March 2008.
[RFC5161]Gulbrandsen，A.和A.Melnikov，“IMAP启用扩展”，RFC 51612008年3月。
[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月。
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access Protocol version 4 - LIST Command Extensions", RFC 5258, June 2008.
[RFC5258]Leiba，B.和A.Melnikov，“互联网消息访问协议第4版-列表命令扩展”，RFC 5258，2008年6月。
[RFC5259] Melnikov, A. and P. Coates, "Internet Message Access Protocol - CONVERT Extension", RFC 5259, July 2008.
[RFC5259]Melnikov，A.和P.Coates，“互联网消息访问协议-转换扩展”，RFC 5259，2008年7月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335]Abel，Y.，“国际化电子邮件标题”，RFC 53352008年9月。
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.
[RFC5504]Fujiwara，K.和Y.Yoneya，“电子邮件地址国际化的降级机制”，RFC 55042009年3月。
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[RFC2049]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[RFC2088]迈尔斯，J.，“IMAP4非同步文字”，RFC2088，1997年1月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277]Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8", RFC 5721, February 2010.
[RFC5721]Gellens，R.和C.Newman，“UTF-8的POP3支持”，RFC 57212010年2月。
This non-normative section discusses the reasons behind some of the design choices in the above specification.
本非规范性章节讨论了上述规范中某些设计选择背后的原因。
The basic approach of advertising the ability to access a mailbox in UTF-8 mode is intended to permit graceful upgrade, including servers that support multiple mailbox formats. In particular, it would be undesirable to force conversion of an entire server mailstore to UTF-8 headers, so being able to phase-in support for new mailboxes and gradually migrate old mailboxes is permitted by this design.
宣传以UTF-8模式访问邮箱的能力的基本方法旨在允许优雅的升级，包括支持多种邮箱格式的服务器。特别是，强制将整个服务器邮件存储转换为UTF-8头是不可取的，因此这种设计允许分阶段支持新邮箱并逐步迁移旧邮箱。
"UTF8=USER" is optional because many identity systems are US-ASCII only, so it's helpful to inform the client up front that UTF-8 won't work.
“UTF8=USER”是可选的，因为许多标识系统仅为US-ASCII，因此提前通知客户UTF-8不起作用是有帮助的。
"UTF8=APPEND" is optional because it effectively requires IMAP server support for down-conversion, which is a much more complex operation than up-conversion.
“UTF8=APPEND”是可选的，因为它实际上需要IMAP服务器支持下转换，下转换比上转换复杂得多。
The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability problems when legacy support goes away. In the situation where backwards compatibility is broken anyway, just-send-UTF-8 IMAP has the advantage that it might work with some legacy clients. However, the difficulty of diagnosing interoperability problems caused by a just-send-UTF-8 IMAP mechanism is the reason the "UTF8=ONLY" capability mechanism was chosen.
“UTF8=ONLY”机制简化了在旧式支持消失时互操作性问题的诊断。在向后兼容性无论如何都会被破坏的情况下，just-send-UTF-8imap的优点是它可以与一些遗留客户端一起工作。然而，just-send-UTF-8 IMAP机制导致的互操作性问题诊断困难是选择“UTF8=ONLY”功能机制的原因。
The up-conversion requirements are designed to balance the desire to deprecate and eventually eliminate complicated encodings (like MIME header encodings) without creating a significant deployment burden for servers. As IMAP4 servers already require a MIME parser, this includes additional server up-conversion requirements not present in POP3 Support for UTF-8 [RFC5721].
上转换要求旨在平衡不赞成和最终消除复杂编码（如MIME头编码）的愿望，而不会给服务器造成重大的部署负担。由于IMAP4服务器已经需要MIME解析器，这包括额外的服务器上转换要求，而UTF-8[RFC5721]的POP3支持中不存在这种要求。
The set of mandatory charsets comes from two sources: MIME requirements [RFC2049] and IETF Policy on Character Sets [RFC2277]. Including a requirement to up-convert widely deployed encoded ideographic charsets to UTF-8 would be reasonable for most scenarios, but may require unacceptable table sizes for some embedded devices. The open-ended recommendation to support widely deployed charsets avoids the political ramifications of attempting to list such charsets. The authors believe market forces, existing open-source software, and public conversion tables are sufficient to deploy the appropriate charsets.
强制字符集集有两个来源：MIME要求[RFC2049]和IETF字符集策略[RFC2277]。在大多数情况下，将广泛部署的编码表意字符集上转换为UTF-8的要求是合理的，但对于某些嵌入式设备，可能需要不可接受的表大小。支持广泛部署的字符集的开放式建议避免了试图列出此类字符集的政治后果。作者认为，市场力量、现有开源软件和公共转换表足以部署适当的字符集。
Appendix B. Examples Demonstrating Relationships between UTF8= Capabilities
附录B.证明UTF8=能力之间关系的示例
UTF8=ACCEPT UTF8=USER UTF8=APPEND
UTF8=ACCEPT UTF8=ALL
UTF8=ALL ; Note, same as above
UTF8=ACCEPT UTF8=USER UTF8=APPEND UTF8=ALL UTF8=ONLY
UTF8=USER UTF8=ONLY ; Note, same as above
UTF8=ACCEPT UTF8=USER UTF8=APPEND
UTF8=ACCEPT UTF8=ALL
UTF8=ALL ; Note, same as above
UTF8=ACCEPT UTF8=USER UTF8=APPEND UTF8=ALL UTF8=ONLY
UTF8=USER UTF8=ONLY ; Note, same as above
The authors wish to thank the participants of the EAI working group for their contributions to this document with particular thanks to Harald Alvestrand, David Black, Randall Gellens, Arnt Gulbrandsen, Kari Hurtta, John Klensin, Xiaodong Lee, Charles Lindsey, Alexey Melnikov, Subramanian Moonesamy, Shawn Steele, Daniel Taharlev, and Joseph Yee for their specific contributions to the discussion.
作者希望感谢EAI工作组的参与者对本文件的贡献，特别感谢Harald Alvestrand、David Black、Randall Gellens、Arnt Gulbrandsen、Kari Hurta、John Klensin、Lee晓东、Charles Lindsey、Alexey Melnikov、Subramanian Moonesamy、Shawn Steele、Daniel Taharlev、，以及Joseph Yee对讨论的具体贡献。
Authors' Addresses
作者地址
Pete Resnick Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 US
美国加利福尼亚州圣地亚哥莫豪斯大道5775号Pete Resnick高通公司，邮编92121-1714
Phone: +1 858 651 4478
EMail: presnick@qualcomm.com
URI: http://www.qualcomm.com/~presnick/
Phone: +1 858 651 4478
EMail: presnick@qualcomm.com
URI: http://www.qualcomm.com/~presnick/
Chris Newman Sun Microsystems 800 Royal Oaks Monrovia, CA 91016 US
克里斯纽曼太阳微系统800皇家橡树园蒙罗维亚，加利福尼亚州91016美国
EMail: chris.newman@sun.com
EMail: chris.newman@sun.com