Network Working Group S. Legg
Request for Comments: 3687 Adacel Technologies
Category: Standards Track February 2004
Lightweight Directory Access Protocol (LDAP)
and X.500 Component Matching Rules
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
The syntaxes of attributes in a Lightweight Directory Access Protocol (LDAP) or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes. Matching rules defined for the complex syntaxes usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax.
ライトウェイトディレクトリアクセスプロトコル（LDAP）、またはテキスト文字列、整数、またはブールなどの単純なデータ型、から、このようなディレクトリスキーマ操作属性の構文のような複雑な構造化データ型、にX.500ディレクトリの範囲内の属性の構文。複雑な構文用に定義されたルールに一致することは通常はほとんどすぐに便利なマッチング機能を提供します。この文書は、任意の任意の複雑な属性構文の属性値内の任意のユーザが選択した構成部品を一致させることができ、一般的なマッチング規則を定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ComponentAssertion . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Component Reference. . . . . . . . . . . . . . . . . . . 6
3.1.1. Component Type Substitutions . . . . . . . . . . 7
3.1.2. Referencing SET, SEQUENCE and CHOICE Components. 8
3.1.3. Referencing SET OF and SEQUENCE OF Components. . 9
3.1.4. Referencing Components of Parameterized Types. . 10
3.1.5. Component Referencing Example. . . . . . . . . . 10
3.1.6. Referencing Components of Open Types . . . . . . 12
3.1.6.1. Open Type Referencing Example . . . . . 12
3.1.7. Referencing Contained Types. . . . . . . . . . . 14
3.1.7.1. Contained Type Referencing Example. . . 14
3.2. Matching of Components . . . . . . . . . . . . . . . . . 15
3.2.1. Applicability of Existing Matching Rules . . . . 17
3.2.1.1. String Matching . . . . . . . . . . . . 17
3.2.1.2. Telephone Number Matching . . . . . . . 17
3.2.1.3. Distinguished Name Matching . . . . . . 18
3.2.2. Additional Useful Matching Rules . . . . . . . . 18
3.2.2.1. The rdnMatch Matching Rule. . . . . . . 18
3.2.2.2. The presentMatch Matching Rule. . . . . 19
3.2.3. Summary of Useful Matching Rules . . . . . . . . 20
4. ComponentFilter. . . . . . . . . . . . . . . . . . . . . . . . 21
5. The componentFilterMatch Matching Rule . . . . . . . . . . . . 22
6. Equality Matching of Complex Components. . . . . . . . . . . . 24
6.1. The OpenAssertionType Syntax . . . . . . . . . . . . . . 24
6.2. The allComponentsMatch Matching Rule . . . . . . . . . . 25
6.3. Deriving Component Equality Matching Rules . . . . . . . 27
6.4. The directoryComponentsMatch Matching Rule . . . . . . . 28
7. Component Matching Examples. . . . . . . . . . . . . . . . . . 30
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 37
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. Normative References. . . . . . . . . . . . . . . . . . 38
11.2. Informative References. . . . . . . . . . . . . . . . . 40
12. Intellectual Property Statement. . . . . . . . . . . . . . . . 40
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 41
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 42
The structure or data type of data held in an attribute of a Lightweight Directory Access Protocol (LDAP) [7] or X.500 [19] directory is described by the attribute's syntax. Attribute syntaxes range from simple data types, such as text string, integer, or boolean, to complex data types, for example, the syntaxes of the directory schema operational attributes.
ライトウェイトディレクトリアクセスプロトコル（LDAP）の属性に保持されているデータの構造やデータ型は、[7]またはX.500 [19]ディレクトリは属性の構文によって記述されています。属性構文は、例えば、テキスト文字列、整数、またはブール値などの単純なデータ型、より複雑なデータ型に、ディレクトリスキーマの操作属性の構文の範囲です。
In X.500, the attribute syntaxes are explicitly described by Abstract Syntax Notation One (ASN.1) [13] type definitions. ASN.1 type notation has a number of simple data types (e.g., PrintableString, INTEGER, BOOLEAN), and combining types (i.e., SET, SEQUENCE, SET OF, SEQUENCE OF, and CHOICE) for constructing arbitrarily complex data types from simpler component types. In LDAP, the attribute syntaxes are usually described in Augmented Backus-Naur Form (ABNF) [2], though there is an implied association between the LDAP attribute syntaxes and the X.500 ASN.1 types. To a large extent, the data types of attribute values in either an LDAP or X.500 directory are described by ASN.1 types. This formal description can be exploited to identify component parts of an attribute value for a variety of purposes. This document addresses attribute value matching.
X.500では、属性構文は、明示的に抽象構文記法1（ASN.1）[13]タイプの定義に記載されています。 ASN.1型表記は、単純なデータ型の数を有している（例えば、PrintableStringの、INTEGER、BOOLEAN）、及び単純なコンポーネントから任意の複雑なデータタイプを構築するための結合型（すなわち、SET、SEQUENCE、セット、シーケンス、およびCHOICE）タイプ。 LDAP属性構文およびX.500のASN.1型の間の暗黙の関連付けがあるがLDAPでは、属性構文は、通常、[2]増補バッカス - ナウアフォーム（ABNF）に記載されています。大部分は、LDAPやX.500ディレクトリのいずれかの属性値のデータ型は、ASN.1の型で記述されています。この正式な記述は、様々な目的のための属性値の部品を識別するために利用することができます。この文書アドレスは、値マッチング属性。
With any complex attribute syntax there is normally a requirement to partially match an attribute value of that syntax by matching only selected components of the value. Typically, matching rules specific to the attribute syntax are defined to fill this need. These highly specific matching rules usually only provide the most immediately useful matching capability. Some complex attribute syntaxes don't even have an equality matching rule let alone any additional matching rules for partial matching. This document defines a generic way of matching user selected components in an attribute value of any arbitrarily complex attribute syntax, where that syntax is described using ASN.1 type notation. All of the type notations defined in X.680 [13] are supported.
複雑な属性構文で部分値のみ選択したコンポーネントを照合することによって、その構文の属性値と一致する必要は通常存在します。一般的に、属性構文に固有の一致規則は、このニーズを満たすために定義されています。これらの非常に特異的なマッチングルールは、通常はほとんどすぐに便利なマッチング機能を提供します。いくつかの複雑な属性構文でも平等に一致するルールだけでは部分一致のための追加のマッチングルールを聞かせていません。この文書は、構文はASN.1タイプの表記を用いて記述された任意の任意の複雑な属性構文の属性値がユーザ選択されたコンポーネントを一致させる一般的な方法を定義します。 X.680 [13]で定義されたタイプの表記の全てがサポートされています。
Section 3 describes the ComponentAssertion, a testable assertion about the value of a component of an attribute value of any complex syntax.
第3節ではComponentAssertion、任意の複雑な構文の属性値の構成要素の値についての検証可能なアサーションを記述しています。
Section 4 introduces the ComponentFilter assertion, which is an expression of ComponentAssertions. The ComponentFilter enables more powerful filter matching of components in an attribute value.
セクション4はComponentAssertionsの表現であるComponentFilterアサーションを導入します。 ComponentFilterは、属性値のコンポーネントのより強力なフィルタのマッチングを可能にします。
Section 5 defines the componentFilterMatch matching rule, which enables a ComponentFilter to be evaluated against attribute values.
セクション5は、属性値に対して評価されるComponentFilterを可能componentFilterMatchマッチング規則を定義します。
Section 6 defines matching rules for component-wise equality matching of attribute values of any syntax described by an ASN.1 type definition.
セクション6は、ASN.1型定義によって記載される任意の構文の属性値の成分ごとの等価マッチングのためのマッチングルールを定義します。
Examples showing the usage of componentFilterMatch are in Section 7.
componentFilterMatchの使用を示す例は、セクション7です。
For a new attribute syntax, the Generic String Encoding Rules [9] and the specifications in sections 3 to 6 of this document make it possible to fully and precisely define the LDAP-specific encoding, the LDAP and X.500 binary encoding (and possibly other ASN.1 encodings in the future), a suitable equality matching rule, and a comprehensive collection of component matching capabilities, by simply writing down an ASN.1 type definition for the syntax. These implicit definitions are also automatically extended if the ASN.1 type is later extended. The algorithmic relationship between the ASN.1 type definition, the various encodings and the component matching behaviour makes directory server implementation support for the component matching rules amenable to automatic code generation from ASN.1 type definitions.
新しい属性の構文については、[9]一般的な文字列の符号化規則及び本文書の6セクション3における仕様は、おそらく完全かつ正確LDAP固有の符号化、LDAPおよびX.500バイナリ符号化を定義することを可能にする（及び単に構文については、ASN.1型定義を書き留めることにより、将来的には他のASN.1エンコーディング）は、適切な平等マッチングルール、およびコンポーネントのマッチング機能の包括的なコレクション、。 ASN.1タイプは、後で拡張されている場合、これらの暗黙の定義も自動的に延長されます。 ASN.1型定義との間のアルゴリズム関係、様々なエンコーディング及び成分マッチング動作はASN.1タイプ定義から自動コード生成に適し成分マッチングルールのディレクトリサーバの実装のサポートを行います。
Schema designers have the choice of storing related items of data as a single attribute value of a complex syntax in some entry, or as a subordinate entry where the related data items are stored as separate attribute values of simpler syntaxes. The inability to search component parts of a complex syntax has been used as an argument for favouring the subordinate entries approach. The component matching rules provide the analogous matching capability on an attribute value of a complex syntax that a search filter has on a subordinate entry.
スキーマの設計者は、いくつかのエントリに複雑な構文の単一の属性値などのデータの関連項目を保存する、または関連するデータ項目は、単純な構文の別々の属性値として格納されている下位のエントリとしての選択肢を持っています。複雑な構文の構成部品を検索することができないことは、下位のエントリのアプローチを好むための引数として使用されています。コンポーネントのマッチング規則は、検索フィルタは、下位エントリを有する複雑な構文の属性値に類似したマッチング機能を提供します。
Most LDAP syntaxes have corresponding ASN.1 type definitions, though they are usually not reproduced or referenced alongside the formal definition of the LDAP syntax. Syntaxes defined with only a character string encoding, i.e., without an explicit or implied corresponding ASN.1 type definition, cannot use the component matching capabilities described in this document unless and until a semantically equivalent ASN.1 type definition is defined for them.
彼らは通常、複製またはLDAP構文の正式な定義と一緒に参照されていないものの、ほとんどのLDAP構文は、対応するASN.1型定義を持っています。意味的に等価ASN.1型定義がそれらのために定義されない限りまでのみ文字列エンコーディングで定義された構文は、即ち、明示的または暗黙対応ASN.1型定義することなく、本文書に記載の成分のマッチング機能を使用することはできません。
Throughout this document "type" shall be taken to mean an ASN.1 type unless explicitly qualified as an attribute type, and "value" shall be taken to mean an ASN.1 value unless explicitly qualified as an attribute value.
本書では、「タイプは、」属性の型として明示的に修飾しない限り、ASN.1タイプを意味するものとし、「値が」属性値として明示的に修飾しない限り、ASN.1値を意味するものとします。
Note that "ASN.1 value" does not mean a Basic Encoding Rules (BER) [17] encoded value. The ASN.1 value is an abstract concept that is independent of any particular encoding. BER is just one possible encoding of an ASN.1 value. The component matching rules operate at the abstract level without regard for the possible encodings of a value.
「ASN.1値が」基本符号化規則（BER）[17]符号化された値を意味するものではないことに留意されたいです。 ASN.1値は、任意の特定のエンコーディングとは独立した抽象的な概念です。 BERは、ASN.1値のひとつの可能なエンコーディングです。コンポーネントマッチングルールは値の可能な符号化を考慮せずに抽象レベルで動作します。
Attribute type and matching rule definitions in this document are provided in both the X.500 [10] and LDAP [4] description formats. Note that the LDAP descriptions have been rendered with additional white-space and line breaks for the sake of readability.
この文書に記載されているタイプと一致するルール定義はX.500 [10]及びLDAP [4]記述形式の両方で提供される属性。 LDAPの説明は読みやすさのために追加の空白や改行でレンダリングされていることに注意してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [1]. The key word "OPTIONAL" is exclusively used with its ASN.1 meaning.
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD" "ないもの"、 "推奨" "NOTべきだ" と、この文書で説明するように解釈されるべきであり、 "MAY" BCP 14、RFC 2119 [1]。キーワード「OPTIONAL」は、もっぱらそのASN.1の意味で使用されています。
A ComponentAssertion is an assertion about the presence, or values of, components within an ASN.1 value, i.e., an instance of an ASN.1 type. The ASN.1 value is typically an attribute value, where the ASN.1 type is the syntax of the attribute. However, a ComponentAssertion may also be applied to a component part of an attribute value. The assertion evaluates to either TRUE, FALSE or Undefined for each tested ASN.1 value.
ComponentAssertionは存在、またはASN.1値、ASN.1型の、すなわち、インスタンス内の構成要素の値に関するアサーションです。 ASN.1値は、通常、ASN.1型は属性の構文である属性値、です。しかし、ComponentAssertionは、属性値の構成部品にも適用することができます。アサーションは、各テストASN.1値のため、TRUE FALSEまたは未定義のいずれかに評価されます。
A ComponentAssertion is described by the following ASN.1 type (assumed to be defined with "EXPLICIT TAGS" in force):
ComponentAssertionは、（力の「明示的タグ」と定義されると仮定）は、以下のASN.1タイプによって記述されます。
ComponentAssertion ::= SEQUENCE {
component ComponentReference (SIZE(1..MAX)) OPTIONAL,
useDefaultValues BOOLEAN DEFAULT TRUE,
rule MATCHING-RULE.&id,
value MATCHING-RULE.&AssertionType }
ComponentReference ::= UTF8String
MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching rule. MATCHING-RULE.&AssertionType is an open type (formerly known as the ANY type).
マッチング-RULE。＆IDが一致したルールのオブジェクト識別子に相当します。マッチングルール。＆AssertionType（以前の任意のタイプとして知られている）オープンタイプです。
The "component" field of a ComponentAssertion identifies which component part of a value of some ASN.1 type is to be tested, the "useDefaultValues" field indicates whether DEFAULT values are to be substituted for absent component values, the "rule" field indicates how the component is to be tested, and the "value" field is an asserted ASN.1 value against which the component is tested. The ASN.1 type of the asserted value is determined by the chosen rule.
いくつかのASN.1タイプの値の構成部品を試験するComponentAssertionの識別の「成分」フィールドは、「useDefaultValues」フィールドは、デフォルト値が存在しない成分値と置換されるべきかどうかを示し、「ルール」フィールドが示しますどのコンポーネントがテストされるべきであり、「値」フィールドには、コンポーネントがテストされる対抗ASN.1値です。アサートされた値のASN.1タイプは、選択されたルールによって決定されます。
The fields of a ComponentAssertion are described in detail in the following sections.
ComponentAssertionのフィールドは、以下のセクションに詳細に記載されています。
The component field in a ComponentAssertion is a UTF-8 character string [6] whose textual content is a component reference, identifying a component part of some ASN.1 type or value. A component reference conforms to the following ABNF [2], which extends the notation defined in Clause 14 of X.680 [13]:
ComponentAssertionコンポーネントフィールドは、[6]、そのテキストコンテンツいくつかASN.1タイプまたは値の構成部品を識別し、コンポーネントの参照であるUTF-8文字列です。コンポーネントの参照は、以下のABNFに準拠し[2]、X.680 [13]の節14に定義された表記法を拡張しています。
component-reference = ComponentId *( "." ComponentId ) ComponentId = identifier / from-beginning / count / from-end / ; extends Clause 14 content / ; extends Clause 14 select / ; extends Clause 14 all
コンポーネントリファレンス= COMPONENTID *（ "" のComponentID）COMPONENTID =識別子/から、開始/カウント/からエンド/。条項14コンテンツを拡張/。 /項14セレクト延びています。第14条すべての拡張
identifier = lowercase *alphanumeric *(hyphen 1*alphanumeric) alphanumeric = uppercase / lowercase / decimal-digit uppercase = %x41-5A ; "A" to "Z" lowercase = %x61-7A ; "a" to "z" hyphen = "-"
識別子=小文字の英数字* *（ハイフン1 *英数字）=％x41-5A大文字英数字=大文字/小文字/小数桁。 "Z" 小文字=％x61-7Aに "A"。 「」から「Z」ハイフン=「 - 」
from-beginning = positive-number count = "0" from-end = "-" positive-number content = %x63.6F.6E.74.65.6E.74 ; "content" select = "(" Value *( "," Value ) ")" all = "*"
最初-から=正の数カウント= "0" からエンド= " - " 正の数のコンテンツ=％x63.6F.6E.74.65.6E.74。 "コンテンツ" "（" バリュー*（ "" バリュー） "）" =選択したすべて= "*"
positive-number = non-zero-digit *decimal-digit
正の数=非ゼロ桁*小数点以下桁
decimal-digit = %x30-39 ; "0" to "9" non-zero-digit = %x31-39 ; "1" to "9"
小数桁=％x30-39。 「0」〜「9」の非ゼロ桁=％x31-39。 "1" 〜 "9"
An <identifier> conforms to the definition of an identifier in ASN.1 notation (Clause 11.3 of X.680 [13]). It begins with a lowercase letter and is followed by zero or more letters, digits, and hyphens. A hyphen is not permitted to be the last character and a hyphen is not permitted to be followed by another hyphen.
<識別子>は、ASN.1表記の識別子の定義に合致（X.680の節11.3 [13]）。それは小文字で始まり、ゼロ個以上の文字、数字、およびハイフンが続いています。ハイフンが最後の文字であることを許可されていないとハイフンは、別のハイフンが続くことを許可されていません。
The <Value> rule is described by the Generic String Encoding Rules (GSER) [9].
<値>ルールは、一般的な文字符号化規則（GSER）によって記載されている[9]。
A component reference is a sequence of one or more ComponentIds where each successive ComponentId identifies either an inner component at the next level of nesting of an ASN.1 combining type, i.e., SET, SEQUENCE, SET OF, SEQUENCE OF, or CHOICE, or a specific type within an ASN.1 open type.
コンポーネントの参照は、各連続のComponentIDタイプ、すなわち、SET、配列の配列のセット、または選択を組み合わせるASN.1のネストの次のレベルでの内部成分のいずれかを識別する一つ以上ComponentIdsの配列であり、又はASN.1オープンタイプ内の特定のタイプ。
A component reference is always considered in the context of a particular complex ASN.1 type. When applied to the ASN.1 type the component reference identifies a specific component type. When applied to a value of the ASN.1 type a component reference identifies zero, one or more component values of that component type. The component values are potentially in a DEFAULT value if useDefaultValues is TRUE. The specific component type identified by the component reference determines what matching rules are capable of being used to match the component values.
コンポーネントの参照は、常に特定の複合ASN.1型のコンテキストで考えられています。 ASN.1型に適用した場合のコンポーネントの参照は、特定のコンポーネントタイプを識別する。 ASN.1タイプの値に適用されたときにコンポーネントの参照は、そのコンポーネントのタイプの1つの以上の構成要素の値をゼロに識別する。 useDefaultValuesがTRUEである場合、コンポーネントの値は、デフォルト値に潜在的にあります。コンポーネントの参照によって識別される特定のコンポーネントタイプは、一致するルールは、コンポーネントの値を一致させるために使用されることが可能であるかを判断します。
The component field in a ComponentAssertion may also be absent, in which case the identified component type is the ASN.1 type to which the ComponentAssertion is applied, and the identified component value is the whole ASN.1 value.
ComponentAssertionコンポーネントフィールドはまた、識別されたコンポーネントタイプはASN.1タイプComponentAssertionが印加されることである、と識別された成分値が全体ASN.1値である場合には、存在しなくてもよいです。
A valid component reference for a particular complex ASN.1 type is constructed by starting with the outermost combining type and repeatedly selecting one of the permissible forms of ComponentId to identify successively deeper nested components. A component reference MAY identify a component with a complex ASN.1 type, i.e., it is not required that the component type identified by a component reference be a simple ASN.1 type.
特定の複合ASN.1タイプの有効成分基準は、最も外側の結合タイプで開始し、繰り返し順次深くネストされたコンポーネントを識別するためのComponentIDの許容形式のいずれかを選択することによって構成されています。コンポーネントの参照は、構成要素に参照により識別されたコンポーネントタイプは、単純なASN.1タイプである必要はない、すなわち、複合ASN.1タイプでコンポーネントを識別してもよいです。
ASN.1 type notation has a number of constructs for referencing other defined types, and constructs that are irrelevant for matching purposes. These constructs are not represented in a component reference in any way and substitutions of the component type are performed to eliminate them from further consideration. These substitutions automatically occur prior to each ComponentId, whether constructing or interpreting a component reference, but do not occur after the last ComponentId, except as allowed by Section 3.2.
ASN.1型表記は、目的に合致するために無関係な他の定義された型を参照するための構築物及び構築物の数を有しています。これらの構築物は、任意の方法で構成要素の参照に示されていないとコンポーネントタイプの置換は、さらなる考慮からそれらを除去するために行われます。これらの置換は、自動的に構築または構成要素の参照を解釈するかどうか、それぞれのComponentIDの前に起こるが、3.2節で許可される場合を除き、最後のComponentID後に発生していません。
If the ASN.1 type is an ASN.1 type reference then the component type is taken to be the actual definition on the right hand side of the type assignment for the referenced type.
ASN.1タイプはASN.1型の参照である場合、コンポーネントタイプは、参照型の型割り当ての右側の実際の定義であるとみなされます。
If the ASN.1 type is a tagged type then the component type is taken to be the type without the tag.
ASN.1型がタグ付けされたタイプである場合、コンポーネントタイプは、タグなしのタイプであるとみなされます。
If the ASN.1 type is a constrained type (see X.680 [13] and X.682 [15] for the details of ASN.1 constraint notation) then the component type is taken to be the type without the constraint.
ASN.1型が拘束型である場合、コンポーネントタイプが制約無しタイプであるとみなされる（X.680 [13]とASN.1制約表記の詳細については、X.682 [15]を参照）。
If the ASN.1 type is an ObjectClassFieldType (Clause 14 of X.681 [14]) that denotes a specific ASN.1 type (e.g., MATCHING-RULE.&id denotes the OBJECT IDENTIFIER type) then the component type is taken to be the denoted type. Section 3.1.6 describes the case where the ObjectClassFieldType denotes an open type.
ASN.1タイプは、特定のASN.1タイプ表す（例えば、マッチングルールを。＆IDは、オブジェクト識別子タイプを表す）ObjectClassFieldType（X.681の箇条14 [14]）である場合、コンポーネントタイプは、であると解釈されます示されたタイプ。 3.1.6項ではObjectClassFieldTypeはオープン型を表す場合について説明します。
If the ASN.1 type is a selection type other than one used in the list of components for a SET or SEQUENCE type then the component type is taken to be the selected alternative type from the named CHOICE.
ASN.1タイプがSETまたはSEQUENCEタイプのコンポーネントのリストで使用されるもの以外の選択タイプである場合、コンポーネントタイプは、名前の選択から選択された別のタイプであるとみなされます。
If the ASN.1 type is a TypeFromObject (Clause 15 of X.681 [14]) then the component type is taken to be the denoted type.
ASN.1タイプはTypeFromObject（X.681の箇条15 [14]）である場合、コンポーネントタイプは、示されたタイプであるとみなされます。
If the ASN.1 type is a ValueSetFromObjects (Clause 15 of X.681 [14]) then the component type is taken to be the governing type of the denoted values.
ASN.1タイプはValueSetFromObjects（X.681の箇条15 [14]）である場合、コンポーネントタイプは、示された値の支配型であるとみなされます。
If the ASN.1 type is a SET or SEQUENCE type then the <identifier> form of ComponentId may be used to identify the component type within that SET or SEQUENCE having that identifier. If <identifier> references an OPTIONAL component type and that component is not present in a particular value then there are no corresponding component values. If <identifier> references a DEFAULT component type and useDefaultValues is TRUE (the default setting for useDefaultValues) and that component is not present in a particular value then the component value is taken to be the default value. If <identifier> references a DEFAULT component type and useDefaultValues is FALSE and that component is not present in a particular value then there are no corresponding component values.
ASN.1タイプがSETまたはSEQUENCE型である場合、COMPONENTIDの<識別子>フォームは、その識別子を有するように設定または配列内のコンポーネントタイプを識別するために使用されてもよいです。 <識別子>参照任意成分の種類とそのコンポーネントが特定の値に存在しない場合は、該当する要素値がありません。 <識別子>は、デフォルトのコンポーネントタイプを参照しuseDefaultValuesがTRUEである（デフォルトはuseDefaultValuesの設定）と、そのコンポーネントは、コンポーネント値がデフォルト値であると解釈される特定の値に存在しない場合。 <識別子>参照DEFAULTコンポーネントタイプとuseDefaultValuesがFALSEであり、その成分は、特定の値が存在しない場合は、該当する要素値がありません。
If the ASN.1 type is a CHOICE type then the <identifier> form of ComponentId may be used to identify the alternative type within that CHOICE having that identifier. If <identifier> references an alternative other than the one used in a particular value then there are no corresponding component values.
ASN.1タイプがCHOICE型である場合、COMPONENTIDの<識別子>フォームは、その識別子を有することCHOICE内代替のタイプを識別するために使用されてもよいです。 <識別子>が特定の値に使用されるもの以外の代替を参照する場合、該当するコンポーネントの値は存在しません。
The COMPONENTS OF notation in Clause 24 of X.680 [13] augments the defined list of components in a SET or SEQUENCE type by including all the components of another defined SET or SEQUENCE type respectively. These included components are referenced directly by identifier as though they were defined in-line in the SET or SEQUENCE type containing the COMPONENTS OF notation.
X.680の節24に表記の構成要素[13]は、それぞれ別の定義されたセットまたはシーケンスのタイプのすべてのコンポーネントを含めることによって、SETまたはSEQUENCEタイプのコンポーネントの定義されたリストを増強します。彼らは、インライン表記の構成要素を含む集合またはシーケンスタイプで定義されているかのように、これらの含まれるコンポーネントは、識別子によって直接参照されます。
The SelectionType (Clause 29 of X.680 [13]), when used in the list of components for a SET or SEQUENCE type, includes a single component from a defined CHOICE type. This included component is referenced directly by identifier as though it was defined in-line in the SET or SEQUENCE type.
SETまたはSEQUENCEタイプのコンポーネントのリストで使用される場合のSelectionType（X.680の箇条29 [13]）、定義されたCHOICE型から単一の成分を含みます。それはインラインSETまたはSEQUENCEタイプで定義されたかのように、この付属部品は、識別子によって直接参照されます。
The REAL type is treated as though it is the SEQUENCE type defined in Clause 20.5 of X.680 [13].
それはX.680 [13]の節20.5に定義されたシーケンス型であるかのようにREALタイプが処理されます。
The EMBEDDED PDV type is treated as though it is the SEQUENCE type defined in Clause 33.5 of X.680 [13].
それはX.680 [13]の節33.5に定義されたシーケンス型であるかのようEMBEDDED PDVタイプが処理されます。
The EXTERNAL type is treated as though it is the SEQUENCE type defined in Clause 8.18.1 of X.690 [17].
それはX.690 [17]の節8.18.1に定義されたシーケンス型であるかのように、外部タイプが処理されます。
The unrestricted CHARACTER STRING type is treated as though it is the SEQUENCE type defined in Clause 40.5 of X.680 [13].
それはX.680 [13]の節40.5に定義されたシーケンス型であるかのように無制限の文字列型は、治療されています。
The INSTANCE OF type is treated as though it is the SEQUENCE type defined in Annex C of X.681 [14].
それはX.681の附属書C [14]で定義されたSEQUENCE型であるかのようにタイプのインスタンスが処理されます。
The <identifier> form MUST NOT be used on any other ASN.1 type.
<識別子>フォームは、他のASN.1タイプに使用してはいけません。
If the ASN.1 type is a SET OF or SEQUENCE OF type then the <from-beginning>, <from-end>, <count> and <all> forms of ComponentId may be used.
ASN.1タイプは、一連のまたはタイプのシーケンスである場合、<から-開始>、<からエンド>、<カウント>とのComponentIDの<全>の形態を使用することができます。
The <from-beginning> form of ComponentId may be used to identify one
instance (i.e., value) of the component type of the SET OF or
SEQUENCE OF type (e.g., if Foo ::= SET OF Bar, then Bar is the
component type), where the instances are numbered from one upwards.
If <from-beginning> references a higher numbered instance than the
last instance in a particular value of the SET OF or SEQUENCE OF type
then there is no corresponding component value.
The <from-end> form of ComponentId may be used to identify one instance of the component type of the SET OF or SEQUENCE OF type, where "-1" is the last instance, "-2" is the second last instance, and so on. If <from-end> references a lower numbered instance than the first instance in a particular value of the SET OF or SEQUENCE OF type then there is no corresponding component value.
COMPONENTIDの<からエンド>フォームが「-1」の最後のインスタンスのセット又はタイプ、一連の構成要素タイプの1つのインスタンスを識別するために使用することができる、「-2」二最後のインスタンスであり、そして上のようにします。 <からエンド>のセット又はタイプのシーケンスの特定の値に最初のインスタンスよりも低い番号のインスタンスを参照する場合は、該当するコンポーネントの値は存在しません。
The <count> form of ComponentId identifies a notional count of the number of instances of the component type in a value of the SET OF or SEQUENCE OF type. This count is not explicitly represented but for matching purposes it has an assumed ASN.1 type of INTEGER (0..MAX). A ComponentId of the <count> form, if used, MUST be the last ComponentId in a component reference.
COMPONENTIDの<数>フォームは、一連のまたはタイプのシーケンスの値のコンポーネントタイプのインスタンスの数の想定数を識別する。このカウントは、明示的に表されますが、一致の目的のために、それはINTEGER（0..MAX）の仮定ASN.1型を持つされていません。 <カウント>フォームのCOMPONENTIDは、使用される場合、成分基準の最後のComponentIDなければなりません。
The <all> form of ComponentId may be used to simultaneously identify all instances of the component type of the SET OF or SEQUENCE OF type. It is through the <all> form that a component reference can identify more than one component value. However, if a particular value of the SET OF or SEQUENCE OF type is an empty list, then there are no corresponding component values.
COMPONENTIDの<全>フォームが同時にセット又はタイプのシーケンスのコンポーネントタイプのすべてのインスタンスを識別するために使用されてもよいです。これは、コンポーネントの参照は、複数の成分値を識別することができること<全>フォームからです。セット又はタイプのシーケンスの特定の値は空のリストである場合は、次に該当する成分の値が存在しません。
Where multiple component values are identified, the remaining ComponentIds in the component reference, if any, can identify zero, one or more subcomponent values for each of the higher level component values.
複数の成分値が識別される場合、コンポーネント参照の残りComponentIdsは、もしあれば、より高いレベルのコンポーネント値のそれぞれに対して、ゼロ、1つまたは複数の副成分値を識別することができます。
The corresponding ASN.1 type for the <from-beginning>, <from-end>, and <all> forms of ComponentId is the component type of the SET OF or SEQUENCE OF type.
<から-開始>に対応するASN.1タイプ、<からエンド>、及びCOMPONENTIDの<全>フォームのセット又はタイプのシーケンスのコンポーネントタイプです。
The <from-beginning>, <count>, <from-end> and <all> forms MUST NOT be used on ASN.1 types other than SET OF or SEQUENCE OF.
<から-開始>、<数>、<からエンド>と<すべて>フォームは一連のかOF SEQUENCE以外のASN.1タイプに使用してはいけません。
A component reference cannot be formed for a parameterized type unless the type has been used with actual parameters, in which case the type is treated as though the DummyReferences [16] have been substituted with the actual parameters.
型は型がDummyReferences [16]かのように扱われている場合に実際のパラメータと一緒に使用されていない限り、成分の基準は、実際のパラメータで置換されたパラメータ化されたタイプに形成することができません。
Consider the following ASN.1 type definitions.
以下のASN.1型定義を考えてみましょう。
ExampleType ::= SEQUENCE {
part1 [0] INTEGER,
part2 [1] ExampleSet,
part3 [2] SET OF OBJECT IDENTIFIER,
part4 [3] ExampleChoice }
ExampleSet ::= SET {
option PrintableString,
setting BOOLEAN }
ExampleChoice ::= CHOICE {
eeny-meeny BIT STRING,
miney-mo OCTET STRING }
Following are component references constructed with respect to the type ExampleType.
型ExampleTypeに関して構築コンポーネントの参照は次のとおりです。
The component reference "part1" identifies a component of a value of ExampleType having the ASN.1 tagged type [0] INTEGER.
コンポーネントリファレンス「その1」はASN.1タグ付けされたタイプ[0] INTEGERを有するExampleTypeの値のコンポーネントを識別する。
The component reference "part2" identifies a component of a value of ExampleType having the ASN.1 type of [1] ExampleSet
コンポーネントリファレンス「その2」は、[1] ExampleSetのASN.1型を有するExampleTypeの値の成分を識別する
The component reference "part2.option" identifies a component of a value of ExampleType having the ASN.1 type of PrintableString. A ComponentAssertion could also be applied to a value of ASN.1 type ExampleSet, in which case the component reference "option" would identify the same kind of information.
成分基準「part2.option」とはPrintableStringのASN.1型を有するExampleTypeの値のコンポーネントを識別する。 ComponentAssertionは、コンポーネントの参照「オプションは、」情報の同じ種類を識別することになる場合には、ASN.1型ExampleSetの値に適用することができます。
The component reference "part3" identifies a component of a value of ExampleType having the ASN.1 type of [2] SET OF OBJECT IDENTIFIER.
コンポーネントリファレンス「その3」は、オブジェクト識別子[2] SETのASN.1型を有するExampleTypeの値のコンポーネントを識別する。
The component reference "part3.2" identifies the second instance of the part3 SET OF. The instance has the ASN.1 type of OBJECT IDENTIFIER.
成分基準「part3.2は」OFその3セットの2番目のインスタンスを識別する。インスタンスは、オブジェクト識別子のASN.1タイプがあります。
The component reference "part3.0" identifies the count of the number of instances in the part3 SET OF. The count has the corresponding ASN.1 type of INTEGER (0..MAX).
成分基準「part3.0は」OFその3セット内のインスタンスの数を識別する。カウントはINTEGER（0..MAX）の対応するASN.1タイプがあります。
The component reference "part3.*" identifies all the instances in the part3 SET OF. Each instance has the ASN.1 type of OBJECT IDENTIFIER.
成分基準「その3。*」は、その3 OFセット内のすべてのインスタンスを識別する。各インスタンスはオブジェクト識別子のASN.1タイプがあります。
The component reference "part4" identifies a component of a value of ExampleType having the ASN.1 type of [3] ExampleChoice.
コンポーネントリファレンス「その4」は、[3] ExampleChoiceのASN.1型を有するExampleTypeの値のコンポーネントを識別する。
The component reference "part4.miney-mo" identifies a component of a value of ExampleType having the ASN.1 type of OCTET STRING.
成分基準「part4.miney-Moは」オクテットSTRINGのASN.1型を有するExampleTypeの値のコンポーネントを識別する。
If a sequence of ComponentIds identifies an ObjectClassFieldType denoting an open type (e.g., ATTRIBUTE.&Type denotes an open type) then the ASN.1 type of the component varies. An open type is typically constrained by some other component(s) in an outer enclosing type, either formally through the use of a component relation constraint [15], or informally in the accompanying text, so the actual ASN.1 type of a value of the open type will generally be known. The constraint will also limit the range of permissible types. The <select> form of ComponentId may be used to identify one of these permissible types in an open type. Subcomponents of that type can then be identified with further ComponentIds.
ComponentIdsの配列は、開放型表すObjectClassFieldType識別する（例えば、属性。＆タイプオープンタイプを示す）場合、コンポーネントのASN.1タイプが変化します。オープンタイプは、典型的には、値の実際のASN.1型に、いずれかの形式的、または非公式添付のテキストコンポーネント関係制約[15]を使用することにより、外側封入型でいくつかの他の成分（単数または複数）によって制約されますオープンタイプで、一般的に知られているであろう。制約も許容型の範囲が制限されます。 COMPONENTIDの<選択>フォームは、開放型のこれらの許容タイプのいずれかを識別するために使用され得ます。そのタイプのサブコンポーネントは、その後さらにComponentIdsで識別することができます。
The other components constraining the open type are termed the referenced components [15]. The <select> form contains a list of one or more values which take the place of the value(s) of the referenced component(s) to uniquely identify one of the permissible types of the open type.
オープンタイプの拘束他の構成要素は、参照コンポーネント[15]と呼ばれます。 <選択>フォームが一意にオープンタイプの許容タイプのいずれかを識別するために参照される成分（S）の値（S）に代わる1つ以上の値のリストを含みます。
Where the open type is constrained by a component relation constraint, there is a <Value> in the <select> form for each of the referenced components in the component relation constraint, appearing in the same order. The ASN.1 type of each of these values is the same as the ASN.1 type of the corresponding referenced component. The type of a referenced component is potentially any ASN.1 type however it is typically an OBJECT IDENTIFIER or INTEGER, which means that the <Value> in the <select> form of ComponentId will nearly always be an <ObjectIdentifierValue> or <IntegerValue> [9]. Furthermore, component relation constraints typically have only one referenced component.
オープンタイプは、コンポーネント関係制約によって制約される場合には、<value>は同じ順序で出現する、コンポーネント関係制約で参照されるコンポーネントのそれぞれのための形態を、<選択>です。これらの値のそれぞれのASN.1タイプは、対応する参照先コンポーネントのASN.1型と同じです。参照される成分の種類は、潜在的に意味することは、典型的には、オブジェクト識別子またはINTEGERであるが、任意のASN.1型であるという点で、<値> <選択>のComponentIDの形はほぼ常になり<ObjectIdentifierValue>または<するIntegerValue> [9]。また、コンポーネント関係制約は、典型的には、唯一の参照成分を有します。
Where the open type is not constrained by a component relation constraint, the specification introducing the syntax containing the open type should explicitly nominate the referenced components and their order, so that the <select> form can be used.
オープンタイプは、コンポーネント関係制約によって制約されていない場合<選択>フォームを使用することができるように、オープンタイプを含む構文を導入仕様が明示的に参照されるコンポーネントとその順序を推薦すべきです。
If an instance of <select> contains a value other than the value of the referenced component used in a particular value of the outer enclosing type then there are no corresponding component values for the open type.
<選択>のインスタンスは、外側包囲タイプの特定の値に使用される参照成分の値以外の値が含まれている場合、オープンタイプのための対応する成分の値が存在しません。
The ASN.1 type AttributeTypeAndValue [10] describes a single attribute value of a nominated attribute type.
ASN.1型AttributeTypeAndValue [10]指名属性タイプの単一の属性値を記述する。
AttributeTypeAndValue ::= SEQUENCE {
type ATTRIBUTE.&id ({SupportedAttributes}),
value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) }
ATTRIBUTE.&id denotes an OBJECT IDENTIFIER and ({SupportedAttributes}) constrains the OBJECT IDENTIFIER to be a supported attribute type.
ATTRIBUTE。＆IDは、オブジェクト識別子と（{SupportedAttributesを}）であり、オブジェクト識別子がサポートされている属性タイプであることを制約します。
ATTRIBUTE.&Type denotes an open type, in this case an attribute value, and ({SupportedAttributes}{@type}) is a component relation constraint that constrains the open type to be of the attribute syntax for the attribute type. The component relation constraint references only the "type" component, which has the ASN.1 type of OBJECT IDENTIFIER, thus if the <select> form of ComponentId is used to identify attribute values of specific attribute types it will contain a single OBJECT IDENTIFIER value.
ATTRIBUTE。＆タイプは、この場合には、属性値を開放型であり、（{SupportedAttributes} {@タイプ}）は、属性タイプの属性構文であるとオープンタイプを制約コンポーネント関係制約です。オブジェクト識別子のASN.1型を有する唯一の「タイプ」コンポーネント、コンポーネント関係制約参照、COMPONENTIDの形態は、特定の属性タイプの属性値を識別するために使用される<SELECT>場合したがって、単一のオブジェクト識別子の値を含むであろう。
The component reference "value" on AttributeTypeAndValue refers to the open type.
AttributeTypeAndValue上の成分基準「値は」オープンタイプを指します。
One of the X.500 standard attributes is facsimileTelephoneNumber [12], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is defined to have the following syntax.
X.500標準属性の1つはオブジェクト識別子2.5.4.23で識別され、次の構文を持つように定義されてfacsimileTelephoneNumber [12]、です。
FacsimileTelephoneNumber ::= SEQUENCE {
telephoneNumber PrintableString(SIZE(1..ub-telephone-number)),
parameters G3FacsimileNonBasicParameters OPTIONAL }
The component reference "value.(2.5.4.23)" on AttributeTypeAndValue specifies an attribute value with the FacsimileTelephoneNumber syntax.
成分基準「値。（2.5.4.23）」AttributeTypeAndValueにはFacsimileTelephoneNumber構文の属性値を指定します。
The component reference "value.(2.5.4.23).telephoneNumber" on AttributeTypeAndValue identifies the telephoneNumber component of a facsimileTelephoneNumber attribute value. The component reference "value.(facsimileTelephoneNumber)" is equivalent to "value.(2.5.4.23)".
成分基準「値。（2.5.4.23）.telephoneNumber」AttributeTypeAndValueにはfacsimileTelephoneNumber属性値のTelephoneNumberコンポーネントを識別する。成分基準 "値。（facsimileTelephoneNumber）" に相当する "値。（2.5.4.23）"。
If the AttributeTypeAndValue ASN.1 value contains an attribute type other than facsimileTelephoneNumber then there are no corresponding component values for the component references "value.(2.5.4.23)" and "value.(2.5.4.23).telephoneNumber".
AttributeTypeAndValue ASN.1値がfacsimileTelephoneNumber以外の属性タイプが含まれている場合、コンポーネントの参照には、対応するコンポーネントの値が存在しない「値。（2.5.4.23）」と「値。（2.5.4.23）.telephoneNumber」。
Sometimes the contents of a BIT STRING or OCTET STRING value are required to be the encodings of other ASN.1 values of specific ASN.1 types. For example, the extnValue component of the Extension type component in the Certificate type [11] is an OCTET STRING that is required to contain a Distinguished Encoding Rules (DER) [17] encoding of a certificate extension value. It is useful to be able to refer to the embedded encoded value and its components. An embedded encoded value is here referred to as a contained value and its associated type as the contained type.
時にはビット列またはOCTET STRING値の内容は、特定のASN.1タイプの他のASN.1値の符号化であることが要求されています。例えば、証明書のタイプ拡張型成分のextnValue成分[11]証明書拡張値の識別符号化規則（DER）[17]符号化を含むことが要求されるオクテット列です。埋め込まれたエンコードされた値とその構成要素を参照することができることが有用です。埋め込み符号化された値は、ここに含まれる値と含まタイプとしてのその関連するタイプと呼ばれています。
If the ASN.1 type is a BIT STRING or OCTET STRING type containing encodings of other ASN.1 values then the <content> form of ComponentId may be used to identify the contained type. Subcomponents of that type can then be identified with further ComponentIds.
ASN.1タイプは他のASN.1値の符号化を含むビット列またはオクテット文字列型である場合、COMPONENTIDの<内容>フォームが含まれているタイプを識別するために使用されてもよいです。そのタイプのサブコンポーネントは、その後さらにComponentIdsで識別することができます。
The contained type may be (effectively) an open type, constrained by some other component in an outer enclosing type (e.g., in a certificate Extension, extnValue is constrained by the chosen extnId). In these cases the next ComponentId, if any, MUST be of the <select> form.
含まれるタイプ（効果的に）外側包囲タイプ（例えば、証明書拡張で、extnValueを選択extnIdによって制約されている）内の他のコンポーネントによって拘束開放型であってもよいです。これらの場合に次のComponentIDは、もしあれば、<選択>の形式でなければなりません。
For the purpose of building component references, the content of the extnValue OCTET STRING in the Extension type is assumed to be an open type having a notional component relation constraint with the extnId component as the single referenced component, i.e.,
ビルドコンポーネントの参照の目的のために、拡張タイプextnValueオクテット文字列の内容は、すなわち、単一の参照成分としてextnId成分と概念的な成分関係制約を有する開放型であると仮定され、
EXTENSION.&ExtnType ({ExtensionSet}{@extnId})
EXTENSION。＆ExtnType（{ExtensionSet} {@ extnId}）
The data-value component of the associated types for the EMBEDDED PDV and CHARACTER STRING types is an OCTET STRING containing the encoding of a data value described by the identification component. For the purpose of building component references, the content of the data-value OCTET STRING in these types is assumed to be an open type having a notional component relation constraint with the identification component as the single referenced component.
EMBEDDED PDV文字列タイプの関連するタイプのデータ値のコンポーネントは、識別コンポーネントによって記述されたデータ値の符号化を含むオクテット文字列です。コンポーネントの参照を構築する目的のために、これらのタイプのデータ値のオクテット文字列の内容は、単一の参照成分として識別コンポーネントとの概念的な成分関係制約を有する開放型であると仮定されます。
The Extension ASN.1 type [11] describes a single certificate extension value of a nominated extension type.
拡張ASN.1タイプ[11]指名拡張型の単一の証明書拡張の値を記載しています。
Extension ::= SEQUENCE {
extnId EXTENSION.&id ({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
-- contains a DER encoding of a value of type &ExtnType
-- for the extension object identified by extnId -- }
EXTENSION.&id denotes an OBJECT IDENTIFIER and ({ExtensionSet}) constrains the OBJECT IDENTIFIER to be the identifier of a supported certificate extension.
EXTENSION。＆IDは、オブジェクト識別子を示し、（{ExtensionSet}）はサポートされている証明書拡張の識別子と対象物識別子を制約します。
The component reference "extnValue" on Extension refers to a component type of OCTET STRING. The corresponding component values will be OCTET STRING values. The component reference "extnValue.content" on Extension refers to the type of the contained type, which in this case is an open type.
コンポーネントリファレンス拡張の「extnValueは」オクテットストリングのコンポーネントタイプを指します。対応する成分の値は、OCTET STRING値であろう。コンポーネントリファレンス拡張の「extnValue.content」は、この場合には開放型で含まれるタイプの種類を指します。
One of the X.509 [11] standard extensions is basicConstraints, which is identified with the OBJECT IDENTIFIER 2.5.29.19 and is defined to have the following syntax.
X.509 [11]標準の拡張機能の一つは、オブジェクト識別子2.5.29.19で識別され、次の構文を持つように定義されているbasicConstraintsの、です。
BasicConstraintsSyntax ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
The component reference "extnValue.content.(2.5.29.19)" on Extension specifies a BasicConstraintsSyntax extension value and the component reference "extnValue.content.(2.5.29.19).cA" identifies the cA component of a BasicConstraintsSyntax extension value.
延長上のコンポーネントの参照「extnValue.content。（2.5.29.19）は、」BasicConstraintsSyntax拡張値およびコンポーネントの参照を指定する「extnValue.content。（2.5.29.19）.CAは」BasicConstraintsSyntax拡張値のCa成分を識別する。
The rule in a ComponentAssertion specifies how the zero, one or more component values identified by the component reference are tested by the assertion. Attribute matching rules are used to specify the semantics of the test.
ComponentAssertionにルールがどのようにゼロを指定し、コンポーネントの参照によって識別された1つのまたは複数の成分値は、アサーションによってテストされます。属性一致規則は、テストのセマンティクスを指定するために使用されています。
Each matching rule has a notional set of attribute syntaxes (typically one), defined as ASN.1 types, to which it may be applied. When used in a ComponentAssertion these matching rules apply to the same ASN.1 types, only in this context the corresponding ASN.1 values are not necessarily complete attribute values.
各マッチングルールは、それが適用されるASN.1タイプとして定義属性構文（典型的には1）の概念的なセットを有します。 ComponentAssertionで使用される場合、これらのマッチングルールは、この文脈では、対応するASN.1値は、必ずしも完全な属性値ではない、同じASN.1タイプに適用されます。
Note that the referenced component type may be a tagged and/or constrained version of the expected attribute syntax (e.g., [0] INTEGER, whereas integerMatch would expect simply INTEGER), or an open type. Additional type substitutions of the kind described in
（integerMatchは単にINTEGERを期待する一方、例えば、[0] INTEGER）参照コンポーネントタイプが予想属性構文のタグ付けされた及び/又は制約バージョンであってもよいことに留意されたい、又はオープンタイプ。に記載された種類の追加のタイプの置換
Section 3.1.1 are performed as required to reduce the component type to the same type as the attribute syntax expected by the matching rule.
必要に応じて、セクション3.1.1は、マッチングルールにより予想される属性構文と同じタイプのコンポーネントタイプを低減するために行われます。
If a matching rule applies to more than one attribute syntax (e.g., objectIdentifierFirstComponentMatch [12]) then the minimum number of substitutions required to conform to any one of those syntaxes is performed. If a matching rule can apply to any attribute syntax (e.g., the allComponentsMatch rule defined in Section 6.2) then the referenced component type is used as is, with no additional substitutions.
マッチングルールは、複数の属性の構文（例えば、objectIdentifierFirstComponentMatch [12]）に適用される場合、それらの構文のいずれかに適合するために必要な置換基の最小数が行われます。マッチングルールは、任意の属性構文に適用することができる場合、参照される成分の種類がない追加の置換を有する、そのまま使用される（例えば、allComponentsMatchルールはセクション6.2で定義されます）。
The value in a ComponentAssertion will be of the assertion syntax (i.e., ASN.1 type) required by the chosen matching rule. Note that the assertion syntax of a matching rule is not necessarily the same as the attribute syntax(es) to which the rule may be applied.
ComponentAssertionの値が選択されたマッチング規則によって必要とされるアサーション構文（すなわち、ASN.1タイプ）のものであろう。マッチングルールのアサーション構文は必ずしも規則が適用される属性構文（ES）と同じではないことに留意されたいです。
Some matching rules do not have a fixed assertion syntax (e.g., allComponentsMatch). The required assertion syntax is determined in each instance of use by the syntax of the attribute type to which the matching rule is applied. For these rules the ASN.1 type of the referenced component is used in place of an attribute syntax to decide the required assertion syntax.
いくつかのマッチング規則は、固定されたアサーションの構文（例えば、allComponentsMatch）を持っていません。必要なアサーション構文は、一致するルールが適用される属性タイプの構文による使用の各インスタンスに決定されます。これらの規則のために参照されているコンポーネントのASN.1型が必要なアサーション構文を決定する属性構文の代わりに使用されます。
The ComponentAssertion is Undefined if:
ComponentAssertionは未定義です。
a) the matching rule in the ComponentAssertion is not known to the evaluating procedure,
A）成分アサーションにマッチングルールが評価手順には知られていません、
b) the matching rule is not applicable to the referenced component type, even with the additional type substitutions,
b）は、マッチングルールがあっても、追加のタイプの置換を有する、参照される成分の種類に適用されません、
c) the value in the ComponentAssertion does not conform to the assertion syntax defined for the matching rule,
C）ComponentAssertionの値は、一致するルールに定義されたアサーション構文に準拠していません、
d) some part of the component reference identifies an open type in the tested value that cannot be decoded, or
D）成分の基準の一部を復号することができない試験値でオープンタイプを識別し、又は
e) the implementation does not support the particular combination of component reference and matching rule.
E）の実装は、コンポーネントリファレンスとマッチングルールの特定の組合せをサポートしていません。
If the ComponentAssertion is not Undefined then the ComponentAssertion evaluates to TRUE if there is at least one component value for which the matching rule applied to that component value returns TRUE, and evaluates to FALSE otherwise (which includes the case where there are no component values).
ComponentAssertionが不定でない場合ComponentAssertionがTRUEと評価マッチングルールは、その成分値に適用される少なくとも一つの成分値が存在するならば、TRUEを返し、かつ（まったく成分値が存在しない場合を含む）そうでなければFALSEと評価。
ASN.1 has a number of built in restricted character string types with different character sets and/or different character encodings. A directory user generally has little interest in the particular character set or encoding used to represent a character string component value, and some directory server implementations make no distinction between the different string types in their internal representation of values. So rather than define string matching rules for each of the restricted character string types, the existing case ignore and case exact string matching rules are extended to apply to component values of any of the restricted character string types and any ChoiceOfStrings type [9], in addition to component values of the DirectoryString type. This extension is only for the purposes of component matching described in this document.
ASN.1は、異なる文字セットおよび/または異なる文字エンコーディングで制限された文字列の型に建てられたの数を持っています。ディレクトリユーザは、一般的に文字列の成分値を表すために使用される特定の文字セットまたは符号化にはほとんど関心があり、いくつかのディレクトリサーバ実装は、値の内部表現に異なる文字列型の区別をしません。そうではなく制限された文字列型のそれぞれの文字列に一致するルールを定義するよりも、既存のケースは無視した場合、正確な文字列マッチングの規則は制限文字列タイプのいずれかの成分値に適用するように拡張され、いかなるChoiceOfStrings式[9]でDirectoryStringタイプの成分値に加え。この拡張は、本書では説明成分マッチングの目的です。
The relevant string matching rules are: caseIgnoreMatch, caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, caseExactMatch, caseExactOrderingMatch and caseExactSubstringsMatch. The relevant restricted character string types are: NumericString, PrintableString, VisibleString, IA5String, UTF8String, BMPString, UniversalString, TeletexString, VideotexString, GraphicString and GeneralString. A ChoiceOfStrings type is a purely syntactic CHOICE of these ASN.1 string types. Note that GSER [9] declares each and every use of the DirectoryString{} parameterized type to be a ChoiceOfStrings type.
関連する文字列マッチングのルールは以下のとおりです。caseIgnoreMatch、caseIgnoreOrderingMatch、caseIgnoreSubstringsMatch、CaseExactMatchの、caseExactOrderingMatchとcaseExactSubstringsMatch。関連する制限された文字列のタイプは次のとおりです。NumericString、PrintableStringの、VisibleString、IA5String、UTF8Stringを、BMPString、UniversalString、TeletexString、VideotexString、GraphicStringとGeneralString。 ChoiceOfStringsタイプは、これらのASN.1文字列タイプの純粋に構文上のCHOICEです。 GSER [9] ChoiceOfStrings型であることがDirectoryString {}パラメータ化された型の各々および全ての使用を宣言することに留意されたいです。
The assertion syntax of the string matching rules is still DirectoryString regardless of the string syntax of the component being matched. Thus an implementation will be called upon to compare a DirectoryString value to a value of one of the restricted character string types, or a ChoiceOfStrings type. As is the case when comparing two DirectoryStrings where the chosen alternatives are of different string types, the comparison proceeds so long as the corresponding characters are representable in both character sets. Otherwise matching returns FALSE.
文字列照合規則のアサーション構文はまだかかわらず一致しているコンポーネントの文字列構文のDirectoryStringれます。このような実装は、制限された文字列型のいずれかの値、またはChoiceOfStringsタイプにDirectoryString値を比較するときに呼び出されます。選択された選択肢が異なる文字列型の二つDirectoryStringsを比較するときにそうであるように、比較は、対応する文字が両方の文字セットで表現される限り進みます。そうでない場合はfalseを返しにマッチします。
Early editions of X.520 [12] gave the syntax of the telephoneNumber attribute as a constrained PrintableString. The fourth edition of X.520 equates the ASN.1 type name TelephoneNumber to the constrained PrintableString and uses TelephoneNumber as the attribute and assertion syntax. For the purposes of component matching, telephoneNumberMatch and telephoneNumberSubstringsMatch are permitted to be applied to any PrintableString value, as well as to TelephoneNumber values.
[12] X.520の早期のエディションには制約はPrintableStringとしてtelephoneNumber属性の構文を与えました。 X.520の第四版は、制約はPrintableStringにASN.1タイプ名のTelephoneNumberを相当と属性と主張構文としてのTelephoneNumberを使用しています。成分マッチングの目的のために、telephoneNumberMatchとtelephoneNumberSubstringsMatchは任意PrintableStringの値に、並びにのTelephoneNumber値に適用することが許可されています。
The DistinguishedName type is defined by assignment to be the same as the RDNSequence type, however RDNSequence is sometimes directly used in other type definitions. For the purposes of component matching, distinguishedNameMatch is also permitted to be applied to values of the RDNSequence type.
識別名型しかしながらRDNSequence時には直接他のタイプの定義で使用され、RDNSequence型と同じになるように割り当てによって定義されます。成分マッチングの目的のために、distinguishedNameMatchもRDNSequence型の値に適用されることが許可されています。
This section defines additional matching rules that may prove useful in ComponentAssertions. These rules may also be used in extensibleMatch search filters [3].
このセクションでは、ComponentAssertionsにおいて有用であろう追加のマッチング規則を定義します。これらのルールは、extensibleMatch検索フィルタで使用することができる[3]。
The distinguishedNameMatch matching rule can match whole distinguished names but it is sometimes useful to be able to match specific Relative Distinguished Names (RDNs) in a Distinguished Name (DN) without regard for the other RDNs in the DN. The rdnMatch matching rule allows component RDNs of a DN to be tested.
distinguishedNameMatchマッチングルールは、全体識別名を一致させることができ、DN内の他のRDNに関係なく識別名（DN）内の特定の相対識別名（のRDN）と一致することができることが、時には有用です。 rdnMatchマッチングルールは、DNの構成要素のRDNを試験することを可能にします。
The LDAP-style definitions for rdnMatch and its assertion syntax are:
rdnMatchとそのアサーション構文については、LDAPスタイルの定義は以下のとおりです。
( 1.2.36.79672281.1.13.3 NAME 'rdnMatch' SYNTAX 1.2.36.79672281.1.5.0 )
（1.2.36.79672281.1.13.3 NAME 'rdnMatch' SYNTAX 1.2.36.79672281.1.5.0）
( 1.2.36.79672281.1.5.0 DESC 'RDN' )
（1.2.36.79672281.1.5.0 DESC "NDR"）
The LDAP-specific encoding for a value of the RDN syntax is given by the <RelativeDistinguishedNameValue> rule [9].
RDN構文の値のためのLDAP固有の符号化は、<RelativeDistinguishedNameValue>ルールによって与えられる[9]。
The X.500-style definition for rdnMatch is:
rdnMatchのためのX.500スタイルの定義は次のとおりです。
rdnMatch MATCHING-RULE ::= {
SYNTAX RelativeDistinguishedName
ID { 1 2 36 79672281 1 13 3 } }
The rdnMatch rule evaluates to true if the component value and assertion value are the same RDN, using the same RDN comparison method as distinguishedNameMatch.
成分値と主張値がdistinguishedNameMatch同じRDN比較法を用いて、同一のRDNである場合rdnMatch規則が真と評価します。
When using rdnMatch to match components of DNs it is important to note that the LDAP-specific encoding of a DN [5] reverses the order of the RDNs. So for the DN represented in LDAP as "cn=Steven Legg,o=Adacel,c=AU", the RDN "cn=Steven Legg" corresponds to the component reference "3", or alternatively, "-1".
DNの構成要素と一致するrdnMatchを使用する場合には、DNのLDAP固有の符号化[5]のRDNの順序を逆にすることを留意することが重要です。そうDNのための、代替的成分基準 "3" に対応し、又は "CN =スティーブンレッグ、O = Adacel、C = AU"、RDN "CN =スティーブンレッグ" としてLDAPで表される "-1"。
At times it would be useful to test not if a specific value of a particular component is present, but whether any value of a particular component is present. The presentMatch matching rule allows the presence of a particular component value to be tested.
特定の成分の特定の値が存在するが、特定の成分のいずれかの値が存在するかどうか場合の回ではないテストするのに有用であろう。 presentMatchマッチングルールは、特定の成分値の存在を試験することを可能にします。
The LDAP-style definitions for presentMatch and its assertion syntax are:
presentMatchとそのアサーション構文については、LDAPスタイルの定義は以下のとおりです。
( 1.2.36.79672281.1.13.5 NAME 'presentMatch' SYNTAX 1.2.36.79672281.1.5.1 )
（1.2.36.79672281.1.13.5 NAME 'presentMatch' SYNTAX 1.2.36.79672281.1.5.1）
( 1.2.36.79672281.1.5.1 DESC 'NULL' )
（1.2.36.79672281.1.5.1 DESC 'NULL'）
The LDAP-specific encoding for a value of the NULL syntax is given by the <NullValue> rule [9].
NULL構文の値のためのLDAP固有の符号化は、<NULLVALUE>ルールによって与えられる[9]。
The X.500-style definition for presentMatch is:
presentMatchのためのX.500スタイルの定義は次のとおりです。
presentMatch MATCHING-RULE ::= {
SYNTAX NULL
ID { 1 2 36 79672281 1 13 5 } }
When used in a extensible match filter item, presentMatch behaves like the "present" case of a regular search filter. In a ComponentAssertion, presentMatch evaluates to TRUE if and only if the component reference identifies one or more component values, regardless of the actual component value contents. Note that if useDefaultValues is TRUE then the identified component values may be (part of) a DEFAULT value.
拡張可能な一致フィルタ項目で使用される場合、presentMatchは通常の検索フィルタの「有」の場合のように振る舞います。 ComponentAssertionにおいて、presentMatchがTRUEと評価された場合、コンポーネントの参照は、1つまたは複数の成分値を識別した場合にのみ、関係なく、実際の成分値の内容の。 useDefaultValuesがTRUEであるならば、識別されたコンポーネントの値はデフォルト値（の一部）であってもよいことに留意されたいです。
The notional count referenced by the <count> form of ComponentId is taken to be present if the SET OF value is present, and absent otherwise. Note that in ASN.1 notation an absent SET OF value is distinctly different from a SET OF value that is present but empty. It is up to the specification using the ASN.1 notation to decide whether the distinction matters. Often an empty SET OF component and an absent SET OF component are treated as semantically equivalent. If a SET OF value is present, but empty, a presentMatch on the SET OF component SHALL return TRUE and the notional count SHALL be regarded as present and equal to zero.
COMPONENTIDの<数>の形で参照名目カウントは値のセットはそうでなければ存在し、存在しない場合に存在するとみなされます。 ASN.1表記で値不在SETが存在するが空である値のセットから明確に異なることに注意してください。それは区別が重要かどうかを決定するためにASN.1表記を使用して仕様次第です。多くの場合、コンポーネントとコンポーネントの不在セットの空のセットは、意味的に等価なものとして扱われます。値のセットが存在するが、空である場合、コンポーネントのセットにpresentMatchはTRUE返すと名目カウントが存在し、ゼロに等しいとみなします。
The following is a non-exhaustive list of useful matching rules and the ASN.1 types to which they can be applied, taking account of all the extensions described in Section 3.2.1, and the new matching rules defined in Section 3.2.2.
以下は、彼らは、セクション3.2.1、および3.2.2項で定義された新しいマッチングルールに記載されているすべての拡張を考慮して、適用可能な便利なマッチングルールとASN.1タイプの非網羅的なリストです。
+================================+==============================+
| Matching Rule | ASN.1 Type |
+================================+==============================+
| bitStringMatch | BIT STRING |
+--------------------------------+------------------------------+
| booleanMatch | BOOLEAN |
+--------------------------------+------------------------------+
| caseIgnoreMatch | NumericString |
| caseIgnoreOrderingMatch | PrintableString |
| caseIgnoreSubstringsMatch | VisibleString (ISO646String) |
| caseExactMatch | IA5String |
| caseExactOrderingMatch | UTF8String |
| caseExactSubstringsMatch | BMPString (UCS-2, UNICODE) |
| | UniversalString (UCS-4) |
| | TeletexString (T61String) |
| | VideotexString |
| | GraphicString |
| | GeneralString |
| | any ChoiceOfStrings type |
+--------------------------------+------------------------------+
| caseIgnoreIA5Match | IA5String |
| caseExactIA5Match | |
+--------------------------------+------------------------------+
| distinguishedNameMatch | DistinguishedName |
| | RDNSequence |
+--------------------------------+------------------------------+
| generalizedTimeMatch | GeneralizedTime |
| generalizedTimeOrderingMatch | |
+--------------------------------+------------------------------+
| integerMatch | INTEGER |
| integerOrderingMatch | |
+--------------------------------+------------------------------+
| numericStringMatch | NumericString |
| numericStringOrderingMatch | |
| numericStringSubstringsMatch | |
+--------------------------------+------------------------------+
| objectIdentifierMatch | OBJECT IDENTIFIER |
+--------------------------------+------------------------------+
| octetStringMatch | OCTET STRING |
| octetStringOrderingMatch | |
| octetStringSubstringsMatch | |
+--------------------------------+------------------------------+
| presentMatch | any ASN.1 type |
+--------------------------------+------------------------------+
| rdnMatch | RelativeDistinguishedName |
+--------------------------------+------------------------------+
| telephoneNumberMatch | PrintableString |
| telephoneNumberSubstringsMatch | TelephoneNumber |
+--------------------------------+------------------------------+
| uTCTimeMatch | UTCTime |
| uTCTimeOrderingMatch | |
+--------------------------------+------------------------------+
Note that the allComponentsMatch matching rule defined in Section 6.2 can be used for equality matching of values of the ENUMERATED, NULL, REAL and RELATIVE-OID ASN.1 types, among other things.
セクション6.2で定義されたallComponentsMatchマッチング規則は、とりわけ列挙、NULL、REALおよび相対OIDのASN.1タイプの値の等価マッチングのために使用することができることに留意されたいです。
The ComponentAssertion allows the value(s) of any one component type in a complex ASN.1 type to be matched, but there is often a desire to match the values of more than one component type. A ComponentFilter is an assertion about the presence, or values of, multiple components within an ASN.1 value.
ComponentAssertionは、複雑なASN.1タイプの任意の一成分型の値（S）が一致することを可能にするが、複数のコンポーネントタイプの値と一致する要望があることが多いです。 ComponentFilterは存在に関するアサーション、またはASN.1値内の複数の成分の値です。
The ComponentFilter assertion, an expression of ComponentAssertions, evaluates to either TRUE, FALSE or Undefined for each tested ASN.1 value.
ComponentFilterアサーション、ComponentAssertionsの発現は、試験した各ASN.1値に対して、TRUE FALSEまたは未定義のいずれかに評価されます。
A ComponentFilter is described by the following ASN.1 type (assumed to be defined with "EXPLICIT TAGS" in force):
ComponentFilterは、（力の「明示的タグ」と定義されると仮定）は、以下のASN.1タイプによって記述されます。
ComponentFilter ::= CHOICE {
item [0] ComponentAssertion,
and [1] SEQUENCE OF ComponentFilter,
or [2] SEQUENCE OF ComponentFilter,
not [3] ComponentFilter }
Note: despite the use of SEQUENCE OF instead of SET OF for the "and" and "or" alternatives in ComponentFilter, the order of the component filters is not significant.
注：代わりのシーケンスの使用ComponentFilter中「と」と「または」代替用のセットにもかかわらず、成分フィルタの順序は重要ではありません。
A ComponentFilter that is a ComponentAssertion evaluates to TRUE if the ComponentAssertion is TRUE, evaluates to FALSE if the ComponentAssertion is FALSE, and evaluates to Undefined otherwise.
ComponentAssertionあるComponentFilterはComponentAssertionがTRUEの場合、TRUEと評価ComponentAssertionがFALSEであればFALSEに評価され、そうでなければ不定に評価します。
The "and" of a sequence of component filters evaluates to TRUE if the sequence is empty or if each component filter evaluates to TRUE, evaluates to FALSE if at least one component filter is FALSE, and evaluates to Undefined otherwise.
「および」成分フィルタの配列の配列が空であるか、または各成分フィルタは、TRUEと評価された場合に少なくとも一つの成分フィルタはFALSEであり、そうでなければ未定義と評価された場合、FALSEに評価される。場合にTRUEと評価
The "or" of a sequence of component filters evaluates to FALSE if the sequence is empty or if each component filter evaluates to FALSE, evaluates to TRUE if at least one component filter is TRUE, and evaluates to Undefined otherwise.
配列が空であるか、または各成分フィルタがFALSEと評価された場合、少なくとも一つの成分フィルタがTRUEの場合にTRUEと評価され、そうでない場合は未定義と評価された場合に成分フィルタの配列がFALSEと評価「または」から。
The "not" of a component filter evaluates to TRUE if the component filter is FALSE, evaluates to FALSE if the component filter is TRUE, and evaluates to Undefined otherwise.
「ない」成分フィルタのコンポーネントフィルタがFALSEである場合、TRUEと評価成分フィルタがTRUEの場合にFALSEと評価し、そうでない場合は未定義と評価します。
The componentFilterMatch matching rule allows a ComponentFilter to be applied to an attribute value. The result of the matching rule is the result of applying the ComponentFilter to the attribute value.
componentFilterMatchマッチングルールはComponentFilter属性値に適用されることを可能にします。マッチングルールの結果は、属性値にComponentFilterを適用した結果です。
The LDAP-style definitions for componentFilterMatch and its assertion syntax are:
componentFilterMatchとそのアサーション構文については、LDAPスタイルの定義は以下のとおりです。
( 1.2.36.79672281.1.13.2 NAME 'componentFilterMatch' SYNTAX 1.2.36.79672281.1.5.2 )
（1.2.36.79672281.1.13.2 NAME 'componentFilterMatch' SYNTAX 1.2.36.79672281.1.5.2）
( 1.2.36.79672281.1.5.2 DESC 'ComponentFilter' )
（1.2.36.79672281.1.5.2 DESC 'ComponentFilter'）
The LDAP-specific encoding for the ComponentFilter assertion syntax is specified by GSER [9].
ComponentFilterアサーション構文のLDAP固有の符号化はGSER [9]によって指定されます。
As a convenience to implementors, an equivalent ABNF description of the GSER encoding for ComponentFilter is provided here. In the event that there is a discrepancy between this ABNF and the encoding determined by GSER, GSER is to be taken as definitive. The GSER encoding of a ComponentFilter is described by the following equivalent ABNF:
実装者への便宜として、ComponentFilter用GSERエンコードの等価ABNFの説明はここで提供されます。このABNFとGSERによって決定エンコーディング間に相違がある場合に、GSERは決定的として解釈されるべきです。 ComponentFilterのGSER符号化は、以下の等価ABNFによって記述されます。
ComponentFilter = filter-item / and-filter / or-filter / not-filter
ComponentFilter =フィルタ項目/及びフィルタ/またはフィルタ/しないフィルタ
filter-item = item-chosen ComponentAssertion and-filter = and-chosen SequenceOfComponentFilter or-filter = or-chosen SequenceOfComponentFilter not-filter = not-chosen ComponentFilter item-chosen = %x69.74.65.6D.3A ; "item:" and-chosen = %x61.6E.64.3A ; "and:" or-chosen = %x6F.72.3A ; "or:" not-chosen = %x6E.6F.74.3A ; "not:"
フィルタ項目=項目選択ComponentAssertion及びフィルタ=と、選択されたSequenceOfComponentFilter又はフィルタ=または、選択されたSequenceOfComponentFilterないフィルタ=未選択ComponentFilter項目選択=％のx69.74.65.6D.3A。 「項目：」と、選択され=％のx61.6E.64.3A。 「と」=％のx6F.72.3Aまたは、選択されました。 「又は」=％のx6E.6F.74.3Aを、選択されていません。 「ありません：」
SequenceOfComponentFilter = "{" [ sp ComponentFilter *( "," sp ComponentFilter) ] sp "}"
SequenceOfComponentFilter = "{" [SPのComponentFilter×（ "" SPのComponentFilter）] SP "}"
ComponentAssertion = "{" [ sp component "," ] [ sp useDefaultValues "," ] sp rule "," sp assertion-value sp "}" component = component-label msp StringValue useDefaultValues = use-defaults-label msp BooleanValue rule = rule-label msp ObjectIdentifierValue assertion-value = value-label msp Value
ComponentAssertion = "{" [SP成分 ""] [SPのuseDefaultValues ""] SPルール "" SPアサーション値SP "}" コンポーネント=コンポーネントラベルMSP STRINGVALUE useDefaultValues =利用デフォルトラベルMSPするBooleanValueルール=ルール・ラベルMSP ObjectIdentifierValueアサーション値=値ラベルのMSP値
component-label = %x63.6F.6D.70.6F.6E.65.6E.74 ; "component" use-defaults-label = %x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75 %x65.73 ; "useDefaultValues" rule-label = %x72.75.6C.65 ; "rule" value-label = %x76.61.6C.75.65 ; "value"
コンポーネント・ラベル=％x63.6F.6D.70.6F.6E.65.6E.74。 「成分」利用のデフォルト・ラベル=％x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75％x65.73。 「useDefaultValues」ルール・ラベル=％x72.75.6C.65。 「ルール」の値ラベル=％x76.61.6C.75.65。 "値"
sp = *%x20 ; zero, one or more space characters msp = 1*%x20 ; one or more space characters
SP = *％のX20;ゼロ、一つ以上の空白文字MSP = 1 *％のX20;一つ以上の空白文字
The ABNF for <Value>, <StringValue>, <ObjectIdentifierValue> and <BooleanValue> is defined by GSER [9].
以下のためのABNF <値>、<STRINGVALUE>、<ObjectIdentifierValue>と<するBooleanValue> GSERによって定義される[9]。
The ABNF descriptions of LDAP-specific encodings for attribute syntaxes typically do not clearly or consistently delineate the component parts of an attribute value. A regular and uniform character string encoding for arbitrary component data types is needed to encode the assertion value in a ComponentAssertion. The <Value> rule from GSER provides a human readable text encoding for a component value of any arbitrary ASN.1 type.
属性構文のためのLDAP固有のエンコーディングのABNFの記述は、一般的に明確にまたは一貫して、属性値の構成部品を描くません。任意成分データ型の規則的かつ均一な文字列エンコーディングはComponentAssertionにおけるアサーション値を符号化するために必要とされます。 GSERから<値>ルールは、任意のASN.1タイプの成分値のためのヒトが読み取り可能なテキストエンコーディングを提供します。
The X.500-style definition [10] for componentFilterMatch is:
componentFilterMatchのためのX.500形式の定義[10]は次のようになります。
componentFilterMatch MATCHING-RULE ::= {
SYNTAX ComponentFilter
ID { 1 2 36 79672281 1 13 2 } }
A ComponentAssertion can potentially use any matching rule, including componentFilterMatch, so componentFilterMatch may be nested. The component references in a nested componentFilterMatch are relative to the component corresponding to the containing ComponentAssertion. In Section 7, an example search on the seeAlso attribute shows this usage.
componentFilterMatchを入れ子にすることができるようComponentAssertionは、潜在的に、componentFilterMatchを含む、任意のマッチング規則を使用することができます。ネストされたcomponentFilterMatchコンポーネント参照は含有ComponentAssertionに対応する構成要素に対するものです。第7節では、seeAlsoの属性上の例の検索では、この使用方法を示しています。
It is possible to test if an attribute value of a complex ASN.1 syntax is the same as some purported (i.e., assertion) value by using a complicated ComponentFilter that tests if corresponding components are the same. However, it would be more convenient to be able to present a whole assertion value to a matching rule that could do the component-wise comparison of an attribute value with the assertion value for any arbitrary attribute syntax. Similarly, the ability to do a straightforward equality comparison of a component value that is itself of a complex ASN.1 type would also be convenient.
複雑なASN.1構文の属性値は、対応する構成要素は同じであるかどうかをテスト複雑ComponentFilterを用いて、いくつかの主張（すなわち、アサーション）値と同じであるかどうかをテストすることが可能です。しかし、任意の属性構文のためのアサーション値と属性値の成分ごとの比較を行うことができ、マッチングルールに全体の主張値を提示できるようにする方が便利だろう。同様に、複雑なASN.1タイプで、それ自体であるコンポーネント値の単純な等価比較を行う能力も便利です。
It would be difficult to define a single matching rule that simultaneously satisfies all notions of what the equality matching semantics should be. For example, in some instances a case sensitive comparison of string components may be preferable to a case insensitive comparison. Therefore a basic equality matching rule, allComponentsMatch, is defined in Section 6.2, and the means to derive new matching rules from it with slightly different equality matching semantics are described in Section 6.3.
同時に平等マッチングセマンティクスはどうあるべきかのすべての概念を満たす単一のマッチングルールを定義することは困難です。例えば、いくつかの例では、文字列要素の大文字と小文字を区別比較は大文字と小文字を区別しない比較することが好ましい場合があります。したがって、基本的な等価マッチングルール、allComponentsMatchは、セクション6.2で定義され、及びセマンティクスに一致わずかに異なる等価でそれから、新たなマッチング規則を導出する手段は、セクション6.3に記載されています。
The directoryComponentsMatch defined in Section 6.4 is a derivation of allComponentsMatch that suits typical uses of the directory. Other specifications are free to derive new rules from allComponentsMatch or directoryComponentsMatch, that suit their usage of the directory.
6.4節で定義されたdirectoryComponentsMatchは、ディレクトリの典型的な用途に合ったallComponentsMatchの導出です。その他の仕様は、ディレクトリのその使用に合わせallComponentsMatchかdirectoryComponentsMatchから新しいルールを導出するのは自由です。
The allComponentsMatch rule, the directoryComponentsMatch rule and any matching rules derived from them are collectively called component equality matching rules.
allComponentsMatchルール、directoryComponentsMatchルールおよびそれらに由来する任意のマッチング規則は、集合的にルールに一致する成分の平等と呼ばれます。
The component equality matching rules have a variable assertion syntax. In X.500 this is indicated by omitting the optional SYNTAX field in the MATCHING-RULE information object. The assertion syntax then defaults to the target attribute's syntax in actual usage, unless the description of the matching rule says otherwise. The SYNTAX field in the LDAP-specific encoding of a MatchingRuleDescription is mandatory, so the OpenAssertionType syntax is defined to fill the same role. That is, the OpenAssertionType syntax is semantically equivalent to an omitted SYNTAX field in an X.500 MATCHING-RULE information object. OpenAssertionType MUST NOT be used as the attribute syntax in an attribute type definition.
コンポーネント平等マッチングルールは、可変アサーション構文を持っています。 X.500では、これは、マッチングルール情報オブジェクト内の任意の構文フィールドを省略して示しています。実際の使用では、ターゲット属性の構文にアサーションの構文、デフォルト、マッチングルールの記述は、特に指定されていない限り。 OpenAssertionType構文が同じ役割を埋めるように定義されているので、MatchingRuleDescriptionのLDAP固有のエンコードでのSYNTAXフィールドは、必須です。すなわちOpenAssertionType構文はX.500マッチングルール情報オブジェクトに省略SYNTAXフィールドと意味的に同等です。 OpenAssertionTypeは、属性型定義における属性構文として使用してはいけません。
Unless explicitly varied by the description of a particular matching rule, if an OpenAssertionType assertion value appears in a ComponentAssertion its LDAP-specific encoding is described by the <Value> rule in GSER [9], otherwise its LDAP-specific encoding is the encoding defined for the syntax of the attribute type to which the matching rule with the OpenAssertionType assertion syntax is applied.
明示的に特定のマッチングルールの記述によって変化しない限り、OpenAssertionTypeアサーション値がComponentAssertionに表示される場合、そのLDAP固有の符号化はGSERで<値>ルールによって記述される[9]、そうでなければそのLDAP固有の符号化が定義されたエンコーディングされOpenAssertionTypeアサーションの構文と一致するルールが適用される属性タイプの構文について。
The LDAP definition for the OpenAssertionType syntax is:
OpenAssertionType構文のLDAP定義は次のとおりです。
( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' )
（1.2.36.79672281.1.5.3 DESC 'OpenAssertionType'）
The LDAP-style definition for allComponentsMatch is:
allComponentsMatchのためのLDAPスタイルの定義は次のとおりです。
( 1.2.36.79672281.1.13.6 NAME 'allComponentsMatch' SYNTAX 1.2.36.79672281.1.5.3 )
（1.2.36.79672281.1.13.6 NAME 'allComponentsMatch' SYNTAX 1.2.36.79672281.1.5.3）
The X.500-style definition for allComponentsMatch is:
allComponentsMatchのためのX.500スタイルの定義は次のとおりです。
allComponentsMatch MATCHING-RULE ::= {
ID { 1 2 36 79672281 1 13 6 } }
When allComponentsMatch is used in a ComponentAssertion the assertion syntax is the same as the ASN.1 type of the identified component. Otherwise, the assertion syntax of allComponentsMatch is the same as the attribute syntax of the attribute to which the matching rule is applied.
allComponentsMatchをComponentAssertionで使用される場合、アサーション構文は、識別されたコンポーネントのASN.1型と同じです。それ以外の場合は、allComponentsMatchのアサーション構文は、一致するルールが適用された属性の属性構文と同じです。
Broadly speaking, this matching rule evaluates to true if and only if corresponding components of the assertion value and the attribute or component value are the same.
大まかに言えば、このマッチングルールがあれば真と評価し、アサーション値及び属性又は成分値の対応する構成要素は同じである場合にのみ。
In detail, equality is determined by the following cases applied recursively.
具体的には、平等は、再帰的に適用され、以下の例により決定されます。
a) Two values of a SET or SEQUENCE type are the same if and only if, for each component type, the corresponding component values are either,
a）は、SETまたはSEQUENCE型の2つの値は、各コンポーネントタイプについて、対応するコンポーネントの値のいずれかであり、場合にのみ同一であり、
1) both absent,
1）両方とも存在しません、
2) both present and the same, or
2）本と同じ、またはその両方
3) absent or the same as the DEFAULT value for the component, if a DEFAULT value is defined.
デフォルト値が定義されている場合3）、存在しないか、またはコンポーネントのデフォルト値と同じ。
Values of an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER STRING, or INSTANCE OF type are compared according to their respective associated SEQUENCE type (see Section 3.1.2).
型埋め込みのPDV、EXTERNAL、無制限の文字列またはインスタンスの値は、それぞれの関連するシーケンスタイプ（セクション3.1.2参照）に従って比較されます。
b) Two values of a SEQUENCE OF type are the same if and only if, the values have the same number of (possibly duplicated) instances and corresponding instances are the same.
B）タイプのシーケンスの2つの値が同じである場合と、値が同じ数の（おそらく重複）インスタンスと対応するインスタンスが同じであるがある場合のみ。
c) Two values of a SET OF type are the same if and only if, the values have the same number of instances and each distinct instance occurs in both values the same number of times, i.e., both values have the same instances, including duplicates, but in any order.
C）タイプのセットの2つの値が同じである場合と、値はインスタンスの同じ数を有し、それぞれ異なるインスタンスは、両方の値で重複を含む同じ回数、すなわち、両方の値を持っている同じインスタンスを発生した場合にのみしかし、いずれのためです。
d) Two values of a CHOICE type are the same if and only if, both values are of the same chosen alternative and the component values are the same.
D）CHOICE型の2つの値は、場合にのみ同じであり、両方の値が同一の選択された代替のものであり、部品の値は同じです。
e) Two BIT STRING values are the same if and only if the values have the same number of bits and corresponding bits are the same. If the BIT STRING type is defined with a named bit list then trailing zero bits in the values are treated as absent for the purposes of this comparison.
E）2つのビット文字列値が同じである場合、値は同じビット数を有し、対応するビットが同じである場合のみ。ビット列タイプは、値ゼロのビットの後続ビット名前リストで定義されている場合、この比較の目的のために存在しないものとして扱われます。
f) Two BOOLEAN values are the same if and only if both are TRUE or both are FALSE.
F）2つのブール値が同じである場合との両方がTRUEであるか、またはその両方が偽である場合にのみ。
g) Two values of a string type are the same if and only if the values have the same number of characters and corresponding characters are the same. Letter case is significant. For the purposes of allComponentsMatch, the string types are NumericString, PrintableString, TeletexString (T61String), VideotexString, IA5String, GraphicString, VisibleString (ISO646String), GeneralString, UniversalString, BMPString, UTF8String, GeneralizedTime, UTCTime and ObjectDescriptor.
G）は、文字列型の2つの値が同じである場合、値は文字の数が同じで、対応する文字が同じである場合のみ。レターケースが重要です。 allComponentsMatchの目的のために、文字列型はNumericString、はPrintableString、TeletexString（T61String）、VideotexString、IA5String、GraphicString、VisibleString（ISO646String）、GeneralString、UniversalString、BMPString、UTF8Stringを、GeneralizedTimeの、UTC時刻とのObjectDescriptorあります。
h) Two INTEGER values are the same if and only if the integers are equal.
h）の2つの整数値は、整数が等しい場合にのみ同じです。
i) Two ENUMERATED values are the same if and only if the enumeration item identifiers are the same (equivalently, if the integer values associated with the identifiers are equal).
I）2列挙された値があれば同じであり、識別子に関連付けられた整数値が等しい場合列挙アイテム識別子は、等価的に（同一である場合のみ）。
j) Two NULL values are always the same, unconditionally.
j）の二つのNULL値は無条件に、常に同じです。
k) Two OBJECT IDENTIFIER values are the same if and only if the values have the same number of arcs and corresponding arcs are the same.
k）は2つのオブジェクト識別子の値が同じである場合、値は円弧の同じ数を有し、対応する円弧が同じである場合のみ。
l) Two OCTET STRING values are the same if and only if the values have the same number of octets and corresponding octets are the same.
L）2つのオクテットストリング値が同じである場合、値はオクテットの数が同じで、対応するオクテットが同じである場合のみ。
m) Two REAL values are the same if and only if they are both the same special value, or neither is a special value and they have the same base and represent the same real number. The special values for REAL are zero, PLUS-INFINITY and MINUS-INFINITY.
それらはいずれも同じ特別な値、またはその両方である場合にのみ特別な値である場合、M）2つのREAL値が同じであり、それらは同じベースを持ち、同一の実数を表します。 REALのための特別な値は、PLUS-INFINITYとMINUS-INFINITYゼロです。
n) Two RELATIVE-OID values are the same if and only if the values have the same number of arcs and corresponding arcs are the same. The respective starting nodes for the RELATIVE-OID values are disregarded in the comparison, i.e., they are assumed to be the same.
n）は2つの相対-OID値が同じである場合、値は円弧の同じ数を有し、対応する円弧が同じである場合のみ。相対OID値についてそれぞれの始点ノードは、比較において無視され、すなわち、それらは同じであると仮定されます。
o) Two values of an open type are the same if and only if both are of the same ASN.1 type and are the same according to that type. If the actual ASN.1 type of the values is unknown then the allComponentsMatch rule evaluates to Undefined.
）Oオープンタイプの2つの値が同じである場合との両方が同じASN.1タイプのものであり、その種類に応じて、同じである場合にのみ。値の実際のASN.1タイプが不明な場合は、allComponentsMatchルールは未定義と評価されます。
Tags and constraints, being part of the type definition and not part of the abstract values, are ignored for matching purposes.
タグと制約は、型定義ではなく、抽象値の一部の一部である、目的に合致するために無視されます。
The allComponentsMatch rule may be used as the defined equality matching rule for an attribute.
allComponentsMatchルールは、属性の定義された等価マッチングルールとして使用することができます。
A new component equality matching rule with more refined matching semantics may be derived from allComponentsMatch, or any other component equality matching rule, using the convention described in this section.
より洗練されたマッチング・セマンティクスを使用して新しいコンポーネント等価マッチングルールがallComponentsMatchから誘導することができる、または他の任意の成分の平等は、このセクションで説明する規則を使用して、ルールに一致します。
The matching behaviour of a derived component equality matching rule is specified by nominating, for each of one or more identified components, a commutative equality matching rule that will be used to match values of that component. This overrides the matching that would otherwise occur for values of that component using the base rule for the derivation. These overrides can be conveniently represented as rows in a table of the following form.
派生コンポーネント平等マッチングルールのマッチング動作は一つ以上の同定された成分、その成分の値を一致させるために使用される可換平等マッチングルールのそれぞれについて、指名によって指定されます。これは、そうでなければ導出するための基本ルールを使用してその成分の値について生じるマッチングを上書き。これらのオーバーライドは便利な次の形式のテーブルの行として表現することができます。
Component | Matching Rule
============+===============
|
|
Usually, all component values of a particular ASN.1 type are to be matched the same way. An ASN.1 type reference (e.g., DistinguishedName) or an ASN.1 built-in type name (e.g., INTEGER) in the Component column of the table specifies that the nominated equality matching rule is to be applied to all values of the named type, regardless of context.
通常、特定のASN.1タイプのすべてのコンポーネントの値が同じように一致されるべきです。 ASN.1タイプの参照（例えば、識別名）、または内蔵型の名前（例えば、INTEGER）表のコンポーネントの列にASN.1はノミネート平等マッチングルールは、名前付きのすべての値に適用することを指定種類に関係なく、コンテキストの。
An ASN.1 type reference with a component reference appended (separated by a ".") specifies that the nominated matching rule applies only to the identified components of values of the named type. Other component values that happen to be of the same ASN.1 type are not selected.
（「」で区切られた）付加成分参照してASN.1型参照は指名マッチングルールのみ名前タイプの値の識別されたコンポーネントに適用されることを指定します。同じASN.1型に起こる他の成分の値が選択されていません。
Additional type substitutions as described in Section 3.2 are assumed to be performed to align the component type with the matching rule assertion syntax.
付加的なタイプの置換セクション3.2で説明したように、マッチングルールアサーション構文を使用してコンポーネントタイプを整列させるために行われるものとします。
Conceptually, the rows in a table for the base rule are appended to the rows in the table for a derived rule for the purpose of deciding the matching semantics of the derived rule. Notionally, allComponentsMatch has an empty table.
概念的に、ベースルールのテーブルの行を導出ルールのマッチングセマンティクスを決定するために派生ルールのテーブル内の行に追加されています。概念的に、allComponentsMatchは、空のテーブルを持っています。
A row specifying values of an outer containing type (e.g., DistinguishedName) takes precedence over a row specifying values of an inner component type (e.g., RelativeDistinguishedName), regardless of their order in the table. Specifying a row for component values of an inner type is only useful if a value of the type can also appear on its own, or as a component of values of a different outer type. For example, if there is a row for DistinguishedName then a row for RelativeDistinguishedName can only ever apply to RelativeDistinguishedName component values that are not part of a DistinguishedName. A row for values of an outer type in the table for the base rule takes precedence over a row for values of an inner type in the table for the derived rule.
アウター含むタイプの値を指定する行が（例えば、識別名）は、テーブル内の順序にかかわらず、内部部品の種類（例えば、RelativeDistinguishedName）の値を指定する行よりも優先されます。タイプの値は、それ自身の上に表示され、又は異なる外型の値の成分としてできればインナータイプのコンポーネントの値の行を指定するのみ有用です。識別名の行は、次に、存在する場合、例えば、RelativeDistinguishedNameの行はしか識別名の一部ではないRelativeDistinguishedName成分値に適用することができます。ベースルールのテーブルにおける外型の値の行は、派生ルールの表にインナータイプの値の行よりも優先されます。
Where more than one row applies to a particular component value the earlier row takes precedence over the later row. Thus rows in the table for the derived rule take precedence over any rows for the same component in the table for the base rule.
複数の行は、特定の成分値に適用される場合、以前の行が後行よりも優先されます。したがって派生ルールの表の行は、基本ルールのテーブルで同じコンポーネントの任意の行に優先します。
The directoryComponentsMatch matching rule is derived from the allComponentsMatch matching rule.
directoryComponentsMatchマッチングルールはallComponentsMatchマッチングルールに由来します。
The LDAP-style definition for directoryComponentsMatch is:
directoryComponentsMatchのためのLDAPスタイルの定義は次のとおりです。
( 1.2.36.79672281.1.13.7 NAME 'directoryComponentsMatch' SYNTAX 1.2.36.79672281.1.5.3 )
（1.2.36.79672281.1.13.7 NAME 'directoryComponentsMatch' SYNTAX 1.2.36.79672281.1.5.3）
The X.500-style definition for directoryComponentsMatch is:
directoryComponentsMatchのためのX.500スタイルの定義は次のとおりです。
directoryComponentsMatch MATCHING-RULE ::= {
ID { 1 2 36 79672281 1 13 7 } }
The matching semantics of directoryComponentsMatch are described by the following table, using the convention described in Section 6.3.
directoryComponentsMatchのマッチングセマンティクスはセクション6.3に記載規則を使用して、以下の表に記載されています。
ASN.1 Type | Matching Rule
=========================================+========================
RDNSequence | distinguishedNameMatch
RelativeDistinguishedName | rdnMatch
TelephoneNumber | telephoneNumberMatch
FacsimileTelephoneNumber.telephoneNumber | telephoneNumberMatch
NumericString | numericStringMatch
GeneralizedTime | generalizedTimeMatch
UTCTime | uTCTimeMatch
DirectoryString{} | caseIgnoreMatch
BMPString | caseIgnoreMatch
GeneralString | caseIgnoreMatch
GraphicString | caseIgnoreMatch
IA5String | caseIgnoreMatch
PrintableString | caseIgnoreMatch
TeletexString | caseIgnoreMatch
UniversalString | caseIgnoreMatch
UTF8String | caseIgnoreMatch
VideotexString | caseIgnoreMatch
VisibleString | caseIgnoreMatch
Notes:
ノート：
1) The DistinguishedName type is defined by assignment to be the same as the RDNSequence type. Some types (e.g., Name and LocalName) directly reference RDNSequence rather than DistinguishedName. Specifying RDNSequence captures all these DN-like types.
1）識別名タイプはRDNSequence型と同じになるように割り当てによって定義されます。いくつかのタイプ（例えば、名前プロパティおよびlocalName）を直接RDNSequenceなく識別名を参照します。 RDNSequenceを指定すると、これらすべてのDN-のようなタイプをキャプチャします。
2) A RelativeDistinguishedName value is only matched by rdnMatch if it is not part of an RDNSequence value.
それはRDNSequence値の一部でない場合2）RelativeDistinguishedName値のみrdnMatchによって整合されます。
3) The telephone number component of the FacsimileTelephoneNumber ASN.1 type [12] is defined as a constrained PrintableString. PrintableString component values that are part of a FacsimileTelephoneNumber value can be identified separately from other components of PrintableString type by the specifier FacsimileTelephoneNumber.telephoneNumber, so that telephoneNumberMatch can be selectively applied. The fourth edition of X.520 defines the telephoneNumber component of FacsimileTelephoneNumber to be of the type TelephoneNumber, making the row for FacsimileTelephoneNumber.telephoneNumber components redundant.
3）FacsimileTelephoneNumber ASN.1タイプ[12]の電話番号の構成要素は、制約はPrintableStringとして定義されます。 telephoneNumberMatchを選択的に適用することができるようにFacsimileTelephoneNumber値の一部であるのprintablestring成分値は、指定子FacsimileTelephoneNumber.telephoneNumberによってはPrintableStringタイプの他の成分から別々に識別することができます。 X.520第4版は、冗長FacsimileTelephoneNumber.telephoneNumberコンポーネントの列を作る、型のTelephoneNumberであることがFacsimileTelephoneNumberののTelephoneNumberコンポーネントを定義しています。
The directoryComponentsMatch rule may be used as the defined equality matching rule for an attribute.
directoryComponentsMatchルールは、属性の定義された等価マッチングルールとして使用することができます。
This section contains examples of search filters using the componentFilterMatch matching rule. The filters are described using the string representation of LDAP search filters [18]. Note that this representation requires asterisks to be escaped in assertion values (in these examples the assertion values are all <ComponentAssertion> encodings). The asterisks have not been escaped in these examples for the sake of clarity, and to avoid confusing the protocol representation of LDAP search filter assertion values, where such escaping does not apply. Line breaks and indenting have been added only as an aid to readability.
このセクションでは、componentFilterMatchマッチングルールを使用して、検索フィルタの例が含まれています。フィルタは、LDAP検索フィルタの文字列表現[18]を用いて記述されています。この表現は、（これらの例ではアサーションの値はすべて<ComponentAssertion>エンコーディングである）アサーション値にエスケープするアスタリスクを必要とすることに留意されたいです。アスタリスクは、明瞭にするためにこれらの例ではエスケープされていない、そして、そのようなエスケープは適用されませんLDAP検索フィルターアサーション値のプロトコル表現を、混乱を避けるために。改行やインデントは読みやすさへの援助として追加されました。
The example search filters using componentFilterMatch are all single extensible match filter items, though there is no reason why componentFilterMatch can't be used in more complicated search filters.
componentFilterMatchは、より複雑な検索フィルタで使用することができない理由がないのにcomponentFilterMatchを使用した例検索フィルタは、すべて単一拡張可能な一致フィルタ項目です。
The first examples describe searches over the objectClasses schema operational attribute, which has an attribute syntax described by the ASN.1 type ObjectClassDescription [10], and holds the definitions of the object classes known to a directory server. The definition of ObjectClassDescription is as follows:
最初の例は、ASN.1型ObjectClassDescription [10]によって記述される属性構文を持ち、ディレクトリサーバに知られているオブジェクトクラスの定義を保持するのobjectClassesスキーマオペレーショナル属性、上検索を記述する。次のようにObjectClassDescriptionの定義は次のとおりです。
ObjectClassDescription ::= SEQUENCE {
identifier OBJECT-CLASS.&id,
name SET OF DirectoryString {ub-schema} OPTIONAL,
description DirectoryString {ub-schema} OPTIONAL,
obsolete BOOLEAN DEFAULT FALSE,
information [0] ObjectClassInformation }
ObjectClassInformation ::= SEQUENCE {
subclassOf SET OF OBJECT-CLASS.&id OPTIONAL,
kind ObjectClassKind DEFAULT structural,
mandatories [3] SET OF ATTRIBUTE.&id OPTIONAL,
optionals [4] SET OF ATTRIBUTE.&id OPTIONAL }
ObjectClassKind ::= ENUMERATED {
abstract (0),
structural (1),
auxiliary (2) }
OBJECT-CLASS.&id and ATTRIBUTE.&id are equivalent to the OBJECT IDENTIFIER ASN.1 type. A value of OBJECT-CLASS.&id is an OBJECT IDENTIFIER for an object class. A value of ATTRIBUTE.&id is an OBJECT IDENTIFIER for an attribute type.
OBJECT-CLASS。＆IDとATTRIBUTE。＆IDは、オブジェクト識別子ASN.1型と同等です。 OBJECT-CLASS。＆IDの値は、オブジェクト・クラスのオブジェクト識別子です。 ATTRIBUTE。＆IDの値は、属性タイプのオブジェクト識別子です。
The following search filter finds the object class definition for the object class identified by the OBJECT IDENTIFIER 2.5.6.18:
次の検索フィルタは、オブジェクト識別子2.5.6.18で識別されるオブジェクトクラスのオブジェクトクラス定義を検索します。
(objectClasses:componentFilterMatch:= item:{ component "identifier", rule objectIdentifierMatch, value 2.5.6.18 })
（のobjectClasses：componentFilterMatch：=項目：{コンポーネント "識別子"、objectIdentifierMatchルール、値2.5.6.18}）
A match on the "identifier" component of objectClasses values is equivalent to the objectIdentifierFirstComponentMatch matching rule applied to attribute values of the objectClasses attribute type. The componentFilterMatch matching rule subsumes the functionality of the objectIdentifierFirstComponentMatch, integerFirstComponentMatch and directoryStringFirstComponentMatch matching rules.
objectClasses値の「識別子」コンポーネント上の一致はobjectIdentifierFirstComponentMatchマッチングルールに相当するが、のobjectClassesの値は、タイプ属性の属性に適用されます。 componentFilterMatchマッチングルールはobjectIdentifierFirstComponentMatch、integerFirstComponentMatchとdirectoryStringFirstComponentMatchマッチングルールの機能を包含する。
The following search filter finds the object class definition for the object class called foobar:
次の検索フィルタがfoobarに呼ばれるオブジェクトクラスのオブジェクトクラス定義を検索します。
(objectClasses:componentFilterMatch:= item:{ component "name.*", rule caseIgnoreMatch, value "foobar" })
（のobjectClasses：componentFilterMatch：=項目：{コンポーネント "名*"、caseIgnoreMatchルール、値 "foobarに"}）
An object class definition can have multiple names and the above filter will match an objectClasses value if any one of the names is "foobar".
オブジェクトクラス定義は、複数の名前を持つことができ、名前のいずれかが「foobarに」である場合は、上記のフィルタは、のobjectClasses値と一致します。
The component reference "name.0" identifies the notional count of the number of names in an object class definition. The following search filter finds object class definitions with exactly one name:
成分基準「name.0は、」オブジェクト・クラス定義内の名前の数の想定数を識別する。次の検索フィルタは、厳密に1つの名前を持つオブジェクトのクラス定義を検索します。
(objectClasses:componentFilterMatch:= item:{ component "name.0", rule integerMatch, value 1 })
（のobjectClasses：componentFilterMatch：=項目：{成分 "name.0"、integerMatchルール、値1}）
The "description" component of an ObjectClassDescription is defined to be an OPTIONAL DirectoryString. The following search filter finds object class definitions that have descriptions, regardless of the contents of the description string:
ObjectClassDescriptionの「説明」の成分は、任意のDirectoryStringであると定義されます。次の検索フィルターは関係なく、説明文字列の内容の、記述を持つオブジェクトのクラス定義を検索します。
(objectClasses:componentFilterMatch:= item:{ component "description", rule presentMatch, value NULL })
（のobjectClasses：componentFilterMatch：=項目：{コンポーネント "説明"、presentMatchルール、値NULL}）
The presentMatch returns TRUE if the description component is present and FALSE otherwise.
記述コンポーネントは、さもなければ存在し、FALSEであればpresentMatchはTRUEを返し。
The following search filter finds object class definitions that don't have descriptions:
次の検索フィルタが説明を持たないオブジェクトのクラス定義を検索します。
(objectClasses:componentFilterMatch:= not:item:{ component "description", rule presentMatch, value NULL })
（のobjectClasses：componentFilterMatch：=ではない：アイテム：{コンポーネント "説明"、presentMatchルール、値NULL}）
The following search filter finds object class definitions with the word "bogus" in the description:
次の検索フィルタは、説明中の単語「偽」でオブジェクトのクラス定義を検索します。
(objectClasses:componentFilterMatch:= item:{ component "description", rule caseIgnoreSubstringsMatch, value { any:"bogus" } })
（のobjectClasses：componentFilterMatch：=項目：{コンポーネント "説明"、caseIgnoreSubstringsMatchルール、値{いずれか： "偽"}}）
The assertion value is of the SubstringAssertion syntax, i.e.,
アサーション値、すなわち、SubstringAssertion構文であります
SubstringAssertion ::= SEQUENCE OF CHOICE {
initial [0] DirectoryString {ub-match},
any [1] DirectoryString {ub-match},
final [2] DirectoryString {ub-match} }
The "obsolete" component of an ObjectClassDescription is defined to be DEFAULT FALSE. An object class is obsolete if the "obsolete" component is present and set to TRUE. The following search filter finds all obsolete object classes:
ObjectClassDescriptionの「廃止」コンポーネントはデフォルトFALSEであると定義されます。 「廃止」成分が存在し、Trueに設定されている場合、オブジェクトクラスは廃止されました。次の検索フィルタが廃止されたすべてのオブジェクトクラスを検索します。
(objectClasses:componentFilterMatch:= item:{ component "obsolete", rule booleanMatch, value TRUE })
（のobjectClasses：componentFilterMatch：=項目：{コンポーネント "廃止"、booleanMatchルール、値TRUE}）
An object class is not obsolete if the "obsolete" component is not present, in which case it defaults to FALSE, or is present but is explicitly set to FALSE. The following search filter finds all non-obsolete object classes:
「廃止」成分はFALSEに、それがデフォルトその場合には、存在しない、または存在するが、明示的にFALSEに設定されている場合、オブジェクトクラスは時代遅れではありません。次の検索フィルタは、すべての非時代遅れのオブジェクトクラスを検索します。
(objectClasses:componentFilterMatch:= item:{ component "obsolete", rule booleanMatch, value FALSE })
（のobjectClasses：componentFilterMatch：=項目：{コンポーネント "廃止"、booleanMatch、値FALSEを支配}）
The useDefaultValues flag in the ComponentAssertion defaults to TRUE so the componentFilterMatch rule treats an absent "obsolete" component as being present and set to FALSE. The following search filter finds only object class definitions where the "obsolete" component has been explicitly set to FALSE, rather than implicitly defaulting to FALSE:
TRUEにComponentAssertionデフォルトでuseDefaultValuesフラグcomponentFilterMatchルールが存在し、FALSEに設定されているとして存在しない「廃止」コンポーネントを扱うように。次の検索フィルタは「時代遅れ」コンポーネントを明示的にFALSEに設定されている唯一のオブジェクトクラス定義を見つけるのではなく、暗黙的にFALSEをデフォルト：
(objectClasses:componentFilterMatch:= item:{ component "obsolete", useDefaultValues FALSE, rule booleanMatch, value FALSE })
（のobjectClasses：componentFilterMatch：=項目：{ルール、useDefaultValues FALSE、成分 "廃止" booleanMatch、値FALSE}）
With the useDefaultValues flag set to FALSE, if the "obsolete" component is absent the component reference identifies no component value and the matching rule will return FALSE. The matching rule can only return TRUE if the component is present and set to FALSE.
「廃止」成分が存在しない場合はFALSEに設定useDefaultValuesフラグと、コンポーネントの参照には成分値を特定せず、マッチングルールはFALSEを返します。成分が存在し、Falseに設定されている場合、一致するルールは、TRUEを返すことができます。
The "information.kind" component of the ObjectClassDescription is an ENUMERATED type. The allComponentsMatch matching rule can be used to match values of an ENUMERATED type. The following search filter finds object class definitions for auxiliary object classes:
ObjectClassDescriptionの「information.kind」成分は、列挙型です。 allComponentsMatchマッチングルールは、列挙型の値を一致させるために使用することができます。次の検索フィルタは、補助オブジェクトクラスのオブジェクトクラス定義を検索します。
(objectClasses:componentFilterMatch:= item:{ component "information.kind", rule allComponentsMatch, value auxiliary })
（のobjectClasses：componentFilterMatch：=項目：{成分 "information.kind"、allComponentsMatchルール、値補助}）
The following search filter finds auxiliary object classes with commonName (cn or 2.5.4.3) as a mandatory attribute:
次の検索フィルタは必須属性としてのcommonName（CNまたは2.5.4.3）と補助オブジェクト・クラスを検索します。
(objectClasses:componentFilterMatch:=and:{ item:{ component "information.kind", rule allComponentsMatch, value auxiliary }, item:{ component "information.mandatories.*", rule objectIdentifierMatch, value cn } })
（のobjectClasses：componentFilterMatch：=と：{アイテム：{成分 "information.kind"、allComponentsMatchルール、値補助}、項目： "information.mandatories *" {コンポーネント、objectIdentifierMatchルール、値CN}}）
The following search filter finds auxiliary object classes with commonName as a mandatory or optional attribute:
次の検索フィルタが必須またはオプションの属性としてcommonNameを持つ補助オブジェクトクラスを検索します。
(objectClasses:componentFilterMatch:=and:{ item:{ component "information.kind", rule allComponentsMatch, value auxiliary }, or:{ item:{ component "information.mandatories.*", rule objectIdentifierMatch, value cn }, item:{ component "information.optionals.*", rule objectIdentifierMatch, value cn } } })
（のobjectClasses：componentFilterMatch：=と：{アイテム：{成分 "information.kind"、allComponentsMatchルール、値補助}、または{アイテム：{コンポーネント "information.mandatories *"、objectIdentifierMatchルール、値} CN、項目： {コンポーネント "information.optionals。*"、objectIdentifierMatchルール、値CN}}}）
Extra care is required when matching optional SEQUENCE OF or SET OF components because of the distinction between an absent list of instances and a present, but empty, list of instances. The following search filter finds object class definitions with less than three names, including object class definitions with a present but empty list of names, but does not find object class definitions with an absent list of names:
特別な注意が原因インスタンスの不在リストと現在との間の区別の任意のシーケンス又はコンポーネントのセットを照合する際に必要な、しかしインスタンスの空のリストです。次の検索フィルタは、名前の存在が、空のリストを持つオブジェクトクラス定義を含む、以下の3つの名前を持つオブジェクトのクラス定義を見つけたが、名前の不在リストでオブジェクトクラス定義を見つけることができません。
(objectClasses:componentFilterMatch:= item:{ component "name.0", rule integerOrderingMatch, value 3 })
（のobjectClasses：componentFilterMatch：=項目：{成分 "name.0"、integerOrderingMatchルール、値3}）
If the "name" component is absent the "name.0" component is also considered to be absent and the ComponentAssertion evaluates to FALSE. If the "name" component is present, but empty, the "name.0" component is also present and equal to zero, so the ComponentAssertion evaluates to TRUE. To also find the object class definitions with an absent list of names the following search filter would be used:
「名前」コンポーネントが存在しない場合は、「name.0」の成分も存在しないとみなされ、ComponentAssertionはFALSEと評価されます。 「名前」の成分が存在するが、空である場合、「name.0」成分もまた存在し、ゼロに等しいので、ComponentAssertionはTRUEと評価されます。また、次の検索フィルタが使用される名前の不在のリストを持つオブジェクトのクラス定義を検索するには：
(objectClasses:componentFilterMatch:=or:{ not:item:{ component "name", rule presentMatch, value NULL }, item:{ component "name.0", rule integerOrderingMatch, value 3 } })
（のobjectClasses：componentFilterMatch：=や：{ない：アイテム：{コンポーネント "名前"、presentMatchルール、値NULL}項目{成分 "name.0"、integerOrderingMatchルール、値3}}）
Distinguished names embedded in other syntaxes can be matched with a componentFilterMatch. The uniqueMember attribute type has an attribute syntax described by the ASN.1 type NameAndOptionalUID.
他の構文に埋め込まれた識別名はcomponentFilterMatchと一致させることができます。 uniqueMember属性タイプは、ASN.1タイプNameAndOptionalUIDによって記述される属性の構文を持っています。
NameAndOptionalUID ::= SEQUENCE {
dn DistinguishedName,
uid UniqueIdentifier OPTIONAL }
The following search filter finds values of the uniqueMember attribute containing the author's DN:
次の検索フィルタは、著者のDNを含むuniqueMember属性の値を検索します。
(uniqueMember:componentFilterMatch:= item:{ component "dn", rule distinguishedNameMatch, value "cn=Steven Legg,o=Adacel,c=AU" })
（のuniqueMember：componentFilterMatch：=項目：{コンポーネント "DN"、distinguishedNameMatchルール、値 "CN =スティーブンレッグ、O = Adacel、C = AU"}）
The DistinguishedName and RelativeDistinguishedName ASN.1 types are also complex ASN.1 types so the component matching rules can be applied to their inner components.
ルールに一致する成分は、それらの内部部品に適用することができるように、識別名とRelativeDistinguishedName ASN.1タイプは、複雑なASN.1タイプです。
DistinguishedName ::= RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType ({SupportedAttributes}),
value AttributeValue ({SupportedAttributes}{@type}) }
AttributeType ::= ATTRIBUTE.&id
AttributeValue ::= ATTRIBUTE.&Type
ATTRIBUTE.&Type is an open type. A value of ATTRIBUTE.&Type is constrained by the type component of AttributeTypeAndValue to be of the attribute syntax of the nominated attribute type. Note: the fourth edition of X.500 extends and renames the AttributeTypeAndValue SEQUENCE type.
ATTRIBUTE。＆タイプオープンタイプです。 ATTRIBUTE。＆型の値が指名属性タイプの属性構文であることがAttributeTypeAndValueのタイプのコンポーネントによって制約されます。注意：X.500の第四版が延びており、AttributeTypeAndValueのSEQUENCEタイプの名前を変更します。
The seeAlso attribute has the DistinguishedName syntax. The following search filter finds seeAlso attribute values containing the RDN, "o=Adacel", anywhere in the DN:
seeAlsoの属性は、識別名の構文を持っています。次の検索フィルタが見つかっseeAlsoのRDN、「O = Adacel」を含む属性値を、どこでもDNに：
(seeAlso:componentFilterMatch:= item:{ component "*", rule rdnMatch, value "o=Adacel" })
（seeAlsoの：componentFilterMatch：=項目：{コンポーネント "*"、rdnMatchルール、値 "O = Adacel"}）
The following search filter finds all seeAlso attribute values with "cn=Steven Legg" as the RDN of the named entry (i.e., the "first" RDN in an LDAPDN or the "last" RDN in an X.500 DN):
次の検索フィルタは「CN =スティーブンレッグ」で全てseeAlsoの属性値を見つけると名付けられたエントリのRDN（すなわち、LDAPDNまたはX.500 DNで「最後」RDNにおける「第1の」RDN）。
(seeAlso:componentFilterMatch:= item:{ component "-1", rule rdnMatch, value "cn=Steven Legg" })
（seeAlsoの：componentFilterMatch：=項目：{コンポーネント "-1"、rdnMatchルール、値 "CN =スティーブンレッグ"}）
The following search filter finds all seeAlso attribute values naming entries in the DIT subtree of "o=Adacel,c=AU":
次の検索フィルタは、「O = Adacel、C = AU」のDITサブツリー内のエントリに名前を付け、すべてのseeAlsoの属性値を検索します。
(seeAlso:componentFilterMatch:=and:{ item:{ component "1", rule rdnMatch, value "c=AU" }, item:{ component "2", rule rdnMatch, value "o=Adacel" } })
（seeAlsoの：componentFilterMatch：=と：{アイテム：{コンポーネント "1"、rdnMatchルール、値 "C = AU"}、項目：{コンポーネント "2"、rdnMatchルール、値 "O = Adacel"}}）
The following search filter finds all seeAlso attribute values containing the naming attribute types commonName (cn) and telephoneNumber in the same RDN:
次の検索フィルタが命名を含むすべてのseeAlsoの属性値が同じRDNに種類のcommonName（CN）とtelephoneNumberの属性検索します。
(seeAlso:componentFilterMatch:= item:{ component "*", rule componentFilterMatch, value and:{ item:{ component "*.type", rule objectIdentifierMatch, value cn }, item:{ component "*.type", rule objectIdentifierMatch, value telephoneNumber } } })
（seeAlsoの：componentFilterMatch：=項目：{コンポーネント "*"、componentFilterMatchルール、値：{アイテム：{コンポーネント "* .TYPE"、objectIdentifierMatchルール、値CN}項目{コンポーネント "* .TYPE" は、objectIdentifierMatchを支配、値telephoneNumberの}}}）
The following search filter would find all seeAlso attribute values containing the attribute types commonName and telephoneNumber, but not necessarily in the same RDN:
次の検索フィルタは、属性タイプのcommonNameとtelephoneNumberのを含むすべてのseeAlsoの属性値を見つけることが、必ずしもそうではない、同じRDN内になります。
(seeAlso:componentFilterMatch:=and:{ item:{ component "*.*.type", rule objectIdentifierMatch, value cn }, item:{ component "*.*.type", rule objectIdentifierMatch, value telephoneNumber } })
（seeAlsoの：componentFilterMatch：=と：{アイテム：{コンポーネント "*タイプ。"、objectIdentifierMatchルール、値CN}項目{コンポーネント "*。*タイプ"、objectIdentifierMatchルール、値telephoneNumberの}}）
The following search filter finds all seeAlso attribute values containing the word "Adacel" in any organizationalUnitName (ou) attribute value in any AttributeTypeAndValue of any RDN:
次の検索フィルタは、任意のorganizationalUnitName（OU）内の単語「Adacel」を含むすべてのseeAlsoの属性値がどのRDNのいずれかのAttributeTypeAndValueに属性値を検索します。
(seeAlso:componentFilterMatch:= item:{ component "*.*.value.(2.5.4.11)", rule caseIgnoreSubstringsMatch, value { any:"Adacel" } })
（seeAlsoの：componentFilterMatch：=項目：{コンポーネント "。。*値（2.5.4.11）"、caseIgnoreSubstringsMatchルール、値{いずれか： "Adacel"}}）
The component reference "*.*.value" identifies an open type, in this case an attribute value. In a particular AttributeTypeAndValue, if the attribute type is not organizationalUnitName then the ComponentAssertion evaluates to FALSE. Otherwise the substring assertion is evaluated against the attribute value.
コンポーネントの参照「*。*。値は」この場合、属性値は、オープンタイプを識別する。特にAttributeTypeAndValueでは、属性タイプがComponentAssertionがFALSEと評価され、その後organizationalUnitNameされていない場合。それ以外の場合はサブストリングアサーションは属性値に対して評価されます。
Absent component references in ComponentAssertions can be exploited to avoid false positive matches on multi-valued attributes. For example, suppose there is a multi-valued attribute named productCodes, defined to have the Integer syntax (1.3.6.1.4.1.1466.115.121.1.27). Consider the following search filter:
ComponentAssertionsには存在しないコンポーネントの参照は、複数値属性の偽陽性の一致を回避するために悪用される可能性があります。例えば、整数の構文（1.3.6.1.4.1.1466.115.121.1.27）を持つように定義されたproductCodesという名前の複数値の属性があるとします。次の検索フィルタを考えてみましょう：
(&(!(productCodes:integerOrderingMatch:=3)) (productCodes:integerOrderingMatch:=8))
（＆（（productCodes：！integerOrderingMatch：= 3））（productCodes：integerOrderingMatch：= 8））
An entry whose productCodes attribute contains only the values 1 and 10 will match the above filter. The first subfilter is satisfied by the value 10 (10 is not less than 3), and the second subfilter is satisfied by the value 1 (1 is less than 8). The following search filter can be used instead to only match entries that have a productCodes value in the range 3 to 7, because the ComponentFilter is evaluated against each productCodes value in isolation:
そのproductCodes属性を含むエントリは、値1及び10は、上記のフィルタと一致します。最初のサブフィルタは、値10（10 3以上である）で満たされ、そして第二のサブフィルタは、値1（1未満8）によって満たされます。 ComponentFilterを分離して各productCodes値に対して評価されるので、次の検索フィルタは、7の範囲3にproductCodes値を有するのみ一致エントリを代わりに使用することができます。
(productCodes:componentFilterMatch:= and:{ not:item:{ rule integerOrderingMatch, value 3 }, item:{ rule integerOrderingMatch, value 8 } })
（productCodes：componentFilterMatch：=と：{ない：アイテム：{}値3、integerOrderingMatchルール、項目：{integerOrderingMatchルール、値8}}）
An entry whose productCodes attribute contains only the values 1 and 10 will not match the above filter.
そのproductCodes属性を含むエントリは、値1及び10は、上記のフィルタと一致しないであろう。
The component matching rules described in this document allow for a compact specification of matching capabilities that could otherwise have been defined by a plethora of specific matching rules, i.e., despite their expressiveness and flexibility the component matching rules do not behave in a way uncharacteristic of other matching rules, so the security issues for component matching rules are no different than for any other matching rule. However, because the component matching rules are applicable to any attribute syntax, support for them in a directory server may allow searching of attributes that were previously unsearchable by virtue of there not being a suitable matching rule. Such attribute types ought to be properly protected with appropriate access controls. A generic, interoperable access control mechanism has not yet been developed, however, and implementors should be aware of the interaction of that lack with the increased risk of exposure described above.
この文書で説明したルールに一致するコンポーネントは、その表現力と柔軟性その他の特徴のないように動作していないルールに一致する部品にもかかわらず、そうでない場合、すなわち、特定のマッチングルールの過多によって定義されている可能性がマッチング機能をコンパクトな仕様を可能にコンポーネントマッチングルールのセキュリティ問題は、他のマッチングルールよりも違いはありませんので、ルールに一致します。しかし、部品のマッチングルールは、ディレクトリサーバ内でそれらのためのサポートがあり、適切なマッチングルールされていないのおかげで、以前に検索不可能だった属性の検索を可能にすることができる、任意の属性構文にも適用可能です。このような属性タイプが正しく、適切なアクセス制御で保護されるべきです。一般的な、相互運用可能なアクセス制御メカニズムはまだしかし、開発されていない、と実装者は、上記の暴露のリスク増加との欠如の相互作用に注意する必要があります。
The author would like to thank Tom Gindin for private email discussions that clarified and refined the ideas presented in this document.
著者は、この文書で提示アイデアを明確にし、洗練された民間の電子メールの議論のためのトムGindinに感謝したいと思います。
The Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry [8] as indicated by the following templates:
以下のテンプレートによって示されるようにIANA（Internet Assigned Numbers Authority）は、[8] LDAP記述子レジストリを更新しました：
Subject: Request for LDAP Descriptor Registration Descriptor (short name): componentFilterMatch Object Identifier: 1.2.36.79672281.1.13.2 Person & email address to contact for further information: Steven Legg <steven.legg@adacel.com.au> Usage: other (matching rule) Specification: RFC 3687 Author/Change Controller: IESG
件名：LDAP記述子登録記述子（短い名前）のための要求：componentFilterMatchオブジェクト識別子：1.2.36.79672281.1.13.2人＆詳細のために連絡する電子メールアドレス：スティーブン・レッグ<steven.legg@adacel.com.au>使用方法：他の（マッチングルール）仕様：RFC 3687著者/変更コントローラ：IESG
Subject: Request for LDAP Descriptor Registration Descriptor (short name): rdnMatch Object Identifier: 1.2.36.79672281.1.13.3 Person & email address to contact for further information: Steven Legg <steven.legg@adacel.com.au> Usage: other (matching rule) Specification: RFC 3687 Author/Change Controller: IESG
件名：LDAP記述子登録記述子（短い名前）のための要求：rdnMatchオブジェクト識別子：スティーブン・レッグ<steven.legg@adacel.com.au>使用法：1.2.36.79672281.1.13.3人とEメールアドレスは、詳細のために連絡するために、他の（マッチングルール）仕様：RFC 3687著者/変更コントローラ：IESG
Subject: Request for LDAP Descriptor Registration Descriptor (short name): presentMatch Object Identifier: 1.2.36.79672281.1.13.5 Person & email address to contact for further information: Steven Legg <steven.legg@adacel.com.au> Usage: other (matching rule) Specification: RFC 3687 Author/Change Controller: IESG
件名：LDAP記述子登録記述子（短い名前）のための要求：presentMatchオブジェクト識別子：1.2.36.79672281.1.13.5人＆詳細のために連絡する電子メールアドレス：スティーブン・レッグ<steven.legg@adacel.com.au>使用方法：他の（マッチングルール）仕様：RFC 3687著者/変更コントローラ：IESG
Subject: Request for LDAP Descriptor Registration Descriptor (short name): allComponentsMatch Object Identifier: 1.2.36.79672281.1.13.6 Person & email address to contact for further information: Steven Legg <steven.legg@adacel.com.au> Usage: other (matching rule) Specification: RFC 3687 Author/Change Controller: IESG
件名：LDAP記述子登録記述子（短い名前）のための要求：allComponentsMatchオブジェクト識別子：スティーブン・レッグ<steven.legg@adacel.com.au>使用法：1.2.36.79672281.1.13.6人とEメールアドレスは、詳細のために連絡するために、他の（マッチングルール）仕様：RFC 3687著者/変更コントローラ：IESG
Subject: Request for LDAP Descriptor Registration Descriptor (short name): directoryComponentsMatch Object Identifier: 1.2.36.79672281.1.13.7 Person & email address to contact for further information: Steven Legg <steven.legg@adacel.com.au> Usage: other (matching rule) Specification: RFC 3687 Author/Change Controller: IESG
件名：LDAP記述子登録記述子（短い名前）のための要求：directoryComponentsMatchオブジェクト識別子：1.2.36.79672281.1.13.7人＆詳細のために連絡する電子メールアドレス：スティーブン・レッグ<steven.legg@adacel.com.au>使用方法：他の（マッチングルール）仕様：RFC 3687著者/変更コントローラ：IESG
The object identifiers have been assigned for use in this specification by Adacel Technologies, under an arc assigned to Adacel by Standards Australia.
オブジェクト識別子は、規格、オーストラリアでAdacelに割り当てられたアークの下で、Adacel技術によって、この明細書での使用のために割り当てられています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[3]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[4]ワール、M.、Coulbeck、A.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）：属性の構文定義"、RFC 2252、1997年12月。
[5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[5]ワール、M.、Kille S.とT.ハウズ。 "ライトウェイトディレクトリアクセスプロトコル（v3の）：識別名のUTF-8文字列表現"、RFC 2253、1997年12月。
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[6] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[7] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[7]ホッジス、J.とR.モルガン、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：技術仕様"、RFC 3377、2002年9月。
[8] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[8] Zeilenga、BCP 64、RFC 3383、2002年9月K.、 "LDAP（Lightweight Directory Access Protocol）のためのIANA（Internet Assigned Numbers Authority）に考慮事項"。
[9] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 Types", RFC 3641, October 2003.
[9]レッグ、S.、 "ASN.1タイプのための一般的な文字列の符号化規則（GSER）"、RFC 3641、2003年10月。
[10] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, Information Technology - Open Systems Interconnection - The Directory: Models
[10] ITU-T勧告X.501（1993）| ISO / IEC 9594から2：1994、情報技術 - 開放型システム間相互接続 - ディレクトリ：モデル
[11] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998, Information Technology - Open Systems Interconnection - The Directory: Authentication Framework
[11] ITU-T勧告X.509（1997）| ISO / IEC 9594から8：1998、情報技術 - 開放型システム間相互接続 - ディレクトリ：認証フレームワーク
[12] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, Information technology - Open Systems Interconnection - The Directory: Selected attribute types
[12] ITU-T勧告X.520（1993）| ISO / IEC 9594から6：1994、情報技術 - 開放型システム間相互接続 - ディレクトリ：選択した属性タイプ
[13] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation
[13] ITU-T勧告X.680（7月2日）| ISO / IEC 8824から1：2002、情報技術 - 抽象構文記法1（ASN.1）：基本的な表記法の仕様
[14] ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2:2002, Information technology - Abstract Syntax Notation One (ASN.1): Information object specification
[14] ITU-T勧告X.681（7月2日）| ISO / IEC 8824から2：2002、情報技術 - 抽象構文記法1（ASN.1）：情報オブジェクトの仕様
[15] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3:2002, Information technology - Abstract Syntax Notation One (ASN.1): Constraint specification
[15] ITU-T勧告X.682（7月2日）| ISO / IEC 8824から3：2002、情報技術 - 抽象構文記法1（ASN.1）：制約の指定
[16] ITU-T Recommendation X.683 (07/02) | ISO/IEC 8824-4:2002, Information technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications
[16] ITU-T勧告X.683（7月2日）| ISO / IEC 8824から4：2002、情報技術 - 抽象構文記法1（ASN.1）：ASN.1仕様のパラメータ化
[17] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
[17] ITU-T勧告X.690（7月2日）| ISO / IEC 8825から1、情報技術 - ASN.1エンコーディング規則：基本符号化規則（BER）の仕様、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）
[18] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
[18]ハウズ、T.、 "LDAP検索フィルタの文字列表現"、RFC 2254、1997年12月。
[19] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, Information Technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services
[19] ITU-T勧告X.500（1993）| ISO / IEC 9594から1：1994、情報技術 - 開放型システム間相互接続 - ディレクトリ：概念、モデルとサービスの概要
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Steven Legg Adacel Technologies Ltd. 250 Bay Street Brighton, Victoria 3186 AUSTRALIA
スティーブン・レッグ・Adacelテクノロジーズ株式会社250ベイストリートブライトン、ビクトリア3186オーストラリア
Phone: +61 3 8530 7710 Fax: +61 3 8530 7888 EMail: steven.legg@adacel.com.au
電話：+61 3 8530 7710ファックス：+61 3 8530 7888 Eメール：steven.legg@adacel.com.au
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。