Internet Engineering Task Force (IETF) P. Resnick, Ed.
Request for Comments: 6855 Qualcomm Incorporated
Obsoletes: 5738 C. Newman, Ed.
Category: Standards Track Oracle
ISSN: 2070-1721 S. Shen, Ed.
CNNIC
March 2013
Internet Engineering Task Force (IETF) P. Resnick, Ed.
Request for Comments: 6855 Qualcomm Incorporated
Obsoletes: 5738 C. Newman, Ed.
Category: Standards Track Oracle
ISSN: 2070-1721 S. Shen, Ed.
CNNIC
March 2013
IMAP Support for UTF-8
对UTF-8的IMAP支持
Abstract
摘要
This specification extends the Internet Message Access Protocol (IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 5738.
本规范扩展了Internet消息访问协议（IMAP），以支持用户名、邮件地址和消息头中的UTF-8编码国际字符。本规范取代RFC 5738。
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/rfc6855.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6855.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. "UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP
Quoted-Strings . . . . . . . . . . . . . . . . . . . . . . . . 3
4. IMAP UTF8 "APPEND" Data Extension . . . . . . . . . . . . . . 4
5. "LOGIN" Command and UTF-8 . . . . . . . . . . . . . . . . . . 5
6. "UTF8=ONLY" Capability . . . . . . . . . . . . . . . . . . . . 5
7. Dealing with Legacy Clients . . . . . . . . . . . . . . . . . 6
8. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 11
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. "UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP
Quoted-Strings . . . . . . . . . . . . . . . . . . . . . . . . 3
4. IMAP UTF8 "APPEND" Data Extension . . . . . . . . . . . . . . 4
5. "LOGIN" Command and UTF-8 . . . . . . . . . . . . . . . . . . 5
6. "UTF8=ONLY" Capability . . . . . . . . . . . . . . . . . . . . 5
7. Dealing with Legacy Clients . . . . . . . . . . . . . . . . . 6
8. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 11
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 11
This specification forms part of the Email Address Internationalization protocols described in the Email Address Internationalization Framework document [RFC6530]. It extends IMAP [RFC3501] to permit UTF-8 [RFC3629] in headers, as described in "Internationalized Email Headers" [RFC6532]. It also adds a mechanism to support mailbox names using the UTF-8 charset. This specification creates two new IMAP capabilities to allow servers to advertise these new extensions.
本规范构成电子邮件地址国际化框架文档[RFC6530]中描述的电子邮件地址国际化协议的一部分。它扩展了IMAP[RFC3501]以允许在标头中使用UTF-8[RFC3629]，如“国际化电子邮件标头”[RFC6532]中所述。它还添加了一种机制来支持使用UTF-8字符集的邮箱名称。该规范创建了两个新的IMAP功能，允许服务器发布这些新扩展。
This specification assumes that the IMAP server will be operating in a fully internationalized environment, i.e., one in which all clients accessing the server will be able to accept non-ASCII message header fields and other information, as specified in Section 3. At least during a transition period, that assumption will not be realistic for many environments; the issues involved are discussed in Section 7 below.
本规范假设IMAP服务器将在完全国际化的环境中运行，即所有访问服务器的客户端将能够接受非ASCII消息头字段和其他信息，如第3节所述。至少在过渡期内，这种假设在许多环境中是不现实的；下文第7节讨论了涉及的问题。
This specification replaces an earlier, experimental approach to the same problem [RFC5738].
本规范取代了以前针对同一问题的实验方法[RFC5738]。
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. In addition, rules from IMAP [RFC3501], UTF-8 [RFC3629], Extensions to IMAP ABNF [RFC4466], and IMAP "LIST" command extensions [RFC5258] are also referenced. This document assumes that the reader will have a reasonably good understanding of these RFCs.
形式语法使用增广的Backus-Naur形式（ABNF）[RFC5234]表示法。此外，还引用了来自IMAP[RFC3501]、UTF-8[RFC3629]、IMAP ABNF[RFC4466]扩展和IMAP“列表”命令扩展[RFC5258]的规则。本文件假设读者对这些RFC有相当好的理解。
The "UTF8=ACCEPT" capability indicates that the server supports the ability to open mailboxes containing internationalized messages with the "SELECT" and "EXAMINE" commands, and the server can provide UTF-8 responses to the "LIST" and "LSUB" commands. This capability also affects other IMAP extensions that can return mailbox names or their prefixes, such as NAMESPACE [RFC2342] and ACL [RFC4314].
“UTF8=ACCEPT”功能表示服务器支持使用“选择”和“检查”命令打开包含国际化邮件的邮箱，并且服务器可以对“列表”和“LSUB”命令提供UTF-8响应。此功能还影响其他可以返回邮箱名称或其前缀的IMAP扩展，如命名空间[RFC2342]和ACL[RFC4314]。
The "UTF8=ONLY" capability, described in Section 6, implies the "UTF8=ACCEPT" capability. A server is said to support "UTF8=ACCEPT" if it advertises either "UTF8=ACCEPT" or "UTF8=ONLY".
第6节中描述的“UTF8=ONLY”功能意味着“UTF8=ACCEPT”功能。如果服务器播发“UTF8=ACCEPT”或“UTF8=ONLY”，则称其支持“UTF8=ACCEPT”。
A client MUST use the "ENABLE" command [RFC5161] with the "UTF8=ACCEPT" option (defined in Section 4 below) to indicate to the server that the client accepts UTF-8 in quoted-strings and supports the "UTF8=ACCEPT" extension. The "ENABLE UTF8=ACCEPT" command is only valid in the authenticated state.
客户机必须使用带有“UTF8=ACCEPT”选项的“ENABLE”命令[RFC5161]（在下面的第4节中定义）向服务器指示客户机接受带引号字符串的UTF-8，并支持“UTF8=ACCEPT”扩展。“ENABLE UTF8=ACCEPT”命令仅在经过身份验证的状态下有效。
The IMAP base specification [RFC3501] 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 IMAP non-synchronizing literals [RFC2088], this requires an extra round trip for each UTF-8 string sent by the client. When the IMAP server supports "UTF8=ACCEPT", it supports UTF-8 in quoted-strings with the following syntax:
IMAP基本规范[RFC3501]禁止在原子或带引号的字符串中使用8位字符。因此，UTF-8字符串只能作为文本发送。从编码的角度来看，这可能会很不方便，除非服务器提供IMAP非同步文本[RFC2088]，否则客户端发送的每个UTF-8字符串都需要额外的往返。当IMAP服务器支持“UTF8=ACCEPT”时，它支持带引号的字符串中的UTF-8，语法如下：
quoted =/ DQUOTE *uQUOTED-CHAR DQUOTE ; QUOTED-CHAR is not modified, as it will affect ; other RFC 3501 ABNF non-terminals.
quoted=/DQUOTE*uQUOTED字符DQUOTE；QUOTED-CHAR不会被修改，因为它会影响；其他RFC 3501 ABNF非终端。
uQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4
uQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <Defined in Section 4 of RFC 3629>
UTF8-2 = <Defined in Section 4 of RFC 3629>
UTF8-3 = <Defined in Section 4 of RFC 3629>
UTF8-3 = <Defined in Section 4 of RFC 3629>
UTF8-4 = <Defined in Section 4 of RFC 3629>
UTF8-4 = <Defined in Section 4 of RFC 3629>
When this extended quoting mechanism is used by the client, the server MUST reject, with a "BAD" response, any octet sequences with
当客户端使用这种扩展的引用机制时，服务器必须以“坏”响应拒绝任何具有
the high bit set that fail to comply with the formal syntax requirements of UTF-8 [RFC3629]. The IMAP server MUST NOT send UTF-8 in quoted-strings to the client unless the client has indicated support for that syntax by using the "ENABLE UTF8=ACCEPT" command.
不符合UTF-8[RFC3629]正式语法要求的高位集。IMAP服务器不得向客户端发送带引号字符串的UTF-8，除非客户端使用“ENABLE UTF8=ACCEPT”命令表示支持该语法。
If the server supports "UTF8=ACCEPT", the client MAY use extended 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. Specific cases where UTF-8 characters are permitted or not permitted are described in the following paragraphs.
如果服务器支持“UTF8=ACCEPT”，则客户端可以将扩展引号语法与允许字符串的任何IMAP参数（包括astring和nstring）一起使用。但是，如果在不适当的位置使用US-ASCII指令集之外的字符，结果将与使用其他语法有效但语义无效的字符相同。以下段落描述了允许或不允许使用UTF-8字符的具体情况。
All IMAP servers that support "UTF8=ACCEPT" 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 ([RFC5198], Section 2) with the specific exception that they MUST NOT contain control characters (U+0000-U+001F and U+0080-U+ 009F), a delete character (U+007F), a line separator (U+2028), or a paragraph separator (U+2029).
所有支持“UTF8=ACCEPT”的IMAP服务器都应接受邮箱名称中的UTF-8，并且那些还支持RFC 3501第5.1.3节中描述的邮箱国际命名约定的服务器必须接受UTF8引用的邮箱名称，并将其转换为适当的内部格式。邮箱名称必须符合净Unicode定义（[RFC5198]，第2节），但具体的例外情况是它们不得包含控制字符（U+0000-U+001F和U+0080-U+009F）、删除字符（U+007F）、行分隔符（U+2028）或段落分隔符（U+2029）。
Once an IMAP client has enabled UTF-8 support with the "ENABLE UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that contains a charset specification. If an IMAP server receives such a "SEARCH" command in that situation, it SHOULD reject the command with a "BAD" response (due to the conflicting charset labels).
IMAP客户端使用“ENABLE UTF8=ACCEPT”命令启用UTF-8支持后，不得发出包含字符集规范的“SEARCH”命令。如果IMAP服务器在这种情况下收到这样的“搜索”命令，它应该以“错误”响应拒绝该命令（由于字符集标签冲突）。
If the server supports "UTF8=ACCEPT", 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" data extension to the "APPEND" command. If the server also advertises the "CATENATE" capability [RFC4469], the client can use the same data extension to include such a message in a catenated message part. The ABNF for the "APPEND" data extension and "CATENATE" extension follows:
如果服务器支持“UTF8=ACCEPT”，则服务器接受“APPEND”命令消息参数中的UTF-8头。向服务器发送带有UTF-8头的消息的客户端必须使用“APPEND”命令的“UTF8”数据扩展名发送消息。如果服务器还宣传“连锁”功能[RFC4469]，则客户机可以使用相同的数据扩展将此类消息包含在连锁消息部分中。“附加”数据扩展和“链接”扩展的ABNF如下所示：
utf8-literal = "UTF8" SP "(" literal8 ")"
utf8 literal=“utf8”SP”（“literal8”）”
literal8 = <Defined in RFC 4466>
literal8 = <Defined in RFC 4466>
append-data =/ utf8-literal
追加数据=/utf8文本
cat-part =/ utf8-literal
cat零件=/utf8文字
If an IMAP server supports "UTF8=ACCEPT" and the IMAP client has not issued the "ENABLE UTF8=ACCEPT" command, the server MUST reject, with a "NO" response, an "APPEND" command that includes any 8-bit character in message header fields.
如果IMAP服务器支持“UTF8=ACCEPT”，并且IMAP客户端尚未发出“ENABLE UTF8=ACCEPT”命令，则服务器必须拒绝包含消息头字段中任何8位字符的“APPEND”命令，并给出“NO”响应。
This specification does not extend the IMAP "LOGIN" command [RFC3501] to support UTF-8 usernames and passwords. Whenever a client needs to use UTF-8 usernames or passwords, it MUST use the IMAP "AUTHENTICATE" command, which is already capable of passing UTF-8 usernames and credentials.
本规范不扩展IMAP“LOGIN”命令[RFC3501]以支持UTF-8用户名和密码。每当客户端需要使用UTF-8用户名或密码时，它必须使用IMAP“AUTHENTICATE”命令，该命令已经能够传递UTF-8用户名和凭据。
Although using the IMAP "AUTHENTICATE" command in this way makes it syntactically legal to have a UTF-8 username or password, there is no guarantee that the user provisioning system utilized by the IMAP server will allow such identities. This is an implementation decision and may depend on what identity system the IMAP server is configured to use.
尽管以这种方式使用IMAP“AUTHENTICATE”命令使拥有UTF-8用户名或密码在语法上合法，但不能保证IMAP服务器使用的用户配置系统将允许此类身份。这是一个实施决策，可能取决于IMAP服务器配置为使用的标识系统。
The "UTF8=ONLY" capability indicates that the server supports "UTF8=ACCEPT" (see Section 4) and that it requires support for UTF-8 from clients. In particular, this means that the server will send UTF-8 in quoted-strings, and it will not accept the older international mailbox name convention (modified UTF-7 [RFC3501]). Because these are incompatible changes to IMAP, explicit server announcement and client confirmation is necessary: clients MUST use the "ENABLE UTF8=ACCEPT" command before using this server. A server that advertises "UTF8=ONLY" will reject, with a "NO [CANNOT]" response [RFC5530], any command that might require UTF-8 support and is not preceded by an "ENABLE UTF8=ACCEPT" command.
“UTF8=ONLY”功能表示服务器支持“UTF8=ACCEPT”（参见第4节），并且需要客户端对UTF-8的支持。特别是，这意味着服务器将以带引号的字符串发送UTF-8，并且不接受旧的国际邮箱名称约定（修改的UTF-7[RFC3501]）。因为这些是对IMAP的不兼容更改，所以需要明确的服务器公告和客户端确认：客户端在使用此服务器之前必须使用“ENABLE UTF8=ACCEPT”命令。播发“UTF8=ONLY”的服务器将以“NO[CANNOT]”响应[RFC5530]拒绝任何可能需要UTF-8支持且前面没有“ENABLE UTF8=ACCEPT”命令的命令。
IMAP clients that find support for a server that announces "UTF8=ONLY" problematic are encouraged to at least detect the announcement and provide an informative error message to the end-user.
如果IMAP客户机发现对宣布“UTF8=ONLY”有问题的服务器的支持，则鼓励其至少检测该宣布，并向最终用户提供信息性错误消息。
Because the "UTF8=ONLY" server capability includes support for "UTF8=ACCEPT", the capability string will include, at most, one of those and never both. For the client, "ENABLE UTF8=ACCEPT" is always used -- never "ENABLE UTF8=ONLY".
因为“UTF8=ONLY”服务器功能包含对“UTF8=ACCEPT”的支持，所以功能字符串最多包含其中一个，而不会同时包含两个。对于客户端，始终使用“ENABLE UTF8=ACCEPT”，而不是“ENABLE UTF8=ONLY”。
In most situations, it will be difficult or impossible for the implementer or operator of an IMAP (or POP) server to know whether all of the clients that might access it, or the associated mail store more generally, will be able to support the facilities defined in this document. In almost all cases, servers that conform to this specification will have to be prepared to deal with clients that do not enable the relevant capabilities. Unfortunately, there is no completely satisfactory way to do so other than for systems that wish to receive email that requires SMTPUTF8 capabilities to be sure that all components of those systems -- including IMAP and other clients selected by users -- are upgraded appropriately.
在大多数情况下，IMAP（或POP）服务器的实现者或操作员很难或不可能知道可能访问它的所有客户机，或者更一般地说，关联的邮件存储是否能够支持本文档中定义的功能。在几乎所有情况下，符合此规范的服务器都必须准备好处理未启用相关功能的客户端。不幸的是，除了需要SMTPUTF8功能以确保这些系统的所有组件（包括IMAP和用户选择的其他客户端）都得到适当升级的希望接收电子邮件的系统之外，没有完全令人满意的方法。
When a message that requires SMTPUTF8 is encountered and the client does not enable UTF-8 capability, choices available to the server include hiding the problematic message(s), creating in-band or out-of-band notifications or error messages, or somehow trying to create a surrogate of the message with the intention of providing useful information to that client about what has occurred. Such surrogate messages cannot be actual substitutes for the original message: they will almost always be impossible to reply to (either at all or without loss of information) and the new header fields or specialized constructs for server-client communications may go beyond the requirements of current email specifications (e.g., [RFC5322]). Consequently, such messages may confuse some legacy mail user agents (including IMAP clients) or not provide expected information to users. There are also trade-offs in constructing surrogates of the original message between accepting complexity and additional computation costs in order to try to preserve as much information as possible (for example, in "Post-Delivery Message Downgrading for Internationalized Email Messages" [RFC6857]) and trying to minimize those costs while still providing useful information (for example, in "Simplified POP and IMAP Downgrading for Internationalized Email" [RFC6858]).
当遇到需要SMTPUTF8的消息且客户端未启用UTF-8功能时，服务器可用的选项包括隐藏有问题的消息、创建带内或带外通知或错误消息，或者以某种方式试图创建消息的代理，目的是向该客户提供有关所发生事件的有用信息。此类代理消息不能实际替代原始消息：它们几乎总是无法回复（无论是完全回复还是不丢失信息），新的头字段或服务器-客户端通信专用结构可能超出当前电子邮件规范的要求（例如，[RFC5322]）。因此，这样的消息可能会混淆某些旧邮件用户代理（包括IMAP客户端），或者无法向用户提供预期的信息。在构造原始邮件的代理时，为了尽可能多地保留信息，在接受复杂性和额外计算成本之间也存在权衡（例如，在“国际化电子邮件邮件的投递后邮件降级”[RFC6857]中）在提供有用信息的同时尽量减少这些成本（例如，在“简化的POP和IMAP国际邮件降级”[RFC6858]）。
Implementations that choose to perform downgrading SHOULD use one of the standardized algorithms provided in RFC 6857 or RFC 6858. Getting downgrade algorithms right, and minimizing the risk of operational problems and harm to the email system, is tricky and requires careful engineering. These two algorithms are well understood and carefully designed.
选择执行降级的实现应使用RFC 6857或RFC 6858中提供的标准化算法之一。正确使用降级算法，并最大限度地降低操作问题的风险和对电子邮件系统的危害，这是一项棘手的工作，需要仔细设计。这两种算法都得到了很好的理解和精心设计。
Because such messages are really surrogates of the original ones, not really "downgraded" ones (although that terminology is often used for convenience), they inevitably have relationships to the originals that the IMAP specification [RFC3501] did not anticipate. This brings up two concerns in particular: First, digital signatures
因为这些消息实际上是原始消息的代理，而不是真正的“降级”消息（尽管该术语通常用于方便），它们不可避免地与IMAP规范[RFC3501]没有预料到的原始消息有关系。这特别带来了两个问题：第一，数字签名
computed over and intended for the original message will often not be applicable to the surrogate message, and will often fail signature verification. (It will be possible for some digital signatures to be verified, if they cover only parts of the original message that are not affected in the creation of the surrogate.) Second, servers that may be accessed by the same user with different clients or methods (e.g., POP or webmail systems in addition to IMAP or IMAP clients with different capabilities) will need to exert extreme care to be sure that UIDVALIDITY [RFC3501] behaves as the user would expect. Those issues may be especially sensitive if the server caches the surrogate message or computes and stores it when the message arrives with the intent of making either form available depending on client capabilities. Additionally, in order to cope with the case when a server compliant with this extension returns the same UIDVALIDITY to both legacy and "UTF8=ACCEPT"-aware clients, a client upgraded from being non-"UTF8=ACCEPT"-aware MUST discard its cache of messages downloaded from the server.
根据原始消息计算并用于原始消息通常不适用于代理消息，并且签名验证通常会失败。（如果某些数字签名仅涵盖原始消息中在创建代理时不受影响的部分，则可以对其进行验证。）第二，同一用户可以使用不同的客户端或方法访问的服务器（例如，除了具有不同功能的IMAP或IMAP客户端之外，POP或webmail系统）需要格外小心，以确保UID的有效性[RFC3501]行为与用户预期的一致。如果服务器缓存代理消息，或在消息到达时计算并存储代理消息，并根据客户端功能使任一表单可用，则这些问题可能特别敏感。此外，为了处理符合此扩展的服务器返回时的情况对于旧式和“UTF8=ACCEPT”感知的客户端，相同的UID有效性，从非“UTF8=ACCEPT”感知升级的客户端必须丢弃从服务器下载的消息缓存。
The best (or "least bad") approach for any given environment will depend on local conditions, local assumptions about user behavior, the degree of control the server operator has over client usage and upgrading, the options that are actually available, and so on. It is impossible, at least at the time of publication of this specification, to give good advice that will apply to all situations, or even particular profiles of situations, other than "upgrade legacy clients as soon as possible".
任何给定环境的最佳（或“最不坏”）方法将取决于本地条件、用户行为的本地假设、服务器运营商对客户端使用和升级的控制程度、实际可用的选项等等。至少在本规范发布时，除了“尽快升级遗留客户端”之外，不可能给出适用于所有情况，甚至是特定情况的良好建议。
When an IMAP server uses a mailbox format that supports UTF-8 headers and it permits selection or examination of that mailbox without issuing "ENABLE UTF8=ACCEPT" first, it is the responsibility of the server to comply with the IMAP base specification [RFC3501] and the Internet Message Format [RFC5322] with respect to all header information transmitted over the wire. The issue of handling messages containing non-ASCII characters in legacy environments is discussed in Section 7.
当IMAP服务器使用支持UTF-8标头的邮箱格式，并且允许在不首先发出“ENABLE UTF8=ACCEPT”的情况下选择或检查该邮箱时，服务器有责任遵守IMAP基本规范[RFC3501]和Internet邮件格式[RFC5322]关于通过导线传输的所有报头信息。第7节讨论了在遗留环境中处理包含非ASCII字符的消息的问题。
This document redefines two capabilities ("UTF8=ACCEPT" and "UTF8=ONLY") in the "IMAP 4 Capabilities" registry [RFC3501]. Three other capabilities that were described in the experimental predecessor to this document ("UTF8=ALL", "UTF8=APPEND", "UTF8=USER") are now OBSOLETE. IANA has updated the registry as follows:
本文档在“IMAP 4功能”注册表[RFC3501]中重新定义了两种功能（“UTF8=ACCEPT”和“UTF8=ONLY”）。本文档的实验性前文中描述的其他三种功能（“UTF8=ALL”、“UTF8=APPEND”、“UTF8=USER”）现已过时。IANA已将注册信息更新如下：
OLD:
+--------------+-----------------+
| UTF8=ACCEPT | [RFC5738] |
| UTF8=ALL | [RFC5738] |
| UTF8=APPEND | [RFC5738] |
| UTF8=ONLY | [RFC5738] |
| UTF8=USER | [RFC5738] |
+--------------+-----------------+
OLD:
+--------------+-----------------+
| UTF8=ACCEPT | [RFC5738] |
| UTF8=ALL | [RFC5738] |
| UTF8=APPEND | [RFC5738] |
| UTF8=ONLY | [RFC5738] |
| UTF8=USER | [RFC5738] |
+--------------+-----------------+
NEW:
+------------------------+---------------------+
| UTF8=ACCEPT | [RFC6855] |
| UTF8=ALL (OBSOLETE) | [RFC5738] [RFC6855]|
| UTF8=APPEND (OBSOLETE) | [RFC5738] [RFC6855]|
| UTF8=ONLY | [RFC6855] |
| UTF8=USER (OBSOLETE) | [RFC5738] [RFC6855]|
+------------------------+---------------------+
NEW:
+------------------------+---------------------+
| UTF8=ACCEPT | [RFC6855] |
| UTF8=ALL (OBSOLETE) | [RFC5738] [RFC6855]|
| UTF8=APPEND (OBSOLETE) | [RFC5738] [RFC6855]|
| UTF8=ONLY | [RFC6855] |
| UTF8=USER (OBSOLETE) | [RFC5738] [RFC6855]|
+------------------------+---------------------+
The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] apply to this specification, particularly with respect to use of UTF-8 in usernames and passwords. Otherwise, this is not believed to alter the security considerations of IMAP.
UTF-8[RFC3629]和SASLprep[RFC4013]的安全注意事项适用于本规范，特别是在用户名和密码中使用UTF-8方面。否则，这不会改变IMAP的安全考虑。
Special considerations, some of them with security implications, occur if a server that conforms to this specification is accessed by a client that does not, as well as in some more complex situations in which a given message is accessed by multiple clients that might use different protocols and/or support different capabilities. Those issues are discussed in Section 7.
如果符合此规范的服务器由不符合此规范的客户端访问，以及在某些更复杂的情况下（在这种情况下，给定消息由可能使用不同协议和/或支持不同功能的多个客户端访问），则会出现特殊注意事项，其中一些注意事项具有安全含义。第7节讨论了这些问题。
[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月。
[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月。
[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月。
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.
[RFC6532]Yang，A.，Steele，S.，和N.Freed，“国际化电子邮件标题”，RFC 6532，2012年2月。
[RFC6857] Fujiwara, K., "Post-Delivery Message Downgrading for Internationalized Email Messages", RFC 6857, March 2013.
[RFC6857]Fujiwara，K.，“国际化电子邮件的投递后邮件降级”，RFC 6857，2013年3月。
[RFC6858] Gulbrandsen, A., "Simplified POP and IMAP Downgrading for Internationalized Email", RFC 6858, March 2013.
[RFC6858]Gulbrandsen，A.，“国际化电子邮件的简化POP和IMAP降级”，RFC 6858，2013年3月。
[RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[RFC2088]迈尔斯，J.，“IMAP4非同步文字”，RFC2088，1997年1月。
[RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[RFC2342]Gahrns，M.和C.Newman，“IMAP4名称空间”，RFC2342，1998年5月。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[RFC4314]Melnikov，A.，“IMAP4访问控制列表（ACL）扩展”，RFC 4314，2005年12月。
[RFC5530] Gulbrandsen, A., "IMAP Response Codes", RFC 5530, May 2009.
[RFC5530]Gulbrandsen，A.，“IMAP响应代码”，RFC5530，2009年5月。
[RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8", RFC 5738, March 2010.
[RFC5738]Resnick，P.和C.Newman，“UTF-8的IMAP支持”，RFC 5738，2010年3月。
This non-normative section discusses the reasons behind some of the design choices in this specification.
本非规范性章节讨论了本规范中某些设计选择背后的原因。
The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability problems when legacy support goes away. In the situation where backwards compatibility is not working anyway, the non-conforming "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-8 IMAP”有一个优点，即它可以与一些遗留客户端一起工作。然而，“just-send-UTF-8imap”机制导致的互操作性问题诊断困难是选择“UTF8=ONLY”功能机制的原因。
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 (editor) Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 USA
Pete Resnick（编辑）高通公司，美国加利福尼亚州圣地亚哥Morehouse大道5775号，邮编92121-1714
Phone: +1 858 651 4478
EMail: presnick@qti.qualcomm.com
Phone: +1 858 651 4478
EMail: presnick@qti.qualcomm.com
Chris Newman (editor) Oracle 800 Royal Oaks Monrovia, CA 91016 USA
克里斯·纽曼（编辑）美国加利福尼亚州蒙罗维亚皇家橡树园Oracle 800 91016
Phone: EMail: chris.newman@oracle.com
电话：电子邮件：克里斯。newman@oracle.com
Sean Shen (editor) CNNIC No.4 South 4th Zhongguancun Street Beijing, 100190 China
沈肖恩（编辑）CNNIC中国北京中关村第四大街南4号，100190
Phone: +86 10-58813038
EMail: shenshuo@cnnic.cn
Phone: +86 10-58813038
EMail: shenshuo@cnnic.cn