Network Working Group C. Newman
Request for Comments: 5255 Sun Microsystems
Category: Standards Track A. Gulbrandsen
Oryx Mail Systems GmhH
A. Melnikov
Isode Limited
June 2008
Network Working Group C. Newman
Request for Comments: 5255 Sun Microsystems
Category: Standards Track A. Gulbrandsen
Oryx Mail Systems GmhH
A. Melnikov
Isode Limited
June 2008
Internet Message Access Protocol Internationalization
Internet消息访问协议国际化
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions that improve international support including language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread.
Internet消息访问协议（IMAP）版本4rev1基本支持邮箱名称和搜索子字符串中的非ASCII字符。它还支持非ASCII消息头和由多用途Internet邮件扩展（MIME）指定的编码内容。本规范定义了一组IMAP扩展，这些扩展可改善国际支持，包括国际错误文本的语言协商、名称空间前缀的翻译以及搜索、排序和线程的比较器协商。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. LANGUAGE Extension ..............................................3
3.1. LANGUAGE Extension Requirements ............................4
3.2. LANGUAGE Command ...........................................4
3.3. LANGUAGE Response ..........................................6
3.4. TRANSLATION Extension to the NAMESPACE Response ............7
3.5. Formal Syntax ..............................................8
4. I18NLEVEL=1 and I18NLEVEL=2 Extensions ..........................9
4.1. Introduction and Overview ..................................9
4.2. Requirements Common to Both I18NLEVEL=1 and I18NLEVEL=2 ....9
4.3. I18NLEVEL=1 Extension Requirements ........................10
4.4. I18NLEVEL=2 Extension Requirements ........................10
4.5. Compatibility Notes .......................................11
4.6. Comparators and Character Encodings .......................11
4.7. COMPARATOR Command ........................................13
4.8. COMPARATOR Response .......................................14
4.9. BADCOMPARATOR Response Code ...............................14
4.10. Formal Syntax ............................................14
5. Other IMAP Internationalization Issues .........................15
5.1. Unicode Userids and Passwords .............................15
5.2. UTF-8 Mailbox Names .......................................15
5.3. UTF-8 Domains, Addresses, and Mail Headers ................15
6. IANA Considerations ............................................16
7. Security Considerations ........................................16
8. Acknowledgements ...............................................16
9. Relevant Sources of Documents for Internationalized IMAP
Implementations ................................................17
10. Normative References ..........................................17
11. Informative References ........................................18
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. LANGUAGE Extension ..............................................3
3.1. LANGUAGE Extension Requirements ............................4
3.2. LANGUAGE Command ...........................................4
3.3. LANGUAGE Response ..........................................6
3.4. TRANSLATION Extension to the NAMESPACE Response ............7
3.5. Formal Syntax ..............................................8
4. I18NLEVEL=1 and I18NLEVEL=2 Extensions ..........................9
4.1. Introduction and Overview ..................................9
4.2. Requirements Common to Both I18NLEVEL=1 and I18NLEVEL=2 ....9
4.3. I18NLEVEL=1 Extension Requirements ........................10
4.4. I18NLEVEL=2 Extension Requirements ........................10
4.5. Compatibility Notes .......................................11
4.6. Comparators and Character Encodings .......................11
4.7. COMPARATOR Command ........................................13
4.8. COMPARATOR Response .......................................14
4.9. BADCOMPARATOR Response Code ...............................14
4.10. Formal Syntax ............................................14
5. Other IMAP Internationalization Issues .........................15
5.1. Unicode Userids and Passwords .............................15
5.2. UTF-8 Mailbox Names .......................................15
5.3. UTF-8 Domains, Addresses, and Mail Headers ................15
6. IANA Considerations ............................................16
7. Security Considerations ........................................16
8. Acknowledgements ...............................................16
9. Relevant Sources of Documents for Internationalized IMAP
Implementations ................................................17
10. Normative References ..........................................17
11. Informative References ........................................18
This specification defines two IMAP4rev1 [RFC3501] extensions to enhance international support. These extensions can be advertised and implemented separately.
本规范定义了两个IMAP4rev1[RFC3501]扩展，以增强国际支持。这些扩展可以单独发布和实现。
The LANGUAGE extension allows the client to request a suitable language for protocol error messages and in combination with the NAMESPACE extension [RFC2342] enables namespace translations.
语言扩展允许客户端为协议错误消息请求合适的语言，并结合命名空间扩展[RFC2342]启用命名空间转换。
The I18NLEVEL=2 extension allows the client to request a suitable collation that will modify the behavior of the base specification's SEARCH command as well as the SORT and THREAD extensions [SORT]. This leverages the collation registry [RFC4790]. The I18NLEVEL=1 extension updates SEARCH/SORT/THREAD to use i;unicode-casemap comparator, as defined in [UCM]. I18NLEVEL=1 is a simpler version of I18NLEVEL=2 with no ability to select a different collation.
I18NLEVEL=2扩展允许客户端请求适当的排序规则，该排序规则将修改基本规范的搜索命令以及排序和线程扩展[SORT]的行为。这利用了排序规则注册表[RFC4790]。I18NLEVEL=1扩展将SEARCH/SORT/THREAD更新为使用i；unicode casemap比较器，如[UCM]中所定义。I18NLEVEL=1是I18NLEVEL=2的一个更简单版本，无法选择其他排序规则。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation including the core rules defined in Appendix A.
形式语法使用扩展的Backus Naur Form（ABNF）[RFC5234]符号，包括附录A中定义的核心规则。
The UTF-8-related productions are defined in [RFC3629].
[RFC3629]中定义了UTF-8相关产品。
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:”标签适用于多行，则这些行之间的换行符仅用于编辑清晰性，不属于实际协议交换的一部分。
IMAP allows server responses to include human-readable text that in many cases needs to be presented to the user. But that text is limited to US-ASCII by the IMAP specification [RFC3501] in order to preserve backwards compatibility with deployed IMAP implementations. This section specifies a way for an IMAP client to negotiate which language the server should use when sending human-readable text.
IMAP允许服务器响应包括在许多情况下需要呈现给用户的人类可读文本。但IMAP规范[RFC3501]将该文本限制为US-ASCII，以保持与已部署IMAP实现的向后兼容性。本节指定IMAP客户端在发送人类可读文本时协商服务器应使用哪种语言的方法。
The LANGUAGE extension only provides a mechanism for altering fixed server strings such as response text and NAMESPACE folder names. Assigning localized language aliases to shared mailboxes would be done with a separate mechanism such as the proposed METADATA extension (see [METADATA]).
语言扩展只提供一种机制来更改固定服务器字符串，如响应文本和命名空间文件夹名称。将本地化语言别名分配给共享邮箱将通过单独的机制完成，如建议的元数据扩展（请参见[元数据]）。
IMAP servers that support this extension MUST list the keyword LANGUAGE in their CAPABILITY response as well as in the greeting CAPABILITY data.
支持此扩展的IMAP服务器必须在其功能响应以及问候功能数据中列出关键字语言。
A server that advertises this extension MUST use the language "i-default" as described in [RFC2277] as its default language until another supported language is negotiated by the client. A server MUST include "i-default" as one of its supported languages. IMAP servers SHOULD NOT advertise the LANGUAGE extension if they discover that they only support "i-default".
播发此扩展的服务器必须使用[RFC2277]中所述的语言“i-default”作为其默认语言，直到客户端协商另一种受支持的语言。服务器必须包含“i-default”作为其支持的语言之一。如果IMAP服务器发现它们只支持“i-default”，则不应公布语言扩展。
Clients and servers that support this extension MUST also support the NAMESPACE extension [RFC2342].
支持此扩展的客户端和服务器还必须支持命名空间扩展[RFC2342]。
The LANGUAGE command is valid in all states. Clients SHOULD issue LANGUAGE before authentication, since some servers send valuable user information as part of authentication (e.g., "password is correct, but expired"). If a security layer (such as SASL or TLS) is subsequently negotiated by the client, it MUST re-issue the LANGUAGE command in order to make sure that no previous active attack (if any) on LANGUAGE negotiation has effect on subsequent error messages. (See Section 7 for a more detailed explanation of the attack.)
语言命令在所有状态下都有效。客户端应该在身份验证之前发出语言，因为一些服务器发送有价值的用户信息作为身份验证的一部分（例如，“密码正确，但已过期”）。如果客户端随后协商了安全层（如SASL或TLS），则必须重新发出语言命令，以确保先前对语言协商的主动攻击（如果有）不会对后续错误消息产生影响。（有关攻击的详细说明，请参见第7节。）
Arguments: Optional language range arguments.
参数：可选语言范围参数。
Response: A possible LANGUAGE response (see Section 3.3). A possible NAMESPACE response (see Section 3.4).
响应：可能的语言响应（见第3.3节）。可能的名称空间响应（参见第3.4节）。
Result: OK - Command completed NO - Could not complete command BAD - Arguments invalid
结果：确定-命令已完成否-无法完成命令错误-参数无效
The LANGUAGE command requests that human-readable text emitted by the server be localized to a language matching one of the language range argument as described by Section 2 of [RFC4647].
LANGUAGE命令要求将服务器发出的人类可读文本本地化为与[RFC4647]第2节所述的语言范围参数之一匹配的语言。
If the command succeeds, the server will return human-readable responses in the first supported language specified. These responses will be in UTF-8 [RFC3629]. The server MUST send a LANGUAGE response specifying the language used, and the change takes effect immediately after the LANGUAGE response.
如果命令成功，服务器将以指定的第一种支持的语言返回人类可读的响应。这些响应将出现在UTF-8[RFC3629]中。服务器必须发送指定所用语言的语言响应，并且更改在语言响应后立即生效。
If the command fails, the server continues to return human-readable responses in the language it was previously using.
如果命令失败，服务器将继续以以前使用的语言返回人类可读的响应。
The special "default" language range argument indicates a request to use a language designated as preferred by the server administrator. The preferred language MAY vary based on the currently active user.
特殊的“default”语言范围参数表示使用服务器管理员指定为首选语言的请求。首选语言可能因当前活动用户而异。
If a language range does not match a known language tag exactly but does match a language by the rules of [RFC4647], the server MUST send an untagged LANGUAGE response indicating the language selected.
如果某个语言范围与已知语言标记不完全匹配，但根据[RFC4647]的规则与某个语言匹配，则服务器必须发送一个未标记的语言响应，指示所选语言。
If there aren't any arguments, the server SHOULD send an untagged LANGUAGE response listing the languages it supports. If the server is unable to enumerate the list of languages it supports it MAY return a tagged NO response to the enumeration request. If, after receiving a LANGUAGE request, the server discovers that it doesn't support any language other than i-default, it MUST return a tagged NO response to the enumeration request.
如果没有任何参数，服务器应该发送一个未标记的语言响应，列出它支持的语言。如果服务器无法枚举其支持的语言列表，则可能会对枚举请求返回标记为“否”的响应。如果在接收到语言请求后，服务器发现它不支持除i-default之外的任何语言，则它必须对枚举请求返回一个标记为NO的响应。
< The server defaults to using English i-default responses until the user explicitly changes the language. >
<在用户明确更改语言之前，服务器默认使用英语i-default响应。>
C: A001 LOGIN KAREN PASSWORD
S: A001 OK LOGIN completed
C: A001 LOGIN KAREN PASSWORD
S: A001 OK LOGIN completed
< Client requested MUL language, which no server supports. >
<客户端请求的MUL语言，没有服务器支持。>
C: A002 LANGUAGE MUL
S: A002 NO Unsupported language MUL
C: A002 LANGUAGE MUL
S: A002 NO Unsupported language MUL
< A LANGUAGE command with no arguments is a request to enumerate the list of languages the server supports. >
<不带参数的语言命令是枚举服务器支持的语言列表的请求。>
C: A003 LANGUAGE
S: * LANGUAGE (EN DE IT i-default)
S: A003 OK Supported languages have been enumerated
C: A003 LANGUAGE
S: * LANGUAGE (EN DE IT i-default)
S: A003 OK Supported languages have been enumerated
C: B001 LANGUAGE
S: B001 NO Server is unable to enumerate supported languages
C: B001 LANGUAGE
S: B001 NO Server is unable to enumerate supported languages
< Once the client changes the language, all responses will be in that language starting after the LANGUAGE response. Note that this includes the NAMESPACE response. Because RFCs are in US-ASCII, this document uses an ASCII transcription rather than UTF-8 text, e.g., "ue" in the word "ausgefuehrt" >
<一旦客户端更改语言，所有响应都将在语言响应后开始使用该语言。注意，这包括名称空间响应。由于RFC采用US-ASCII格式，因此本文档使用ASCII转录而非UTF-8文本，例如，“Ausgeefuehrt”一词中的“ue”>
C: C001 LANGUAGE DE
S: * LANGUAGE (DE)
S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
"TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: C001 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
C: C001 LANGUAGE DE
S: * LANGUAGE (DE)
S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
"TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: C001 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
< If a server does not support the requested primary language, responses will continue to be returned in the current language the server is using. >
<如果服务器不支持请求的主语言，响应将继续以服务器当前使用的语言返回。>
C: D001 LANGUAGE FR
S: D001 NO Diese Sprache ist nicht unterstuetzt
C: D002 LANGUAGE DE-IT
S: * LANGUAGE (DE-IT)
S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
"TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: D002 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
C: D003 LANGUAGE "default"
S: * LANGUAGE (DE)
S: D003 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
C: D001 LANGUAGE FR
S: D001 NO Diese Sprache ist nicht unterstuetzt
C: D002 LANGUAGE DE-IT
S: * LANGUAGE (DE-IT)
S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
"TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: D002 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
C: D003 LANGUAGE "default"
S: * LANGUAGE (DE)
S: D003 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
< Server does not speak French, but does speak English. User speaks Canadian French and Canadian English. >
<服务器不会讲法语，但会讲英语。用户会说加拿大法语和加拿大英语。>
C: E001 LANGUAGE FR-CA EN-CA
S: * LANGUAGE (EN)
S: E001 OK Now speaking English
C: E001 LANGUAGE FR-CA EN-CA
S: * LANGUAGE (EN)
S: E001 OK Now speaking English
Contents: A list of one or more language tags.
内容：一个或多个语言标记的列表。
The LANGUAGE response occurs as a result of a LANGUAGE command. A LANGUAGE response with a list containing a single language tag indicates that the server is now using that language. A LANGUAGE response with a list containing multiple language tags indicates the server is communicating a list of available languages to the client, and no change in the active language has been made.
语言响应是语言命令的结果。带有包含单个语言标记的列表的语言响应表示服务器现在正在使用该语言。带有包含多个语言标记的列表的语言响应表示服务器正在向客户端传送可用语言列表，并且未对活动语言进行任何更改。
If localized representations of the namespace prefixes are available in the selected language, the server SHOULD include these in the TRANSLATION extension to the NAMESPACE response.
如果名称空间前缀的本地化表示在所选语言中可用，则服务器应在名称空间响应的翻译扩展中包含这些前缀。
The TRANSLATION extension to the NAMESPACE response returns a single string, containing the modified UTF-7 [RFC3501] encoded translation of the namespace prefix. It is the responsibility of the client to convert between the namespace prefix and the translation of the namespace prefix when presenting mailbox names to the user.
名称空间响应的转换扩展返回单个字符串，其中包含名称空间前缀的修改UTF-7[RFC3501]编码转换。当向用户显示邮箱名称时，客户端负责在名称空间前缀和名称空间前缀的转换之间进行转换。
In this example, a server supports the IMAP4 NAMESPACE command. It uses no prefix to the user's Personal Namespace, a prefix of "Other Users" to its Other Users' Namespace, and a prefix of "Public Folders" to its only Shared Namespace. Since a client will often display these prefixes to the user, the server includes a translation of them that can be presented to the user.
在本例中，服务器支持IMAP4 NAMESPACE命令。它对用户的个人名称空间不使用前缀，对其其他用户的名称空间使用前缀“其他用户”，对其唯一共享名称空间使用前缀“公共文件夹”。由于客户机通常会向用户显示这些前缀，因此服务器会将这些前缀的翻译提供给用户。
C: A001 LANGUAGE DE-IT
S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
"TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: A001 OK LANGUAGE-Befehl ausgefuehrt
C: A001 LANGUAGE DE-IT
S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
"TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: A001 OK LANGUAGE-Befehl ausgefuehrt
The following syntax specification inherits ABNF [RFC5234] rules from IMAP4rev1 [RFC3501], IMAP4 Namespace [RFC2342], Tags for the Identifying Languages [RFC4646], UTF-8 [RFC3629], and Collected Extensions to IMAP4 ABNF [RFC4466].
以下语法规范继承了来自IMAP4rev1[RFC3501]、IMAP4名称空间[RFC2342]、标识语言[RFC4646]、UTF-8[RFC3629]的ABNF[RFC5234]规则，并收集了对IMAP4 ABNF[RFC4466]的扩展。
command-any =/ language-cmd ; LANGUAGE command is valid in all states
命令any=/language cmd；语言命令在所有状态下都有效
language-cmd = "LANGUAGE" *(SP lang-range-quoted)
language cmd=“language”*（引用SP语言范围）
response-payload =/ language-data
响应负载=/语言数据
language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP lang-tag-quoted) ")"
language data=“language”SP”（“引用的语言标记*（引用的SP语言标记）”）
namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string ")"
; the string is encoded in Modified UTF-7.
; this is a subset of the syntax permitted by
; the Namespace-Response-Extension rule in [RFC4466]
namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string ")"
; the string is encoded in Modified UTF-7.
; this is a subset of the syntax permitted by
; the Namespace-Response-Extension rule in [RFC4466]
lang-range-quoted = astring ; Once any literal wrapper or quoting is removed, this ; follows the language-range rule in [RFC4647]
引用的lang范围=astring；一旦任何文字包装或引用被删除，这；遵循[RFC4647]中的语言范围规则
lang-tag-quoted = astring ; Once any literal wrapper or quoting is removed, this follows ; the Language-Tag rule in [RFC4646]
引用lang tag=astring；一旦任何文字包装或引用被删除，这如下；[RFC4646]中的语言标记规则
resp-text = ["[" resp-text-code "]" SP ] UTF8-TEXT-CHAR
*(UTF8-TEXT-CHAR / "[")
; After the server is changed to a language other than
; i-default, this resp-text rule replaces the resp-text
; rule from [RFC3501].
resp-text = ["[" resp-text-code "]" SP ] UTF8-TEXT-CHAR
*(UTF8-TEXT-CHAR / "[")
; After the server is changed to a language other than
; i-default, this resp-text rule replaces the resp-text
; rule from [RFC3501].
UTF8-TEXT-CHAR = %x20-5A / %x5C-7E / UTF8-2 / UTF8-3 / UTF8-4
; UTF-8 excluding 7-bit control characters and "["
UTF8-TEXT-CHAR = %x20-5A / %x5C-7E / UTF8-2 / UTF8-3 / UTF8-4
; UTF-8 excluding 7-bit control characters and "["
IMAP4rev1 [RFC3501] includes the SEARCH command that can be used to locate messages matching criteria including human-readable text. The SORT extension [SORT] to IMAP allows the client to ask the server to determine the order of messages based on criteria including human-readable text. These mechanisms require the ability to support non-English search and sort functions.
IMAP4rev1[RFC3501]包含搜索命令，可用于查找符合条件的消息，包括人类可读文本。IMAP的排序扩展[SORT]允许客户端要求服务器根据包括人类可读文本在内的标准确定消息的顺序。这些机制需要支持非英语搜索和排序功能。
Section 4 defines two IMAP extensions for internationalizing IMAP SEARCH, SORT, and THREAD [SORT] using the comparator framework [RFC4790].
第4节定义了两个IMAP扩展，用于使用comparator框架[RFC4790]对IMAP搜索、排序和线程[SORT]进行国际化。
The I18NLEVEL=1 extension updates SEARCH/SORT/THREAD to use i;unicode-casemap comparator, as defined in [UCM]. See Sections 4.2 and 4.3 for more details.
I18NLEVEL=1扩展将SEARCH/SORT/THREAD更新为使用i；unicode casemap比较器，如[UCM]中所定义。详见第4.2节和第4.3节。
The I18NLEVEL=2 extension is a superset of the I18NLEVEL=1 extension. It adds to I18NLEVEL=1 extension the ability to determine the active comparator (see definition below) and to negotiate use of comparators using the COMPARATOR command. It also adds the COMPARATOR response that indicates the active comparator and possibly other available comparators. See Sections 4.2 and 4.4 for more details.
I18NLEVEL=2扩展是I18NLEVEL=1扩展的超集。它为I18NLEVEL=1扩展增加了确定活动比较器（见下面的定义）和使用比较器命令协商比较器使用的能力。它还添加了比较器响应，该响应指示活动比较器和可能的其他可用比较器。详见第4.2节和第4.4节。
The term "default comparator" refers to the comparator that is used by SEARCH and SORT absent any negotiation using the COMPARATOR command (see Section 4.7). The term "active comparator" refers to the comparator which will be used within a session, e.g., by SEARCH and SORT. The COMPARATOR command is used to change the active comparator.
术语“默认比较器”是指在没有任何协商的情况下使用比较器命令进行搜索和排序时使用的比较器（见第4.7节）。术语“活动比较器”是指将在会话中使用的比较器，例如通过搜索和排序。比较器命令用于更改活动比较器。
The active comparator applies to the following SEARCH keys: "BCC", "BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO", and "HEADER". If the server also advertises the "SORT" extension, then the active comparator applies to the following SORT keys: "CC", "FROM", "SUBJECT", and "TO". If the server advertises THREAD=ORDEREDSUBJECT, then the active comparator applies to the ORDEREDSUBJECT threading algorithm. If the server advertises THREAD=REFERENCES, then the active comparator applies to the subject field comparisons done by REFERENCES threading algorithm. Future extensions may choose to apply the active comparator to their SEARCH keys.
活动比较器适用于以下搜索键：“密件抄送”、“正文”、“抄送”、“发件人”、“主题”、“文本”、“收件人”和“标题”。如果服务器还播发“SORT”扩展，那么活动比较器将应用于以下排序键：“CC”、“FROM”、“SUBJECT”和“to”。如果服务器播发THREAD=ORDEREDSUBJECT，则活动比较器将应用于ORDEREDSUBJECT线程算法。如果服务器播发THREAD=REFERENCES，那么活动比较器将应用于由REFERENCES线程算法完成的主题字段比较。未来的扩展可能会选择将活动比较器应用于其搜索键。
For SORT and THREAD, the pre-processing necessary to extract the base subject text from a Subject header occurs prior to the application of a comparator.
对于排序和线程，从主题标题提取基本主题文本所需的预处理发生在应用比较器之前。
A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST implement the i;unicode-casemap comparator, as defined in [UCM].
播发I18NLEVEL=1或I18NLEVEL=2扩展的服务器必须实现i；unicode casemap比较器，如[UCM]中所定义。
A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST support UTF-8 as a SEARCH charset.
播发I18NLEVEL=1或I18NLEVEL=2扩展名的服务器必须支持UTF-8作为搜索字符集。
An IMAP server that satisfies all requirements specified in Sections 4.2 and 4.6 (and that doesn't support/advertise any other I18NLEVEL=<n> extension, where n > 1) MUST list the keyword I18NLEVEL=1 in its CAPABILITY data once IMAP enters the authenticated state, and MAY list that keyword in other states.
满足第4.2节和第4.6节中规定的所有要求的IMAP服务器（不支持/公布任何其他I18NLEVEL=<n>扩展，其中n>1）必须在IMAP进入认证状态后在其功能数据中列出关键字I18NLEVEL=1，并且可以在其他状态中列出该关键字。
An IMAP server that satisfies all requirements specified in Sections 4.2, 4.4, and 4.6-4.10 (and that doesn't support/advertise any other I18NLEVEL=<n> extension, where n > 2) MUST list the keyword I18NLEVEL=2 in its CAPABILITY data once IMAP enters the authenticated state, and MAY list that keyword in other states.
满足第4.2节、第4.4节和第4.6-4.10节中规定的所有要求的IMAP服务器（不支持/公布任何其他I18NLEVEL=<n>扩展，其中n>2）必须在IMAP进入认证状态后在其功能数据中列出关键字I18NLEVEL=2，并且可以在其他状态中列出该关键字。
A server that advertises this extension MUST implement the i;unicode-casemap comparator, as defined in [UCM]. It MAY implement other comparators from the IANA registry established by [RFC4790]. See also Section 4.5 of this document.
播发此扩展的服务器必须实现i；unicode casemap比较器，如[UCM]中所定义。它可以从[RFC4790]建立的IANA注册表中实现其他比较器。另见本文件第4.5节。
A server that advertises this extension SHOULD use i;unicode-casemap as the default comparator. (Note that i;unicode-casemap is the default comparator for I18NLEVEL=1, but not necessarily the default for I18NLEVEL=2.) The selection of the default comparator MAY be adjustable by the server administrator, and MAY be sensitive to the current user. Once the IMAP connection enters authenticated state, the default comparator MUST remain static for the remainder of that connection.
播发此扩展的服务器应使用i；unicode casemap作为默认的比较器。（请注意，i；unicode casemap是I18NLEVEL=1的默认比较器，但不一定是I18NLEVEL=2的默认比较器。）默认比较器的选择可以由服务器管理员调整，并且可能对当前用户敏感。一旦IMAP连接进入认证状态，默认比较器必须在该连接的其余部分保持静态。
Note that since SEARCH uses the substring operation, IMAP servers can only implement collations that offer the substring operation (see [RFC4790], Section 4.2.2). Since SORT uses the ordering operation (which in turn uses the equality operation), IMAP servers that advertise the SORT extension can only implement collations that offer all three operations (see [RFC4790], Sections 4.2.2-4.2.4).
请注意，由于搜索使用子字符串操作，IMAP服务器只能实现提供子字符串操作的排序规则（请参阅[RFC4790]，第4.2.2节）。由于排序使用排序操作（而排序操作又使用相等操作），因此播发排序扩展的IMAP服务器只能实现提供所有三种操作的排序规则（请参见[RFC4790]，第4.2.2-4.2.4节）。
If the active collation does not provide the operations needed by an IMAP command, the server MUST respond with a tagged BAD.
如果活动排序规则未提供IMAP命令所需的操作，则服务器必须使用标记为BAD的命令进行响应。
Several server implementations deployed prior to the publication of this specification comply with I18NLEVEL=1 (see Section 4.3), but do not advertise that. Other legacy servers use the i;ascii-casemap comparator (see [RFC4790]).
在本规范发布之前部署的多个服务器实现都符合I18NLEVEL=1（请参见第4.3节），但不公布这一点。其他遗留服务器使用i；ascii casemap比较器（参见[RFC4790]）。
There is no good way for a client to know which comparator a legacy server uses. If the client has to assume the worst, it may end up doing expensive local operations to obtain i;unicode-casemap comparisons even though the server implements it.
对于客户端来说，没有好的方法可以知道遗留服务器使用哪个比较器。如果客户不得不承担最坏的情况，它可能最终会进行昂贵的本地操作以获得i；unicode casemap比较，即使服务器实现了它。
Legacy server implementations which comply with I18NLEVEL=1 should be updated to advertise I18NLEVEL=1. All server implementations should eventually be updated to comply with the I18NLEVEL=2 extension.
应更新符合I18NLEVEL=1的旧版服务器实现，以公布I18NLEVEL=1。所有服务器实现最终都应该更新，以符合I18NLEVEL=2扩展。
RFC 3501, Section 6.4.4, says:
RFC 3501第6.4.4节规定：
In all search keys that use strings, a message matches the key if the string is a substring of the field. The matching is case-insensitive.
在所有使用字符串的搜索关键字中，如果字符串是字段的子字符串，则消息与关键字匹配。匹配不区分大小写。
When performing the SEARCH operation, the active comparator is applied instead of the case-insensitive matching specified above.
执行搜索操作时，将应用活动比较器，而不是上面指定的不区分大小写的匹配。
An IMAP server which performs collation operations (e.g., as part of commands such as SEARCH, SORT, and THREAD) does so according to the following procedure:
执行排序操作（例如，作为搜索、排序和线程等命令的一部分）的IMAP服务器根据以下过程执行排序操作：
(a) MIME encoding (for example, see [RFC2047] for headers and [RFC2045] for body parts) MUST be removed in the texts being collated.
(a) MIME编码（例如，标题请参见[RFC2047]，正文部分请参见[RFC2045]）必须在正在整理的文本中删除。
If MIME encoding removal fails for a message (e.g., a body part of the message has an unsupported Content-Transfer-Encoding, uses characters not allowed by the Content-Transfer-Encoding, etc.), the collation of this message is undefined by this specification, and is handled in an implementation-dependent manner.
如果消息的MIME编码删除失败（例如，消息的正文部分具有不受支持的内容传输编码、使用内容传输编码不允许的字符等），则此消息的排序规则不受本规范的定义，并以依赖于实现的方式处理。
(b) The decoded text from (a) MUST be converted to the charset expected by the active comparator.
(b) 来自（a）的解码文本必须转换为活动比较器预期的字符集。
(c) For the substring operation:
(c) 对于子字符串操作：
If step (b) failed (e.g., the text is in an unknown charset, contains a sequence that is not valid according in that charset, etc.), the original decoded text from (a) (i.e., before the charset conversion attempt) is collated using the i;octet comparator (see [RFC4790]).
如果步骤（b）失败（例如，文本位于未知字符集，包含根据该字符集无效的序列等），则使用i；八位字节比较器（见[RFC4790]）。
If step (b) was successful, the converted text from (b) is collated according to the active comparator.
如果步骤（b）成功，则根据激活的比较器整理（b）中转换的文本。
For the ordering operation:
对于订购操作：
All strings that were successfully converted by step (b) are separated from all strings that failed step (b). Strings in each group are collated independently. All strings successfully converted by step (b) are then validated by the active comparator. Strings that pass validation are collated using the active comparator. All strings that either fail step (b) or fail the active collation's validity operation are collated (after applying step (a)) using the i;octet comparator (see [RFC4790]). The resulting sorted list is produced by appending all collated "failed" strings after all strings collated using the active comparator.
步骤（b）成功转换的所有字符串与步骤（b）失败的所有字符串分开。每个组中的字符串都是独立整理的。通过步骤（b）成功转换的所有字符串随后由活动比较器验证。通过验证的字符串使用活动比较器进行整理。所有未通过步骤（b）或未通过活动排序规则有效性操作的字符串都将使用i；八位字节比较器（见[RFC4790]）。在使用活动比较器整理所有字符串之后，通过追加所有整理的“失败”字符串来生成结果排序列表。
Example: The following example demonstrates ordering of 4 different strings using the i;unicode-casemap [UCM] comparator. Strings are represented using hexadecimal notation used by ABNF [RFC5234].
示例：下面的示例演示了使用i对4个不同字符串进行排序；unicode casemap[UCM]比较器。字符串使用ABNF[RFC5234]使用的十六进制表示法表示。
(1) %xD0 %xC0 %xD0 %xBD %xD0 %xB4 %xD1 %x80 %xD0 %xB5 %xD0 %xB9 (labeled with charset=UTF-8) (2) %xD1 %x81 %xD0 %x95 %xD0 %xA0 %xD0 %x93 %xD0 %x95 %xD0 %x99 (labeled with charset=UTF-8) (3) %xD0 %x92 %xD0 %xB0 %xD1 %x81 %xD0 %xB8 %xD0 %xBB %xD0 %xB8 %xFF %xB9 (labeled with charset=UTF-8) (4) %xE1 %xCC %xC5 %xCB %xD3 %xC5 %xCA (labeled with charset=KOI8-R)
(1) %xD0%xC0%xD0%xBD%xD0%xB4%xD1%x80%xD0%xB5%xD0%xB9（用字符集=UTF-8标记）（2）%xD1%x81%xD0%xD0%xD0%x93%xD0%xD0%xD0%x99（用字符集=UTF-8标记）（3）%xD0%x92%xD0%xD0%xB0%xD1%x81%xD0%xB0%xB0%xB8%xB8%xB8%xB9（用字符集=UTF-8标记）（4%xC5%xC5%xC5%xC5%xC5（标有字符集=KOI8-R）
Step (b) will convert string (4) to the following sequence of octets (in UTF-8):
步骤（b）将字符串（4）转换为以下八位字节序列（UTF-8）：
%xD0 %x90 %xD0 %xBB %xD0 %xB5 %xD0 %xBA %xD1 %x81 %xD0 %xB5 %xD0 %xB9
%xD0%x90%xD0%xBB%xD0%xB5%xD0%xBA%xD1%x81%xD0%xB5%xD0%xB9
and will reject strings (1) and (3), as they contain octets not allowed in charset=UTF-8.
并且将拒绝字符串（1）和（3），因为它们包含字符集=UTF-8中不允许的八位字节。
After that, using the i;unicode-casemap collation, string (4) will collate before string (2). Using the i;octet collation on the original strings, string (3) will collate before string (1). So the final ordering is as follows: (4) (2) (3) (1).
之后，使用i；unicode casemap排序规则，字符串（4）将在字符串（2）之前排序。使用i；八位字节排序法对原始字符串进行排序，字符串（3）将在字符串（1）之前进行排序。因此，最终的顺序如下：（4）（2）（3）（1）。
If the substring operation (e.g., IMAP SEARCH) of the active comparator returns the "undefined" result (see Section 4.2.3 of [RFC4790]) for either the text specified in the SEARCH command or the message text, then the operation is repeated on the result of step (a) using the i;octet comparator.
如果活动比较器的子字符串操作（例如，IMAP搜索）返回搜索命令中指定文本或消息文本的“未定义”结果（见[RFC4790]第4.2.3节），则使用i；八位组比较器。
The ordering operation (e.g., IMAP SORT and THREAD) SHOULD collate the following together: strings encoded using unknown or invalid character encodings, strings in unrecognized charsets, and invalid input (as defined by the active collation).
排序操作（例如，IMAP排序和线程）应将以下内容整理在一起：使用未知或无效字符编码编码编码的字符串、未识别字符集中的字符串和无效输入（由活动排序规则定义）。
Arguments: Optional comparator order arguments.
参数：可选的比较器顺序参数。
Response: A possible COMPARATOR response (see Section 4.8).
响应：可能的比较器响应（见第4.8节）。
Result: OK - Command completed NO - No matching comparator found BAD - Arguments invalid
结果：确定-命令完成否-未找到匹配的比较器错误-参数无效
The COMPARATOR command is valid in authenticated and selected states.
COMPARATOR命令在已验证和选定状态下有效。
The COMPARATOR command is used to determine or change the active comparator. When issued with no arguments, it results in a COMPARATOR response indicating the currently active comparator.
比较器命令用于确定或更改活动比较器。如果发出时没有参数，则会产生一个比较器响应，指示当前活动的比较器。
When issued with one or more comparator arguments, it changes the active comparator as directed. (If more than one installed comparator is matched by an argument, the first argument wins.) The COMPARATOR response lists all matching comparators if more than one matches the specified patterns.
当发出一个或多个比较器参数时，它会按照指示更改活动比较器。（如果一个参数匹配多个已安装的比较器，则第一个参数获胜。）如果多个比较器匹配指定模式，则比较器响应将列出所有匹配的比较器。
The argument "default" refers to the server's default comparator. Otherwise, each argument is a collation specification as defined in the Internet Application Protocol Comparator Registry [RFC4790].
参数“default”指的是服务器的默认比较器。否则，每个参数都是在Internet应用程序协议比较器注册表[RFC4790]中定义的排序规则规范。
< The client requests activating a Czech comparator if possible, or else a generic international comparator which it considers suitable for Czech. The server picks the first supported comparator. >
<如有可能，客户要求激活捷克比较仪，或激活其认为适合捷克的通用国际比较仪。服务器选择第一个支持的比较器。>
C: A001 COMPARATOR "cz;*" i;basic
S: * COMPARATOR i;basic
S: A001 OK Will use i;basic for collation
C: A001 COMPARATOR "cz;*" i;basic
S: * COMPARATOR i;basic
S: A001 OK Will use i;basic for collation
Contents: The active comparator. An optional list of available matching comparators
内容：有源比较器。可用匹配比较器的可选列表
The COMPARATOR response occurs as a result of a COMPARATOR command. The first argument in the comparator response is the name of the active comparator. The second argument is a list of comparators which matched any of the arguments to the COMPARATOR command and is present only if more than one match is found.
比较器响应是比较器命令的结果。比较器响应中的第一个参数是活动比较器的名称。第二个参数是一个比较器列表，它将任何参数与COMPARATOR命令相匹配，并且仅当找到多个匹配项时才出现。
This response code SHOULD be returned as a result of server failing an IMAP command (returning NO), when the server knows that none of the specified comparators match the requested comparator(s).
当服务器知道指定的比较器中没有一个与请求的比较器匹配时，应将此响应代码作为IMAP命令失败（返回否）的结果返回。
The following syntax specification inherits ABNF [RFC5234] rules from IMAP4rev1 [RFC3501] and the Internet Application Protocol Comparator Registry [RFC4790].
以下语法规范继承了来自IMAP4rev1[RFC3501]和Internet应用程序协议比较器注册表[RFC4790]的ABNF[RFC5234]规则。
command-auth =/ comparator-cmd
命令auth=/comparator cmd
resp-text-code =/ "BADCOMPARATOR"
resp文本代码=/“BADCOMPARATOR”
comparator-cmd = "COMPARATOR" *(SP comp-order-quoted)
comparator cmd=“comparator”*（引用SP comp订单）
response-payload =/ comparator-data
响应负载=/比较器数据
comparator-data = "COMPARATOR" SP comp-sel-quoted [SP "(" comp-id-quoted *(SP comp-id-quoted) ")"]
比较器数据=“比较器”引用的SP公司选择[SP”（“引用的公司id*（引用的SP公司id）”）”]
comp-id-quoted = astring ; Once any literal wrapper or quoting is removed, this ; follows the collation-id rule from [RFC4790]
引用的comp id=astring；一旦任何文字包装或引用被删除，这；遵循[RFC4790]中的排序规则id
comp-order-quoted = astring ; Once any literal wrapper or quoting is removed, this ; follows the collation-order rule from [RFC4790]
报价的公司订单=astring；一旦任何文字包装或引用被删除，这；遵循[RFC4790]中的排序规则
comp-sel-quoted = astring ; Once any literal wrapper or quoting is removed, this ; follows the collation-selected rule from [RFC4790]
引用的comp-sel=astring；一旦任何文字包装或引用被删除，这；遵循从[RFC4790]中选择的排序规则
The following sections provide an overview of various other IMAP internationalization issues. These issues are not resolved by this specification, but could be resolved by other standards work, such as that being done by the EAI working group (see [IMAP-EAI]).
以下各节概述了其他各种IMAP国际化问题。本规范未解决这些问题，但可通过其他标准工作解决，如EAI工作组正在进行的工作（见[IMAP-EAI]）。
IMAP4rev1 currently restricts the userid and password fields of the LOGIN command to US-ASCII. The "userid" and "password" fields of the IMAP LOGIN command are restricted to US-ASCII only until a future standards track RFC states otherwise. Servers are encouraged to validate both fields to make sure they conform to the formal syntax of UTF-8 and to reject the LOGIN command if that syntax is violated. Servers MAY reject the LOGIN command if either the "userid" or "password" field contains an octet with the highest bit set.
IMAP4rev1当前将登录命令的用户ID和密码字段限制为US-ASCII。IMAP LOGIN命令的“userid”和“password”字段仅限于US-ASCII，直到未来的标准跟踪RFC另有规定。鼓励服务器验证这两个字段，以确保它们符合UTF-8的正式语法，并在违反该语法时拒绝登录命令。如果“userid”或“password”字段包含设置了最高位的八位字节，服务器可能会拒绝登录命令。
When AUTHENTICATE is used, some servers may support userids and passwords in Unicode [RFC3490] since SASL (see [RFC4422]) allows that. However, such userids cannot be used as part of email addresses.
当使用身份验证时，一些服务器可能支持Unicode[RFC3490]中的用户名和密码，因为SASL（请参见[RFC4422]）允许这样做。但是，此类用户名不能用作电子邮件地址的一部分。
The modified UTF-7 mailbox naming convention described in Section 5.1.3 of RFC 3501 is best viewed as an transition from the status quo in 1996 when modified UTF-7 was first specified. At that time, there was widespread unofficial use of local character sets such as ISO-8859-1 and Shift-JIS for non-ASCII mailbox names, with resultant non-interoperability.
RFC 3501第5.1.3节中描述的修改后的UTF-7邮箱命名约定最好被视为从1996年首次指定修改后的UTF-7时的现状过渡。当时，本地字符集（如ISO-8859-1和Shift JIS）被广泛非官方地用于非ASCII邮箱名称，导致互操作性不强。
The requirements in Section 5.1 of RFC 3501 are very important if we're ever going to be able to deploy UTF-8 mailbox names. Servers are encouraged to enforce them.
如果我们要部署UTF-8邮箱名称，RFC 3501第5.1节中的要求非常重要。鼓励服务器强制执行它们。
There is now an IETF standard for "Internationalizing Domain Names in Applications (IDNA)" [RFC3490]. While IMAP clients are free to support this standard, an argument can be made that it would be helpful to simple clients if the IMAP server could perform this conversion (the same argument would apply to MIME header encoding
现在有一个IETF标准用于“应用程序中的域名国际化（IDNA）”[RFC3490]。虽然IMAP客户机可以自由地支持此标准，但可以提出一个论点，即如果IMAP服务器可以执行此转换，这将对简单客户机有所帮助（相同的论点将适用于MIME头编码）
[RFC2047]). However, it would be unwise to move forward with such work until the work in progress to define the format of international email addresses is complete.
[RFC2047]）。然而，在确定国际电子邮件地址格式的工作完成之前，继续开展此类工作是不明智的。
IANA added LANGUAGE, I18NLEVEL=1, and I18NLEVEL=2 to the IMAP4 Capabilities Registry.
IANA向IMAP4功能注册表中添加了语言I18NLEVEL=1和I18NLEVEL=2。
The LANGUAGE extension makes a new command available in "Not Authenticated" state in IMAP. Some IMAP implementations run with root privilege when the server is in "Not Authenticated" state and do not revoke that privilege until after authentication is complete. Such implementations are particularly vulnerable to buffer overflow security errors at this stage and need to implement parsing of this command with extra care.
语言扩展使新命令在IMAP中处于“未验证”状态。某些IMAP实现在服务器处于“未验证”状态时使用root权限运行，并且在验证完成之前不会撤消该权限。在这个阶段，这样的实现特别容易受到缓冲区溢出安全错误的攻击，需要格外小心地实现对这个命令的解析。
A LANGUAGE command issued prior to activation of a security layer is subject to an active attack that suppresses or modifies the negotiation, and thus makes STARTTLS or authentication error messages more difficult to interpret. This is not a new attack as the error messages themselves are subject to active attack. Clients MUST re-issue the LANGUAGE command once a security layer is active, in order to prevent this attack from impacting subsequent protocol operations.
在激活安全层之前发出的语言命令会受到抑制或修改协商的主动攻击，从而使STARTTLS或身份验证错误消息更难解释。这不是新的攻击，因为错误消息本身会受到主动攻击。一旦安全层处于活动状态，客户端必须重新发出LANGUAGE命令，以防止此攻击影响后续协议操作。
LANGUAGE, I18NLEVEL=1, and I18NLEVEL=2 extensions use the UTF-8 charset; thus, the security considerations for UTF-8 [RFC3629] are relevant. However, neither uses UTF-8 for identifiers, so the most serious concerns do not apply.
语言，I18NLEVEL=1和I18NLEVEL=2扩展使用UTF-8字符集；因此，UTF-8[RFC3629]的安全注意事项是相关的。但是，两者都没有使用UTF-8作为标识符，因此最严重的问题不适用。
The LANGUAGE extension is based on a previous document by Mike Gahrns, a substantial portion of the text in that section was written by him. Many people have participated in discussions about an IMAP Language extension in the various fora of the IETF and Internet working groups, so any list of contributors is bound to be incomplete. However, the authors would like to thank Andrew McCown for early work on the original proposal, John Myers for suggestions regarding the namespace issue, along with Jutta Degener, Mark Crispin, Mark Pustilnik, Larry Osterman, Cyrus Daboo, Martin Duerst, Timo Sirainen, Ben Campbell, and Magnus Nystrom for their many suggestions that have been incorporated into this document.
语言扩展基于Mike Gahrns之前的文档，该部分的大部分文本由他编写。在IETF和互联网工作组的各种论坛上，许多人都参与了关于IMAP语言扩展的讨论，因此任何贡献者的名单都是不完整的。然而，作者要感谢安德鲁·麦考恩（Andrew McCown）对原始提案的早期工作，约翰·迈尔斯（John Myers）就名称空间问题提出的建议，以及朱塔·德杰纳（Jutta Degener）、马克·克里斯平（Mark Crispin）、马克·普斯蒂尼克（Mark Pustilnik）、拉里·奥斯特曼（Larry Osterman）、赛勒斯·达布（Cyrus Daboo）、马丁·杜尔斯（Martin Duerst）、蒂莫·西莱，和Magnus Nystrom，感谢他们在本文件中提出的许多建议。
Initial discussion of the I18NLEVEL=2 extension involved input from Mark Crispin and other participants of the IMAP Extensions WG.
I18NLEVEL=2扩展的初步讨论涉及Mark Crispin和IMAP扩展工作组其他参与者的输入。
9. Relevant Sources of Documents for Internationalized IMAP Implementations
9. 国际化IMAP实施的相关文档来源
This is a non-normative list of sources to consider when implementing i18n-aware IMAP software.
这是在执行I18N意识的IMAP软件时要考虑的非规范列表。
o The LANGUAGE and I18NLEVEL=2 extensions to IMAP (this specification).
o 语言和I18NLEVEL=2对IMAP（本规范）的扩展。
o The 8-bit rules for mailbox naming in Section 5.1 of RFC 3501.
o RFC 3501第5.1节中邮箱命名的8位规则。
o The Mailbox International Naming Convention in Section 5.1.3 of RFC 3501.
o RFC 3501第5.1.3节中的邮箱国际命名约定。
o MIME [RFC2045] for message bodies.
o 消息正文的MIME[RFC2045]。
o MIME header encoding [RFC2047] for message headers.
o 消息头的MIME头编码[RFC2047]。
o The IETF EAI working group.
o IETF EAI工作组。
o MIME Parameter Value and Encoded Word Extensions [RFC2231] for filenames. Quality IMAP server implementations will automatically combine multipart parameters when generating the BODYSTRUCTURE. There is also some deployed non-standard use of MIME header encoding inside double quotes for filenames.
o MIME参数值和文件名的编码字扩展名[RFC2231]。优质IMAP服务器实现将在生成BODYSTRUCTURE时自动组合多部分参数。在文件名的双引号中还部署了一些非标准的MIME头编码。
o IDNA [RFC3490] and punycode [RFC3492] for domain names (currently only relevant to IMAP clients).
o 域名的IDNA[RFC3490]和punycode[RFC3492]（目前仅与IMAP客户端相关）。
o The UTF-8 charset [RFC3629].
o UTF-8字符集[RFC3629]。
o The IETF policy on Character Sets and Languages [RFC2277].
o IETF关于字符集和语言的政策[RFC2277]。
[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月。
[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月。
[RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[RFC2342]Gahrns，M.和C.Newman，“IMAP4名称空间”，RFC2342，1998年5月。
[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月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.，Ed.，和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[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月。
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[RFC4646]Phillips，A.和M.Davis，“识别语言的标记”，BCP 47，RFC 46462006年9月。
[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006.
[RFC4647]Phillips，A.和M.Davis，“语言标记的匹配”，BCP 47，RFC 4647，2006年9月。
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[RFC4790]Newman，C.，Duerst，M.，和A.Gulbrandsen，“互联网应用协议整理注册表”，RFC 47902007年3月。
[SORT] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, June 2008.
[SORT]Crispin，M.和K.Murchison，“互联网消息访问协议-排序和线程扩展”，RFC 5256，2008年6月。
[UCM] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, October 2007.
[UCM]Crispin，M.，“i；unicode案例图-简单unicode排序算法”，RFC 5051，2007年10月。
[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月。
[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月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月。
[METADATA] Daboo, C., "IMAP METADATA Extension", Work in Progress, April 2008.
[元数据]Daboo，C.，“IMAP元数据扩展”，正在进行的工作，2008年4月。
[IMAP-EAI] Resnick, P., and C. Newman, "IMAP Support for UTF-8", Work in Progress, November 2007.
[IMAP-EAI]Resnick，P.和C.Newman，“对UTF-8的IMAP支持”，正在进行的工作，2007年11月。
Authors' Addresses
作者地址
Chris Newman Sun Microsystems 3401 Centrelake Dr., Suite 410 Ontario, CA 91761 US
Chris Newman Sun Microsystems 3401 Centrelake博士，美国加利福尼亚州安大略省410号套房，邮编：91761
EMail: chris.newman@sun.com
EMail: chris.newman@sun.com
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany
Arnt Gulbrandsen Oryx邮件系统有限公司Schweppermannstr。德国慕尼黑8D-81671
EMail: arnt@oryx.com
Fax: +49 89 4502 9758
EMail: arnt@oryx.com
Fax: +49 89 4502 9758
Alexey Melnikov Isode Limited 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, UK
Alexey Melnikov Isode Limited 5城堡商业村，英国米德尔塞克斯汉普顿车站路36号，TW12 2BX
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.