RFC 4518 - Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4518
タイトル : RFC 4518 - 軽量ディレクトリアクセスプロトコル（LDAP）：国際化された文字列準備
翻訳編集 : 自動生成

[要約] RFC 4518は、LDAPで使用される国際化文字列の準備に関する規格です。このRFCの目的は、LDAPディレクトリエントリの文字列を正規化し、比較可能な形式に変換することです。

Network Working Group                                        K. Zeilenga
Request for Comments: 4518                           OpenLDAP Foundation
Category: Standards Track                                      June 2006

Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation

軽量ディレクトリアクセスプロトコル（LDAP）：国際化された文字列準備

Status of This Memo

本文書の位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how character string matching is to be performed. This led to a number of usability and interoperability problems. This document defines string preparation algorithms for character-based matching rules defined for use in LDAP.

以前のLightWeight Directory Access Protocol（LDAP）技術仕様では、文字列の一致がどのように実行されるかを正確に定義しませんでした。これにより、多くの使いやすさと相互運用性の問題が発生しました。このドキュメントでは、LDAPで使用するために定義された文字ベースのマッチングルールの文字列準備アルゴリズムを定義します。

1. Introduction

1. はじめに

1.1. Background

1.1. 背景

A Lightweight Directory Access Protocol (LDAP) [RFC4510] matching rule [RFC4517] defines an algorithm for determining whether a presented value matches an attribute value in accordance with the criteria defined for the rule. The proposition may be evaluated to True, False, or Undefined.

軽量ディレクトリアクセスプロトコル（LDAP）[RFC4510]マッチングルール[RFC4517]は、提示された値がルールに定義された基準に従って属性値と一致するかどうかを判断するためのアルゴリズムを定義します。命題は、真、虚偽、または未定義に評価される場合があります。

True - the attribute contains a matching value,

true-属性には一致する値が含まれています。

False - the attribute contains no matching value,

false-属性には一致する値が含まれていません、

Undefined - it cannot be determined whether the attribute contains a matching value.

未定義 - 属性に一致する値が含まれているかどうかを決定することはできません。

For instance, the caseIgnoreMatch matching rule may be used to compare whether the commonName attribute contains a particular value without regard for case and insignificant spaces.

たとえば、CaseignoreMatchマッチングルールを使用して、CommonName属性にケースや重要でないスペースに関係なく特定の値が含まれているかどうかを比較できます。

1.2. X.500 String Matching Rules

1.2. X.500文字列マッチングルール

"X.520: Selected attribute types" [X.520] provides (among other things) value syntaxes and matching rules for comparing values commonly used in the directory [X.500]. These specifications are inadequate for strings composed of Unicode [Unicode] characters.

「x.520：選択された属性タイプ」[x.520]は、（とりわけ）値の構文と、ディレクトリで一般的に使用される値を比較するための一致するルールを提供します[x.500]。これらの仕様は、Unicode [Unicode]文字で構成される文字列には不十分です。

The caseIgnoreMatch matching rule [X.520], for example, is simply defined as being a case-insensitive comparison where insignificant spaces are ignored. For printableString, there is only one space character and case mapping is bijective, hence this definition is sufficient. However, for Unicode string types such as universalString, this is not sufficient. For example, a case-insensitive matching implementation that folded lowercase characters to uppercase would yield different results than an implementation that used uppercase to lowercase folding. Or one implementation may view space as referring to only SPACE (U+0020), a second implementation may view any character with the space separator (Zs) property as a space, and another implementation may view any character with the whitespace (WS) category as a space.

たとえば、caseignorematchマッチングルール[x.520]は、重要でないスペースが無視されているケース非感受性比較として単純に定義されます。PrintableStringの場合、スペース文字が1つしかなく、ケースマッピングは生物物語です。したがって、この定義は十分です。ただし、UniversalStringなどのUnicode Stringタイプの場合、これで十分ではありません。たとえば、小文字を大文字に折りたたむケースに依存しない一致する実装は、小文字を使用して折り畳みを使用した実装とは異なる結果をもたらします。または、1つの実装ではスペースをスペースのみ（u 0020）と呼ぶと見なす場合があり、2番目の実装では、スペースセパレーター（zs）プロパティを持つ任意の文字をスペースと見なす場合があり、別の実装では、Whitespace（WS）カテゴリのある文字を表示する場合があります。スペース。

The lack of precise specification for character string matching has led to significant interoperability problems. When used in certificate chain validation, security vulnerabilities can arise. To address these problems, this document defines precise algorithms for preparing character strings for matching.

文字弦のマッチングの正確な仕様がないため、重大な相互運用性の問題が発生しました。証明書チェーンの検証で使用すると、セキュリティの脆弱性が発生する可能性があります。これらの問題に対処するために、このドキュメントは、マッチングのために文字文字列を準備するための正確なアルゴリズムを定義します。

1.3. Relationship to "stringprep"

1.3. 「stringprep」との関係

The character string preparation algorithms described in this document are based upon the "stringprep" approach [RFC3454]. In "stringprep", presented and stored values are first prepared for comparison so that a character-by-character comparison yields the "correct" result.

このドキュメントで説明されている文字文字列準備アルゴリズムは、「stringprep」アプローチ[RFC3454]に基づいています。「StringPrep」では、表示され、保存された値が最初に比較のために準備され、文字ごとの比較が「正しい」結果が得られるようになります。

The approach used here is a refinement of the "stringprep" [RFC3454] approach. Each algorithm involves two additional preparation steps.

ここで使用されるアプローチは、「StringPrep」[RFC3454]アプローチの改良です。各アルゴリズムには、2つの追加の準備手順が含まれます。

a) Prior to applying the Unicode string preparation steps outlined in "stringprep", the string is transcoded to Unicode.

a) 「stringprep」で概説されているUnicode文字列準備手順を適用する前に、文字列はUnicodeにトランスコードされます。

b) After applying the Unicode string preparation steps outlined in "stringprep", the string is modified to appropriately handle characters insignificant to the matching rule.

b) 「StringPrep」で概説されているUnicode文字列の準備手順を適用した後、文字列は変更され、一致するルールに重要でない文字を適切に処理します。

Hence, preparation of character strings for X.500 [X.500] matching [X.501] involves the following steps:

したがって、x.500 [x.500]のキャラクター文字列の準備[x.501]には、次の手順が含まれます。

1) Transcode 2) Map 3) Normalize 4) Prohibit 5) Check Bidi (Bidirectional) 6) Insignificant Character Handling

1) トランスコード2）マップ3）正規化4）禁止5）BIDI（双方向）6）重要でない文字処理

These steps are described in Section 2.

これらの手順については、セクション2で説明します。

It is noted that while various tables of Unicode characters included or referenced by this specification are derived from Unicode [Unicode] data, these tables are to be considered definitive for the purpose of implementing this specification.

この仕様によって含まれるまたは参照されるUnicode文字のさまざまなテーブルは、Unicode [Unicode]データから派生しているが、これらのテーブルはこの仕様を実装する目的で決定的であると見なされることに注意してください。

1.4. Relationship to the LDAP Technical Specification

1.4. LDAP技術仕様との関係

This document is an integral part of the LDAP technical specification [RFC4510], which obsoletes the previously defined LDAP technical specification [RFC3377] in its entirety.

このドキュメントは、LDAP技術仕様[RFC4510]の不可欠な部分であり、以前に定義されたLDAP技術仕様[RFC3377]全体を廃止します。

This document details new LDAP internationalized character string preparation algorithms used by [RFC4517] and possible other technical specifications defining LDAP syntaxes and/or matching rules.

このドキュメントでは、[RFC4517]で使用される新しいLDAP国際的な文字列準備アルゴリズムおよびLDAP構文および/またはマッチングルールを定義する可能性のある他の技術仕様について詳しく説明しています。

1.5. Relationship to X.500

1.5. X.500との関係

LDAP is defined [RFC4510] in X.500 terms as an X.500 access mechanism. As such, there is a strong desire for alignment between LDAP and X.500 syntax and semantics. The character string preparation algorithms described in this document are based upon "Internationalized String Matching Rules for X.500" [XMATCH] proposal to ITU/ISO Joint Study Group 2.

LDAPは、X.500アクセスメカニズムとしてX.500用語で[RFC4510]を定義します。そのため、LDAPとX.500の構文とセマンティクスの間でアラインメントを強く望んでいます。このドキュメントで説明されている文字文字列準備アルゴリズムは、「X.500の国際的な文字列マッチングルール」[XMATCH] ITU/ISO共同研究グループ2への提案に基づいています。

1.6. Conventions and Terms

1.6. 慣習と条件

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14 [RFC2119]に記載されているように解釈される。

Character names in this document use the notation for code points and names from the Unicode Standard [Unicode]. For example, the letter "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. In the lists of mappings and the prohibited characters, the "U+" is left off to make the lists easier to read. The comments for character ranges are shown in square brackets (such as "[CONTROL CHARACTERS]") and do not come from the standard.

このドキュメントの文字名は、Unicode標準[Unicode]のコードポイントと名前の表記を使用します。たとえば、文字「a」は<u 0061>または<ラテンの小さな文字a>として表される場合があります。マッピングと禁止された文字のリストでは、「u」はリストの読み取りを容易にするために省略されています。キャラクターの範囲に対するコメントは、四角い括弧（「[コントロール文字]」など）で表示され、標準からは届きません。

Note: a glossary of terms used in Unicode can be found in [Glossary]. Information on the Unicode character encoding model can be found in [CharModel].

注：Unicodeで使用される用語の用語集は、[用語集]で見つけることができます。Unicode文字エンコードモデルに関する情報は、[Charmodel]に記載されています。

The term "combining mark", as used in this specification, refers to any Unicode [Unicode] code point that has a mark property (Mn, Mc, Me). Appendix A provides a definitive list of combining marks.

この仕様で使用されている「マークの結合」という用語は、マークプロパティ（MN、MC、ME）を持つUnicode [Unicode]コードポイントを指します。付録Aでは、マークを組み合わせた決定的なリストを提供します。

2. String Preparation

2. 文字列準備

The following six-step process SHALL be applied to each presented and attribute value in preparation for character string matching rule evaluation.

次の6段階のプロセスは、文字列マッチングルール評価に備えて、提示された各提示および属性値に適用されます。

1) Transcode 2) Map 3) Normalize 4) Prohibit 5) Check bidi 6) Insignificant Character Handling

1) トランスコード2）マップ3）正規化4）禁止5）Bidi 6）重要でない文字処理

Failure in any step causes the assertion to evaluate to Undefined.

任意のステップでの失敗により、アサーションは未定義に評価されます。

The character repertoire of this process is Unicode 3.2 [Unicode].

このプロセスのキャラクターレパートリーは、Unicode 3.2 [Unicode]です。

Note that this six-step process specification is intended to describe expected matching behavior. Implementations are free to use alternative processes so long as the matching rule evaluation behavior provided is consistent with the behavior described by this specification.

この6段階のプロセス仕様は、予想されるマッチング動作を記述することを目的としていることに注意してください。実装は、提供される一致するルール評価動作がこの仕様で説明されている動作と一致している限り、代替プロセスを自由に使用できます。

2.1. Transcode

2.1. トランスコード

Each non-Unicode string value is transcoded to Unicode.

各非波状の文字列値は、Unicodeにトランスコードされます。

PrintableString [X.680] values are transcoded directly to Unicode.

PrintableString [X.680]値は、Unicodeに直接トランスコードされます。

UniversalString, UTF8String, and bmpString [X.680] values need not be transcoded as they are Unicode-based strings (in the case of bmpString, a subset of Unicode).

UniversalString、utf8string、およびbmpstring [x.680]値は、ユニコードベースの文字列であるため、トランスコード化する必要はありません（bmpstringの場合、ユニコードのサブセット）。

TeletexString [X.680] values are transcoded to Unicode. As there is no standard for mapping TeletexString values to Unicode, the mapping is left a local matter.

TeleTexString [X.680]値はUnicodeにトランスコードされます。TeletexString値をUnicodeにマッピングする標準がないため、マッピングにはローカルな問題が残されています。

For these and other reasons, use of TeletexString is NOT RECOMMENDED.

これらおよびその他の理由により、TeletexStringの使用は推奨されません。

The output is the transcoded string.

出力はトランスコードされた文字列です。

2.2. Map

2.2. 地図

SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is mapped to nothing.

ソフトハイフン（U 00AD）とモンゴルのトドソフトハイフン（U 1806）コードポイントは何もマッピングされていません。Grapheme Joiner（U 034F）とバリエーションセレクター（U 180B-180D、FF00-FE0F）のコードポイントを組み合わせることも、何もマッピングされません。オブジェクト置換文字（U FFFC）は、何もマッピングされません。

CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR) (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020).

キャラクターの集計（U 0009）、ラインフィード（LF）（U 000A）、ライン集計（U 000B）、フォームフィード（FF）（U 000C）、キャリッジリターン（CR）（U 000D）、および次のライン（NEL）（U 0085）はスペースにマッピングされます（U 0020）。

All other control code (e.g., Cc) points or code points with a control function (e.g., Cf) are mapped to nothing. The following is a complete list of these code points: U+0000-0008, 000E-001F, 007F-0084, 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063, 206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F.

他のすべてのコントロールコード（CCなど）ポイントまたはコントロール関数（例：CF）が何もマッピングされていません。以下は、これらのコードポイントの完全なリストです：U 0000-0008、000E-001F、007F-0084、0086-009F、06DD、070F、180E、200C-200F、202A-202E、2060-2063、206A-206F、FEFF、FFF9-FFFB、1D173-1D17A、E0001、E0020-E007F。

ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code points with Separator (space, line, or paragraph) property (e.g., Zs, Zl, or Zp) are mapped to SPACE (U+0020). The following is a complete list of these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029, 202F, 205F, 3000.

ゼロ幅空間（U 200b）は何もマッピングされません。セパレーター（スペース、ライン、または段落）プロパティ（ZS、ZL、またはZPなど）を備えた他のすべてのコードポイントは、スペース（U 0020）にマッピングされます。以下は、これらのコードポイントの完全なリストです：U 0020、00A0、1680、2000-200A、2028-2029、202F、205F、3000。

For case ignore, numeric, and stored prefix string matching rules, characters are case folded per B.2 of [RFC3454].

ケース無視、数値、および保存されたプレフィックス文字列マッチングルールの場合、文字は[RFC3454]のB.2ごとにケース折りたたまれます。

The output is the mapped string.

出力はマッピングされた文字列です。

2.3. Normalize

2.3. ノーマライズ

The input string is to be normalized to Unicode Form KC (compatibility composed) as described in [UAX15]. The output is the normalized string.

[UAX15]に記載されているように、入力文字列はUnicode Form KC（互換性の構成）に正規化されます。出力は正規化された文字列です。

2.4. Prohibit

2.4. 禁止

All Unassigned code points are prohibited. Unassigned code points are listed in Table A.1 of [RFC3454].

すべての割り当てされていないコードポイントは禁止されています。未割り当てのコードポイントは、[RFC3454]の表A.1にリストされています。

Characters that, per Section 5.8 of [RFC3454], change display properties or are deprecated are prohibited. These characters are listed in Table C.8 of [RFC3454].

[RFC3454]のセクション5.8ごとに、ディスプレイプロパティを変更するか、非推奨される文字は禁止されています。これらの文字は、[RFC3454]の表C.8にリストされています。

Private Use code points are prohibited. These characters are listed in Table C.3 of [RFC3454].

プライベート使用コードポイントは禁止されています。これらの文字は、[RFC3454]の表C.3にリストされています。

All non-character code points are prohibited. These code points are listed in Table C.4 of [RFC3454].

すべての非文字コードポイントは禁止されています。これらのコードポイントは、[RFC3454]の表C.4にリストされています。

Surrogate codes are prohibited. These characters are listed in Table C.5 of [RFC3454].

代理コードは禁止されています。これらの文字は、[RFC3454]の表C.5にリストされています。

The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.

置換文字（U FFFD）コードポイントは禁止されています。

The step fails if the input string contains any prohibited code point. Otherwise, the output is the input string.

入力文字列に禁止されているコードポイントが含まれている場合、ステップは失敗します。それ以外の場合、出力は入力文字列です。

2.5. Check bidi

2.5. Bidiを確認してください

Bidirectional characters are ignored.

双方向のキャラクターは無視されます。

2.6. Insignificant Character Handling

2.6. 取るに足らない文字処理

In this step, the string is modified to ensure proper handling of characters insignificant to the matching rule. This modification differs from matching rule to matching rule.

このステップでは、文字列が変更されて、マッチングルールに取るに足らない文字を適切に処理することができます。この変更は、一致するルールと一致するルールとは異なります。

Section 2.6.1 applies to case ignore and exact string matching. Section 2.6.2 applies to numericString matching. Section 2.6.3 applies to telephoneNumber matching.

セクション2.6.1は、ケースの無視と正確な文字列の一致に適用されます。セクション2.6.2は、numericStringマッチングに適用されます。セクション2.6.3は、ThelephoneNumberマッチングに適用されます。

2.6.1. Insignificant Space Handling

2.6.1. 取るに足らないスペースハンドリング

For the purposes of this section, a space is defined to be the SPACE (U+0020) code point followed by no combining marks.

このセクションの目的のために、スペースはスペース（u 0020）コードポイントであると定義され、その後にマークが組み合わされていません。

NOTE - The previous steps ensure that the string cannot contain any code points in the separator class, other than SPACE (U+0020).

注 - 前の手順では、文字列にスペース以外のセパレータークラスのコードポイントが含まれないことを確認します（U 0020）。

For input strings that are attribute values or non-substring assertion values: If the input string contains no non-space character, then the output is exactly two SPACEs. Otherwise (the input string contains at least one non-space character), the string is modified such that the string starts with exactly one space character, ends with exactly one SPACE character, and any inner (non-empty) sequence of space characters is replaced with exactly two SPACE characters. For instance, the input strings "foo<SPACE>bar<SPACE><SPACE>", result in the output "<SPACE>foo<SPACE><SPACE>bar<SPACE>".

属性値または非潜水艦アサーション値である入力文字列の場合：入力文字列に非空間文字が含まれていない場合、出力は正確に2つのスペースです。それ以外の場合は（入力文字列には少なくとも1つの非空間文字が含まれています）、文字列は1つのスペース文字で始まり、正確に1つのスペース文字で終了し、スペース文字の内側（空でない）シーケンスで終了するように変更されます。正確に2つのスペース文字に置き換えられました。たとえば、入力文字列「foo <space> bar <Space> <Space>」により、出力「space> foo <sace <space> <space> bar <Space>」が出力されます。

For input strings that are substring assertion values: If the string being prepared contains no non-space characters, then the output string is exactly one SPACE. Otherwise, the following steps are taken:

サブストリングアサーション値である入力文字列の場合：準備されている文字列に非空間文字が含まれていない場合、出力文字列はまさに1つのスペースです。それ以外の場合、次の手順が取られます。

- If the input string is an initial substring, it is modified to start with exactly one SPACE character;

- 入力文字列が初期サブストリングである場合、1つのスペース文字から開始するように変更されます。

- If the input string is an initial or an any substring that ends in one or more space characters, it is modified to end with exactly one SPACE character;

- 入力文字列が初期または1つ以上のスペース文字で終わるサブストリングである場合、1つのスペース文字で終了するように変更されます。

- If the input string is an any or a final substring that starts in one or more space characters, it is modified to start with exactly one SPACE character; and

- 入力文字列が1つ以上のスペース文字で始まる最終的なサブストリングである場合、1つのスペース文字から始めるように変更されます。と

- If the input string is a final substring, it is modified to end with exactly one SPACE character.

- 入力文字列が最終的なサブストリングである場合、1つのスペース文字で終了するように変更されます。

For instance, for the input string "foo<SPACE>bar<SPACE><SPACE>" as an initial substring, the output would be "<SPACE>foo<SPACE><SPACE>bar<SPACE>". As an any or final substring, the same input would result in "foo<SPACE>bar<SPACE>".

たとえば、入力文字列「foo <Space> bar <Space> <Space>」の最初のサブストリングとして、出力は「<Space> foo <Saceal> <Space> bar <Space>」になります。任意のまたは最終的なサブストリングとして、同じ入力により「foo <sace> bar <sace>」になります。

Appendix B discusses the rationale for the behavior.

付録Bでは、行動の理論的根拠について説明します。

2.6.2. numericString Insignificant Character Handling

2.6.2. numericStringは重要でない文字処理

For the purposes of this section, a space is defined to be the SPACE (U+0020) code point followed by no combining marks.

このセクションの目的のために、スペースはスペース（u 0020）コードポイントであると定義され、その後にマークが組み合わされていません。

All spaces are regarded as insignificant and are to be removed.

すべてのスペースは取るに足らないと見なされ、削除されます。

For example, removal of spaces from the Form KC string: "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>" would result in the output string: "123456" and the Form KC string: "<SPACE><SPACE><SPACE>" would result in the output string: "" (an empty string).

たとえば、フォームKC文字列からのスペースの削除： "<Space> <Space> 123 <Space> <Space> 456 <Space> <Space>"は出力文字列になります： "123456"およびkc文字列：「<Space> <Space> <Space>」は、出力文字列： ""（空の文字列）になります。

2.6.3. telephoneNumber Insignificant Character Handling

2.6.3. ThelephoneNumberの重要でない文字処理

For the purposes of this section, a hyphen is defined to be a HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010), NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by no combining marks and a space is defined to be the SPACE (U+0020) code point followed by no combining marks.

このセクションの目的のために、ハイフンはハイフン - マイナス（U 002d）、アルメニアハイフン（U 058A）、ハイフン（U 2010）、非壊れたハイフン（U 2011）、マイナスサイン（U 2212）であると定義されています。、小さなハイフン - マイナス（U Fe63）、または全幅ハイフン - マイナス（U ff0d）コードポイントとその後のマークが組み合わされず、スペースはスペース（u 0020）コードポイントに続いて結合されないマークが続きます。

All hyphens and spaces are considered insignificant and are to be removed.

すべてのハイフンとスペースは取るに足らないと見なされ、除去されます。

For example, removal of hyphens and spaces from the Form KC string: "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>" would result in the output string: "123456" and the Form KC string: "<HYPHEN><HYPHEN><HYPHEN>" would result in the (empty) output string: "".

たとえば、フォームKC文字列からのハイフンとスペースの除去： "<Space> <phyphen> 123 <Space> <Space> 456 <Space> <Phyphen>"は出力文字列： "123456"およびkcの形式になります文字列： "<Hyphen> <Phiphen> <Hiphen>"は（空の）出力文字列： ""になります。

3. Security Considerations

3. セキュリティに関する考慮事項

"Preparation of Internationalized Strings ("stringprep")" [RFC3454] security considerations generally apply to the algorithms described here.

「国際化された文字列の準備（ "StringPrep"）」[RFC3454]セキュリティ上の考慮事項は、一般にここで説明するアルゴリズムに適用されます。

4. Acknowledgements

4. 謝辞

The approach used in this document is based upon design principles and algorithms described in "Preparation of Internationalized Strings ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some additional guidance was drawn from Unicode Technical Standards, Technical Reports, and Notes.

このドキュメントで使用されるアプローチは、ポールホフマンとマークブランシェットによる「国際化された文字列（「StringPrep '）」[RFC3454]で説明されている設計原則とアルゴリズムに基づいています。Unicodeの技術標準、技術レポート、およびメモからいくつかの追加のガイダンスが作成されました。

This document is a product of the IETF LDAP Revision (LDAPBIS) Working Group.

このドキュメントは、IETF LDAPリビジョン（LDAPBIS）ワーキンググループの製品です。

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.

[RFC3454] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（「StringPrep」）」、RFC 3454、2002年12月。

[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.

[RFC4510] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：技術仕様ロードマップ」、RFC 4510、2006年6月。

[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.

[RFC4517] Legg、S.、ed。、「Lightweight Directory Access Protocol（LDAP）：構文と一致するルール」、RFC 4517、2006年6月。

[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).

[Unicode] Unicodeコンソーシアム「Unicode Standard、バージョン3.2.0」は、「Unicode Standard、バージョン3.0」（Reading、MA、Addison-Wesley、2000。ISBN0-201- 61633-5）で定義されています。「Unicode Standard Annex＃27：Unicode 3.1」（http://www.unicode.org/reports/tr27/）および「Unicode Standard Annex＃28：Unicode 3.2」（http：//www.unicode.org/Reports/TR28/）。

[UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15: Unicode Normalization Forms, Version 3.2.0". <http://www.unicode.org/unicode/reports/tr15/tr15- 22.html>, March 2002.

[UAX15] Davis、M。およびM. Duerst、「Unicode Standard Annex＃15：Unicode Normalization Forms、バージョン3.2.0」。<http://www.unicode.org/unicode/reports/tr15/tr15- 22.html>、2002年3月。

[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(2002) (also ISO/IEC 8824-1:2002).

[X.680]国際電気通信連合 - 通信標準化セクター、「要約構文表記1（ASN.1） - 基本表記の仕様」、X.680（2002）（ISO/IEC 8824-1：2002）。

5.2. Informative References

5.2. 参考引用

[X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994).

[X.500]国際電気通信連合 - 通信標準化セクター、「ディレクトリ - 概念、モデル、サービスの概要」X.500（1993）（また、ISO/IEC 9594-1：1994）。

[X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Models," X.501(1993) (also ISO/IEC 9594- 2:1994).

[X.501]国際電気通信連合 - 電気通信標準化セクター、「ディレクトリ - モデル」X.501（1993）（ISO/IEC 9594- 2：1994）。

[X.520] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Selected Attribute Types", X.520(1993) (also ISO/IEC 9594-6:1994).

[X.520]国際電気通信連合 - 通信標準化セクター、「ディレクトリ：選択された属性タイプ」、X.520（1993）（ISO/IEC 9594-6：1994）。

[Glossary] The Unicode Consortium, "Unicode Glossary", <http://www.unicode.org/glossary/>.

[用語集] Unicode Consortium、「Unicode Glossary」、<http://www.unicode.org/glossary/>。

[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report #17, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr17/>, August 2000.

[Charmodel] Whistler、K。and M. Davis、「Unicode Technical Report＃17、Character Encoding Model」、utr17、<http://www.unicode.org/unicode/reports/tr17/>、2000年8月。

[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.

[RFC3377] Hodges、J。およびR. Morgan、「Lightweight Directory Access Protocol（V3）：技術仕様」、RFC 3377、2002年9月。

[RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006.

[RFC4515]スミス、M。、編およびT. Howes、「Lightweight Directory Access Protocol（LDAP）：検索フィルターの文字列表現」、RFC 4515、2006年6月。

[XMATCH] Zeilenga, K., "Internationalized String Matching Rules for X.500", Work in Progress.

[Xmatch] Zeilenga、K。、「X.500の国際的な文字列マッチングルール」、進行中の作業。

Appendix A. Combining Marks

付録A. マークを組み合わせます

This appendix is normative.

この付録は規範的です。

This table was derived from Unicode [Unicode] data files; it lists all code points with the Mn, Mc, or Me properties. This table is to be considered definitive for the purposes of implementation of this specification.

このテーブルは、Unicode [Unicode]データファイルから派生しました。MN、MC、またはMEプロパティを使用して、すべてのコードポイントをリストします。この表は、この仕様の実装を目的として決定的であると見なされます。

0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1 05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670 06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A 07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963 0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7 09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D 0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD 0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57 0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03 0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83 0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03 0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA 0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A 0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19 0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97 0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714 1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9 20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23 1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B 1D1AA-1D1AD

0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1 05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670 06ed 0711 0730-074a 07a6-07b0 0901-0903 093C 093E-094F 0951-0954 0962-0963 0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7 09E2-09E3 0A02 0A3C 0A3C 0A3C 0A3E-0A47-0A47A47A47A47A47A47A 0A70-0A71 0A81-0A83 0ABC 0ABE-0AC50AC7-0AC9 0ACB-0ACD 0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4-0B4D 0B56-0B57 0B82 8 0C4A-0C4D 0C55-0C56 0C82-0C83 0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03 0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA E34-0E3A 0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19 0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97 0F99-0FBC 0FC6 34 1752-1753 1772-177317B4-17D3 180B-180D 18A9 20D0-20EA 302A-302A-302FF 3099-309A FB1E FE00-FE0F FE20F FE20-FE23 1D165-1D169 1D16D-1172 1D17B-1D182 1D185-1DD18B 1D1A-DD11ADADADADADADAD

Appendix B. Substrings Matching

付録B. サブストリングマッチング

This appendix is non-normative.

この付録は非規範的です。

In the absence of substrings matching, the insignificant space handling for case ignore/exact matching could be simplified. Specifically, the handling could be to require that all sequences of one or more spaces be replaced with one space and, if the string contains non-space characters, removal of all leading spaces and trailing spaces.

サブストリングのマッチングがない場合、ケースの無視/正確な一致のための取るに足らないスペースハンドリングが簡素化される可能性があります。具体的には、1つ以上のスペースのすべてのシーケンスを1つのスペースに置き換える必要があり、文字列に非スペース文字が含まれている場合、すべての主要なスペースとトレーリングスペースが削除されることを要求することができます。

In the presence of substrings matching, this simplified space handling would lead to unexpected and undesirable matching behavior. For instance:

一致するサブストリングの存在下では、この単純化されたスペース処理は、予期せぬ望ましくないマッチング動作につながります。例えば：

   1) (CN=foo\20*\20bar) would match the CN value "foobar";

2) (CN=*\20foobar\20*) would match "foobar", but (CN=*\20*foobar*\20*) would not.

2) （cn =*\ 20foobar \ 20*）は「foobar」と一致しますが、（cn =*\ 20*foobar*\ 20*）はそうではありません。

Note to readers not familiar with LDAP substrings matching: the LDAP filter [RFC4515] assertion (CN=A*B*C) says to "match any value (of the attribute CN) that begins with A, contains B after A, ends with C where C is also after B."

LDAPサブストリングに精通していない読者への注意：LDAPフィルター[RFC4515]アサーション（CN = a*b*c）は、「aから始まる（属性cnの）の値をa、bの後に含む、aの後に終了する」と述べています。cここで、CはBの後にもあります。 "

The first case illustrates that this simplified space handling would cause leading and trailing spaces in substrings of the string to be regarded as insignificant. However, only leading and trailing (as well as multiple consecutive spaces) of the string (as a whole) are insignificant.

最初のケースは、この単純化されたスペースの取り扱いにより、文字列のサブストリング内の先頭と後続のスペースが取るに足らないと見なされることを示しています。ただし、文字列（全体として）のリーディングとトレイル（および複数の連続したスペース）のみが取るに足らないものです。

The second case illustrates that this simplified space handling would cause sub-partitioning failures. That is, if a prepared any substring matches a partition of the attribute value, then an assertion constructed by subdividing that substring into multiple substrings should also match.

2番目のケースは、この単純化されたスペース処理がサブパーティションの障害を引き起こすことを示しています。つまり、準備されたサブストリングが属性値のパーティションと一致する場合、複数のサブストリングへのサブストリングも一致することを細分化することによって構築されたアサーションが一致するはずです。

In designing an appropriate approach for space handling for substrings matching, one must study key aspects of X.500 case exact/ignore matching. X.520 [X.520] says:

サブストリングマッチングのためのスペースハンドリングに適したアプローチを設計する際には、X.500ケースの重要な側面を研究する必要があります。x.520 [x.520]は言う：

The [substrings] rule returns TRUE if there is a partitioning of the attribute value (into portions) such that:

[サブストリング]ルールは、次のような属性値（部分に）のパーティションがある場合にtrueを返します。

- the specified substrings (initial, any, final) match different portions of the value in the order of the strings sequence;

- 指定されたサブストリング（初期、任意の、最終）は、文字列シーケンスの順序で値のさまざまな部分と一致します。

- initial, if present, matches the first portion of the value;

- 存在する場合、初期は値の最初の部分と一致します。

- final, if present, matches the last portion of the value;

- 最終的な場合、存在する場合、値の最後の部分と一致します。

- any, if present, matches some arbitrary portion of the value.

- 存在する場合は、値の任意の部分に一致します。

That is, the substrings assertion (CN=foo\20*\20bar) matches the attribute value "foo<SPACE><SPACE>bar" as the value can be partitioned into the portions "foo<SPACE>" and "<SPACE>bar" meeting the above requirements.

つまり、サブストリングスアサーション（CN = foo \ 20*\ 20bar）は、値を「foo <sace> "foo <space>"および "<sace>" <sace> bar "foo <sace> <sace> bar"と属性値 "foo <sace> <sace> bar"と一致させます。上記の要件を満たすこと。

X.520 also says:

x.520も言います：

[T]he following spaces are regarded as not significant:

[次のスペースは重要ではないと見なされます。

- leading spaces (i.e., those preceding the first character that is not a space);

- 主要なスペース（つまり、スペースではない最初のキャラクターに先行するスペース）;

- trailing spaces (i.e., those following the last character that is not a space);

- トレーリングスペース（つまり、スペースではない最後のキャラクターに続くもの）;

- multiple consecutive spaces (these are taken as equivalent to a single space character).

- 複数の連続したスペース（これらは単一のスペース文字に相当するものと見なされます）。

This statement applies to the assertion values and attribute values as whole strings, and not individually to substrings of an assertion value. In particular, the statements should be taken to mean that if an assertion value and attribute value match without any consideration to insignificant characters, then that assertion value should also match any attribute value that differs only by inclusion nor removal of insignificant characters.

このステートメントは、アサーション値と属性値全体としての属性に適用され、アサーション値のサブストリングには個別には適用されません。特に、ステートメントは、重要でない文字を考慮せずにアサーション値と属性値が一致する場合、そのアサーション値は、包含または削除された文字の除去によってのみ異なる属性値と一致する必要があることを意味するようにする必要があります。

Hence the assertion (CN=foo\20*\20bar) matches "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal of insignificant spaces.

したがって、これらの値は「foo <Space> <saper> <sace> bar」と「foo <Space> bar」と「foo <space> <sace> <sace> bar」と「foo <sace> <sace> <space> bar」とアサーション（cn = foo \ 20*\ 20bar）は、「foo <space> <space> bar」とは一致します。「取るに足らないスペースの包含または除去によって。

Astute readers of this text will also note that there are special cases where the specified space handling does not ignore spaces that could be considered insignificant. For instance, the assertion (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>" (insignificant spaces present in value) or " " (insignificant spaces not present in value). However, as these cases have no practical application that cannot be met by simple assertions, e.g., (cn=\20), and this minor anomaly can only be fully addressed by a preparation algorithm to be used in conjunction with character-by-character partitioning and matching, the anomaly is considered acceptable.

このテキストの鋭い読者は、指定されたスペースハンドリングが取るに足らないと見なされる可能性のあるスペースを無視しない特別なケースがあることにも注目します。たとえば、アサーション（CN = \ 20*\ 20*\ 20）は、「<Space> <sacers> <sape>」（価値に存在する重要でないスペース）または「 "（価値に存在しない重要でないスペース）と一致しません。ただし、これらのケースには、単純なアサーションでは満たすことができない実用的なアプリケーションがないため、たとえば（CN = \ 20）。このマイナーな異常は、文字ごとに使用される準備アルゴリズムによってのみ完全に対処できます。分割とマッチング、異常は許容可能であると見なされます。

Author's Address

著者の連絡先

Kurt D. Zeilenga OpenLDAP Foundation

Kurt D. Zeilenga OpenLdap Foundation

   EMail: Kurt@OpenLDAP.org

Full Copyright Statement

完全な著作権声明

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 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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。