[要約] RFC 3687は、LDAPとX.500のコンポーネントのマッチングルールに関する規格です。その目的は、ディレクトリサービスでのデータの検索と一致を容易にするための一貫性のあるルールを提供することです。
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
軽量ディレクトリアクセスプロトコル（LDAP）およびX.500コンポーネントマッチングルール
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）The Internet Society（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）があります。種類。LDAPでは、属性の構文は通常、補強されたバックスノーフォーム（ABNF）[2]で説明されていますが、LDAP属性の構文とX.500 ASN.1タイプの間に暗黙の関連性があります。大部分は、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では、複雑な構文の属性値のコンポーネントの値に関するテスト可能なアサーションであるコンポーネントアサーションについて説明します。
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では、コンポーネントアサーションの表現であるComponentFilterアサーションを紹介します。ComponentFilterは、属性値のコンポーネントのより強力なフィルターマッチングを可能にします。
Section 5 defines the componentFilterMatch matching rule, which enables a ComponentFilter to be evaluated against attribute values.
セクション5では、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]およびこのドキュメントのセクション3〜6の仕様により、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.
Schema Designersは、関連するデータの項目を、あるエントリの複雑な構文の単一属性値として保存するか、関連するデータ項目がより単純な構文の個別の属性値として保存される下位エントリとして保存することを選択します。複雑な構文のコンポーネント部分を検索できないことは、下位エントリアプローチを支持するための議論として使用されています。コンポーネントマッチングルールは、検索フィルターが下位エントリに持っている複雑な構文の属性値に類似の一致機能を提供します。
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構文には、対応するASN.1タイプ定義がありますが、通常はLDAP構文の正式な定義とともに再現または参照されていません。文字文字列エンコードのみで定義された構文、つまり、明示的または暗黙の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値の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.
「必須」、「必要」、「必須」、「「shall」、「shall」、「suff」、「 "buld" "bould"、 "becommended" and "May"が記載されているように解釈されるべきである」BCP 14、RFC 2119 [1]。キーワード「オプション」は、その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.
コンポーネントアサーションとは、ASN.1値内のコンポーネント、つまりASN.1タイプのインスタンスの存在または値に関する主張です。ASN.1値は通常、属性値であり、ASN.1タイプは属性の構文です。ただし、コンポーネントアサーションは、属性値のコンポーネント部分にも適用できます。このアサーションは、テストされた各asn.1値に対して真、false、または未定義のいずれかと評価されます。
A ComponentAssertion is described by the following ASN.1 type (assumed to be defined with "EXPLICIT TAGS" in force):
コンポーネントアサーションは、次の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).
マッチングルール。＆IDは、マッチングルールのオブジェクト識別子に等しくなります。マッチングルール。
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タイプの値のコンポーネント部分を識別します。1型はテストされます。「usedefaultvalues」フィールドは、デフォルト値がコンポーネント値のない場合にデフォルト値が置換されるかどうかを示します。コンポーネントがどのようにテストされるか、および「値」フィールドは、コンポーネントがテストされるasn.1値です。ASN.1タイプの主張された値は、選択されたルールによって決定されます。
The fields of a ComponentAssertion are described in detail in the following sections.
コンポーネントアサーションのフィールドについては、次のセクションで詳しく説明します。
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]:
コンポーネントアサーションのコンポーネントフィールドは、テキストコンテンツがコンポーネントリファレンスであるUTF-8文字文字列[6]です。コンポーネント参照は、次の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
identifier = lowercase *alphanumeric
*(hyphen 1*alphanumeric)
alphanumeric = uppercase / lowercase / decimal-digit
uppercase = %x41-5A ; "A" to "Z"
lowercase = %x61-7A ; "a" to "z"
hyphen = "-"
from-beginning = positive-number
count = "0"
from-end = "-" positive-number
content = %x63.6F.6E.74.65.6E.74 ; "content"
select = "(" Value *( "," Value ) ")"
all = "*"
positive-number = non-zero-digit *decimal-digit
ポジティブ番号=ゼロ桁以外 *10進数桁
decimal-digit = %x30-39 ; "0" to "9"
non-zero-digit = %x31-39 ; "1" to "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 [13]の節11.3）。それは小文字から始まり、その後にゼロ以上の文字、数字、およびハイフンが続きます。ハイフンは最後のキャラクターであることは許可されておらず、ハイフンには別のハイフンが続くことは許可されていません。
The <Value> rule is described by the Generic String Encoding Rules (GSER) [9].
<value>ルールは、一般的な文字列エンコードルール（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.
コンポーネント参照は、1つ以上のコンポーネントのシーケンスであり、各連続したコンポーネントがASN.1の次のネストの次のレベルの内側コンポーネントを識別します。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つ以上のコンポーネント値を識別します。使用済みEFAULTVALUESが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.
コンポーネントアサーション内のコンポーネントフィールドも存在しない場合があります。この場合、識別されたコンポーネントタイプは、コンポーネントアサーションが適用されるasn.1タイプであり、識別されたコンポーネント値は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タイプの有効なコンポーネント参照は、最も外側の組み合わせタイプから開始し、許容される形式の1つを繰り返し選択して、連続してより深いネストされたコンポーネントを識別することにより構築されます。コンポーネント参照は、複雑な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タイプ表記には、他の定義されたタイプを参照するための多くのコンストラクトがあり、一致する目的では無関係なコンストラクトがあります。これらの構造は、コンポーネントの参照では表されず、コンポーネントタイプの置換が実行され、さらに考慮されます。これらの置換は、コンポーネントの参照を構築または解釈するかどうかにかかわらず、各コンポーネントの前に自動的に発生しますが、セクション3.2で許可されている場合を除き、最後のコンポーネントの後には発生しません。
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タイプが制約付きタイプである場合（ASN.1制約表記の詳細については、X.680 [13]および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タイプを示すObjectClassFieldType（X.681 [14]の条項14）である場合（例：一致するルール。＆IDはオブジェクト識別子タイプを示します）、コンポーネントタイプはとらえられます。示されたタイプ。セクション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タイプが、セットまたはシーケンスタイプのコンポーネントのリストで使用されるもの以外の選択タイプである場合、コンポーネントタイプは、指定された選択肢の選択された代替タイプと見なされます。
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 [14]の条項15）である場合、コンポーネントタイプは示されたタイプと見なされます。
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タイプがValySetFromObjects（X.681 [14]の条項15）である場合、コンポーネントタイプは、示された値の支配タイプと見なされます。
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タイプがセットまたはシーケンスタイプの場合、コンポーネントの<識別子>形式を使用して、そのセットまたはその識別子を持つシーケンス内のコンポーネントタイプを識別することができます。<identifier>がオプションのコンポーネントタイプを参照し、そのコンポーネントが特定の値に存在しない場合、対応するコンポーネント値はありません。<識別子>参照デフォルトのコンポーネントタイプとusedefaultValuesがtrue（usedefaultvaluesのデフォルト設定）であり、そのコンポーネントが特定の値に存在しない場合、コンポーネント値はデフォルト値と見なされます。<識別子>参照デフォルトのコンポーネントタイプを参照し、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タイプが選択タイプの場合、<識別子>コンポーネント>形式を使用して、その選択肢内の代替タイプを識別することができます。<identifier>は、特定の値で使用されるもの以外の代替案を参照する場合、対応するコンポーネント値はありません。
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 [13]の条項24の表記のコンポーネントは、それぞれ別の定義されたセットまたはシーケンスタイプのすべてのコンポーネントを含めることにより、セットまたはシーケンスタイプのコンポーネントの定義されたリストを拡張します。これらに含まれるコンポーネントは、表記のコンポーネントを含むセットまたはシーケンスタイプでインラインで定義されているかのように、識別子によって直接参照されます。
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.
セットまたはシーケンスタイプのコンポーネントのリストで使用される場合、selectionType（X.680 [13]の条項29）には、定義された選択型の単一コンポーネントが含まれます。これに含まれるコンポーネントは、識別子によって直接参照されます。まるで、セットまたはシーケンスタイプでインラインで定義されているかのようです。
The REAL type is treated as though it is the SEQUENCE type defined in Clause 20.5 of X.680 [13].
実際のタイプは、X.680の条項20.5で定義されているシーケンスタイプであるかのように扱われます[13]。
The EMBEDDED PDV type is treated as though it is the SEQUENCE type defined in Clause 33.5 of X.680 [13].
埋め込まれたPDVタイプは、X.680の条項33.5で定義されている配列タイプであるかのように扱われます[13]。
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の条項40.5で定義されているシーケンスタイプであるかのように扱われます[13]。
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]。
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タイプがタイプのセットまたはシーケンスのセットである場合、<from-beginning>、<from-end>、<count>、および<ly> 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.
<FromEnd> componentIDの形式を使用して、型のセットまたはシーケンスのコンポーネントタイプの1つのインスタンスを識別することができます。ここで、「-1」は最後のインスタンスであり、「-2」は2番目のインスタンスであり、すぐ。<FromEnd>が、タイプのセットまたはシーケンスの特定の値の最初のインスタンスよりも低い番号のインスタンスを参照する場合、対応するコンポーネント値はありません。
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の<count>形式は、タイプのセットまたはシーケンスの値のコンポーネントタイプのインスタンスの数の概念カウントを識別します。このカウントは明示的に表されるのではなく、一致する目的では、ASN.1整数のタイプ（0..max）があります。<count>フォームのコンポーネントは、使用する場合は、コンポーネントリファレンスの最後のコンポーネントでなければなりません。
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.
<All> componentidの形式を使用して、タイプのセットまたはシーケンスのコンポーネントタイプのすべてのインスタンスを同時に識別できます。コンポーネント参照が複数のコンポーネント値を識別できるのは、<All>フォームを介してです。ただし、タイプのセットまたはシーケンスの特定の値が空のリストである場合、対応するコンポーネント値はありません。
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.
複数のコンポーネント値が識別される場合、コンポーネント参照の残りのコンポーネントは、あれば、それぞれの高レベルコンポーネント値のゼロ、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.
<from-beginning>、<from-end>、および<all> form of componentidの対応するasn.1タイプは、タイプのセットまたはシーケンスのコンポーネントタイプです。
The <from-beginning>, <count>, <from-end> and <all> forms MUST NOT be used on ASN.1 types other than SET OF or SEQUENCE OF.
<from-beginning>、<count>、<from-end>、および<all>フォームは、setまたは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.
タイプが実際のパラメーターで使用されていない限り、パラメーター化されたタイプに対してコンポーネント参照を形成することはできません。この場合、タイプは実際のパラメーターに置き換えられているかのように扱われます。
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.
コンポーネント参照「PART1」は、asn.1タグ付きタイプ[0]整数を持つExampleTypeの値のコンポーネントを識別します。
The component reference "part2" identifies a component of a value of ExampleType having the ASN.1 type of [1] ExampleSet
コンポーネント参照「PART2」は、asn.1タイプの[1] Examplesetを持つ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の値のコンポーネントを識別します。コンポーネントアサーションは、asn.1タイプの例セットの値にも適用できます。この場合、コンポーネント参照「オプション」は同じ種類の情報を識別します。
The component reference "part3" identifies a component of a value of ExampleType having the ASN.1 type of [2] SET OF OBJECT IDENTIFIER.
コンポーネント参照「PART3」は、[2]オブジェクト識別子セットの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」は、PART3セットの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」は、PART3セットのインスタンスの数のカウントを識別します。カウントには、対応するasn.1整数のタイプ（0..max）があります。
The component reference "part3.*" identifies all the instances in the part3 SET OF. Each instance has the ASN.1 type of OBJECT IDENTIFIER.
コンポーネント参照「Part3。*」は、PART3セットのすべてのインスタンスを識別します。各インスタンスには、ASN.1タイプのオブジェクト識別子があります。
The component reference "part4" identifies a component of a value of ExampleType having the ASN.1 type of [3] ExampleChoice.
コンポーネント参照「PART4」は、[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」は、asn.1タイプのOctet文字列を持つ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.
一連のコンポーネントIDSが、オープンタイプ（例：属性。＆タイプはオープンタイプを意味する）を示すObjectClassFieldTypeを識別する場合、コンポーネントのasn.1タイプは異なります。通常、オープンタイプは、コンポーネント関係の制約[15]、または添付のテキストで非公式に使用することにより、正式には外側の囲いタイプの他のコンポーネントによって制約されます。一般的にオープンタイプのことが知られています。制約により、許容型の範囲も制限されます。componentidの<select>形式を使用して、これらの許容タイプの1つを開いた型で識別できます。そのタイプのサブコンポーネントは、さらなるコンポーネントで識別できます。
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]。<select>フォームには、参照されたコンポーネントの値に取って代わる1つ以上の値のリストが含まれており、許容されるタイプのオープンタイプの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.
オープンタイプがコンポーネント関係の制約によって制約されている場合、コンポーネント関係の制約に参照される各コンポーネントの<select>フォームに<値>フォームがあり、同じ順序で表示されます。これらの各値のASN.1タイプは、対応する参照コンポーネントのASN.1タイプと同じです。参照されるコンポーネントのタイプは潜在的にASN.1タイプですが、通常はオブジェクト識別子または整数です。つまり、ComponentIDの<select>形式の<surea>は<objectidididifiervalue>または<integervalue>になります。[9]。さらに、コンポーネント関係の制約には、通常、参照されたコンポーネントが1つだけです。
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.
オープンタイプがコンポーネント関係の制約によって制約されていない場合、オープンタイプを含む構文を導入する仕様は、参照されるコンポーネントとその順序を明示的に指名して、<select>フォームを使用できるようにする必要があります。
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.
<select>のインスタンスに、外側の囲まれたタイプの特定の値で使用される参照コンポーネントの値以外の値が含まれている場合、オープンタイプに対応するコンポーネント値はありません。
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.
属性。＆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.
属性。＆タイプは、オープンタイプを示します。この場合、属性値を示し、（{supportedattributes} {@type}）は、オープンタイプを属性タイプの属性構文のものに制限するコンポーネント関係の制約です。コンポーネント関係の制約は、「タイプ」コンポーネントのみを参照します。これにはASN.1タイプのオブジェクト識別子があります。。
The component reference "value" on AttributeTypeAndValue refers to the open type.
aTributeTypeandValueのコンポーネント参照「値」は、オープンタイプを指します。
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つは、facsimiletelephoneNumber [12]であり、オブジェクト識別子2.5.4.23で識別され、次の構文を持つように定義されています。
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.
属性のあるコンポーネント参照「値」を参照します。
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」astibuteTypeandValueのfacsimileteLephoneNumber属性値のテレフォンマンバーコンポーネントを識別します。コンポーネント参照「値。（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".
astibuteTypeandValue asn.1値にfacsimiletelephoneNumber以外の属性タイプが含まれている場合、コンポーネント参照「値」に対応するコンポーネント値はありません。
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.
ビット文字列またはオクテット文字列値の内容が、特定のasn.1タイプの他のasn.1値のエンコーディングであるために必要な場合があります。たとえば、証明書タイプ[11]の拡張型型コンポーネントのextnValueコンポーネントは、著名なエンコードルール（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の<content>形式を使用して、含まれるタイプを識別できます。そのタイプのサブコンポーネントは、さらなるコンポーネントで識別できます。
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によって制約されます）。これらの場合、次のコンポーネントは、もしあれば、<select>フォームでなければなりません。
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})
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.
埋め込まれた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.
拡張機能。＆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文字列のコンポーネントタイプを指します。対応するコンポーネント値は、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]標準拡張機能の1つはBasicConstraintsであり、オブジェクト識別子2.5.29.19で識別され、次の構文を持つように定義されています。
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）」は、Basic Constraintssyntax拡張値とコンポーネント参照「extnvalue.content。（2.5.29.19）.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.
一致する各ルールには、属性構文の概念的なセット（通常1つ）があり、ASN.1タイプとして定義され、適用される可能性があります。コンポーネントアサーションで使用する場合、これらの一致するルールは同じ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 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.
一致するルールが複数の属性構文（たとえば、ObjectididifierFirstComponentMatch [12]）に適用される場合、これらの構文のいずれかに準拠するために必要な代替の最小数が実行されます。一致するルールが任意の属性構文（セクション6.2で定義されているAllComponentsmatchルールなど）に適用できる場合、参照されるコンポーネントタイプは、追加の置換なしでそのまま使用されます。
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:
次の場合、コンポーネントアサーションは未定義です。
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が未定義でない場合、コンポーネントアサーションは、そのコンポーネント値に適用される一致するルールがtrueを返し、falseに評価するコンポーネント値が少なくとも1つある場合、trueに評価します（コンポーネント値がない場合が含まれます）。
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には、異なる文字セットおよび/または異なる文字エンコーディングを備えた制限付き文字列タイプが多数あります。ディレクトリユーザーは通常、文字文字列コンポーネント値を表すために使用される特定の文字セットまたはエンコードにほとんど関心がありません。一部のディレクトリサーバーの実装は、値の内部表現において異なる文字列タイプを区別しません。したがって、制限付き文字文字列タイプのそれぞれの文字列マッチングルールを定義するのではなく、既存のケースを無視し、ケースの正確な文字列マッチングルールは、制限された文字列タイプのコンポーネント値と任意の選択肢の型[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、caseignoreorousubstringsmatch、caseexactmatch、caseexactordingmatch、caseexactsubstringsmatchです。関連する制限付き文字列タイプは、numericString、printablestring、visiblestring、ia5string、utf8string、bmpsstring、universtring、teletexstring、videotexstring、graphicstring、generalstringです。選択型の選択タイプは、これらのasn.1文字列タイプの純粋に構文的な選択です。GSER [9]は、DirectoryString {}パラメーター化されたタイプのすべての使用を、ShoiceOfStringsタイプと宣言することに注意してください。
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値を制限された文字列タイプの1つまたは選択OfStringsタイプの値と比較するために、実装が求められます。選択した代替品が文字列タイプの異なる2つのディレクトリストリングを比較する場合のように、対応する文字が両方の文字セットで表現できる限り、比較は進行します。それ以外の場合は、一致するものが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.
X.520 [12]の初期版[12]は、TelephonEnumber属性の構文を制約された印刷物として与えました。X.520の第4版では、ASN.1タイプ名のテレフォンナンバーが制約付きのPrintAblestringに等しくなり、ThelevonEnumberを属性およびアサーション構文として使用します。コンポーネントマッチングの目的で、ThelebonEnumberMatchとThelefonEnumberSubstringsmatchは、PrintAblestring値、およびThelephonEnumber値に適用されることが許可されています。
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.
distinguednameタイプは、割り当てによってRDNシーケンスタイプと同じであると定義されますが、RDNシーケンスは他のタイプ定義で直接使用される場合があります。コンポーネントマッチングの目的のために、DistinguishedNameMatchもRDNシーケンスタイプの値に適用されることが許可されています。
This section defines additional matching rules that may prove useful in ComponentAssertions. These rules may also be used in extensibleMatch search filters [3].
このセクションでは、コンポーネントアサーションで有用であることが証明される可能性のある追加のマッチングルールを定義します。これらのルールは、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を考慮せずに、特定の相対的な著名な名前（RDN）を著名な名前（DN）で一致させることができる場合があります。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 'rdn'）
The LDAP-specific encoding for a value of the RDN syntax is given by the <RelativeDistinguishedNameValue> rule [9].
RDN構文の値に対するLDAP固有のエンコードは、<relativedistinguednamevalue>ルール[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.
RDNMatchルールは、コンポーネント値とアサーション値が同じRDNである場合、DistinguishedNameMatchと同じRDN比較方法を使用してTrueに評価されます。
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".
DNSのコンポーネントを一致させるためにRDNMatchを使用する場合、DN [5]のLDAP固有のエンコードがRDNの順序を逆転させることに注意することが重要です。したがって、LDAPで「CN = Steven Legg、O = Adacel、C = Au」として表されるDNの場合、RDN "CN = Steven Legg"はコンポーネント参照「3」、または「-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.
特定のコンポーネントの特定の値が存在するかどうかではなく、特定のコンポーネントの値が存在するかどうかではなく、テストすると便利な場合があります。現在のマッチマッチングルールにより、特定のコンポーネント値の存在をテストできます。
The LDAP-style definitions for presentMatch and its assertion syntax are:
現在のマッチとそのアサーション構文の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名前「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].
ヌル構文の値に対するLDAP固有のエンコードは、<nullvalue>ルール[9]によって与えられます。
The X.500-style definition for presentMatch is:
現在のマッチの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は通常の検索フィルターの「現在の」ケースのように動作します。コンポーネントアサーションでは、PresentMatchは、実際のコンポーネント値の内容に関係なく、コンポーネント参照が1つ以上のコンポーネント値を識別する場合にのみTrueに評価します。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.
<count> componentidの形式によって参照される概念的なカウントは、価値のセットが存在する場合、そうでない場合は存在しない場合に存在すると見なされます。ASN.1表記では、存在しない値のセットは、存在するが空の価値のセットとは明らかに異なることに注意してください。区別が重要かどうかを決定するために、ASN.1表記を使用した仕様次第です。多くの場合、空のコンポーネントのセットとコンポーネントの欠如セットは、意味的に同等のものとして扱われます。値のセットが存在するが空の場合、コンポーネントのセットのプレゼントマッチは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マッチングルールは、列挙された、ヌル、リアル、相対障害のある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.
コンポーネントアサーションにより、複雑なasn.1タイプの1つのコンポーネントタイプの値を一致させることができますが、多くの場合、複数のコンポーネントタイプの値を一致させたいという欲求があります。ComponentFilterは、ASN.1値内の複数のコンポーネントの存在または値に関する主張です。
The ComponentFilter assertion, an expression of ComponentAssertions, evaluates to either TRUE, FALSE or Undefined for each tested ASN.1 value.
コンポーネントアサーションの式であるComponentFilterアサーションは、テストされた各ASN.1値に対して真、fals、または未定義のいずれかと評価されます。
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.
注： "and" and "または" "or"の代替であるコンポーネントフィルターのセットの代わりに一連のシーケンスを使用しているにもかかわらず、コンポーネントフィルターの順序は重要ではありません。
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.
コンポーネントアサリオンであるコンポーネントフィルターは、コンポーネントアサーションがtrueの場合、Trueに評価され、コンポーネントアサーションが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に評価され、少なくとも1つのコンポーネントフィルターが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に評価され、少なくとも1つのコンポーネントフィルターがtrueである場合はtrueに評価され、他の方法では未定義と評価されます。
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.
コンポーネントフィルターの「not」は、コンポーネントフィルターがfalsである場合に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を属性値に適用できます。一致するルールの結果は、コンポーネントフィルターを属性値に適用した結果です。
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 'componentfiltermatch'構文1.2.36.79672281.1.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].
コンポーネントフィルターアサーション構文の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は決定的なものと見なされます。コンポーネントフィルターのGSERエンコードは、次の同等のABNFで説明されています。
ComponentFilter = filter-item / and-filter / or-filter / not-filter
componentfilter = filter-item / and-filter / or-filter / not-filter
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:"
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 component "、"] [sp sudeefaultValues "、"] sp rule "、" sp assertion-value sp "}" component = component-label msp stringvalue sudeefaultvalues = use-defaults-label msp booleanvalueルール=ルールラベルMSP ObjectIdentidifierValue Assertion-Value = value-label 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"
sp = *%x20 ; zero, one or more space characters
msp = 1*%x20 ; one or more space characters
The ABNF for <Value>, <StringValue>, <ObjectIdentifierValue> and <BooleanValue> is defined by GSER [9].
<value>、<StringValue>、<ObjectIdentifierValue>、および<BooleanValue>のABNFは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説明は、通常、属性値のコンポーネント部分を明確または一貫して描写しません。任意のコンポーネントデータ型のためにエンコードする通常の均一な文字列は、コンポーネントアサーションのアサーション値をエンコードするために必要です。GSERからの<value>ルールは、任意の任意の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.
ComponentAssertionは、componentfiltermatchを含む一致するルールを使用する可能性があるため、componentfiltermatchがネストされる可能性があります。ネストされたコンポーネントのコンポーネント参照は、含有コンポーネントアサーションに対応するコンポーネントに関連しています。セクション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構文の属性値が、対応するコンポーネントが同じかどうかをテストする複雑なコンポーネントフィルターを使用して、何らかの（すなわち、アサーション）値と同じかどうかをテストすることができます。ただし、任意の属性構文の属性値とアサーション値のコンポーネントでの比較を実行できるマッチングルールに全体のアサーション値を提示できるようにする方が便利です。同様に、複雑な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では、これは一致するルール情報オブジェクトのオプションの構文フィールドを省略することによって示されます。Assertion構文は、一致するルールの説明に特に説明されていない限り、実際の使用法でターゲット属性の構文にデフォルトであります。MatchingRuleDesscriptionのLDAP固有のエンコードの構文フィールドは必須であるため、OpenAssertionType構文は同じ役割を果たすように定義されています。つまり、openAssertionType構文は、X.500マッチングルール情報オブジェクトの省略された構文フィールドとセマンティックに同等です。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アサーション値がコンポーネントアサーションに表示される場合、そのLDAP固有のエンコードはGSER [9]の<値>ルールで説明されています。OpenAssertionType Assertion構文を使用した一致するルールが適用される属性タイプの構文の場合。
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名「AllComponentsmatch」構文1.2.36.79672281.1.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がコンポーネントアサーションで使用される場合、アサーション構文は、識別されたコンポーネントの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.
大まかに言えば、この一致するルールは、アサーション値と属性またはコンポーネント値の対応するコンポーネントが同じである場合にのみTrueに評価されます。
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) セットタイプまたはシーケンスタイプの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、外部、無制限の文字列、またはタイプのインスタンスの値は、それぞれの関連するシーケンスタイプに従って比較されます（セクション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) 選択タイプの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つのブール値は、両方が真であるか、両方が偽である場合にのみ同じです。
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、universalsstring、bmpstring、utf8string、generalimed、utf8string、
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) 2つのヌル値は、常に同じで、無条件です。
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つの実際の値は、両方が同じ特別な値である場合、またはどちらも特別な値ではなく、同じベースを持ち、同じ実数を表している場合にのみ同じです。実際の特別な値はゼロ、プラスインフィニティ、マイナスインフィニティです。
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つの相対of値は同じです。相対of値のそれぞれの開始ノードは、比較では無視されます。つまり、それらは同じであると想定されています。
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の値のタイプが不明の場合、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.
派生コンポーネントの等式マッチングルールのマッチング動作は、1つ以上の識別されたコンポーネントのそれぞれについて、そのコンポーネントの値を一致させるために使用される通勤平等マッチングルールを指名することによって指定されます。これにより、派生のベースルールを使用して、そのコンポーネントの値に対して発生するマッチングが無効になります。これらのオーバーライドは、次の形式の表の行として便利に表現できます。
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タイプの参照（例：distinguedname）または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.
テーブル内での順序に関係なく、外側の含有タイプ（例：distinguedname）の値を指定する行（distinguednameなど）は、内部コンポーネントタイプ（例：relativedististinguedname）の値を指定する行よりも優先されます。内側の型のコンポーネント値の行を指定することは、タイプの値が単独で表示される場合、または異なる外側型の値のコンポーネントとしても表示される場合にのみ役立ちます。たとえば、DistingUishedNameの行がある場合、relativeDististinguedNameの行は、DistingiedNameの一部ではないrelativedistisidedNameコンポーネント値にのみ適用できます。ベースルールのテーブル内の外側タイプの値の行は、派生ルールのテーブル内の内側のタイプの値の行に優先されます。
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'構文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) distingiednameタイプは、rdn sequenceタイプと同じであるという割り当てによって定義されます。いくつかのタイプ（例：名前やローカル名）は、識別名ではなくrdn sequenceを直接参照します。RDNシーケンスの指定は、これらすべてのDN様タイプをキャプチャします。
2) A RelativeDistinguishedName value is only matched by rdnMatch if it is not part of an RDNSequence value.
2) relativeDististIngiedName値は、RDNシーケンス値の一部ではない場合にのみ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]の電話番号コンポーネントは、制約された印刷物として定義されます。FaxsimileteLephoneNumber値の一部であるPrintAblestringコンポーネント値は、指定子FACSIMILETELEPHONENUMBER.TELEPHONENUMBERによって印刷型の他のコンポーネントとは別に識別できます。X.520の第4版では、FaxsimileTeLephoneNumberのThelephonEnumberコンポーネントをタイプのThelephonEnumberであると定義し、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:
最初の例では、ObjectClasses Schema Operational属性の検索を説明します。これには、asn.1タイプObjectClassDescription [10]によって記述された属性構文があり、ディレクトリサーバーに既知のオブジェクトクラスの定義を保持します。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および属性。＆IDは、オブジェクト識別子ASN.1タイプと同等です。オブジェクトクラスの値。＆IDは、オブジェクトクラスのオブジェクト識別子です。属性の値。＆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 })
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値の「識別子」コンポーネントの一致は、ObjectClasses属性タイプの属性値に適用されるObjectididifierFirstComponentMatchマッチングルールに相当します。ComponentFilTermatchマッチングルールは、ObjectididifierFirstComponentMatch、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" })
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」である場合、オブジェクトクラスの値と一致します。
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 })
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 })
The presentMatch returns TRUE if the description component is present and FALSE otherwise.
説明コンポーネントが存在し、それ以外の場合はfalseの場合、現在のマッチはtrueを返します。
The following search filter finds object class definitions that don't have descriptions:
次の検索フィルターでは、説明がないオブジェクトクラスの定義を見つけます。
(objectClasses:componentFilterMatch:=
not:item:{ component "description",
rule presentMatch, value 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" } })
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 })
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:
「時代遅れの」コンポーネントが存在しない場合、オブジェクトクラスは時代遅れではありません。次の検索フィルターでは、すべての非肥満のオブジェクトクラスが見つかります。
(objectClasses:componentFilterMatch:=
item:{ component "obsolete", rule booleanMatch, value 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:
ComponentAssertionのUsedEfaultValuesフラグはデフォルトであるため、ComponentFilTermatchルールは、「廃止」コンポーネントを存在し、falseに設定していると扱います。次の検索フィルターでは、「時代遅れ」コンポーネントがfalseに暗黙的にデフォルトであるのではなく、「廃止」コンポーネントが明示的にfalseに設定されている場合、オブジェクトクラスの定義のみを見つけます。
(objectClasses:componentFilterMatch:=
item:{ component "obsolete", useDefaultValues FALSE,
rule booleanMatch, value 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.
UsedEfaultValuesフラグがFALSEに設定されている場合、「廃止」コンポーネントが存在しない場合、コンポーネント参照はコンポーネント値を識別せず、一致するルールは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 })
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 } })
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 } } })
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 })
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」コンポーネントが存在しない場合、「name.0」コンポーネントも存在しないと見なされ、コンポーネントアサートはfalseに評価されます。「名前」コンポーネントが存在するが空の場合、「name.0」コンポーネントも存在し、ゼロに等しいため、コンポーネントアサーションはtrueに評価されます。また、名前の欠如リストを持つオブジェクトクラスの定義を見つけるには、次の検索フィルターを使用します。
(objectClasses:componentFilterMatch:=or:{
not:item:{ component "name", rule presentMatch, value NULL },
item:{ component "name.0",
rule integerOrderingMatch, value 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:componentFilterMatch:=
item:{ component "dn",
rule distinguishedNameMatch,
value "cn=Steven Legg,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.
distinguednameおよびlerativedistinguishedname 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.
属性。＆タイプはオープンタイプです。属性の値。＆タイプは、Nominated属性タイプの属性構文の属性コンポーネントによって制約されます。注：X.500の第4版は、AtributeTypeandValueシーケンスタイプを拡張および名前を変更します。
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属性には、distinguedname構文があります。次の検索フィルターでは、DNのどこにでもRDN「O = Adacel」を含むSeeALSO属性値が見つかります。
(seeAlso:componentFilterMatch:=
item:{ component "*", rule rdnMatch, value "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):
次の検索フィルターでは、すべてのSeealso属性値が「CN = Steven Legg」を指定されたエントリのRDN（つまり、LDAPDNの「最初の」RDNまたはX.500 DNの「最後の」RDN）として見つけます。
(seeAlso:componentFilterMatch:=
item:{ component "-1",
rule rdnMatch, value "cn=Steven Legg" })
The following search filter finds all seeAlso attribute values naming entries in the DIT subtree of "o=Adacel,c=AU":
次の検索フィルターでは、すべてのseealso属性値が「o = adacel、c = au」のDITサブツリーのエントリの名前を挙げます：
(seeAlso:componentFilterMatch:=and:{
item:{ component "1", rule rdnMatch, value "c=AU" },
item:{ component "2", rule rdnMatch, value "o=Adacel" } })
The following search filter finds all seeAlso attribute values containing the naming attribute types commonName (cn) and telephoneNumber in the same RDN:
次の検索フィルターでは、同じRDNのNAMING属性タイプ（CN）とテレフォンガナンバを含むすべてのSeeALSO属性値が見つかります。
(seeAlso:componentFilterMatch:=
item:{ component "*", rule componentFilterMatch,
value and:{
item:{ component "*.type",
rule objectIdentifierMatch, value cn },
item:{ component "*.type",
rule objectIdentifierMatch,
value 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とThelephonEnumberを含むすべてのSeeALSO属性値が見つかりますが、必ずしも同じRDNにはありません。
(seeAlso:componentFilterMatch:=and:{
item:{ component "*.*.type",
rule objectIdentifierMatch, value cn },
item:{ component "*.*.type",
rule objectIdentifierMatch, value 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:
次の検索フィルターでは、RDNの任意の属性の値に任意の組織nationalunitname（ou）属性値に「adacel」という単語を含むすべてのseealso属性値が見つかります。
(seeAlso:componentFilterMatch:=
item:{ component "*.*.value.(2.5.4.11)",
rule caseIgnoreSubstringsMatch,
value { any:"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.
コンポーネント参照「*。*。値」は、オープンタイプを識別します。この場合、属性値を識別します。特定の属性のvalueでは、属性タイプが組織化されていない場合、ComponentAssertionはfalseに評価されます。それ以外の場合、サブストリングアサーションは属性値に対して評価されます。
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:
コンポーネントアサーションにコンポーネント参照がないことを悪用して、多値属性の誤検知の一致を避けることができます。たとえば、整数構文（1.3.6.1.4.1.1.146.115.121.1.1.27）を持つと定義された製品コードという名前のマルチ値属性があるとします。次の検索フィルターを検討してください。
(&(!(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以上）で満たされ、2番目のサブフィルターは値1（1は8未満）によって満たされます。代わりに、次の検索フィルターを使用して、範囲3から7の製品コード値を持つエントリのみを一致させることができます。これは、各製品コード値に対して単独で評価されるため、
(productCodes:componentFilterMatch:= and:{
not:item:{ rule integerOrderingMatch, value 3 },
item:{ rule integerOrderingMatch, value 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.
著者は、この文書で提示されたアイデアを明確にし、洗練したプライベートメールディスカッションについて、Tom Gindinに感謝したいと思います。
The Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry [8] as indicated by the following templates:
インターネットが割り当てられた番号局（IANA）は、次のテンプレートで示されているように、LDAP記述子レジストリ[8]を更新しました。
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
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
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
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
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
The object identifiers have been assigned for use in this specification by Adacel Technologies, under an arc assigned to Adacel by Standards Australia.
オブジェクト識別子は、Adacel Technologiesによってこの仕様で使用されるように割り当てられており、AdacelにAdacelに割り当てられたStandards Australiaに割り当てられています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker、D.、ed。および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] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（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] Wahl、M.、Coulbeck、A.、Howes、T。and S. Kille、「Lightweight Directory Access Protocol（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] Wahl、M.、Kille S.およびT. Howes。「Lightweight Directory Access Protocol（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] Hodges、J。およびR. Morgan、「Lightweight Directory Access Protocol（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、K。、「Lightweight Directory Access Protocol（LDAP）のインターネット割り当てされた数字権（IANA）の考慮事項」、BCP 64、RFC 3383、2002年9月。
[9] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 Types", RFC 3641, October 2003.
[9] Legg、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（07/02）|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（07/02）|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（07/02）|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（07/02）|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（07/02）|ISO/IEC 8825-1、情報技術-ASN.1エンコーディングルール：基本エンコードルール（BER）、標準エンコードルール（CER）、および区別エンコードルール（DER）の仕様
[18] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
[18] Howes、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
Steven Legg Adacel Technologies Ltd. 250 Bay Street Brighton、Victoria 3186 Australia
Phone: +61 3 8530 7710
Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。