Network Working Group C. Newman
Request for Comments: 4790 Sun Microsystems
Category: Standards Track M. Duerst
Aoyama Gakuin University
A. Gulbrandsen
Oryx
March 2007
Network Working Group C. Newman
Request for Comments: 4790 Sun Microsystems
Category: Standards Track M. Duerst
Aoyama Gakuin University
A. Gulbrandsen
Oryx
March 2007
Internet Application Protocol Collation Registry
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
Many Internet application protocols include string-based lookup, searching, or sorting operations. However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function, and the repertoire of comparison functions can be extended in the future.
许多Internet应用程序协议包括基于字符串的查找、搜索或排序操作。然而，搜索和排序国际字符串的问题空间很大，没有得到充分的探索，并且不属于互联网工程任务组（IETF）的专业领域。本规范没有试图解决这样一个大的问题，而是创建了一个抽象框架，以便应用程序协议能够精确地识别比较函数，并且比较函数的指令集可以在将来扩展。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Collation Definition and Purpose . . . . . . . . . . . . . . . 4
2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Some Other Terms Used in this Document . . . . . . . . . . 5
2.4. Sort Keys . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Collation Identifier Syntax . . . . . . . . . . . . . . . . . 6
3.1. Basic Syntax . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Ordering Direction . . . . . . . . . . . . . . . . . . . . 7
3.4. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Naming Guidelines . . . . . . . . . . . . . . . . . . . . 7
4. Collation Specification Requirements . . . . . . . . . . . . . 8
4.1. Collation/Server Interface . . . . . . . . . . . . . . . . 8
4.2. Operations Supported . . . . . . . . . . . . . . . . . . . 8
4.2.1. Validity . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Equality . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.3. Substring . . . . . . . . . . . . . . . . . . . . . . 9
4.2.4. Ordering . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Sort Keys . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Use of Lookup Tables . . . . . . . . . . . . . . . . . . . 11
5. Application Protocol Requirements . . . . . . . . . . . . . . 11
5.1. Character Encoding . . . . . . . . . . . . . . . . . . . . 11
5.2. Operations . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. String Comparison . . . . . . . . . . . . . . . . . . . . 12
5.5. Disconnected Clients . . . . . . . . . . . . . . . . . . . 12
5.6. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 13
5.7. Octet Collation . . . . . . . . . . . . . . . . . . . . . 13
6. Use by Existing Protocols . . . . . . . . . . . . . . . . . . 13
7. Collation Registration . . . . . . . . . . . . . . . . . . . . 14
7.1. Collation Registration Procedure . . . . . . . . . . . . . 14
7.2. Collation Registration Format . . . . . . . . . . . . . . 15
7.2.1. Registration Template . . . . . . . . . . . . . . . . 15
7.2.2. The Collation Element . . . . . . . . . . . . . . . . 15
7.2.3. The Identifier Element . . . . . . . . . . . . . . . . 16
7.2.4. The Title Element . . . . . . . . . . . . . . . . . . 16
7.2.5. The Operations Element . . . . . . . . . . . . . . . . 16
7.2.6. The Specification Element . . . . . . . . . . . . . . 16
7.2.7. The Submitter Element . . . . . . . . . . . . . . . . 16
7.2.8. The Owner Element . . . . . . . . . . . . . . . . . . 16
7.2.9. The Version Element . . . . . . . . . . . . . . . . . 17
7.2.10. The Variable Element . . . . . . . . . . . . . . . . . 17
7.3. Structure of Collation Registry . . . . . . . . . . . . . 17
7.4. Example Initial Registry Summary . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Collation Definition and Purpose . . . . . . . . . . . . . . . 4
2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Some Other Terms Used in this Document . . . . . . . . . . 5
2.4. Sort Keys . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Collation Identifier Syntax . . . . . . . . . . . . . . . . . 6
3.1. Basic Syntax . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Ordering Direction . . . . . . . . . . . . . . . . . . . . 7
3.4. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Naming Guidelines . . . . . . . . . . . . . . . . . . . . 7
4. Collation Specification Requirements . . . . . . . . . . . . . 8
4.1. Collation/Server Interface . . . . . . . . . . . . . . . . 8
4.2. Operations Supported . . . . . . . . . . . . . . . . . . . 8
4.2.1. Validity . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Equality . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.3. Substring . . . . . . . . . . . . . . . . . . . . . . 9
4.2.4. Ordering . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Sort Keys . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Use of Lookup Tables . . . . . . . . . . . . . . . . . . . 11
5. Application Protocol Requirements . . . . . . . . . . . . . . 11
5.1. Character Encoding . . . . . . . . . . . . . . . . . . . . 11
5.2. Operations . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. String Comparison . . . . . . . . . . . . . . . . . . . . 12
5.5. Disconnected Clients . . . . . . . . . . . . . . . . . . . 12
5.6. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 13
5.7. Octet Collation . . . . . . . . . . . . . . . . . . . . . 13
6. Use by Existing Protocols . . . . . . . . . . . . . . . . . . 13
7. Collation Registration . . . . . . . . . . . . . . . . . . . . 14
7.1. Collation Registration Procedure . . . . . . . . . . . . . 14
7.2. Collation Registration Format . . . . . . . . . . . . . . 15
7.2.1. Registration Template . . . . . . . . . . . . . . . . 15
7.2.2. The Collation Element . . . . . . . . . . . . . . . . 15
7.2.3. The Identifier Element . . . . . . . . . . . . . . . . 16
7.2.4. The Title Element . . . . . . . . . . . . . . . . . . 16
7.2.5. The Operations Element . . . . . . . . . . . . . . . . 16
7.2.6. The Specification Element . . . . . . . . . . . . . . 16
7.2.7. The Submitter Element . . . . . . . . . . . . . . . . 16
7.2.8. The Owner Element . . . . . . . . . . . . . . . . . . 16
7.2.9. The Version Element . . . . . . . . . . . . . . . . . 17
7.2.10. The Variable Element . . . . . . . . . . . . . . . . . 17
7.3. Structure of Collation Registry . . . . . . . . . . . . . 17
7.4. Example Initial Registry Summary . . . . . . . . . . . . . 18
8. Guidelines for Expert Reviewer . . . . . . . . . . . . . . . . 18
9. Initial Collations . . . . . . . . . . . . . . . . . . . . . . 19
9.1. ASCII Numeric Collation . . . . . . . . . . . . . . . . . 20
9.1.1. ASCII Numeric Collation Description . . . . . . . . . 20
9.1.2. ASCII Numeric Collation Registration . . . . . . . . . 20
9.2. ASCII Casemap Collation . . . . . . . . . . . . . . . . . 21
9.2.1. ASCII Casemap Collation Description . . . . . . . . . 21
9.2.2. ASCII Casemap Collation Registration . . . . . . . . . 22
9.3. Octet Collation . . . . . . . . . . . . . . . . . . . . . 22
9.3.1. Octet Collation Description . . . . . . . . . . . . . 22
9.3.2. Octet Collation Registration . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 24
8. Guidelines for Expert Reviewer . . . . . . . . . . . . . . . . 18
9. Initial Collations . . . . . . . . . . . . . . . . . . . . . . 19
9.1. ASCII Numeric Collation . . . . . . . . . . . . . . . . . 20
9.1.1. ASCII Numeric Collation Description . . . . . . . . . 20
9.1.2. ASCII Numeric Collation Registration . . . . . . . . . 20
9.2. ASCII Casemap Collation . . . . . . . . . . . . . . . . . 21
9.2.1. ASCII Casemap Collation Description . . . . . . . . . 21
9.2.2. ASCII Casemap Collation Registration . . . . . . . . . 22
9.3. Octet Collation . . . . . . . . . . . . . . . . . . . . . 22
9.3.1. Octet Collation Description . . . . . . . . . . . . . 22
9.3.2. Octet Collation Registration . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 24
The Application Configuration Access Protocol ACAP [11] specification introduced the concept of a comparator (which we call collation in this document), but failed to create an IANA registry. With the introduction of stringprep [6] and the Unicode Collation Algorithm [7], it is now time to create that registry and populate it with some initial values appropriate for an international community. This specification replaces and generalizes the definition of a comparator in ACAP, and creates a collation registry.
应用程序配置访问协议ACAP[11]规范引入了比较器的概念（我们在本文中称之为排序规则），但未能创建IANA注册表。随着stringprep[6]和Unicode排序算法[7]的引入，现在是创建该注册表并使用适合国际社会的初始值填充它的时候了。本规范取代并概括了ACAP中比较器的定义，并创建了一个排序规则注册表。
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" [1].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照“RFC中用于表示需求水平的关键词”中的定义进行解释[1]。
The attribute syntax specifications use the Augmented Backus-Naur Form (ABNF) [2] notation, including the core rules defined in Appendix A. The ABNF production "Language-tag" is imported from Language Tags [5] and "reg-name" from URI: Generic Syntax [4].
属性语法规范使用增广的Backus Naur Form（ABNF）[2]表示法，包括附录A中定义的核心规则。ABNF产品“语言标记”从语言标记[5]导入，“注册名称”从URI导入：通用语法[4]。
A collation is a named function which takes two arbitrary length strings as input and can be used to perform one or more of three basic comparison operations: equality test, substring match, and ordering test.
排序规则是一个命名函数，它接受两个任意长度的字符串作为输入，并可用于执行三个基本比较操作中的一个或多个：相等性测试、子字符串匹配和排序测试。
Collations are an abstraction for comparison functions so that these comparison functions can be used in multiple protocols. The details of a particular comparison operation can be specified by someone with appropriate expertise, independent of the application protocols that use that collation. This is similar to the way a charset [13] separates the details of octet to character mapping from a protocol specification, such as MIME [9], or the way SASL [10] separates the details of an authentication mechanism from a protocol specification, such as ACAP [11].
排序规则是比较函数的抽象，因此这些比较函数可以在多个协议中使用。特定比较操作的详细信息可以由具有适当专业知识的人员指定，与使用该排序规则的应用程序协议无关。这类似于字符集[13]从协议规范（如MIME[9]）中分离八位字节到字符映射细节的方式，或者SASL[10]从协议规范（如ACAP[11]）中分离身份验证机制细节的方式。
Here is a small diagram to help illustrate the value of this abstraction:
下面是一个小图，有助于说明此抽象的价值：
+-------------------+ +-----------------+
| IMAP i18n SEARCH |--+ | Basic |
+-------------------+ | +--| Collation Spec |
| | +-----------------+
+-------------------+ | +-------------+ | +-----------------+
| ACAP i18n SEARCH |--+--| Collation |--+--| A stringprep |
+-------------------+ | | Registry | | | Collation Spec |
| +-------------+ | +-----------------+
+-------------------+ | | +-----------------+
| ...other protocol |--+ | | locale-specific |
+-------------------+ +--| Collation Spec |
+-----------------+
+-------------------+ +-----------------+
| IMAP i18n SEARCH |--+ | Basic |
+-------------------+ | +--| Collation Spec |
| | +-----------------+
+-------------------+ | +-------------+ | +-----------------+
| ACAP i18n SEARCH |--+--| Collation |--+--| A stringprep |
+-------------------+ | | Registry | | | Collation Spec |
| +-------------+ | +-----------------+
+-------------------+ | | +-----------------+
| ...other protocol |--+ | | locale-specific |
+-------------------+ +--| Collation Spec |
+-----------------+
Thus IMAP, ACAP, and future application protocols with international search capability simply specify how to interface to the collation registry instead of each protocol specification having to specify all the collations it supports.
因此，具有国际搜索功能的IMAP、ACAP和未来的应用程序协议只需指定如何连接到排序规则注册表，而不是每个协议规范都必须指定其支持的所有排序规则。
The terms client, server, and protocol are used in somewhat unusual senses.
客户机、服务器和协议这三个术语的含义有些不同寻常。
Client means a user, or a program acting directly on behalf of a user. This may be a mail reader acting as an IMAP client, or it may be an interactive shell, where the user can type protocol commands/ requests directly, or it may be a script or program written by the user.
客户端是指用户或直接代表用户的程序。这可以是充当IMAP客户端的邮件读取器，也可以是用户可以直接键入协议命令/请求的交互式shell，也可以是用户编写的脚本或程序。
Server means a program that performs services requested by the client. This may be a traditional server such as an HTTP server, or it may be a Sieve [14] interpreter running a Sieve script written by a user. A server needs to use the operations provided by collations in order to fulfill the client's requests.
服务器是指执行客户端请求的服务的程序。这可能是一个传统的服务器，如HTTP服务器，也可能是一个运行用户编写的筛脚本的筛[14]解释器。服务器需要使用排序规则提供的操作来满足客户机的请求。
The protocol describes how the client tells the server what it wants done, and (if applicable) how the server tells the client about the results. IMAP is a protocol by this definition, and so is the Sieve language.
协议描述了客户端如何告诉服务器它想要做什么，以及（如果适用）服务器如何告诉客户端结果。根据这个定义，IMAP是一个协议，筛语言也是。
One component of a collation is a transformation, which turns a string into a sort key, which is then used while sorting.
排序规则的一个组成部分是转换，它将字符串转换为排序键，然后在排序时使用排序键。
The transformation can range from an identity mapping (e.g., the i;octet collation Section 9.3) to a mapping that makes the string unreadable to a human.
转换的范围可以从标识映射（例如，第9.3节的八位字节排序规则）到使字符串对人不可读的映射。
This is an implementation detail of collations or servers. A protocol SHOULD NOT expose it to clients, since some collations leave the sort key's format up to the implementation, and current conformant implementations are known to use different formats.
这是排序规则或服务器的实现细节。协议不应该向客户机公开它，因为有些排序规则将排序键的格式留给实现，并且已知当前的一致性实现使用不同的格式。
The collation identifier itself is a single US-ASCII string. The identifier MUST NOT be longer than 254 characters, and obeys the following grammar:
排序规则标识符本身是一个US-ASCII字符串。标识符的长度不得超过254个字符，并遵循以下语法：
collation-char = ALPHA / DIGIT / "-" / ";" / "=" / "."
collation-char = ALPHA / DIGIT / "-" / ";" / "=" / "."
collation-id = collation-prefix ";" collation-core-name *collation-arg
排序规则id=排序规则前缀“；”排序规则核心名称*排序规则参数
collation-scope = Language-tag / "vnd-" reg-name
排序范围=语言标记/“vnd-”注册表名
collation-core-name = ALPHA *( ALPHA / DIGIT / "-" )
collation-core-name = ALPHA *( ALPHA / DIGIT / "-" )
collation-arg = ";" ALPHA *( ALPHA / DIGIT ) "="
1*( ALPHA / DIGIT / "." )
collation-arg = ";" ALPHA *( ALPHA / DIGIT ) "="
1*( ALPHA / DIGIT / "." )
Note: the ABNF production "Language-tag" is imported from Language Tags [5] and "reg-name" from URI: Generic Syntax [4].
注意：ABNF产品“语言标签”是从语言标签[5]导入的，而“注册名称”是从URI:Generic Syntax[4]导入的。
There is a special identifier called "default". For protocols that have a default collation, "default" refers to that collation. For other protocols, the identifier "default" MUST match no collations, and servers SHOULD treat it in the same way as they treat nonexistent collations.
有一个称为“default”的特殊标识符。对于具有默认排序规则的协议，“default”指的是该排序规则。对于其他协议，标识符“default”必须与任何排序规则都不匹配，服务器应以处理不存在的排序规则的方式来处理它。
The string a client uses to select a collation MAY contain one or more wildcard ("*") characters that match zero or more collation-chars. Wildcard characters MUST NOT be adjacent. If the wildcard string matches multiple collations, the server SHOULD attempt to select a widely useful collation in preference to a narrowly useful one.
客户端用于选择排序规则的字符串可能包含一个或多个与零个或多个排序规则字符匹配的通配符（*）。通配符不能相邻。如果通配符字符串匹配多个排序规则，则服务器应尝试选择广泛有用的排序规则，而不是狭义有用的排序规则。
collation-wild = ("*" / (ALPHA ["*"])) *(collation-char ["*"])
; MUST NOT exceed 254 characters total
collation-wild = ("*" / (ALPHA ["*"])) *(collation-char ["*"])
; MUST NOT exceed 254 characters total
When used as a protocol element for ordering, the collation identifier MAY be prefixed by either "+" or "-" to explicitly specify an ordering direction. "+" has no effect on the ordering operation, while "-" inverts the result of the ordering operation. In general, collation-order is used when a client requests a collation, and collation-selected is used when the server informs the client of the selected collation.
当用作排序的协议元素时，排序规则标识符的前缀可以是“+”或“-”，以明确指定排序方向。“+”对排序操作没有影响，而“-”反转排序操作的结果。通常，当客户端请求排序规则时使用排序规则顺序，当服务器通知客户端所选排序规则时使用所选排序规则。
collation-selected = ["+" / "-"] collation-id
collation-selected = ["+" / "-"] collation-id
collation-order = ["+" / "-"] collation-wild
collation-order = ["+" / "-"] collation-wild
Some protocols are designed to use URIs [4] to refer to collations rather than simple tokens. A special section of the IANA URL space is reserved for such usage. The "collation-uri" form is used to refer to a specific named collation (the collation registration may not actually be present). The "collation-auri" form is an abstract name for an ordering, a collation pattern or a vendor private collator.
有些协议设计为使用URI[4]来引用排序规则，而不是简单的令牌。IANA URL空间的一个特殊部分是为这种用途保留的。“排序规则uri”表单用于引用特定的命名排序规则（排序规则注册可能实际上不存在）。“排序规则auri”表单是订单、排序规则模式或供应商专用排序器的抽象名称。
collation-uri = "http://www.iana.org/assignments/collation/"
collation-id ".xml"
collation-uri = "http://www.iana.org/assignments/collation/"
collation-id ".xml"
collation-auri = ( "http://www.iana.org/assignments/collation/"
collation-order ".xml" ) / other-uri
collation-auri = ( "http://www.iana.org/assignments/collation/"
collation-order ".xml" ) / other-uri
other-uri = <absoluteURI>
; excluding the IANA collation namespace.
other-uri = <absoluteURI>
; excluding the IANA collation namespace.
While this specification makes no absolute requirements on the structure of collation identifiers, naming consistency is important, so the following initial guidelines are provided.
虽然本规范对排序规则标识符的结构没有绝对要求，但命名一致性很重要，因此提供了以下初始指导原则。
Collation identifiers with an international audience typically begin with "i;". Collation identifiers intended for a particular language or locale typically begin with a language tag [5] followed by a ";". After the first ";" is normally the name of the general collation algorithm, followed by a series of algorithm modifications separated by the ";" delimiter. Parameterized modifications will use "=" to
国际受众的排序规则标识符通常以“i；”开头。用于特定语言或区域设置的排序规则标识符通常以语言标记[5]开头，后跟“；”。第一个“；”后面通常是一般排序算法的名称，后面是一系列由“；”分隔符分隔的算法修改。参数化修改将使用“=”来
delimit the parameter from the value. The version numbers of any lookup tables used by the algorithm SHOULD be present as parameterized modifications.
从值中分隔参数。算法使用的任何查找表的版本号应作为参数化修改显示。
Collation identifiers of the form *;vnd-hostname;* are reserved for vendor-specific collations created by the owner of the hostname following the "vnd-" prefix (e.g., vnd-example.com for the vendor example.com). Registration of such collations (or the name space as a whole), with intended use of the "Vendor", is encouraged when a public specification or open-source implementation is available, but is not required.
表格*的排序规则标识符；vnd主机名；*保留用于主机名所有者在“vnd-”前缀后创建的特定于供应商的排序规则（例如，vendor example.com的vnd-example.com）。当公共规范或开放源码实现可用时，鼓励注册此类排序规则（或名称空间作为一个整体），以达到“供应商”的预期用途，但不是必需的。
The collation itself defines what it operates on. Most collations are expected to operate on character strings. The i;octet (Section 9.3) collation operates on octet strings. The i;ascii-numeric (Section 9.1) operation operates on numbers.
排序规则本身定义了它的操作。大多数排序规则都需要对字符串进行操作。我；八位字节（第9.3节）排序对八位字节字符串进行操作。我；ascii数字（第9.1节）操作对数字进行操作。
This specification defines the collation interface in terms of octet strings. However, implementations may choose to use character strings instead. Such implementations may not be able to implement e.g., i;octet. Since i;octet is not currently mandatory to implement for any protocol, this should not be a problem.
本规范根据八位字节字符串定义排序规则接口。但是，实现可能会选择使用字符串。此类实现可能无法实现，例如，i；八重奏。自从我；octet目前不是任何协议都必须实现的，这应该不是问题。
A collation specification MUST state which of the three basic operations are supported (equality, substring, ordering) and how to perform each of the supported operations on any two input character strings, including empty strings. Collations must be deterministic, i.e., given a collation with a specific identifier, and any two fixed input strings, the result MUST be the same for the same operation.
排序规则规范必须说明支持三个基本操作（相等、子字符串、排序）中的哪一个，以及如何对任意两个输入字符串（包括空字符串）执行每个支持的操作。排序规则必须是确定性的，即给定具有特定标识符的排序规则和任意两个固定输入字符串，同一操作的结果必须相同。
In general, collation operations should behave as their names suggest. While a collation may be new, the operations are not, so the new collation's operations should be similar to those of older collations. For example, a date/time collation should not provide a "substring" operation that would morph IMAP substring SEARCH into e.g., a date-range search.
一般来说，排序规则操作的行为应该与其名称相符。虽然排序规则可能是新的，但操作不是新的，因此新排序规则的操作应该与旧排序规则的操作类似。例如，日期/时间排序规则不应提供将IMAP子字符串搜索变形为日期范围搜索的“子字符串”操作。
A non-obvious consequence of the rules for each collation operation is that, for any single collation, either none or all of the operations can return "undefined". For example, it is not possible to have an equality operation that never returns "undefined", and a substring operation that occasionally does.
每个排序规则操作的规则的一个不明显的结果是，对于任何单个排序规则，没有或所有操作都可以返回“undefined”。例如，不可能有从不返回“undefined”的相等操作和偶尔返回“undefined”的子字符串操作。
The validity test takes one string as argument. It returns valid if its input string is a valid input to the collation's other operations, and invalid if not. (In other words, a string is valid if it is equal to itself according to the collation's equality operation.)
有效性测试以一个字符串作为参数。如果其输入字符串是排序规则其他操作的有效输入，则返回valid，否则返回invalid。（换句话说，如果根据排序规则的相等操作，字符串等于其自身，则该字符串是有效的。）
The validity test is provided by all collations. It MUST NOT be listed separately in the collation registration.
有效性测试由所有排序规则提供。不得在整理登记中单独列出。
The equality test always returns "match" or "no-match" when it is supplied valid input, and MAY return "undefined" if one or both input strings are not valid.
当提供有效输入时，相等性测试始终返回“匹配”或“不匹配”，如果一个或两个输入字符串无效，则可能返回“未定义”。
The equality test MUST be reflexive and symmetric. For valid input, it MUST be transitive.
等式检验必须是自反的和对称的。对于有效输入，它必须是可传递的。
If a collation provides either a substring or an ordering test, it MUST also provide an equality test. The substring and/or ordering tests MUST be consistent with the equality test.
如果排序规则提供子字符串或排序测试，则它还必须提供相等测试。子字符串和/或顺序测试必须与相等测试一致。
The return values of the equality test are called "match", "no-match" and "undefined" in this document.
平等性测试的返回值在本文档中称为“匹配”、“不匹配”和“未定义”。
The substring matching operation determines if the first string is a substring of the second string, i.e., if one or more substrings of the second string is equal to the first, as defined by the collation's equality operation.
子字符串匹配操作确定第一个字符串是否为第二个字符串的子字符串，即第二个字符串的一个或多个子字符串是否等于第一个字符串，如排序规则的相等操作所定义的。
A collation that supports substring matching will automatically support two special cases of substring matching: prefix and suffix matching, if those special cases are supported by the application protocol. It returns "match" or "no-match" when it is supplied valid input and returns "undefined" when supplied invalid input.
支持子字符串匹配的排序规则将自动支持子字符串匹配的两种特殊情况：前缀和后缀匹配（如果应用程序协议支持这些特殊情况）。当提供有效输入时，它返回“匹配”或“不匹配”，当提供无效输入时，它返回“未定义”。
Application protocols MAY return position information for substring matches. If this is done, the position information SHOULD include both the starting offset and the ending offset for each match. This is important because more sophisticated collations can match strings of unequal length (for example, a pre-composed accented character can match a decomposed accented character). In general, overlapping matches SHOULD be reported (as when "ana" occurs twice within "banana"), although there are cases where a collation may decide not
应用程序协议可以返回子字符串匹配的位置信息。如果完成此操作，位置信息应包括每个匹配的开始偏移和结束偏移。这一点很重要，因为更复杂的排序规则可以匹配长度不等的字符串（例如，预合成的重音字符可以匹配分解的重音字符）。一般来说，应该报告重叠匹配（如“ana”在“banana”中出现两次），尽管在某些情况下，排序规则可能会决定不重复
to. For example, in a collation which treats all whitespace sequences as identical, the substring operation could be defined such that " 1 " (SP "1" SP) is reported just once within " 1 " (SP SP "1" SP SP), not four times (SP SP "1" SP, SP "1" SP, SP "1" SP SP and SP SP "1" SP SP), since the four matches are, in a sense, the same match.
到例如，在将所有空白序列视为相同的排序规则中，子字符串操作可以定义为“1”（SP“1”SP）在“1”（SP“1”SP SP）中只报告一次，而不是四次（SP“1”SP、SP“1”SP、SP“1”SP和SP“1”SP），因为这四个匹配在某种意义上是相同的匹配。
A string is a substring of itself. The empty string is a substring of all strings.
字符串本身就是一个子字符串。空字符串是所有字符串的子字符串。
Note that the substring operation of some collations can match strings of unequal length. For example, a pre-composed accented character can match a decomposed accented character. The Unicode Collation Algorithm [7] discusses this in more detail.
请注意，某些排序规则的子字符串操作可以匹配长度不等的字符串。例如，预合成的重音字符可以与分解的重音字符匹配。Unicode排序算法[7]对此进行了更详细的讨论。
The return values of the substring operation are called "match", "no-match", and "undefined" in this document.
在本文档中，子字符串操作的返回值称为“匹配”、“不匹配”和“未定义”。
The ordering operation determines how two strings are ordered. It MUST be reflexive. For valid input, it MUST be transitive and trichotomous.
排序操作确定两个字符串的排序方式。它必须是反射性的。对于有效的输入，它必须是可传递的和三合的。
Ordering returns "less" if the first string is listed before the second string, according to the collation; "greater", if the second string is listed before the first string; and "equal", if the two strings are equal, as defined by the collation's equality operation. If one or both strings are invalid, the result of ordering is "undefined".
根据排序规则，如果第一个字符串列在第二个字符串之前，则排序返回“less”；“更大”，如果第二个字符串列在第一个字符串之前；和“equal”，如果两个字符串相等（由排序规则的相等操作定义）。如果一个或两个字符串无效，则排序结果为“未定义”。
When the collation is used with a "+" prefix, the behavior is the same as when used with no prefix. When the collation is used with a "-" prefix, the result of the ordering operation of the collation MUST be reversed.
当排序规则与“+”前缀一起使用时，其行为与不使用前缀时相同。当排序规则与“-”前缀一起使用时，排序规则的排序操作的结果必须颠倒。
The return values of the ordering operation are called "less", "equal", "greater", and "undefined" in this document.
在本文档中，排序操作的返回值称为“小于”、“等于”、“大于”和“未定义”。
A collation specification SHOULD describe the internal transformation algorithm to generate sort keys. This algorithm can be applied to individual strings, and the result can be stored to potentially optimize future comparison operations. A collation MAY specify that the sort key is generated by the identity function. The sort key may have no meaning to a human. The sort key may not be valid input to the collation.
排序规范应该描述生成排序键的内部转换算法。该算法可以应用于单个字符串，并且可以存储结果以潜在地优化未来的比较操作。排序规则可以指定排序键由identity函数生成。排序键可能对人没有意义。排序键可能不是排序规则的有效输入。
Some collations use customizable lookup tables, e.g., because the tables depend on locale, and may be modified after shipping the software. Collations that use more than one customizable lookup table in a documented format MUST assign numbers to the tables they use. This permits an application protocol command to access the tables used by a server collation, so that clients and servers use the same tables.
某些排序规则使用可自定义的查找表，例如，因为这些表取决于区域设置，并且可能在软件发布后进行修改。以文档格式使用多个可自定义查找表的排序规则必须为其使用的表分配数字。这允许应用程序协议命令访问服务器排序规则使用的表，以便客户端和服务器使用相同的表。
This section describes the requirements and issues that an application protocol needs to consider if it offers searching, substring matching and/or sorting, and permits the use of characters outside the US-ASCII charset.
本节描述了应用协议在提供搜索、子字符串匹配和/或排序时需要考虑的问题，并允许使用在U-ASCII字符集之外的字符。
The protocol specification has to make sure that it is clear on which characters (rather than just octets) the collations are used. This can be done by specifying the protocol itself in terms of characters (e.g., in the case of a query language), by specifying a single character encoding for the protocol (e.g., UTF-8 [3]), or by carefully describing the relevant issues of character encoding labeling and conversion. In the later case, details to consider include how to handle unknown charsets, any charsets that are mandatory-to-implement, any issues with byte-order that might apply, and any transfer encodings that need to be supported.
协议规范必须确保清楚使用排序规则的字符（而不仅仅是八位字节）。这可以通过以下方式实现：根据字符（例如，在查询语言的情况下）指定协议本身，为协议指定单个字符编码（例如，UTF-8[3]），或者仔细描述字符编码标签和转换的相关问题。在后一种情况下，要考虑的细节包括如何处理未知的字符集、强制执行的任何字符集、可能适用的字节顺序的任何问题以及需要支持的任何传输编码。
The protocol must specify which of the operations defined in this specification (equality matching, substring matching, and ordering) can be invoked in the protocol, and how they are invoked. There may be more than one way to invoke an operation.
协议必须指定本规范中定义的哪些操作（相等匹配、子字符串匹配和排序）可以在协议中调用，以及如何调用它们。调用操作的方法可能不止一种。
The protocol MUST provide a mechanism for the client to select the collation to use with equality matching, substring matching, and ordering.
协议必须提供一种机制，让客户端选择排序规则，以便与相等匹配、子字符串匹配和排序一起使用。
If a protocol needs a total ordering and the collation chosen does not provide it because the ordering operation returns "undefined" at least once, the recommended fallback is to sort all invalid strings after the valid ones, and use i;octet to order the invalid strings.
如果协议需要总排序，而选择的排序规则由于排序操作至少返回一次“undefined”（未定义）而无法提供总排序，建议的回退方法是将所有无效字符串排序在有效字符串之后，并使用i；八位字节对无效字符串进行排序。
Although the collation's substring function provides a list of matches, a protocol need not provide all that to the client. It may
尽管排序规则的子字符串函数提供了匹配项列表，但协议不需要向客户端提供所有匹配项。可能
provide only the first matching substring, or even just the information that the substring search matched. In this way, collations can be used with protocols that are defined such that "x is a substring of y" returns true-false.
仅提供第一个匹配的子字符串，甚至仅提供子字符串搜索匹配的信息。通过这种方式，排序规则可以与协议一起使用，协议定义为“x是y的子字符串”返回true-false。
If the protocol provides positional information for the results of a substring match, that positional information SHOULD fully specify the substring(s) in the result that matches, independent of the length of the search string. For example, returning both the starting and ending offset of the match would suffice, as would the starting offset and a length. Returning just the starting offset is not acceptable. This rule is necessary because advanced collations can treat strings of different lengths as equal (for example, pre-composed and decomposed accented characters).
如果协议为子字符串匹配的结果提供位置信息，则该位置信息应完全指定匹配结果中的子字符串，与搜索字符串的长度无关。例如，返回匹配的起始偏移量和结束偏移量，以及起始偏移量和长度就足够了。仅返回起始偏移量是不可接受的。此规则是必需的，因为高级排序规则可以将不同长度的字符串视为相等（例如，预合成和分解的重音字符）。
The protocol MUST specify whether it allows the use of wildcards in collation identifiers. If the protocol allows wildcards, then: The protocol MUST specify how comparisons behave in the absence of explicit collation negotiation, or when a collation of "default" is requested. The protocol MAY specify that the default collation used in such circumstances is sensitive to server configuration.
协议必须指定是否允许在排序规则标识符中使用通配符。如果协议允许通配符，那么：协议必须指定在没有显式排序规则协商或请求“default”排序规则时比较的行为。协议可以指定在这种情况下使用的默认排序规则对服务器配置敏感。
The protocol SHOULD provide a way to list available collations matching a given wildcard pattern, or patterns.
协议应该提供一种方法来列出与给定通配符模式匹配的可用排序规则。
If a protocol compares strings in any nontrivial way, using a collation may be appropriate. As an example, many protocols use case-independent strings. In many cases, a simple ASCII mapping to upper/lower case works well. In other cases, it may be better to use a specifiable collation; for example, so that a server can treat "i" and "I" as equivalent in Italy, and different in Turkey (Turkish also has a dotted upper-case" I" and a dotless lower-case "i").
如果协议以任何非平凡的方式比较字符串，则使用排序规则可能是合适的。例如，许多协议使用与大小写无关的字符串。在许多情况下，一个简单的ASCII映射到大写/小写可以很好地工作。在其他情况下，最好使用可指定的排序规则；例如，服务器可以在意大利将“i”和“i”视为等价物，在土耳其则不同（土耳其语也有带点的大写“i”和无点的小写“i”）。
Protocol designers should consider, in each case, whether to use a specifiable collation. Keywords often have other needs than user variables, and search arguments may be different again.
在每种情况下，协议设计者都应该考虑是否使用可指定的排序规则。关键字通常有用户变量以外的其他需求，搜索参数也可能不同。
If the protocol supports disconnected clients, and a collation is used that can use configurable tables (e.g., to support locale-specific extensions), then the client may not be able to reproduce the server's collation operations while offline.
如果协议支持断开连接的客户端，并且使用了可以使用可配置表的排序规则（例如，支持特定于语言环境的扩展），则客户端可能无法在脱机时再现服务器的排序规则操作。
A mechanism to download such tables has been discussed. Such a mechanism is not included in the present specification, since the problem is not yet well understood.
已经讨论了下载此类表的机制。这种机制不包括在本说明书中，因为该问题尚未被很好地理解。
The protocol specification should consider assigning protocol error codes for the following circumstances:
协议规范应考虑为下列情况分配协议错误代码：
o The client requests the use of a collation by identifier or pattern, but no implemented collation matches that pattern.
o 客户机请求按标识符或模式使用排序规则，但没有实现与该模式匹配的排序规则。
o The client attempts to use a collation for an operation that is not supported by that collation -- for example, attempting to use the "i;ascii-numeric" collation for substring matching.
o 客户端尝试对排序规则不支持的操作使用排序规则——例如，尝试使用“i；ascii数字”排序规则进行子字符串匹配。
o The client uses an equality or substring matching collation, and the result is an error. It may be appropriate to distinguish between the two input strings, particularly when one is supplied by the client and the other is stored by the server. It might also be appropriate to distinguish the specific case of an invalid UTF-8 string.
o 客户端使用相等或子字符串匹配排序规则，结果是错误。区分两个输入字符串可能是合适的，特别是当一个由客户端提供，另一个由服务器存储时。区分无效UTF-8字符串的特定情况也可能是合适的。
The i;octet (Section 9.3) collation is only usable with protocols based on octet-strings. Clients and servers MUST NOT use i;octet with other protocols.
我；八位字节（第9.3节）排序规则仅适用于基于八位字节字符串的协议。客户端和服务器不得使用i；八位字节与其他协议。
If the protocol permits the use of collations with data structures other than strings, the protocol MUST describe the default behavior for a collation with those data structures.
如果协议允许将排序规则与字符串以外的数据结构一起使用，则协议必须描述具有这些数据结构的排序规则的默认行为。
This section is informative.
本节内容丰富。
Both ACAP [11] and Sieve [14] are standards track specifications that used collations prior to the creation of this specification and registry. Those standards do not meet all the application protocol requirements described in Section 5.
ACAP[11]和SIVE[14]都是标准轨道规范，在创建此规范和注册表之前使用了排序规则。这些标准不符合第5节中描述的所有应用协议要求。
These protocols allow the use of the i;octet (Section 9.3) collation working directly on UTF-8 data, as used in these protocols.
这些协议允许使用i；八位字节（第9.3节）排序直接处理这些协议中使用的UTF-8数据。
In Sieve, all matches are either true or false. Accordingly, Sieve servers must treat "undefined" and "no-match" results of the equality and substring operations as false, and only "match" as true.
在Sieve中，所有匹配要么为真，要么为假。相应地，筛服务器必须将相等和子字符串操作的“未定义”和“不匹配”结果视为false，而仅将“匹配”结果视为true。
In ACAP and Sieve, there are no invalid strings. In this document's terms, invalid strings sort after valid strings.
在ACAP和Sieve中，没有无效字符串。在本文档中，无效字符串在有效字符串之后排序。
IMAP [15] also collates, although that is explicit only when the COMPARATOR [17] extension is used. The built-in IMAP substring operation and the ordering provided by the SORT [16] extension may not meet the requirements made in this document.
IMAP[15]也进行校对，尽管这仅在使用比较器[17]扩展时才明确。SORT[16]扩展提供的内置IMAP子字符串操作和排序可能不符合本文档中的要求。
Other protocols may be in a similar position.
其他协议可能处于类似的位置。
In IMAP, the default collation is i;ascii-casemap, because its operations are understood to match IMAP's built-in operations.
在IMAP中，默认的排序规则是i；ascii casemap，因为其操作与IMAP的内置操作相匹配。
The IETF will create a mailing list, collation@ietf.org, which can be used for public discussion of collation proposals prior to registration. Use of the mailing list is strongly encouraged. The IESG will appoint a designated expert who will monitor the collation@ietf.org mailing list and review registrations.
IETF将创建一个邮件列表，collation@ietf.org，可在注册前供公众讨论整理建议。强烈鼓励使用邮件列表。IESG将任命一名指定专家，负责监督collation@ietf.org邮件列表和审查注册。
The registration procedure begins when a completed registration template is sent to iana@iana.org and collation@ietf.org. The designated expert is expected to tell IANA and the submitter of the registration within two weeks whether the registration is approved, approved with minor changes, or rejected with cause. When a registration is rejected with cause, it can be re-submitted if the concerns listed in the cause are addressed. Decisions made by the designated expert can be appealed to the IESG Applications Area Director, then to the IESG. They follow the normal appeals procedure for IESG decisions.
将完成的注册模板发送到时，注册过程开始iana@iana.org和collation@ietf.org. 指定专家应在两周内告知IANA和注册提交人注册是否被批准、批准时有微小变更还是有理由拒绝。当有理由拒绝注册时，如果原因中列出的问题得到解决，则可以重新提交注册。指定专家做出的决定可向IESG应用领域总监提出上诉，然后再向IESG提出上诉。他们遵循IESG裁决的正常上诉程序。
Collation registrations in a standards track, BCP, or IESG-approved experimental RFC are owned by the IETF, and changes to the registration follow normal procedures for updating such documents. Collation registrations in other RFCs are owned by the RFC author(s). Other collation registrations are owned by the individual(s) listed in the contact field of the registration, and IANA will preserve this information.
标准轨道、BCP或IESG批准的实验RFC中的整理注册归IETF所有，注册变更遵循更新此类文件的正常程序。其他RFC中的排序规则注册归RFC作者所有。其他整理登记由登记联系人字段中列出的个人所有，IANA将保留此信息。
If the registration is a change of an existing collation, it MUST be approved by the owner. In the event the owner cannot be contacted
如果注册是对现有排序规则的更改，则必须得到所有者的批准。如果无法联系到所有者
for a period of one month, and the designated expert deems the change necessary, the IESG MAY re-assign ownership to an appropriate party.
在一个月的期限内，如果指定专家认为有必要进行变更，IESG可以将所有权重新转让给适当的一方。
Registration of a collation is done by sending a well-formed XML document to collation@ietf.org and iana@iana.org.
通过将格式良好的XML文档发送到collation@ietf.org和iana@iana.org.
Here is a template for the registration:
以下是注册的模板：
<?xml version='1.0'?>
<!DOCTYPE collation SYSTEM 'collationreg.dtd'>
<collation rfc="YYYY" scope="global" intendedUse="common">
<identifier>collation identifier</identifier>
<title>technical title for collation</title>
<operations>equality order substring</operations>
<specification>specification reference</specification>
<owner>email address of owner or IETF</owner>
<submitter>email address of submitter</submitter>
<version>1</version>
</collation>
<?xml version='1.0'?>
<!DOCTYPE collation SYSTEM 'collationreg.dtd'>
<collation rfc="YYYY" scope="global" intendedUse="common">
<identifier>collation identifier</identifier>
<title>technical title for collation</title>
<operations>equality order substring</operations>
<specification>specification reference</specification>
<owner>email address of owner or IETF</owner>
<submitter>email address of submitter</submitter>
<version>1</version>
</collation>
The root of the registration document MUST be a <collation> element. The collation element contains the other elements in the registration, which are described in the following sub-subsections, in the order given here.
注册文档的根必须是<collation>元素。collation元素包含注册中的其他元素，这些元素按照此处给出的顺序在下面的子小节中描述。
The <collation> element MAY include an "rfc=" attribute if the specification is in an RFC. The "rfc=" attribute gives only the number of the RFC, without any prefix, such as "RFC", or suffix, such as ".txt".
如果规范位于rfc中，<collation>元素可能包含一个“rfc=”属性。“rfc=”属性只给出rfc的编号，没有任何前缀，如“rfc”，或后缀，如“.txt”。
The <collation> element MUST include a "scope=" attribute, which MUST have one of the values "global", "local", or "other".
<collation>元素必须包含一个“scope=”属性，该属性必须具有一个值“global”、“local”或“other”。
The <collation> element MUST include an "intendedUse=" attribute, which must have one of the values "common", "limited", "vendor", or "deprecated". Collation specifications intended for "common" use are expected to reference standards from standards bodies with significant experience dealing with the details of international character sets.
<collation>元素必须包含一个“intendedUse=”属性，该属性的值必须为“common”、“limited”、“vendor”或“deprecated”。用于“通用”用途的整理规范应参考具有处理国际字符集细节丰富经验的标准机构的标准。
Be aware that future revisions of this specification may add additional function types, as well as additional XML attributes,
请注意，本规范的未来版本可能会添加其他函数类型以及其他XML属性，
values, and elements. Any system that automatically parses these XML documents MUST take this into account to preserve future compatibility.
值和元素。任何自动解析这些XML文档的系统都必须考虑到这一点，以保持将来的兼容性。
The <identifier> element gives the precise identifier of the collation, e.g., i;ascii-casemap. The <identifier> element is mandatory.
<identifier>元素给出排序规则的精确标识符，例如i；ascii案例图。<identifier>元素是必需的。
The <title> element gives the title of the collation. The <title> element is mandatory.
元素提供排序规则的标题。<title>元素是必需的。
The <operations> element lists which of the three operations ("equality", "order" or "substring") the collation provides, separated by single spaces. The <operations> element is mandatory.
元素列出排序规则提供的三个操作（“相等”、“顺序”或“子字符串”）中的哪一个，用单个空格分隔。<operations>元素是必需的。
The <specification> element describes where to find the specification. The <specification> element is mandatory. It MAY have a URI attribute. There may be more than one <specification> element, in which case, they together form the specification.
<specification>元素描述了在何处查找规范。<specification>元素是必需的。它可能有一个URI属性。可能有多个<specification>元素，在这种情况下，它们一起构成规范。
If it is discovered that parts of a collation specification conflict, a new revision of the collation is necessary, and the collation@ietf.org mailing list should be notified.
如果发现排序规则规范的某些部分存在冲突，则需要对排序规则进行新的修订，并且collation@ietf.org应通知邮件列表。
The <submitter> element provides an RFC 2822 [12] email address for the person who submitted the registration. It is optional if the <owner> element contains an email address.
<submitter>元素为提交注册的人提供RFC 2822[12]电子邮件地址。如果<owner>元素包含电子邮件地址，则它是可选的。
There may be more than one <submitter> element.
可能有多个<submitter>元素。
The <owner> element contains either the four letters "IETF" or an email address of the owner of the registration. The <owner> element is mandatory. There may be more than one <owner> element. If so, all owners are equal. Each owner can speak for all.
<owner>元素包含四个字母“IETF”或注册所有者的电子邮件地址。<owner>元素是必需的。可能有多个<owner>元素。如果是这样，所有所有者都是平等的。每个所有者都可以代表所有人说话。
The <version> element MUST be included when the registration is likely to be revised, or has been revised in such a way that the results change for one or more input strings. The <version> element is optional.
当注册可能会被修改，或者修改的方式使一个或多个输入字符串的结果发生变化时，必须包含<version>元素。<version>元素是可选的。
The <variable> element specifies an optional variable to control the collation's behaviour, for example whether it is case sensitive. The <variable> element is optional. When <variable> is used, it must contain <name> and <default> elements, and it may contain one or more <value> elements.
元素指定一个可选变量来控制排序规则的行为，例如它是否区分大小写。<variable>元素是可选的。使用<variable>时，它必须包含<name>和<default>元素，并且可以包含一个或多个<value>元素。
The <name> element specifies the name value of a variable. The <name> element is mandatory.
元素指定变量的名称值。<name>元素是必需的。
The <default> element specifies the default value of a variable. The <default> element is mandatory.
元素指定变量的默认值。<default>元素是必需的。
The <value> element specifies a legal value of a variable. The <value> element is optional. If one or more <value> elements are present, only those values are legal. If none are, then the variable's legal values do not form an enumerated set, and the rules MUST be specified in an RFC accompanying the registration.
元素指定变量的合法值。<value>元素是可选的。如果存在一个或多个<value>元素，则只有这些值是合法的。如果没有，则变量的合法值不会形成枚举集，并且必须在注册时随附的RFC中指定规则。
Once the registration is approved, IANA will store each XML registration document in a URL of the form http://www.iana.org/assignments/collation/collation-id.xml, where collation-id is the content of the identifier element in the registration. Both the submitter and the designated expert are responsible for verifying that the XML is well-formed. The registration document should avoid using new elements. If any are necessary, it is important to be consistent with other registrations.
一旦注册获得批准，IANA将把每个XML注册文档存储在表单的URL中http://www.iana.org/assignments/collation/collation-id.xml，其中排序规则id是注册中标识符元素的内容。提交者和指定的专家都负责验证XML格式是否正确。登记文件应避免使用新元素。如有必要，必须与其他注册保持一致。
IANA will also maintain a text summary of the registry under the name
http://www.iana.org/assignments/collation/collation-index.html. This
summary is divided into four sections. The first section is for
collations intended for common use. This section is intended for
IANA will also maintain a text summary of the registry under the name
http://www.iana.org/assignments/collation/collation-index.html. This
summary is divided into four sections. The first section is for
collations intended for common use. This section is intended for
collation registrations published in IESG-approved RFCs, or for locally scoped collations from the primary standards body for that locale. The designated expert is encouraged to reject collation registrations with an intended use of "common" if the expert believes it should be "limited", as it is desirable to keep the number of "common" registrations small and of high quality. The second section is reserved for limited-use collations. The third section is reserved for registered vendor-specific collations. The final section is reserved for deprecated collations.
在IESG批准的RFC中发布的排序规则注册，或该地区主要标准机构的本地范围排序规则。如果指定专家认为应“有限”，则鼓励指定专家拒绝预期用途为“普通”的整理登记，因为最好保持“普通”登记的数量少且质量高。第二部分保留给有限使用的排序规则。第三部分保留用于已注册的供应商特定排序规则。最后一节是为不推荐使用的排序规则保留的。
The following is an example of how IANA might structure the initial registry summary.html file:
以下是IANA如何构造初始注册表summary.html文件的示例：
Collation Functions Scope Reference
--------- --------- ----- ---------
Common Use Collations:
i;ascii-casemap e, o, s Local [RFC 4790]
Collation Functions Scope Reference
--------- --------- ----- ---------
Common Use Collations:
i;ascii-casemap e, o, s Local [RFC 4790]
Limited Use Collations: i;octet e, o, s Other [RFC 4790] i;ascii-numeric e, o Other [RFC 4790]
有限使用排序规则：i；八位组e，o，s其他[RFC 4790]i；ascii数字e，o其他[RFC 4790]
Vendor Collations:
供应商排序规则：
Deprecated Collations:
不推荐使用的排序规则：
References
----------
[RFC 4790] Newman, C., Duerst, M., Gulbrandsen, A., "Internet
Application Protocol Collation Registry", RFC 4790,
Sun Microsystems, March 2007.
References
----------
[RFC 4790] Newman, C., Duerst, M., Gulbrandsen, A., "Internet
Application Protocol Collation Registry", RFC 4790,
Sun Microsystems, March 2007.
The expert reviewer appointed by the IESG has fairly broad latitude for this registry. While a number of collations are expected (particularly customizations of the UCA for localized use), an explosion of collations (particularly common-use collations) is not desirable for widespread interoperability. However, it is important for the expert reviewer to provide cause when rejecting a registration, and, when possible, to describe corrective action to
IESG任命的专家评审员对本登记册有相当广泛的自由度。虽然预期会有许多排序规则（特别是定制UCA以供本地化使用），但对于广泛的互操作性来说，排序规则（特别是常用排序规则）的爆炸式增长是不可取的。然而，专家评审员在拒绝注册时提供原因，并在可能的情况下描述纠正措施，这一点很重要
permit the registration to proceed. The following table includes some example reasons to reject a registration with cause:
允许注册继续进行。下表包括拒绝注册的一些原因示例：
o The registration is not a well-formed XML document.
o 注册不是格式良好的XML文档。
o The registration has an intended use of "common", but there is no evidence the collation will be widely deployed, so it should be listed as "limited".
o 该注册具有“通用”的预期用途，但没有证据表明该排序规则将被广泛使用，因此应将其列为“有限”。
o The registration has an intended use of "common", but it is redundant with the functionality of a previously registered "common" collation.
o 注册具有“common”的预期用途，但它与以前注册的“common”排序规则的功能是多余的。
o The registration has an intended use of "common", but the specification is not detailed enough to allow interoperable implementations by others.
o 注册具有“common”的预期用途，但规范不够详细，不允许其他人进行互操作实现。
o The collation identifier fails to precisely identify the version numbers of relevant tables to use.
o 排序规则标识符无法准确标识要使用的相关表的版本号。
o The registration fails to meet one of the "MUST" requirements in Section 4.
o 注册不符合第4节中的“必须”要求之一。
o The collation identifier fails to meet the syntax in Section 3.
o 排序规则标识符不符合第3节中的语法。
o The collation specification referenced in the registration is vague or has optional features without a clear behavior specified.
o 注册中引用的排序规则规范不明确，或者具有可选功能，但没有指定明确的行为。
o The referenced specification does not adequately address security considerations specific to that collation.
o 引用的规范没有充分解决特定于该排序规则的安全注意事项。
o The registration's operations are needlessly different from those of traditional operations.
o 注册的操作与传统操作毫无必要地不同。
o The registration's XML is needlessly different from that of already registered collations.
o 注册的XML与已注册的排序规则的XML不必要地不同。
This section registers the three collations that were originally defined in [11], and are implemented in most [14] engines. Some of the behavior of these collations is perhaps not ideal, such as i;ascii-casemap accepting non-ASCII input. Compatibility with widely deployed code was judged more important than fixing the collations. Some of the aspects of these collations are necessary to maintain compatibility with widely deployed code.
本节注册了[11]中最初定义的三个排序规则，它们在大多数[14]引擎中实现。这些排序的一些行为可能并不理想，比如我；接受非ascii输入的ascii案例映射。与广泛部署的代码的兼容性被认为比修复排序规则更重要。这些排序规则的某些方面对于维护与广泛部署的代码的兼容性是必需的。
The "i;ascii-numeric" collation is a simple collation intended for use with arbitrarily-sized, unsigned decimal integer numbers stored as octet strings. US-ASCII digits (0x30 to 0x39) represent digits of the numbers. Before converting from string to integer, the input string is truncated at the first non-digit character. All input is valid; strings that do not start with a digit represent positive infinity.
“i；ascii数字”排序规则是一种简单的排序规则，用于存储为八位字节字符串的任意大小的无符号十进制整数。US-ASCII数字（0x30到0x39）表示数字的数字。在从字符串转换为整数之前，输入字符串在第一个非数字字符处被截断。所有输入均有效；不以数字开头的字符串表示正无穷大。
The collation supports equality and ordering, but does not support the substring operation.
排序规则支持相等和排序，但不支持子字符串操作。
The equality operation returns "match" if the two strings represent the same number (i.e., leading zeroes and trailing non-digits are disregarded), and "no-match" if the two strings represent different numbers.
如果两个字符串表示相同的数字（即忽略前导零和尾随非数字），则相等操作返回“匹配”；如果两个字符串表示不同的数字，则返回“不匹配”。
The ordering operation returns "less" if the first string represents a smaller number than the second, "equal" if they represent the same number, and "greater" if the first string represents a larger number than the second.
如果第一个字符串表示的数字小于第二个字符串，则排序操作返回“less”；如果它们表示的数字相同，则返回“equal”；如果第一个字符串表示的数字大于第二个字符串，则排序操作返回“great”。
Some examples: "0" is less than "1", and "1" is less than "4294967298". "4294967298", "04294967298", and "4294967298b" are all equal. "04294967298" is less than "". "", "x", and "y" are equal.
一些示例：“0”小于“1”，而“1”小于“4294967298”。“4294967298”、“04294967298”和“4294967298b”都是相等的。“04294967298”小于“”。“”和“x”与“y”相等。
<?xml version='1.0'?>
<!DOCTYPE collation SYSTEM 'collationreg.dtd'>
<collation rfc="4790" scope="other" intendedUse="limited">
<identifier>i;ascii-numeric</identifier>
<title>ASCII Numeric</title>
<operations>equality order</operations>
<specification>RFC 4790</specification>
<owner>IETF</owner>
<submitter>chris.newman@sun.com</submitter>
</collation>
<?xml version='1.0'?>
<!DOCTYPE collation SYSTEM 'collationreg.dtd'>
<collation rfc="4790" scope="other" intendedUse="limited">
<identifier>i;ascii-numeric</identifier>
<title>ASCII Numeric</title>
<operations>equality order</operations>
<specification>RFC 4790</specification>
<owner>IETF</owner>
<submitter>chris.newman@sun.com</submitter>
</collation>
The "i;ascii-casemap" collation is a simple collation that operates on octet strings and treats US-ASCII letters case-insensitively. It provides equality, substring, and ordering operations. All input is valid. Note that letters outside ASCII are not treated case-insensitively.
“i；ascii casemap”排序规则是一种简单的排序规则，它对八位字节字符串进行操作，并且不区分US-ascii字母的大小写。它提供相等、子字符串和排序操作。所有输入都是有效的。请注意，ASCII以外的字母不区分大小写。
Its equality, ordering, and substring operations are as for i;octet, except that at first, the lower-case letters (octet values 97-122) in each input string are changed to upper case (octet values 65-90).
它的相等、排序和子字符串操作与i相同；八位字节，除了首先将每个输入字符串中的小写字母（八位字节值97-122）更改为大写字母（八位字节值65-90）。
Care should be taken when using OS-supplied functions to implement this collation, as it is not locale sensitive. Functions, such as strcasecmp and toupper, are sometimes locale sensitive, and may inappropriately map lower-case letters other than a-z to upper case.
在使用操作系统提供的函数实现此排序规则时应小心，因为它不区分区域设置。函数，例如strcasecmp和toupper，有时是区域设置敏感的，并且可能不适当地将a-z以外的小写字母映射到大写字母。
The i;ascii-casemap collation is well-suited for use with many Internet protocols and computer languages. Use with natural language is often inappropriate; even though the collation apparently supports languages such as Swahili and English, in real-world use, it tends to mis-sort a number of types of string:
我；ascii案例图排序非常适合与许多Internet协议和计算机语言一起使用。使用自然语言通常是不合适的；尽管排序规则显然支持斯瓦希里语和英语等语言，但在实际使用中，它往往会对多种类型的字符串进行错误排序：
o people and place names containing non-ASCII,
o 包含非ASCII码的人名和地名，
o words such as "naive" (if spelled with an accent, the accented character could push the word to the wrong spot in a sorted list),
o 诸如“naiver”（如果用重音拼写，重音字符可能会将单词推到排序列表中的错误位置）之类的词，
o names such as "Lloyd" (which, in Welsh, sorts after "Lyon", unlike in English),
o 诸如“Lloyd”之类的名字（与英语不同，在威尔士语中，Lloyd按“Lyon”排序），
o strings containing euro and pound sterling symbols, quotation marks other than '"', dashes/hyphens, etc.
o 包含欧元和英镑符号、除“.”以外的引号、破折号/连字符等的字符串。
<?xml version='1.0'?>
<!DOCTYPE collation SYSTEM 'collationreg.dtd'>
<collation rfc="4790" scope="local" intendedUse="common">
<identifier>i;ascii-casemap</identifier>
<title>ASCII Casemap</title>
<operations>equality order substring</operations>
<specification>RFC 4790</specification>
<owner>IETF</owner>
<submitter>chris.newman@sun.com</submitter>
</collation>
<?xml version='1.0'?>
<!DOCTYPE collation SYSTEM 'collationreg.dtd'>
<collation rfc="4790" scope="local" intendedUse="common">
<identifier>i;ascii-casemap</identifier>
<title>ASCII Casemap</title>
<operations>equality order substring</operations>
<specification>RFC 4790</specification>
<owner>IETF</owner>
<submitter>chris.newman@sun.com</submitter>
</collation>
The "i;octet" collation is a simple and fast collation intended for use on binary octet strings rather than on character data. Protocols that want to make this collation available have to do so by explicitly allowing it. If not explicitly allowed, it MUST NOT be used. It never returns an "undefined" result. It provides equality, substring, and ordering operations.
“i；octet”排序规则是一种简单而快速的排序规则，用于二进制八位字节字符串，而不是字符数据。要使此排序规则可用，协议必须显式地允许它。如果未明确允许，则不得使用。它从不返回“未定义”的结果。它提供相等、子字符串和排序操作。
The ordering algorithm is as follows:
排序算法如下所示：
1. If both strings are the empty string, return the result "equal".
1. 如果两个字符串都是空字符串，则返回结果“equal”。
2. If the first string is empty and the second is not, return the result "less".
2. 如果第一个字符串为空，第二个字符串为空，则返回结果“less”。
3. If the second string is empty and the first is not, return the result "greater".
3. 如果第二个字符串为空，而第一个字符串为空，则返回结果“更大”。
4. If both strings begin with the same octet value, remove the first octet from both strings and repeat this algorithm from step 1.
4. 如果两个字符串以相同的八位字节值开头，则从两个字符串中删除第一个八位字节，并从步骤1开始重复此算法。
5. If the unsigned value (0 to 255) of the first octet of the first string is less than the unsigned value of the first octet of the second string, then return "less".
5. 如果第一个字符串的第一个八位字节的无符号值（0到255）小于第二个字符串的第一个八位字节的无符号值，则返回“小于”。
6. If this step is reached, return "greater".
6. 如果达到此步骤，则返回“更大”。
This algorithm is roughly equivalent to the C library function memcmp, with appropriate length checks added.
此算法大致相当于C库函数memcmp，并添加了适当的长度检查。
The matching operation returns "match" if the sorting algorithm would return "equal". Otherwise, the matching operation returns "no-match".
如果排序算法将返回“相等”，则匹配操作将返回“匹配”。否则，匹配操作将返回“不匹配”。
The substring operation returns "match" if the first string is the empty string, or if there exists a substring of the second string of length equal to the length of the first string, which would result in a "match" result from the equality function. Otherwise, the substring operation returns "no-match".
如果第一个字符串是空字符串，或者如果存在长度等于第一个字符串长度的第二个字符串的子字符串，则子字符串操作返回“match”，这将导致相等函数产生“match”结果。否则，子字符串操作返回“不匹配”。
This collation is defined with intendedUse="limited" because it can only be used by protocols that explicitly allow it.
此排序规则是使用intendedUse=“limited”定义的，因为它只能由显式允许它的协议使用。
<?xml version='1.0'?>
<!DOCTYPE collation SYSTEM 'collationreg.dtd'>
<collation rfc="4790" scope="global" intendedUse="limited">
<identifier>i;octet</identifier>
<title>Octet</title>
<operations>equality order substring</operations>
<specification>RFC 4790</specification>
<owner>IETF</owner>
<submitter>chris.newman@sun.com</submitter>
</collation>
<?xml version='1.0'?>
<!DOCTYPE collation SYSTEM 'collationreg.dtd'>
<collation rfc="4790" scope="global" intendedUse="limited">
<identifier>i;octet</identifier>
<title>Octet</title>
<operations>equality order substring</operations>
<specification>RFC 4790</specification>
<owner>IETF</owner>
<submitter>chris.newman@sun.com</submitter>
</collation>
Section 7 defines how to register collations with IANA. Section 9 defines a list of predefined collations that have been registered with IANA.
第7节定义了如何向IANA注册排序规则。第9节定义了已向IANA注册的预定义排序规则列表。
Collations will normally be used with UTF-8 strings. Thus, the security considerations for UTF-8 [3], stringprep [6], and Unicode TR-36 [8] also apply, and are normative to this specification.
排序规则通常与UTF-8字符串一起使用。因此，UTF-8[3]、stringprep[6]和Unicode TR-36[8]的安全注意事项也适用，并且是本规范的规范性内容。
The authors want to thank all who have contributed to this document, including Brian Carpenter, John Cowan, Dave Cridland, Mark Davis, Spencer Dawkins, Lisa Dusseault, Lars Eggert, Frank Ellermann, Philip Guenther, Tony Hansen, Ted Hardie, Sam Hartman, Kjetil Torgrim Homme, Michael Kay, John Klensin, Alexey Melnikov, Jim Melton, and Abhijit Menon-Sen.
作者要感谢所有对此文件做出贡献的人，包括布赖恩·卡彭特、约翰·考恩、戴夫·克里德兰、马克·戴维斯、斯宾塞·道金斯、丽莎·杜肖尔、拉尔斯·艾格特、弗兰克·埃勒曼、菲利普·根特、托尼·汉森、泰德·哈迪、萨姆·哈特曼、杰蒂尔·托格里姆·霍姆、迈克尔·凯、约翰·克莱辛、亚历克斯·梅尔尼科夫、吉姆·梅尔顿、，阿比吉特·梅农·森。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[3] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005.
[4] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 3986，2005年1月。
[5] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[5] Phillips，A.和M.Davis，“识别语言的标签”，BCP 47，RFC 46462006年9月。
[6] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[6] Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[7] Davis, M. and K. Whistler, "Unicode Collation Algorithm version 14", May 2005, <http://www.unicode.org/reports/tr10/tr10-14.html>.
[7] Davis，M.和K.Whistler，“Unicode排序算法第14版”，2005年5月<http://www.unicode.org/reports/tr10/tr10-14.html>.
[8] Davis, M. and M. Suignard, "Unicode Security Considerations", February 2006, <http://www.unicode.org/reports/tr36/>.
[8] Davis，M.和M.Suignard，“Unicode安全考虑”，2006年2月<http://www.unicode.org/reports/tr36/>.
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[9] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[10] Melnikov, A., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[10] Melnikov，A.，“简单认证和安全层（SASL）”，RFC4422，2006年6月。
[11] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[11] Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[12] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[12] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[13] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[13] Freed，N.和J.Postel，“IANA字符集注册程序”，BCP 19，RFC 2978，2000年10月。
[14] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.
[14] 肖沃尔特，“筛子：邮件过滤语言”，RFC30281001年1月。
[15] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[15] Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[16] Crispin, M. and K. Murchison, "Internet Message Access Protocol - Sort and Thread Extensions", Work in Progress, May 2004.
[16] Crispin，M.和K.Murchison，“互联网消息访问协议-排序和线程扩展”，正在进行的工作，2004年5月。
[17] Newman, C. and A. Gulbrandsen, "Internet Message Access Protocol Internationalization", Work in Progress, January 2006.
[17] Newman，C.和A.Gulbrandsen，“互联网消息访问协议国际化”，正在进行的工作，2006年1月。
Authors' Addresses
作者地址
Chris Newman Sun Microsystems 1050 Lakes Drive West Covina, CA 91790 USA
Chris Newman Sun Microsystems 1050 Lakes Drive West Covina，加利福尼亚州，美国91790
EMail: chris.newman@sun.com
EMail: chris.newman@sun.com
Martin Duerst Aoyama Gakuin University 5-10-1 Fuchinobe Sagamihara, Kanagawa 229-8558 Japan
Martin Duerst Aoyama Gakuin大学5-10-1 Fuchinobe Sagamihara，神奈川229-8558日本
Phone: +81 42 759 6329
Fax: +81 42 759 6495
EMail: duerst@it.aoyama.ac.jp
URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
Phone: +81 42 759 6329
Fax: +81 42 759 6495
EMail: duerst@it.aoyama.ac.jp
URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
Note: Please write "Duerst" with u-umlaut wherever possible, for example as "Dürst" in XML and HTML.
注意：请尽可能用u-umlaut写“Duerst”，例如用XML和HTML写“Dü；rst”。
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 81671 Munich Germany
Arnt Gulbrandsen Oryx邮件系统有限公司Schweppermannstr。德国慕尼黑81671
Fax: +49 89 4502 9758
EMail: arnt@oryx.com
URI: http://www.oryx.com/arnt/
Fax: +49 89 4502 9758
EMail: arnt@oryx.com
URI: http://www.oryx.com/arnt/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。