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）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.
多くのインターネットアプリケーションプロトコルには、文字列ベースの検索、検索、またはソート操作が含まれます。しかし、国際的な文字列の検索やソートのための問題空間は、完全に大規模な探求、およびインターネット・エンジニアリング・タスク・フォース（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レジストリの作成に失敗しました。文字列前[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].
キーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、「要件レベルを示すためのRFCsにおける使用のためのキーワード」で定義されているし、この文書に解釈されるべきである「MAY」[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].
属性構文仕様は、拡張バッカス・ナウアフォーム（ABNF）付録A.ザABNF産「言語タグ」で定義されているコア・ルールを含む[2]の表記は、言語タグ[5]及び「REG-名」からインポートされ、使用します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.
等価テスト、サブストリングの一致、及び順序試験：照合は、入力として任意の二つの長さの文字列を取り、三つの基本的な比較演算の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].
照合順序は、これらの比較関数は、複数のプロトコルで使用できるように比較関数のための抽象化です。特定の比較動作の詳細は、その照合を使用したアプリケーションプロトコルから独立して、適切な専門知識を持つ人、によって指定することができます。これは、文字セット[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 |
+-----------------+
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サーバのような従来のサーバであってもよいし、ユーザによって書かれたSieveスクリプトを実行ふるい[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例えば、I）の範囲であり得ます。
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 / "-" / ";" / "=" / "."
" - " = ALPHA / DIGIT /照合-チャー/ ";" / "=" / ""
collation-id = collation-prefix ";" collation-core-name *collation-arg
照合-ID =照合プレフィックス ";"照合コア名*照合、引数
collation-scope = Language-tag / "vnd-" reg-name
照合スコープ=言語タグ/ "vnd-" REG-名
collation-core-name = ALPHA *( ALPHA / DIGIT / "-" )
照合コア名= ALPHA *（ALPHA / DIGIT / " - "）
collation-arg = ";" ALPHA *( ALPHA / DIGIT ) "=" 1*( ALPHA / DIGIT / "." )
照合、引数=「;」 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から「REG-名」：一般的な構文[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.
「デフォルト」と呼ばれる特別な識別子があります。デフォルトの照合を持つプロトコルでは、「デフォルト」は、その照合を指します。他のプロトコルの場合は、識別子「デフォルトは」何の照合が一致してはならない、と彼らは存在しない照合順序を扱うとサーバーは、同じ方法でそれを扱うべきです。
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.
クライアントは、照合を選択するために使用する文字列は、一の以上のワイルドカード（「*」）は0個以上の照合-文字に一致する文字を含めることができます。ワイルドカード文字は、隣接しているはずがありません。ワイルドカード文字列は、複数の照合順序が一致した場合、サーバは狭く便利なものに優先して広く便利な照合を選択しようとすべきです。
collation-wild = ("*" / (ALPHA ["*"])) *(collation-char ["*"]) ; MUST NOT exceed 254 characters total
照合野生=（ "*" /（ALPHA [ "*"]））*（照合-チャー[ "*"]）。合計254文字を超えてはなりません
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
照合選択= [ "+" / " - "]照合-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.
いくつかのプロトコルは、[4]の照合ではなく、単純なトークンを参照するURIを使用するように設計されています。 IANAのURLスペースの特別なセクションでは、このような使用のために予約されています。 「照合-URI」形態は、特定の名前の照合（照合登録が実際に存在しなくてもよい）を指すために使用されます。 「照合-AURI」フォームには、発注、照合パターンやベンダープライベート丁合いの抽象名前です。
collation-uri = "http://www.iana.org/assignments/collation/" collation-id ".xml"
照合-URI = "http://www.iana.org/assignments/collation/" 照合-ID "の.xml"
collation-auri = ( "http://www.iana.org/assignments/collation/" collation-order ".xml" ) / other-uri
照合-AURI =（ "http://www.iana.org/assignments/collation/" 照合順序 "の.xml"）/他の-URI
other-uri = <absoluteURI> ; excluding the IANA collation namespace.
他の-URI = <absoluteURIで>。 IANAの照合名前空間を除きます。
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.
フォームの照合識別子*;ドンホスト名; *（ベンダーexample.comの例えば、vnd-example.com）「vnd-」接頭辞次ホスト名の所有者によって作成されたベンダー固有の照合のために予約されています。公開された仕様やオープンソース実装が利用可能ですが、必要とされていない場合、このような照合順序の登録（または全体として名前空間）は、「ベンダー」の使用目的で、奨励されています。
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節）の照合は、オクテット文字列で動作します。 I;アスキー数字（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.
この仕様は、オクテット文字列の面で照合インターフェイスを定義します。しかし、実装は代わりに文字列を使用することもできます。そのような実装では、私は、例えば、実装することができない場合があり、オクテット。私ので、オクテットは現在、任意のプロトコルのために実装するために必須ではありませんが、これは問題になることはありません。
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つの固定された入力文字列が与えられると、結果は同じ操作で同じでなければなりません。
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のストリングの一つ以上のサブストリングは、第一に等しい場合、最初の文字列、すなわち、第二の文字列の部分文字列である場合、サブストリングマッチング動作を決定します。
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のSP「1」SPのSP）内に報告されるように定義することができ（SP SPとSP SP "1" SP、SP "1" SP、SP "1" SP SP SPのSP "1"）ではない4回、4つの試合は、ある意味で、同一の一致であるからです。
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.
注文操作は二つの文字列が注文されている方法を決定します。これは反射的でなければなりません。有効な入力のために、それは推移と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".
最初の文字列が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.
注文操作の戻り値は、このドキュメントの「大きい」、および「未定義」、「等しい」、「少ない」と呼ばれています。
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.
照合仕様は、ソートキーを生成するために、内部変換アルゴリズムを記述するべきです。このアルゴリズムは、個々の文字列に適用することができ、その結果は、潜在的に将来の比較演算を最適化するために格納することができます。照合は、ソートキーは恒等関数によって生成されるように指定することができます。ソートキーは、人間に意味を持たないことがあります。ソートキーは、照合に有効な入力ではないかもしれません。
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.
このセクションでは、アプリケーションプロトコルが、それは、検索マッチングサブストリングおよび/またはソート提供している場合は考慮する必要がある要件と問題点を説明し、そしてUS-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.
プロトコルは、全順序を必要とし、発注操作が少なくとも一度は「未定義」を返しますので、選択した照合がそれを提供していない、推奨されるフォールバックが有効なものの後にすべての無効な文字列を並べ替え、および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.
照合のsubstring関数は、マッチのリストを提供しますが、プロトコルは、クライアントにすべてのことを提供する必要はありません。これは、最初に一致したサブストリング、または文字列検索を一致したことだけでも、情報を提供することができます。このように、照合は、真偽を返し、「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』を有します）。
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.
ストリングマッチングの照合;「ASCII数値I」を使用しようと、例えば - Oクライアントはその照合でサポートされていない動作のために照合を使用することを試みます。
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つのクライアントによって供給され、他方がサーバによって格納されている場合は特に、二つの入力文字列を区別するために適切であり得ます。また、無効な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;オクテット（セクション9.3）照合オクテットストリングに基づくプロトコルでのみ使用可能です。クライアントとサーバーは、私を使用してはならない。他のプロトコルとオクテット。
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]篩[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.
ふるいでは、全てのマッチは、trueまたはfalseのいずれかです。したがって、ふるいサーバは、偽、真としてだけ「一致」平等とストリングの操作の「未定義」と「不一致」の結果を扱わなければなりません。
In ACAP and Sieve, there are no invalid strings. In this document's terms, invalid strings sort after valid strings.
ACAPとふるいでは、無効な文字列が存在しません。この文書の用語では、無効な文字列は有効な文字列の後に並べ替えます。
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.
それは、比較器[17]拡張を使用している場合にのみ、明示的であるがIMAP [15]また、照合します。 IMAPサブストリング操作を内蔵しており、SORT [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@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と登録は、承認された軽微な変更を承認、または原因で拒否されているかどうかを2週間以内に登録の提出者に伝えるために期待されています。登録が原因で拒否された場合、原因に記載されている懸念に対処している場合は、それを再提出することができます。指定された専門家によって行われた決定は、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の作者が所有しています。その他の照合の登録は、登録の接触欄に記載されている個々の（S）によって所有され、そして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.
照合の登録はcollation@ietf.orgとiana@iana.orgする整形式のXML文書を送信することにより行われます。
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のバージョン= '1.0'？> <！DOCTYPE照合SYSTEM 'collationreg.dtd'> <照合RFC = "YYYY" スコープ= "グローバル" intendedUse = "共通"> <識別子>照合識別子</識別子> <タイトル照合用>技術的なタイトル</ TITLE> <</操作> <仕様>仕様の参照</仕様> <所有者>所有者の電子メールアドレスまたは提出者のIETF </所有者> <送信者>メールアドレスをサブストリングの操作>平等のため</提出者> <バージョン> 1 </バージョン> </照合>
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.
登録文書のルートは、<照合>要素でなければなりません。照合要素は、ここで与えられた順序で、以下のサブサブセクションに記載されている登録に他の要素を含みます。
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であるならば、<照合>要素は、「RFC =」属性を含むかもしれません。 「RFC =」属性は、このような、そのような「.TXT」として「RFC」、または接尾辞、など、任意の接頭辞なしで、RFCの数だけを与えます。
The <collation> element MUST include a "scope=" attribute, which MUST have one of the values "global", "local", or "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.
<照合>要素は、「共通」「限定」、「ベンダー」、または「非推奨」のいずれかの値を有していなければならない「intendedUse =」属性を含まなければなりません。 「共通」の使用を目的と照合仕様は国際文字セットの詳細を扱う豊富な経験と標準化団体から規格を参照することが期待されています。
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.
ASCII-CASEMAP; <識別子>要素は、照合の正確な識別子、例えば、Iを与えます。 <識別子>要素は必須です。
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.
単一のスペースで区切られた照合が提供する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.
<提出>要素は、登録を提出した人のためのRFC 2822 [12]の電子メールアドレスを提供します。 <所有者>要素は、電子メールアドレスが含まれている場合はオプションです。
There may be more than one <submitter> element.
複数の<送信者>要素があるかもしれません。
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.
<バージョン>要素は、登録が改訂される可能性が高い、または結果が一つ以上の入力文字列に変更するように改訂されたときに含まれなければなりません。 <バージョン>要素はオプションです。
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.
<変数>要素は、大文字と小文字が区別されるかどうかを、例えば、照合の動作を制御する任意の変数を指定します。 <変数>要素はオプションです。使用されている場合は、<変数>は、<name>と<デフォルト>要素が含まれている必要があり、それは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.
<デフォルト>要素は、変数のデフォルト値を指定します。 <デフォルト>要素は必須です。
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.
<値>要素は、変数の有効な値を指定します。 <値>要素はオプションです。 1つ以上の<値>要素が存在する場合、値のみが有効です。何もしない場合、変数の有効な値は、列挙セットを形成していない、とのルールは、登録に伴う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は、照合-idは識別子要素の内容である形態http://www.iana.org/assignments/collation/collation-id.xmlのURLに各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が最初のレジストリsummary.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]
限定使用照合順序：I;オクテットE、O、その他[RFC 4790]よI;アスキー数字E、その他[RFC 4790] O
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.
登録は第4節で「MUST」の要件のいずれかを満たしていないO。
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.
「私は、ASCII数字」の照合は、オクテット文字列として保存され、任意のサイズ、符号なし10進整数での使用を意図簡単な照合です。 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.
最初の文字列が第二のより大きい数を表す場合、最初の文字列は、それらが同じ数を表している場合、「等しい」、第二のより小さい数を表し、そして「大きい」場合順序付け操作は、「少ない」を返します。
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>
<！DOCTYPE照合SYSTEM 'collationreg.dtd'> <？xmlのバージョン= '1.0'> <照合RFC = "4790" スコープ= "その他" intendedUse = "限定"> <識別子> I; ASCII数値</識別子> <タイトル> ASCII数値</ TITLE> <操作>平等のため</操作> <仕様> RFC 4790 </仕様> <所有者> IETF </所有者> <送信者> chris.newman@sun.com </提出者> </照合>
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.
「私は、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.
それは敏感なロケールされていないとして、この照合を実装するためにOSが提供する機能を使用する際には注意が必要です。例えばstrcasecmpとTOUPPERとして機能し、時々ロケールに敏感であり、不適切大文字に-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;アスキー・CASEMAP照合は、多くのインターネット・プロトコルおよびコンピュータ言語で使用するために適しています。自然言語を使用し、多くの場合は不適切です。照合は明らかに、このようなスワヒリ語や英語などの言語をサポートしているにもかかわらず、実際の使用では、それがミスソートに文字列の種類の数を傾向があります：
o people and place names containing non-ASCII,
、人や非ASCIIを含む地名O
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>
<？xmlのバージョン= '1.0'> <！DOCTYPE照合SYSTEM 'collationreg.dtd'> <照合RFC = "4790" スコープ= "ローカル" intendedUse = "共通"> <識別子> I; ASCII-CASEMAP </識別子</操作> <仕様> RFC 4790 </仕様> <所有者> IETF </所有者> <送信者> chris.newman@sun.com </提出者をサブストリング> <タイトル> ASCII CASEMAP </ TITLE> <操作>平等順> </照合>
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.
「私;オクテット」の照合は、バイナリオクテット文字列ではなく、文字データに使用するためのもの、シンプルで高速な照合です。この照合が使用できるようにするプロトコルは、明示的にそれを可能にすることにより、そうしなければなりません。明示的に許可されていない場合は、それを使用してはいけません。それは「未定義」の結果を返すことはありません。それは平等、ストリング、および注文操作を提供します。
The ordering algorithm is as follows:
次のように順序付けアルゴリズムは次のとおりです。
2. If the first string is empty and the second is not, return the result "less".
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".
前記第1の文字列の最初のオクテットの符号なしの値（0〜255）は、第2の文字列の最初のオクテットの符号なしの値よりも小さい場合、「少ない」を返します。
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.
それだけで明示的に許可するプロトコルで使用することができますので、この照合はintendedUse =「限定」で定義されています。
<?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のバージョン= '1.0'？> <DOCTYPE照合SYSTEM 'collationreg.dtd'！> <照合RFC = "4790" スコープ= "グローバル" intendedUse = "限定"> <識別子> I;オクテット</識別子> <タイトル>オクテット</タイトル> <動作>等価順サブストリング</動作> <仕様> RFC 4790 </仕様> <所有者> IETF </所有者> <提出> chris.newman@sun.com </提出> </照合>
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]、[6] STRINGPREP、および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.
著者は、ブライアン・カーペンター、ジョン・コーワン、デイブCridland、マーク・デイビス、スペンサードーキンスリサDusseault、ラースEggertの、フランクEllermann、フィリップ・ギュンター、トニー・ハンセン、テッドハーディー、サム・ハートマンを含め、この文書に貢献してきたすべての人に感謝したいですKjetil Torgrimオム、マイケル・ケイ、ジョン・クレンシン、アレクセイ・メルニコフ、ジム・メルトン、およびAbhijitメノンセン。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2]クロッカー、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]バーナーズ - リー、T.、フィールディング、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]フィリップス、A.とM.デイヴィス、 "言語を識別するためのタグ"、BCP 47、RFC 4646、2006年9月。
[6] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[6]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、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]デイビス、M.及びK.ウィスラー、 "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]デイビス、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]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[10] Melnikov, A., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[10]メルニコフ、A.、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[11] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[11]ニューマン、C.及びJ.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[12] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[12]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[13] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[13]フリード、N.とJ.ポステル、 "IANA文字セット登録手順"、BCP 19、RFC 2978、2000年10月。
[14] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.
[14]ショーウォルター監督、T.、 "ふるい：メールフィルタ言語"、RFC 3028、2001年1月。
[15] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[15]クリスピン、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]クリスピン、M.とK.マーチソン、「インターネットメッセージアクセスプロトコル - ソートとスレッドの拡張機能」、進歩、2004年5月での作業。
[17] Newman, C. and A. Gulbrandsen, "Internet Message Access Protocol Internationalization", Work in Progress, January 2006.
[17]ニューマン、C.とA. Gulbrandsenの、 "インターネットメッセージアクセスプロトコル国際化"、進歩、2006年1月の作業。
Authors' Addresses
著者のアドレス
Chris Newman Sun Microsystems 1050 Lakes Drive West Covina, CA 91790 USA
クリス・ニューマンSun Microsystemsの1050湖ドライブウェストコヴィナ、CA 91790 USA
EMail: chris.newman@sun.com
メールアドレス：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/
電話：+81 42 759 6329ファックス：+81 42 759 6495 Eメール：URI duerst@it.aoyama.ac.jp：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のウムラウトで「Duerst」を入力してください「D＆＃252; RST」XMLとHTMLに。
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 81671 Munich Germany
ARNT Gulbrandsenのオリックスメールシステム社Schweppermannstr。 8 81671ミュンヘンドイツ
Fax: +49 89 4502 9758 EMail: arnt@oryx.com URI: http://www.oryx.com/arnt/
ファックス：+49 89 4502 9758 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。