RFC4790 日本語訳
4790 Internet Application Protocol Collation Registry. C. Newman, M.Duerst, A. Gulbrandsen. March 2007. (Format: TXT=55591 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Newman
Request for Comments: 4790 Sun Microsystems
Category: Standards Track M. Duerst
Aoyama Gakuin University
A. Gulbrandsen
Oryx
March 2007
コメントを求めるワーキンググループC.ニューマン要求をネットワークでつないでください: 4790年のサン・マイクロシステムズカテゴリ: 2007年の標準化過程M.Duerst青山学院大学のA.Gulbrandsenオリックス行進
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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)のための専門的技術の領域の外にあるのではなく、大きいです。 むしろ、そのような大問題を解決するのを試みるよりこの仕様はアプリケーション・プロトコルが正確に比較関数を特定できるように、抽象化枠組みを作成します、そして、将来、比較関数のレパートリーは広げることができます。
Newman, et al. Standards Track [Page 1] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Collation Definition and Purpose . . . . . . . . . . . . . . . 4
2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Some Other Terms Used in this Document . . . . . . . . . . 5
2.4. Sort Keys . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Collation Identifier Syntax . . . . . . . . . . . . . . . . . 6
3.1. Basic Syntax . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Ordering Direction . . . . . . . . . . . . . . . . . . . . 7
3.4. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Naming Guidelines . . . . . . . . . . . . . . . . . . . . 7
4. Collation Specification Requirements . . . . . . . . . . . . . 8
4.1. Collation/Server Interface . . . . . . . . . . . . . . . . 8
4.2. Operations Supported . . . . . . . . . . . . . . . . . . . 8
4.2.1. Validity . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Equality . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.3. Substring . . . . . . . . . . . . . . . . . . . . . . 9
4.2.4. Ordering . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Sort Keys . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Use of Lookup Tables . . . . . . . . . . . . . . . . . . . 11
5. Application Protocol Requirements . . . . . . . . . . . . . . 11
5.1. Character Encoding . . . . . . . . . . . . . . . . . . . . 11
5.2. Operations . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. String Comparison . . . . . . . . . . . . . . . . . . . . 12
5.5. Disconnected Clients . . . . . . . . . . . . . . . . . . . 12
5.6. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 13
5.7. Octet Collation . . . . . . . . . . . . . . . . . . . . . 13
6. Use by Existing Protocols . . . . . . . . . . . . . . . . . . 13
7. Collation Registration . . . . . . . . . . . . . . . . . . . . 14
7.1. Collation Registration Procedure . . . . . . . . . . . . . 14
7.2. Collation Registration Format . . . . . . . . . . . . . . 15
7.2.1. Registration Template . . . . . . . . . . . . . . . . 15
7.2.2. The Collation Element . . . . . . . . . . . . . . . . 15
7.2.3. The Identifier Element . . . . . . . . . . . . . . . . 16
7.2.4. The Title Element . . . . . . . . . . . . . . . . . . 16
7.2.5. The Operations Element . . . . . . . . . . . . . . . . 16
7.2.6. The Specification Element . . . . . . . . . . . . . . 16
7.2.7. The Submitter Element . . . . . . . . . . . . . . . . 16
7.2.8. The Owner Element . . . . . . . . . . . . . . . . . . 16
7.2.9. The Version Element . . . . . . . . . . . . . . . . . 17
7.2.10. The Variable Element . . . . . . . . . . . . . . . . . 17
7.3. Structure of Collation Registry . . . . . . . . . . . . . 17
7.4. Example Initial Registry Summary . . . . . . . . . . . . . 18
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1。 コンベンションは本書では.4 2を使用しました。 照合定義と目的. . . . . . . . . . . . . . . 4 2.1。 定義. . . . . . . . . . . . . . . . . . . . . . . . 4 2.2。 目的. . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3。 このDocument. . . . . . . . . . 5 2.4のいくらかのOther Terms Used。 分類用キー. . . . . . . . . . . . . . . . . . . . . . . . 5 3。 照合識別子構文. . . . . . . . . . . . . . . . . 6 3.1。 基本的な構文. . . . . . . . . . . . . . . . . . . . . . . 6 3.2。 ワイルドカード. . . . . . . . . . . . . . . . . . . . . . . . 6 3.3。 指示. . . . . . . . . . . . . . . . . . . . 7 3.4を注文します。 URI. . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5。 ガイドライン. . . . . . . . . . . . . . . . . . . . 7 4を命名します。 照合仕様書要求事項. . . . . . . . . . . . . 8 4.1。 照合/サーバインタフェース. . . . . . . . . . . . . . . . 8 4.2。 操作は.1に.84.2を支持しました。 正当性. . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2。 平等. . . . . . . . . . . . . . . . . . . . . . . 9 4.2.3。 サブストリング. . . . . . . . . . . . . . . . . . . . . . 9 4.2.4。 注文. . . . . . . . . . . . . . . . . . . . . . . 10 4.3。 分類用キー. . . . . . . . . . . . . . . . . . . . . . . . 10 4.4。 ルックアップ表. . . . . . . . . . . . . . . . . . . 11 5の使用。 アプリケーション・プロトコル要件. . . . . . . . . . . . . . 11 5.1。 キャラクターコード化. . . . . . . . . . . . . . . . . . . . 11 5.2。 操作. . . . . . . . . . . . . . . . . . . . . . . . 11 5.3。 ワイルドカード. . . . . . . . . . . . . . . . . . . . . . . . 12 5.4。 比較. . . . . . . . . . . . . . . . . . . . 12 5.5を結んでください。 外されたクライアント. . . . . . . . . . . . . . . . . . . 12 5.6。 誤りは.135.7をコード化します。 八重奏の照合. . . . . . . . . . . . . . . . . . . . . 13 6。 既存のプロトコル. . . . . . . . . . . . . . . . . . 13 7で、使用します。 照合登録. . . . . . . . . . . . . . . . . . . . 14 7.1。 照合登録手順. . . . . . . . . . . . . 14 7.2。 照合登録形式. . . . . . . . . . . . . . 15 7.2.1。 登録テンプレート. . . . . . . . . . . . . . . . 15 7.2.2。 照合要素. . . . . . . . . . . . . . . . 15 7.2.3。 識別子要素. . . . . . . . . . . . . . . . 16 7.2.4。 タイトル要素. . . . . . . . . . . . . . . . . . 16 7.2.5。 操作要素. . . . . . . . . . . . . . . . 16 7.2.6。 仕様要素. . . . . . . . . . . . . . 16 7.2.7。 Submitter要素. . . . . . . . . . . . . . . . 16 7.2.8。 所有者要素. . . . . . . . . . . . . . . . . . 16 7.2.9。 バージョン要素. . . . . . . . . . . . . . . . . 17 7.2.10。 可変要素. . . . . . . . . . . . . . . . . 17 7.3。 照合登録. . . . . . . . . . . . . 17 7.4の構造。 例の初期の登録概要. . . . . . . . . . . . . 18
Newman, et al. Standards Track [Page 2] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[2ページ]。
8. Guidelines for Expert Reviewer . . . . . . . . . . . . . . . . 18
9. Initial Collations . . . . . . . . . . . . . . . . . . . . . . 19
9.1. ASCII Numeric Collation . . . . . . . . . . . . . . . . . 20
9.1.1. ASCII Numeric Collation Description . . . . . . . . . 20
9.1.2. ASCII Numeric Collation Registration . . . . . . . . . 20
9.2. ASCII Casemap Collation . . . . . . . . . . . . . . . . . 21
9.2.1. ASCII Casemap Collation Description . . . . . . . . . 21
9.2.2. ASCII Casemap Collation Registration . . . . . . . . . 22
9.3. Octet Collation . . . . . . . . . . . . . . . . . . . . . 22
9.3.1. Octet Collation Description . . . . . . . . . . . . . 22
9.3.2. Octet Collation Registration . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 24
8. 専門の評論家. . . . . . . . . . . . . . . . 18 9へのガイドライン。 校合. . . . . . . . . . . . . . . . . . . . . . 19 9.1に頭文字をつけてください。 ASCIIの数値照合. . . . . . . . . . . . . . . . . 20 9.1.1。 ASCIIの数値照合記述. . . . . . . . . 20 9.1.2。 ASCIIの数値照合登録. . . . . . . . . 20 9.2。 ASCII Casemapの照合. . . . . . . . . . . . . . . . . 21 9.2.1。 ASCII Casemap照合記述. . . . . . . . . 21 9.2.2。 ASCII Casemap照合登録. . . . . . . . . 22 9.3。 八重奏の照合. . . . . . . . . . . . . . . . . . . . . 22 9.3.1。 八重奏照合記述. . . . . . . . . . . . . 22 9.3.2。 八重奏照合登録. . . . . . . . . . . . . 23 10。 IANA問題. . . . . . . . . . . . . . . . . . . . . 23 11。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 23 12。 承認. . . . . . . . . . . . . . . . . . . . . . . 23 13。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 24 13.1。 引用規格. . . . . . . . . . . . . . . . . . . 24 13.2。 有益な参照. . . . . . . . . . . . . . . . . . 24
Newman, et al. Standards Track [Page 3] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[3ページ]。
1. Introduction
1. 序論
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.
Application Configuration AccessプロトコルACAP[11]仕様は、比較器(私たちが本書では照合と呼ぶ)の概念を紹介しましたが、IANA登録を作成しませんでした。 stringprep[6]とユニコードCollation Algorithm[7]の導入で、現在国際社会に、適切ないくつかの初期の値でその登録を作成して、もうそれに居住するべき時間です。 この仕様は、ACAPとの比較器の定義を取り替えて、一般化して、照合登録を作成します。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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"、「必須NOT」“SHOULD"、「」 「5月」は「RFCsにおける使用が要件レベルを示すキーワード」[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].
属性構文仕様はAugmented BN記法(ABNF)[2]記法を使用します、Appendix A.で定義されて、Language Tags[5]と「reg-名前」からURIからABNF生産「言語タグ」を輸入するというコア規則を含んでいて: 一般的な構文[4]。
2. Collation Definition and Purpose
2. 照合定義と目的
2.1. Definition
2.1. 定義
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つ以上を実行するのに使用できます: 平等テスト、サブストリングマッチ、および注文は検査されます。
2.2. Purpose
2.2. 目的
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]がプロトコル仕様とキャラクタマッピングに八重奏の詳細を切り離す方法と同様です、MIME[9]、またはSASL[10]がプロトコル仕様と認証機構の細部を切り離す方法などのように、ACAP[11]などのように。
Newman, et al. Standards Track [Page 4] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[4ページ]。
Here is a small diagram to help illustrate the value of this abstraction:
ここに、この抽象化の値を例証するのを助ける小さいダイヤグラムがあります:
+-------------------+ +-----------------+
| IMAP i18n SEARCH |--+ | Basic |
+-------------------+ | +--| Collation Spec |
| | +-----------------+
+-------------------+ | +-------------+ | +-----------------+
| ACAP i18n SEARCH |--+--| Collation |--+--| A stringprep |
+-------------------+ | | Registry | | | Collation Spec |
| +-------------+ | +-----------------+
+-------------------+ | | +-----------------+
| ...other protocol |--+ | | locale-specific |
+-------------------+ +--| Collation Spec |
+-----------------+
+-------------------+ +-----------------+ | IMAP i18n検索|--+ | 基本的| +-------------------+ | +--| 照合仕様| | | +-----------------+ +-------------------+ | +-------------+ | +-----------------+ | ACAP i18n検索|--+--| 照合|--+--| stringprep| +-------------------+ | | 登録| | | 照合仕様| | +-------------+ | +-----------------+ +-------------------+ | | +-----------------+ | ...他のプロトコル|--+ | | 現場特有です。| +-------------------+ +--| 照合仕様| +-----------------+
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、および国際調査能力がある将来のアプリケーション・プロトコルは単にそれが支持するすべての校合を指定しなければならない各プロトコル仕様の代わりに照合登録に連結する方法を指定します。
2.3. Some Other Terms Used in this Document
2.3. このDocumentのいくらかのOther Terms Used
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スクリプトを走らせている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はプロトコルです、そして、Sieve言語もそうです。
2.4. Sort Keys
2.4. 分類用キー
One component of a collation is a transformation, which turns a string into a sort key, which is then used while sorting.
照合の1つのコンポーネントは変化です。(その変化はストリングを分類用キーに変えます)。(次に、それは、分類している間、使用されます)。
Newman, et al. Standards Track [Page 5] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[5ページ]。
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.
変化は人間にとって、読みにくいストリングがそれをマッピングに写像すると(例えば、i; 八重奏照合セクション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.
これは校合かサーバの実現の詳細です。 プロトコルSHOULD NOTはそれをクライアントに露出します、いくつかの校合が分類用キーの形式を実現に任せて、現在のconformant実現が異なった形式を使用するのが知られているので。
3. Collation Identifier Syntax
3. 照合識別子構文
3.1. Basic Syntax
3.1. 基本的な構文
The collation identifier itself is a single US-ASCII string. The identifier MUST NOT be longer than 254 characters, and obeys the following grammar:
照合識別子自体はただ一つの米国-ASCIIストリングです。 識別子は、254のキャラクタより長いはずがなく、以下の文法に従います:
collation-char = ALPHA / DIGIT / "-" / ";" / "=" / "."
「照合炭はアルファー/ DIGIT /「-」/と等しい」;、」 / "=" / "."
collation-id = collation-prefix ";" collation-core-name
*collation-arg
「照合イド=照合接頭語」;、」 照合コア名の*照合arg
collation-scope = Language-tag / "vnd-" reg-name
照合範囲=言語タグ/"vnd"reg-名
collation-core-name = ALPHA *( ALPHA / DIGIT / "-" )
照合コア名=アルファー*(アルファ/ケタ/「-」)
collation-arg = ";" ALPHA *( ALPHA / DIGIT ) "="
1*( ALPHA / DIGIT / "." )
「照合-arg=」;、」 アルファ*(アルファー/ケタ)「=」1*「(アルファ/ケタ/、」、」、)
Note: the ABNF production "Language-tag" is imported from Language Tags [5] and "reg-name" from URI: Generic Syntax [4].
以下に注意してください。 Language Tags[5]と「reg-名前」からURIからABNF生産「言語タグ」を輸入します: 一般的な構文[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.
「デフォルト」と呼ばれる特別な識別子があります。 デフォルトの照合を持っているプロトコルについて「デフォルト」はその照合を示します。 他のプロトコルのために、「デフォルト」という識別子は校合に全く合ってはいけません、そして、実在しない校合を扱うとき、同様に、サーバSHOULDはそれを扱います。
3.2. Wildcards
3.2. ワイルドカード
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.
クライアントが照合を選択するのに使用するストリングがゼロに合っている1個以上のワイルドカード(「*」)のキャラクタを含むかもしれませんか、または、より多くの照合が焦げます。 ワイルドカードキャラクタは隣接しているはずがありません。 ワイルドカードストリングが複数の校合に合っているなら、サーバSHOULDは、狭く役に立つものに優先して広く役に立つ照合を選択するのを試みます。
Newman, et al. Standards Track [Page 6] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[6ページ]。
collation-wild = ("*" / (ALPHA ["*"])) *(collation-char ["*"])
; MUST NOT exceed 254 characters total
照合ワイルドな=(「*」/(アルファー[「*」]))*(照合炭[「*」])。 NOTは総で254のキャラクタを超えなければなりませんか?
3.3. Ordering Direction
3.3. 指示を注文します。
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
照合命令は照合荒野と等しいです[「+」/「-」]。
3.4. URIs
3.4. URI
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-uri = "http://www.iana.org/assignments/collation/"
collation-id ".xml"
照合-uriは" http://www.iana.org/assignments/collation/ "照合イド".xml"と等しいです。
collation-auri = ( "http://www.iana.org/assignments/collation/"
collation-order ".xml" ) / other-uri
照合金=(" http://www.iana.org/assignments/collation/ "照合命令".xml")/uriです他の。
other-uri = <absoluteURI>
; excluding the IANA collation namespace.
他のuriは<absoluteURI>と等しいです。 IANA照合名前空間を除きます。
3.5. Naming Guidelines
3.5. ガイドラインを命名します。
While this specification makes no absolute requirements on the structure of collation identifiers, naming consistency is important, so the following initial guidelines are provided.
この仕様が照合識別子の構造の上で絶対条件を全く作りませんが、一貫性を命名するのが重要であるので、以下の初期のガイドラインを提供します。
Collation identifiers with an international audience typically begin with "i;". Collation identifiers intended for a particular language or locale typically begin with a language tag [5] followed by a ";". After the first ";" is normally the name of the general collation algorithm, followed by a series of algorithm modifications separated by the ";" delimiter. Parameterized modifications will use "=" to
国際的な聴衆がいる照合識別子は「i」で通常始まります。 「a」が言語タグ[5]のあとに続いていて、特定の言語か現場に意図する照合識別子は通常始まります。」 「1日後」;、」 「通常一連のアルゴリズム変更があとに続いた一般的な照合アルゴリズムの名前が切り離される、」、;、」 デリミタ。 意志が「=」を使用する変更をParameterizedしました。
Newman, et al. Standards Track [Page 7] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[7ページ]。
delimit the parameter from the value. The version numbers of any lookup tables used by the algorithm SHOULD be present as parameterized modifications.
値からのパラメタを区切ってください。 parameterizedされるとしてのプレゼントが変更であったならアルゴリズムSHOULDによって使用されたどんなルックアップ表のバージョン番号。
Collation identifiers of the form *;vnd-hostname;* are reserved for vendor-specific collations created by the owner of the hostname following the "vnd-" prefix (e.g., vnd-example.com for the vendor example.com). Registration of such collations (or the name space as a whole), with intended use of the "Vendor", is encouraged when a public specification or open-source implementation is available, but is not required.
フォーム*; vnd-ホスト名; *に関する照合識別子は"vnd"接頭語(例えば、業者example.comのためのvnd-example.com)に従って、ホスト名の所有者によって作成された業者特有の校合のために予約されます。 そのような校合(または、全体で名前スペース)の登録は、公共の仕様かオープンソース実現が利用可能であるときに、「業者」の意図している使用で奨励されますが、必要ではありません。
4. Collation Specification Requirements
4. 照合仕様書要求事項
4.1. Collation/Server Interface
4.1. 照合/サーバインタフェース
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; 八重奏(セクション9.3)の照合は八重奏ストリングを作動させます。 i; ASCIIの数値(セクション9.1)の操作は数を作動させます。
This specification defines the collation interface in terms of octet strings. However, implementations may choose to use character strings instead. Such implementations may not be able to implement e.g., i;octet. Since i;octet is not currently mandatory to implement for any protocol, this should not be a problem.
この仕様は八重奏ストリングに関して照合インタフェースを定義します。 しかしながら、実現は、代わりに文字列を使用するのを選ぶかもしれません。 そのような実現は例えば、iを実行できないかもしれません; 八重奏。 i以来; 八重奏が現在どんなプロトコルのためにも実行するために義務的でない、これは問題であるべきではありません。
4.2. Operations Supported
4.2. 支持された操作
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.
それぞれの照合操作のための規則の非明白な結果は操作のなにもかすべてのどちらかがどんなただ一つの照合のためにも「未定義」の状態で戻ることができるということです。 例えば、「未定義」の状態で決して戻らない平等操作、およびそれが時折するサブストリング操作を持っているのは可能ではありません。
Newman, et al. Standards Track [Page 8] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[8ページ]。
4.2.1. Validity
4.2.1. 正当性
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.
すべての校合で正当性テストを提供します。 別々に照合登録でそれを記載してはいけません。
4.2.2. Equality
4.2.2. 平等
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.
平等テストは、有効な入力をそれに提供するとき、いつも「マッチ」にもかかわらず、「マッチがありません」を返して、1か両方の入力ストリングが有効でないなら、「未定義」の状態で戻るかもしれません。
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.
平等テストのリターン値は、このドキュメントで「マッチ、マッチがありません」と呼ばれて、「未定義です」。
4.2.3. Substring
4.2.3. サブストリング
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つ以上のサブストリングが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
アプリケーション・プロトコルはサブストリングマッチのための位置の情報を返すかもしれません。 これが完了しているなら、位置の情報SHOULDは始めのオフセットと各マッチのために相殺された結末の両方を含んでいます。 より洗練された校合が不平等な長さのストリングに合うことができるので(例えば、プレ落ち着いたアクセント記号付き文字は分解しているアクセント記号付き文字に合うことができます)、これは重要です。 マッチSHOULDを重ね合わせて、一般に、報告されてください(「名言集」が「バナナ」の中に二度起こる時として)、ケースがaの照合が決めるかもしれないところにありますが
Newman, et al. Standards Track [Page 9] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[9ページ]。
to. For example, in a collation which treats all whitespace sequences as identical, the substring operation could be defined such that " 1 " (SP "1" SP) is reported just once within " 1 " (SP SP "1" SP SP), not four times (SP SP "1" SP, SP "1" SP, SP "1" SP SP and SP SP "1" SP SP), since the four matches are, in a sense, the same match.
. 例えば、照合では、どれが定義されたそのようなものがその「1」であったかもしれないなら同じであるとしてのすべての空白系列、サブストリング操作を扱うか、(SP、「1インチのSP)、」 1の中で一度だけ報告される、「(SP SP、「1インチのSP SP)、4回でない、(SP SP、「1インチのSP、SP、「1インチのSP、SP、「1インチのSP SPとSP SP、「1インチのSP SP) ある意味で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.
いくつかの校合のサブストリング操作が不平等な長さのストリングに合うことができることに注意してください。 例えば、プレ落ち着いたアクセント記号付き文字は分解しているアクセント記号付き文字に合うことができます。 ユニコードCollation Algorithm[7]はさらに詳細にこれについて議論します。
The return values of the substring operation are called "match", "no- match", and "undefined" in this document.
サブストリング操作のリターン値は、このドキュメントで「マッチ、いいえマッチ」と呼ばれて、「未定義です」。
4.2.4. Ordering
4.2.4. 注文します。
The ordering operation determines how two strings are ordered. It MUST be reflexive. For valid input, it MUST be transitive and trichotomous.
注文操作は、2個のストリングがどのように注文されるかを決定します。 それは再帰であるに違いありません。 有効な入力のために、それは、他動詞と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であるなら照合の平等操作で定義されるように等しいです。 1か両方のストリングが無効であるなら、注文するという結果は「未定義です」。
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.
注文操作のリターン値は本書では「より少なく」、「等しく」、「よりすばらしく」、「未定義である」と呼ばれます。
4.3. Sort Keys
4.3. 分類用キー
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.
SHOULDが内部の変化アルゴリズムを説明する照合仕様は分類用キーを発生させます。 このアルゴリズムを個々のストリングに適用できます、そして、潜在的に今後の比較操作を最適化するために結果を格納できます。 照合は、分類用キーがアイデンティティ機能で発生すると指定するかもしれません。 分類用キーは人間に意味を持っていないかもしれません。 分類用キーは照合への有効な入力でないかもしれません。
Newman, et al. Standards Track [Page 10] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[10ページ]。
4.4. Use of Lookup Tables
4.4. ルックアップ表の使用
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.
いくつかの校合がカスタマイズ可能なルックアップ表を使用します、例えば、テーブルが現場によって、ソフトウェアを出荷した後に変更されるかもしれないので。 記録された形式に1個以上のカスタマイズ可能なルックアップ表を使用する校合はそれらが使用するテーブルに数を割り当てなければなりません。 これはサーバの照合で使用されるテーブルにアクセスするアプリケーション・プロトコルコマンドを可能にします、クライアントとサーバが同じテーブルを使用するように。
5. Application Protocol Requirements
5. アプリケーション・プロトコル要件
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 charsetの外でキャラクタの使用を可能にするなら、このセクションは要件とアプリケーション・プロトコルが考える必要がある問題について説明します。
5.1. Character Encoding
5.1. キャラクターコード化
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])、または慎重に説明するのによる文字符号化ラベリングと変換の当該の問題。 後の場合では、考える詳細は未知のcharsets、どんな実装するために義務的なcharsets、適用される、バイトオーダーのどんな問題、およびサポートされる必要があるどんな転送encodingsも扱う方法を含んでいます。
5.2. Operations
5.2. 操作
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.
プロトコルは、プロトコルでこの仕様(平等マッチング、サブストリングマッチング、および注文)に基づき定義された操作のどれを呼び出すことができるか、そして、それらがどのように呼び出されるかを指定しなければなりません。 操作を呼び出す1つ以上の方法があるかもしれません。
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
照合のサブストリング機能は取組表を提供しますが、プロトコルはそのすべてをクライアントに提供する必要はありません。 それはそうするかもしれません。
Newman, et al. Standards Track [Page 11] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[11ページ]。
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).
プロトコルがサブストリングマッチの結果のための位置の情報を提供するなら、その位置の情報SHOULDは合っている結果におけるサブストリングを完全に指定します、検索ストリングの長さの如何にかかわらず。 例えば、マッチの戻っている始めの、そして、終わりのオフセットは十分でしょう、始めのオフセットと長さであるだろうことのように。 まさしく始めのオフセットを返すのは許容できません。 高度な校合が等しい異なった同じくらい長さ(例えば、プレ落ち着いて分解しているアクセント記号付き文字)のストリングを扱うことができるので、この規則が必要です。
5.3. Wildcards
5.3. ワイルドカード
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.
プロトコルSHOULDは与えられたワイルドカードパターン、またはパターンに合っている利用可能な校合を記載する方法を提供します。
5.4. String Comparison
5.4. ストリング比較
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マッピングはうまくいきます。 他の場合では、明記できる照合を使用しているほうがよいかもしれません。 「例えば、したがって、そのaサーバはイタリアで同等で、トルコで異なるとして「i」と「私」を扱うことができます(また、トルコ語には、点を打たされた大文字」 I」の、そして、a dotless小文字の「私」があります)。
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.
プロトコルデザイナーは、明記できる照合を使用するかどうかその都度考えるべきです。 キーワードには、ユーザー変数以外の必要性がしばしばあります、そして、検索議論は再び異なっているかもしれません。
5.5. Disconnected Clients
5.5. クライアントであると切断されます。
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.
プロトコルサポートがクライアントから切断して、照合が使用されて、それが構成可能なテーブル(例えば現場特有の拡大をサポートする)を使用できて、次に、オフラインである間、クライアントがサーバの照合操作を再生させることができないかもしれないということであるなら。
Newman, et al. Standards Track [Page 12] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[12ページ]。
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.
そのようなテーブルをダウンロードするメカニズムについて議論しました。 問題がまだよく理解されていないので、そのようなメカニズムは現在の仕様に含まれていません。
5.6. Error Codes
5.6. エラーコード
The protocol specification should consider assigning protocol error codes for the following circumstances:
プロトコル仕様は、以下の事情のためにプロトコルエラーコードを割り当てると考えるべきです:
o The client requests the use of a collation by identifier or
pattern, but no implemented collation matches that pattern.
o クライアントは識別子かパターンから照合の使用を要求しますが、どんな実装している照合もそのパターンに合っていません。
o The client attempts to use a collation for an operation that is
not supported by that collation -- for example, attempting to use
the "i;ascii-numeric" collation for substring matching.
o その照合でサポートされない操作に照合を使用するクライアント試み--例えば、使用するのを試みる、「i;、ASCII数値、」 サブストリングマッチングのための照合。
o The client uses an equality or substring matching collation, and
the result is an error. It may be appropriate to distinguish
between the two input strings, particularly when one is supplied
by the client and the other is stored by the server. It might
also be appropriate to distinguish the specific case of an invalid
UTF-8 string.
o クライアントは平等かサブストリングの合っている照合を使用します、そして、結果は誤りです。 2個の入力ストリングを見分けるのは適切であるかもしれません、特に、1つがクライアントによって供給されて、もう片方がサーバによって保存されるとき。また、無効のUTF-8ストリングの特定のケースを区別するのも適切であるかもしれません。
5.7. Octet Collation
5.7. 八重奏の照合
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)の照合は八重奏ストリングに基づくプロトコルで使用可能であるだけです。 クライアントとサーバは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.
プロトコルがストリング以外のデータ構造との校合の使用を可能にするなら、プロトコルはそれらのデータ構造との照合のためのデフォルトの振舞いについて説明しなければなりません。
6. Use by Existing Protocols
6. 既存のプロトコルによる使用
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.
これらのプロトコルはiの使用を許します; これらのプロトコルに使用されるように直接UTF-8データに取り組む八重奏(セクション9.3)の照合。
Newman, et al. Standards Track [Page 13] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[13ページ]。
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では、すべてのマッチが、本当であるか、または偽です。 それに従って、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.
COMPARATOR[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の内蔵の操作に合ってください。
7. Collation Registration
7. 照合登録
7.1. Collation Registration Procedure
7.1. 照合登録手順
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 に送るとき、登録手順は始まります。 登録が承認されるか、マイナーチェンジで承認されるか、または原因で拒絶されることにかかわらず指定された専門家が2週間以内に登録についてIANAとsubmitterに言うと予想されます。 登録が原因で拒絶されるとき、原因で記載された関心が扱われるなら、それを再提出できます。 IESG Applications Areaディレクターと、そして、そして、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によって所有されています、そして、登録への変化はそのようなドキュメントをアップデートするための正常な手順に続いて起こります。 他のRFCsの照合登録証明書は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
登録が既存の照合の変化であるなら、所有者はそれを承認しなければなりません。 イベントでは、所有者に連絡できません。
Newman, et al. Standards Track [Page 14] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[14ページ]。
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 MAYは適切なパーティーに所有権を再選任します。
7.2. Collation Registration Format
7.2. 照合登録形式
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ドキュメントを送ることによって、照合の登録をします。
7.2.1. Registration Template
7.2.1. 登録テンプレート
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は「一般的な「照合</タイトル><操作>平等オーダーサブストリング</操作>のための><識別子>照合識別子</識別子の>の<のタイトルの>の技術的なタイトル」'と等しいです; 1つの</バージョンのsubmitter</submitter><バージョン>>の</照合>の所有者かIETF</所有者><submitter>Eメールアドレスの<仕様>仕様参照</仕様><所有者>Eメールアドレス
7.2.2. The Collation Element
7.2.2. 照合要素
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=」属性はRFCの数だけを与えます、少しも接頭語なしで、"RFC"、または接尾語などのように、".txt"などのように。
The <collation> element MUST include a "scope=" attribute, which MUST have one of the values "global", "local", or "other".
<照合>要素は「範囲=」属性を含まなければなりません。(それは、「グローバルである」か、「地方」、または「他」に値の1つを持たなければなりません)。
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=」属性を含まなければなりません。(それは、「一般的で」、「制限された」「ベンダー」、または「推奨しなく」値の1つを持たなければなりません)。 「一般的な」使用のために意図する照合仕様は国際的な人物セットについて詳細に対処するという重要な経験がある標準化団体から基準ゲージに予想されます。
Be aware that future revisions of this specification may add additional function types, as well as additional XML attributes,
この仕様の今後の改正が追加関数型、および追加XML属性を加えるかもしれないのを意識してください。
Newman, et al. Standards Track [Page 15] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[15ページ]。
values, and elements. Any system that automatically parses these XML documents MUST take this into account to preserve future compatibility.
値、および要素。 自動的にこれらのXMLドキュメントを分析するどんなシステムも、将来の互換性を保存するためにこれを考慮に入れなければなりません。
7.2.3. The Identifier Element
7.2.3. 識別子要素
The <identifier> element gives the precise identifier of the collation, e.g., i;ascii-casemap. The <identifier> element is mandatory.
<識別子>要素は照合、例えば、iの正確な識別子を与えます; ASCII-casemap。 <識別子>要素は義務的です。
7.2.4. The Title Element
7.2.4. タイトル要素
The <title> element gives the title of the collation. The <title> element is mandatory.
<タイトル>要素は照合のタイトルを与えます。 <タイトル>要素は義務的です。
7.2.5. The Operations Element
7.2.5. 操作要素
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つの操作のどれを記載するか。 <操作>要素は義務的です。
7.2.6. The Specification Element
7.2.6. 仕様要素
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属性があるかもしれません。 一緒に、形成してください。その場合、1つ以上の<仕様>要素があるかもしれない、それら、仕様。
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 メーリングリストは通知されるべきです。
7.2.7. The Submitter Element
7.2.7. Submitter要素
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>要素はRFC2822[12]Eメールアドレスを登録を提出した人に提供します。 <所有者>要素がEメールアドレスを含んでいるなら、任意です。
There may be more than one <submitter> element.
1つ以上の<submitter>要素があるかもしれません。
7.2.8. The Owner Element
7.2.8. 所有者要素
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.
<所有者>要素は"IETF"という4個の手紙か登録の所有者のEメールアドレスのどちらかを含んでいます。 <所有者>要素は義務的です。 1つ以上の<所有者>要素があるかもしれません。 そうだとすれば、すべての所有者が等しいです。 各所有者はすべてを代弁できます。
Newman, et al. Standards Track [Page 16] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[16ページ]。
7.2.9. The Version Element
7.2.9. バージョン要素
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個以上の入力ストリングのために変化するような方法で改訂されました。 <バージョン>要素は任意です。
7.2.10. The Variable Element
7.2.10. 可変要素
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.
例えば、それが大文字と小文字を区別しているか否かに関係なく、<の可変>要素は、照合のふるまいを制御するために任意の変数を指定します。 <の可変>要素は任意です。 <の可変>が使用されているとき、<名前>と<デフォルト>要素を含まなければなりません、そして、1つ以上の<値の>要素を含むかもしれません。
7.2.10.1. The Name Element
7.2.10.1. 名前要素
The <name> element specifies the name value of a variable. The <name> element is mandatory.
<名前>要素は変数値という名前を指定します。 <名前>要素は義務的です。
7.2.10.2. The Default Element
7.2.10.2. デフォルト要素
The <default> element specifies the default value of a variable. The <default> element is mandatory.
<デフォルト>要素はデフォルト変数値を指定します。 <デフォルト>要素は義務的です。
7.2.10.3. The Value Element
7.2.10.3. 価値要素
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で規則を指定しなければなりません。
7.3. Structure of Collation Registry
7.3. 照合登録の構造
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は照合イドが識別子要素の内容であるフォーム http://www.iana.org/assignments/collation/collation-id.xml の1つのURLの登録におけるそれぞれのXML登録用書類を保存するでしょう。 XMLが整形式であることを確かめるのにsubmitterと指定された専門家の両方が責任があります。 登録用書類は、新しい要素を使用するのを避けるはずです。 いずれか必要であるなら、他の登録証明書と一致しているのは重要です。
IANA will also maintain a text summary of the registry under the name http://www.iana.org/assignments/collation/collation-index.html. This summary is divided into four sections. The first section is for collations intended for common use. This section is intended for
また、IANAは http://www.iana.org/assignments/collation/collation-index.html という名で登録のテキスト概要を維持するでしょう。 この概要は4つのセクションに分割されます。 最初のセクションは一般の使用のために意図する校合のためのものです。 このセクションは意図します。
Newman, et al. Standards Track [Page 17] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[17ページ]。
collation registrations published in IESG-approved RFCs, or for locally scoped collations from the primary standards body for that locale. The designated expert is encouraged to reject collation registrations with an intended use of "common" if the expert believes it should be "limited", as it is desirable to keep the number of "common" registrations small and of high quality. The second section is reserved for limited-use collations. The third section is reserved for registered vendor-specific collations. The final section is reserved for deprecated collations.
照合登録証明書はIESGによって承認されたRFCs、またはその現場への原器本体からの局所的に見られた校合のために発行されました。 専門家が、それが「一般的な」登録証明書の数を小さく保つのが望ましくて高い品質について「制限されるべきである」と信じているなら、指定された専門家が「一般的」の意図している使用で照合登録証明書を拒絶するよう奨励されます。 第2セクションは限られた使用校合のために予約されます。 第3セクションは登録されたベンダー特有の校合のために予約されます。 最後のセクションは推奨しない校合のために予約されます。
7.4. Example Initial Registry Summary
7.4. 例の初期の登録概要
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]
照合機能範囲参照--------- --------- ----- --------- コモンは校合を使用します: i; ASCII-casemap e、o、s Local[RFC4790]
Limited Use Collations:
i;octet e, o, s Other [RFC 4790]
i;ascii-numeric e, o Other [RFC 4790]
制限されて、校合を使用してください: i; 八重奏e、o、s Other[RFC4790]i; ASCII数値のe、o Other[RFC4790]
Vendor Collations:
ベンダー校合:
Deprecated Collations:
推奨しない校合:
References
----------
[RFC 4790] Newman, C., Duerst, M., Gulbrandsen, A., "Internet
Application Protocol Collation Registry", RFC 4790,
Sun Microsystems, March 2007.
参照---------- [RFC4790] ニューマン、C.、Duerst、M.、Gulbrandsen、A.、「インターネットアプリケーション・プロトコル照合登録」、RFC4790、サン・マイクロシステムズ、2007年3月。
8. Guidelines for Expert Reviewer
8. 専門の評論家へのガイドライン
The expert reviewer appointed by the IESG has fairly broad latitude for this registry. While a number of collations are expected (particularly customizations of the UCA for localized use), an explosion of collations (particularly common-use collations) is not desirable for widespread interoperability. However, it is important for the expert reviewer to provide cause when rejecting a registration, and, when possible, to describe corrective action to
IESGによって任命された専門の評論家はこの登録への広い緯度を公正に持っています。 多くの校合が予想されますが(特にローカライズしている使用のためのUCAの改造)、広範囲の相互運用性には、校合(一般の特に使用している校合)の爆発は望ましくはありません。 しかしながら、専門家の評論家がそして、可能であるときに登録を拒絶するとき、原因を提供して、修正措置について説明するように、それは重要です。
Newman, et al. Standards Track [Page 18] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[18ページ]。
permit the registration to proceed. The following table includes some example reasons to reject a registration with cause:
登録が続くのを許容してください。 以下のテーブルは原因で登録を拒絶するいくつかの例の理由を含んでいます:
o The registration is not a well-formed XML document.
o 登録は整形式のXMLドキュメントではありません。
o The registration has an intended use of "common", but there is no
evidence the collation will be widely deployed, so it should be
listed as "limited".
o 登録には、「一般的」の意図している使用がありますが、照合が広く配布されるという証拠が全くないので、それは「制限される」として記載されているべきです。
o The registration has an intended use of "common", but it is
redundant with the functionality of a previously registered
"common" collation.
o 登録には、「一般的」の意図している使用がありますが、それは以前に登録された「一般的な」照合の機能性で余分です。
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で“MUST"要件の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は既に登録された校合のものと不必要に異なっています。
9. Initial Collations
9. 初期の校合
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つの校合を登録します。 これらの校合の振舞いのいくつかが恐らくiなどのように理想的ではありません; 非ASCIIが入力したASCII-casemap受諾。 広く配布しているコードとの互換性は校合を修理するより重要であると判断されました。 これらの校合の局面のいくつかが、広く配布しているコードとの互換性を維持するのに必要です。
Newman, et al. Standards Track [Page 19] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[19ページ]。
9.1. ASCII Numeric Collation
9.1. ASCIIの数値照合
9.1.1. ASCII Numeric Collation Description
9.1.1. ASCIIの数値照合記述
The "i;ascii-numeric" collation is a simple collation intended for use with arbitrarily-sized, unsigned decimal integer numbers stored as octet strings. US-ASCII digits (0x30 to 0x39) represent digits of the numbers. Before converting from string to integer, the input string is truncated at the first non-digit character. All input is valid; strings that do not start with a digit represent positive infinity.
「i;、ASCII数値、」 照合は任意にサイズの、そして、未署名の10進整数が八重奏ストリングとして保存されている状態で使用のために意図する簡単な照合です。 米国-ASCIIケタ(0×30から0×39)は数のケタを表します。 ストリングから整数まで変換する前に、入力ストリングは最初の非ケタキャラクタで先端を切られます。 すべての入力が有効です。 ケタから始まらないストリングが陽の無限を表します。
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」は等しいです」。
9.1.2. ASCII Numeric Collation Registration
9.1.2. ASCIIの数値照合登録
<?xml version='1.0'?>
<!DOCTYPE collation SYSTEM 'collationreg.dtd'>
<collation rfc="4790" scope="other" intendedUse="limited">
<identifier>i;ascii-numeric</identifier>
<title>ASCII Numeric</title>
<operations>equality order</operations>
<specification>RFC 4790</specification>
<owner>IETF</owner>
<submitter>chris.newman@sun.com</submitter>
</collation>
<?xmlバージョン= '1.0'?><!「他」のDOCTYPE照合SYSTEM'collationreg.dtd'><照合rfc=「4790」範囲=intendedUseは「「><識別子>i; ASCII数値の</識別子><タイトル>ASCII Numeric</タイトル><操作>平等オーダー</操作><仕様>RFC4790</仕様><所有者>IETF</所有者><submitter>chris。」制限されて、'と等しいです; newman@sun.com 、lt;、/よりsubmitterな></照合>。
Newman, et al. Standards Track [Page 20] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[20ページ]。
9.2. ASCII Casemap Collation
9.2. ASCII Casemapの照合
9.2.1. ASCII Casemap Collation Description
9.2.1. ASCII Casemap照合記述
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する」照合は米国-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などの機能は、時々現場敏感であり、不適当に大文字への1zを除いた小文字アルファベットを写像するかもしれません。
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 ユーロを含んで、ポンド貨シンボル、引用符を結ぶ、'、「'ダッシュ/ハイフンなど'」
Newman, et al. Standards Track [Page 21] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[21ページ]。
9.2.2. ASCII Casemap Collation Registration
9.2.2. ASCII Casemap照合登録
<?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; RFC4790</仕様><所有者>IETF</所有者><submitter>がchrisするASCII casemapな</識別子><タイトル>ASCII Casemap</タイトル><操作>平等オーダーサブストリング</操作><仕様>。」、'; newman@sun.com 、lt;、/よりsubmitterな></照合>。
9.3. Octet Collation
9.3. 八重奏の照合
9.3.1. Octet Collation Description
9.3.1. 八重奏照合記述
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;、八重奏、」 照合はキャラクタデータでというよりむしろ2進の八重奏ストリングにおける使用のために意図する簡単で速い照合です。 この照合を利用可能にしたがっているプロトコルは、明らかにそれを許容することによって、そうしなければなりません。 明らかに許容されていないなら、それを使用してはいけません。 それは「未定義」の結果を決して返しません。 それは平等、サブストリング、および注文に操作を提供します。
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番目のストリングが空であり、1番目が空でないなら、「よりすばらしい」状態で結果を返してください。
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に同等です。
Newman, et al. Standards Track [Page 22] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[22ページ]。
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番目のストリングに「合わせています」。 さもなければ、サブストリング操作リターンは「合っていません」。
9.3.2. Octet Collation Registration
9.3.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; 八重奏</識別子><タイトル>Octet</タイトル><操作>平等オーダーサブストリング</操作><仕様>RFC4790</仕様><所有者>IETF</所有者><submitter>chris。」制限されて、'と等しいです; newman@sun.com 、lt;、/よりsubmitterな></照合>。
10. IANA Considerations
10. IANA問題
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に登録された事前に定義された校合のリストを定義します。
11. Security Considerations
11. セキュリティ問題
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]、およびユニコードTR-36[8]のためのセキュリティ問題も、適用して、この仕様に規範的です。
12. Acknowledgements
12. 承認
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.
作者はこのドキュメントに貢献したすべてに感謝したがっています、ブライアンCarpenter、ジョン・カウァン、デーヴCridland、マーク・デイビス、スペンサー・ダウキンズ、リサDusseault、ラース・エッゲルト、フランクEllermann、フィリップ・グンサー、トニー・ハンセン、テッド・ハーディー、サム・ハートマン、Kjetil Torgrim Homme、マイケル・ケイ、ジョンKlensin、Alexeyメリニコフ、ジムMelton、およびAbhijitメノン-上院議員を含んでいて
Newman, et al. Standards Track [Page 23] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[23ページ]。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[2] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[3] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[3]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変化形式
[4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986,
January 2005.
[4]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC3986、2005年1月。
[5] Phillips, A. and M. Davis, "Tags for Identifying Languages",
BCP 47, RFC 4646, September 2006.
フィリップス(A.とM.デイヴィス)が「言語を特定するためにタグ付けをする」[5]、BCP47、RFC4646、2006年9月。
[6] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
Strings ("stringprep")", RFC 3454, December 2002.
[6] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、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.ウィスラー、「ユニコードCollation Algorithmのバージョンの14インチの2005年5月<httpな://www.unicode.org/レポート/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、「ユニコードセキュリティ問題。」2006年2月、<http://www.unicode.org/reports/tr36/>。
13.2. Informative References
13.2. 有益な参照
[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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[10] Melnikov, A., "Simple Authentication and Security Layer
(SASL)", RFC 4422, June 2006.
[10] メリニコフ、A.、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、2006年6月。
[11] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997.
[11] ニューマン、C.、およびJ.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
[12] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[12] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[13] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
解放された[13]とN.とJ.ポステル、「IANA Charset登録手順」、BCP19、RFC2978、2000年10月。
Newman, et al. Standards Track [Page 24] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[24ページ]。
[14] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028,
January 2001.
[14] ショウォーター、T.、「ふるい:」 「言語をフィルターにかけるメール」、RFC3028、2001年1月。
[15] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003.
[15] クリスピン、M.、「バージョン4rev1"、RFC3501、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
クリスニューマンサン・マイクロシステムズ1050湖はウエストコビナ、カリフォルニア91790米国を運転します。
EMail: chris.newman@sun.com
メール: chris.newman@sun.com
Martin Duerst Aoyama Gakuin University 5-10-1 Fuchinobe Sagamihara, Kanagawa 229-8558 Japan
相模原、マーチンDuerst青山学院大学5-10-1神奈川日本淵野辺229-8558
Phone: +81 42 759 6329 Fax: +81 42 759 6495 EMail: duerst@it.aoyama.ac.jp URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
以下に電話をしてください。 +81 42 759 6329Fax: +81 42 759 6495はメールされます: 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.
以下に注意してください。 どこでも、例えば、「Dürst」としてXMLとHTMLで可能であるところにu-ウムラウト符号で"Duerst"を書いてください。
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 81671 Munich Germany
Arnt GulbrandsenオリックスメールシステムGmbH Schweppermannstr。 8 81671ミュンヘンドイツ
Fax: +49 89 4502 9758 EMail: arnt@oryx.com URI: http://www.oryx.com/arnt/
Fax: +49 89 4502 9758はメールされます: arnt@oryx.com ユリ: http://www.oryx.com/arnt/
Newman, et al. Standards Track [Page 25] RFC 4790 Collation Registry March 2007
ニューマン、他 規格は2007年の照合登録行進のときにRFC4790を追跡します[25ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Newman, et al. Standards Track [Page 26]
ニューマン、他 標準化過程[26ページ]
一覧
スポンサーリンク
