[要約] RFC 4790は、インターネットアプリケーションプロトコルの整理レジストリに関するものであり、その目的は、異なるプロトコルの名前やエンコーディングを統一的に管理することです。
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
インターネットアプリケーションプロトコル照合レジストリ
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）The IETF Trust（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.
多くのインターネットアプリケーションプロトコルには、文字列ベースのルックアップ、検索、または並べ替え操作が含まれます。ただし、国際的な文字列を検索して並べ替えるための問題スペースは大きく、完全には探求されておらず、インターネットエンジニアリングタスクフォース（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
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 Collation Algorithm [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].
属性の構文仕様は、付録Aで定義されているコアルールを含む、拡張されたバックスノーフォーム（ABNF）[2]表記を使用します。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.
照合とは、2つの任意の長さの文字列を入力として取得する名前のある関数であり、3つの基本的な比較操作の1つ以上を実行するために使用できます：等式テスト、サブストリングマッチ、および注文テスト。
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].
照合は比較関数の抽象化であるため、これらの比較関数を複数のプロトコルで使用できます。特定の比較操作の詳細は、その照合を使用するアプリケーションプロトコルとは無関係に、適切な専門知識を持つ人によって指定できます。これは、charset [13]がOctetの詳細を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 |
+-----------------+
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クライアントとして機能するメールリーダーであるか、ユーザーがプロトコルコマンド/リクエストを直接入力できるインタラクティブなシェルであるか、ユーザーが書いたスクリプトまたはプログラムである場合があります。
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.
照合の1つのコンポーネントは変換で、文字列をソートキーに変換し、ソート中に使用されます。
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.
変換は、IDマッピング（例：i; Octet照合セクション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-id = collation-prefix ";" collation-core-name *collation-arg
collation-id = collation-prefix ";"Collation-Core-Name *Collation-Arg
collation-scope = Language-tag / "vnd-" reg-name
collation-scope = Language-tag / "vnd-" reg-name
collation-core-name = ALPHA *( 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]から「reg-name」からインポートされます。
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.
「デフォルト」と呼ばれる特別な識別子があります。デフォルトの照合を持つプロトコルの場合、「デフォルト」とはその照合を指します。他のプロトコルの場合、識別子の「デフォルト」は照合を一致させる必要はなく、サーバーは存在しない照合を扱うのと同じ方法でそれを処理する必要があります。
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.
クライアントが照合を選択するために使用する文字列には、ゼロ以上の照合charに一致する1つ以上のワイルドカード（ "*"）文字が含まれます。ワイルドカードの文字は隣接してはなりません。WildCard文字列が複数のコレクションと一致する場合、サーバーは、狭く有用なコレクションよりも広く有用な照合を選択しようとする必要があります。
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-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」フォームは、特定の名前の照合を参照するために使用されます（照合登録は実際には存在しない場合があります）。「Collation-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
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 delimit the parameter from the value. The version numbers of any lookup tables used by the algorithm SHOULD be present as parameterized modifications.
国際的な視聴者との照合識別子は、通常、「i;」で始まります。特定の言語またはロケールを対象とした照合識別子は、通常、言語タグ[5]に続いて「;」で始まります。最初の「;」の後通常、一般的な照合アルゴリズムの名前で、その後に「;」で区切られた一連のアルゴリズムの変更が続きます。デリミタ。パラメーター化された変更は、「=」を使用して、値からパラメーターを区切ります。アルゴリズムで使用されるルックアップテーブルのバージョン番号は、パラメーター化された変更として存在する必要があります。
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-hostname; *は、「vnd-」プレフィックス（ベンダー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.
照合自体は、それが動作するものを定義します。ほとんどの照合は、キャラクター文字列で動作することが期待されています。i; Octet（セクション9.3）の照合は、Octet弦で動作します。i; ascii-Numeric（セクション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などを実装できない場合があります。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.
照合仕様は、3つの基本操作のうち、サポートされているもの（平等、サブストリング、順序付け）と、空の文字列を含む2つの入力文字列でサポートされている各操作を実行する方法を述べる必要があります。照合は決定論的でなければなりません。つまり、特定の識別子との照合を与えられ、2つの固定入力文字列と同じ操作で同じでなければなりません。
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.
各照合操作の規則の非自明な結果は、単一の照合の場合、操作のいずれかまたはすべてが「未定義」に戻ることができるということです。たとえば、「未定義」を返すことのない平等操作や、時々行うサブストリング操作を持つことはできません。
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.)
有効性テストでは、1つの文字列を引数として取得します。入力文字列が照合の他の操作への有効な入力であり、そうでない場合は無効である場合、有効に戻ります。（言い換えれば、文字列は、照合の平等操作に応じてそれ自体に等しい場合に有効です。）
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.
サブストリングマッチング操作は、最初の文字列が2番目の文字列のサブストリングであるかどうかを決定します。つまり、2番目の文字列の1つ以上のサブストリングが最初の文字列に等しい場合、照合の等式操作で定義されています。
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.
サブストリングマッチングをサポートする照合は、それらの特別なケースがアプリケーションプロトコルによってサポートされている場合、プレフィックスと接尾辞マッチングの2つの特別なケースを自動的にサポートします。有効な入力が提供されると「一致」または「一致なし」を返し、無効な入力が提供されると「未定義」を返します。
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 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.
アプリケーションプロトコルは、サブストリングマッチの位置情報を返す場合があります。これが行われた場合、ポジション情報には、各マッチの開始オフセットと終了オフセットの両方を含める必要があります。これは重要です。なぜなら、より洗練されたコレクションは不均等な長さの文字列に一致する可能性があるためです（たとえば、事前に構成されたアクセントされた文字は分解されたアクセントのある文字に一致する可能性があります）。一般に、重複する一致を報告する必要があります（「ana」が「バナナ」内で2回発生する場合のように）が、照合が決定しない場合があります。たとえば、すべての空白シーケンスを同一と扱う照合では、「1」（sp "1" sp）が「1」（sp "1" sp）内で1回だけ「1」（sp "1" sp）が報告されるように定義できます。4回ではありません（Sp "1" Sp、sp "1" SP、sp "1" sp 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 Collation Algorithm [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.
順序操作により、2つの文字列がどのように順序付けられるかが決まります。反射的でなければなりません。有効な入力の場合、それは推移的で三胞体でなければなりません。
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".
照合によると、最初の文字列が2番目の文字列の前にリストされている場合、順序付けは「少ない」です。2番目の文字列が最初の文字列の前にリストされている場合、「グレーター」。照合の平等操作によって定義されているように、2つの文字列が等しい場合、「等しい」。片方または両方の文字列が無効である場合、注文の結果は「未定義」です。
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.
このドキュメントでは、順序操作の返品値は「Less」、「Equal」、「Greater」、および「未定義」と呼ばれます。
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.
照合仕様は、ソートキーを生成するための内部変換アルゴリズムを説明する必要があります。このアルゴリズムは個々の文字列に適用でき、結果を保存して将来の比較操作を最適化する可能性があります。照合は、ソートキーがID関数によって生成されることを指定する場合があります。ソートキーは、人間に意味がない場合があります。ソートキーは、照合への有効な入力ではない場合があります。
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.
このセクションでは、アプリケーションプロトコルが検索、サブストリングマッチング、および/または並べ替えを提供するかどうかを考慮する必要がある要件と問題について説明し、米国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.
プロトコルに合計注文が必要であり、選択された照合が提供されない場合、順序操作が少なくとも1回「未定義」を返すため、推奨されるフォールバックは有効な文字列の後にすべての無効な文字列を並べ替え、I; Octetを使用して無効なものを注文することです。文字列。
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のサブストリング」が真のファルスを返すように定義されたプロトコルで照合を使用できます。
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.
プロトコルは、照合識別子でワイルドカードを使用できるかどうかを指定する必要があります。プロトコルがワイルドカードを許可する場合、次のとおりです。プロトコルは、明示的な照合交渉がない場合、または「デフォルト」の照合が要求された場合に比較の動作方法を指定する必要があります。プロトコルは、このような状況で使用されるデフォルトの照合がサーバーの構成に敏感であることを指定する場合があります。
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-numeric」照合を使用しようとします。
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 クライアントは平等または一致する照合を使用し、結果はエラーです。特に1つがクライアントから提供され、もう1つがサーバーによって保存される場合、2つの入力文字列を区別することが適切かもしれません。また、無効な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.
i; Octet（セクション9.3）の照合は、Octet stringsに基づくプロトコルでのみ使用可能です。クライアントとサーバーは、他のプロトコルで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]とSieve [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.
これらのプロトコルにより、これらのプロトコルで使用されているように、UTF-8データで直接作業するi; octet（セクション9.3）の照合を使用することができます。
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サーバーは、平等とサブストリング操作の「未定義」および「非試合」の結果を虚偽として扱い、「一致」のみを真のものとして扱う必要があります。
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]拡張が使用される場合にのみ明示的です。組み込みのIMAPサブストリング操作とソート[16]拡張機能によって提供される順序は、このドキュメントで作成された要件を満たしていない場合があります。
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@itf.orgを作成します。メーリングリストの使用を強くお勧めします。IESGは、collation@etf.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に送信されると開始されます。指定された専門家は、登録が承認されるか、わずかな変更で承認されているか、または原因で拒否されているかどうかにかかわらず、2週間以内に登録の提出者に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.
登録が既存の照合の変更である場合、所有者が承認する必要があります。所有者に1か月間連絡を取ることができず、指定された専門家が必要な変更を検討している場合、IESGは所有権を適切な当事者に再割り当てする場合があります。
Registration of a collation is done by sending a well-formed XML document to collation@ietf.org and iana@iana.org.
照合の登録は、well形成された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>
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>要素でなければなりません。照合要素には、登録内の他の要素が含まれています。これらは、ここで示されている順序で、次のサブサブセクションで説明されています。
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".
<collation>要素には、仕様がRFCにある場合、「rfc =」属性を含めることができます。「RFC =」属性は、「RFC」や「.txt」などの接尾辞などのプレフィックスなしで、RFCの数のみを与えます。
The <collation> element MUST include a "scope=" attribute, which MUST have one of the values "global", "local", or "other".
<collation>要素には、「scope =」属性を含める必要があります。これには、「グローバル」、「ローカル」、または「その他」の値のいずれかが必要です。
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>要素には、「inteduse =」属性を含める必要があります。これには、値「共通」、「限定」、「ベンダー」、または「非推奨」の1つが必要です。「一般的な」使用を目的とした照合仕様は、国際的なキャラクターセットの詳細を扱った重要な経験を持つ標準団体から基準を参照することが期待されます。
Be aware that future revisions of this specification may add additional function types, as well as additional XML attributes, values, and elements. Any system that automatically parses these XML documents MUST take this into account to preserve future compatibility.
この仕様の将来の改訂は、追加の関数タイプ、および追加のXML属性、値、および要素が追加される場合があることに注意してください。これらのXMLドキュメントを自動的に解析するシステムは、将来の互換性を維持するためにこれを考慮する必要があります。
The <identifier> element gives the precise identifier of the collation, e.g., i;ascii-casemap. The <identifier> element is mandatory.
<識別子>要素は、照合の正確な識別子を与えます。たとえば、i; ascii-casemap。<識別子>要素は必須です。
The <title> element gives the title of the collation. The <title> element is mandatory.
<title>要素は、照合のタイトルを与えます。<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>要素には、3つの操作のうちどれが単一スペースで区切られている3つの操作（「等式」、「注文」、または「サブストリング」）を一覧表示します。<操作>要素は必須です。
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.
<仕様>要素は、仕様を見つける場所を説明します。<仕様>要素は必須です。URI属性がある場合があります。複数の<仕様>要素がある場合があります。その場合、それらは一緒に仕様を形成します。
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]電子メールアドレスを提供します。<所有者>要素に電子メールアドレスが含まれている場合、オプションです。
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.
<所有者>要素には、登録の所有者の4文字の「IETF」または電子メールアドレスが含まれています。<所有者>要素は必須です。複数の<所有者>要素がある場合があります。もしそうなら、すべての所有者は平等です。各所有者はすべての人のために話すことができます。
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.
登録が改訂される可能性が高い場合、または1つ以上の入力文字列の結果が変化するように改訂された場合、<バージョン>要素を含める必要があります。<バージョン>要素はオプションです。
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>が使用される場合、<name> and <default>要素を含める必要があり、1つ以上の<value>要素が含まれる場合があります。
The <name> element specifies the name value of a variable. The <name> element is mandatory.
<name>要素は、変数の名前値を指定します。<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>要素はオプションです。1つ以上の<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登録中。提出者と指定された専門家の両方が、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 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.
IANAはまた、http://www.iana.org/assignments/collation/collation-index.htmlという名前でレジストリのテキスト概要を維持します。この要約は、4つのセクションに分かれています。最初のセクションは、一般的な使用を目的とした照合用です。このセクションは、IESGが承認したRFCで公開されている照合登録、またはそのロケールの主要な標準団体からのローカルスコープ照合を目的としています。指定された専門家は、「一般的な」登録の数を小さく、高品質の数を維持することが望ましいため、専門家が「制限されている」と信じている場合、「共通」の使用を意図した照合登録を拒否することが推奨されます。2番目のセクションは、限られた使用照合用に予約されています。3番目のセクションは、登録ベンダー固有の照合用に予約されています。最後のセクションは、非推奨の照合用に予約されています。
The following is an example of how IANA might structure the initial registry summary.html file:
以下は、IANAが最初のレジストリサマリーを構成する方法の例です。htmlファイル：
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]
Vendor Collations:
ベンダーの照合：
Deprecated Collations:
非推奨の照合：
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 permit the registration to proceed. The following table includes some example reasons to reject a registration with cause:
IESGによって任命された専門家のレビュアーは、このレジストリに対してかなり広い緯度を持っています。多くの照合が予想されますが（特にローカライズされた使用のためのUCAのカスタマイズ）、照合（特に一般的な照合）の爆発は、広範な相互運用性には望ましくありません。ただし、専門家のレビュアーが登録を拒否する際に原因を提供することが重要であり、可能な場合は、登録を許可するための是正措置を説明することが重要です。次の表には、原因による登録を拒否するいくつかの例が含まれています。
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 登録には「共通」の使用が意図されていますが、以前に登録された「共通」照合の機能に冗長です。
o The registration has an intended use of "common", but the specification is not detailed enough to allow interoperable implementations by others.
o 登録には「共通」の使用が意図されていますが、仕様は相互運用可能な実装を他の人による実装を許可するほど詳細ではありません。
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の「必須」要件の1つを満たしていません。
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は、既に登録されている照合とは不要に異なります。
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]エンジンで実装されている3つの照合を登録します。これらの照合の動作のいくつかは、おそらく私が非ASCII入力を受け入れるASCII-CASEMAPなど、理想的ではありません。広く展開されたコードとの互換性は、照合を修正するよりも重要であると判断されました。これらの照合のいくつかの側面は、広く展開されたコードとの互換性を維持するために必要です。
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-Numeric」照合は、Octet文字列として保存されている任意のサイズの署名されていない小数整数数で使用することを目的とした単純な照合です。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.
平等操作は、2つの文字列が同じ数を表している場合（つまり、先頭のゼロとトレーリングした非桁が無視される場合）、2つの文字列が異なる数値を表す場合は「試合なし」を返します。
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.
順序操作は、最初の文字列が2番目よりも少ない数値を表す場合は「少ない」、同じ数値を表す場合は「等しい」、最初の文字列が2番目の数値よりも大きい場合は「グレート」を返します。
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>
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).
その平等、順序、およびサブストリング操作は、最初は各入力文字列の低ケース文字（オクテット値97-122）が上品に変更されていることを除いて、I; Octetのようです（Octet値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.
OSがサプリされた関数を使用して、ロケールに敏感ではないため、この照合を実装する場合は注意を払う必要があります。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:
i; ascii-casemapの照合は、多くのインターネットプロトコルやコンピューター言語で使用するのに適しています。自然言語での使用はしばしば不適切です。照合は明らかにスワヒリ語や英語などの言語をサポートしていますが、実際の使用では、多くの種類の文字列を誤ってソートする傾向があります。
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 「ナイーブ」などの単語（アクセントで綴られている場合、アクセントされたキャラクターは、ソートされたリストの間違った場所に単語を押し付けることができます）、
o names such as "Lloyd" (which, in Welsh, sorts after "Lyon", unlike in English),
o 「ロイド」などの名前（ウェールズ語では、英語とは異なり、「リヨン」の後に並べ替えます）、
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>
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. 両方の文字列が空の文字列である場合、結果を「等しく」返します。
2. If the first string is empty and the second is not, return the result "less".
2. 最初の文字列が空で、2番目の文字列がない場合は、結果を「少ない」と返します。
3. If the second string is empty and the first is not, return the result "greater".
3. 2番目の文字列が空で、最初の文字列がない場合は、結果を「大きい」と返します。
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）が2番目の文字列の最初のオクテットの符号なしの値よりも小さい場合、「より少ない」を返します。
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".
最初の文字列が空の文字列である場合、または最初の文字列の長さに等しい2番目の文字列のサブストリングが存在する場合、サブストリング操作は「一致」を返します。。それ以外の場合、サブストリング操作は「マッチなし」を返します。
This collation is defined with intendedUse="limited" because it can only be used by protocols that explicitly allow it.
この照合は、明示的に許可するプロトコルでのみ使用できるため、inteduse = "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>
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.
著者は、ブライアン・カーペンター、ジョン・コーワン、デイブ・クライドランド、マーク・デイビス、スペンサー・ドーキンス、リサ・エガート、フランク・エラーマン、フィリップ・ゲンサー、トニー・ハンセン、テッド・ハーディ、サム・ハートマン、サム・ハートマンなど、この文書に貢献したすべての人に感謝したいと思います。Kjetil Torgrim Homme、Michael Kay、John Klensin、Alexey Melnikov、Jim Melton、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 4234、2005年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、「Uniform Resource Identifier（URI）：Generic Syntax」、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 4646、2006年9月。
[6] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[6] Hoffman、P。and 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。and K. Whistler、「Unicode Collation Algorithmバージョン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。and M. Suignard、「Unicode Security Cansications」、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）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[10] Melnikov, A., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[10] Melnikov、A。、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[11] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[11] Newman、C。and J. Myers、「ACAP-アプリケーション構成アクセスプロトコル」、RFC 2244、1997年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 Charset登録手順」、BCP 19、RFC 2978、2000年10月。
[14] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.
[14] Showalter、T。、「Sieve：A Mail Filtering Language」、RFC 3028、2001年1月。
[15] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[15] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[16] Crispin, M. and K. Murchison, "Internet Message Access Protocol - Sort and Thread Extensions", Work in Progress, May 2004.
[16] Crispin、M。and K. Murchison、「インターネットメッセージアクセスプロトコル - ソートとスレッド拡張機能」、2004年5月の作業。
[17] Newman, C. and A. Gulbrandsen, "Internet Message Access Protocol Internationalization", Work in Progress, January 2006.
[17] Newman、C。and A. Gulbrandsen、「インターネットメッセージアクセスプロトコル国際化」、2006年1月、進行中の作業。
Authors' Addresses
著者のアドレス
Chris Newman Sun Microsystems 1050 Lakes Drive West Covina, CA 91790 USA
クリスニューマンサンマイクロシステムズ1050レイクスドライブウェストコヴィナ、カリフォルニア州91790 USA
EMail: chris.newman@sun.com
Martin Duerst Aoyama Gakuin University 5-10-1 Fuchinobe Sagamihara, Kanagawa 229-8558 Japan
マーティン・デュエルーヤマ・ガクイン大学
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.
注：XMLおよびHTMLの「D＆＃252; RST」など、可能な限りU-Umlautで「Duerst」を書いてください。
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 81671 Munich Germany
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr。8 81671ミュンヘンドイツ
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）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。