RFC3687 日本語訳
3687 Lightweight Directory Access Protocol (LDAP) and X.500 ComponentMatching Rules. S. Legg. February 2004. (Format: TXT=96256 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Legg Request for Comments: 3687 Adacel Technologies Category: Standards Track February 2004
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
Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules
Status of this Memo
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.
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.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
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.
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.
Legg Standards Track [Page 1] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 1] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Table of Contents
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
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
Legg Standards Track [Page 2] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 2] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
1. Introduction
1. Introduction
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.
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.
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.
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.
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.
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.
Section 3 describes the ComponentAssertion, a testable assertion about the value of a component of an attribute value of any complex syntax.
Section 3 describes the ComponentAssertion, a testable assertion about the value of a component of an attribute value of any complex syntax.
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.
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.
Section 5 defines the componentFilterMatch matching rule, which enables a ComponentFilter to be evaluated against attribute values.
Section 5 defines the componentFilterMatch matching rule, which enables a ComponentFilter to be evaluated against attribute values.
Legg Standards Track [Page 3] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 3] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Section 6 defines matching rules for component-wise equality matching of attribute values of any syntax described by an ASN.1 type definition.
Section 6 defines matching rules for component-wise equality matching of attribute values of any syntax described by an ASN.1 type definition.
Examples showing the usage of componentFilterMatch are in Section 7.
Examples showing the usage of componentFilterMatch are in Section 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.
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.
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 have the choice of storing related items of data as a single attribute value of a complex syntax in some entry, or as a subordinate entry where the related data items are stored as separate attribute values of simpler syntaxes. The inability to search component parts of a complex syntax has been used as an argument for favouring the subordinate entries approach. The component matching rules provide the analogous matching capability on an attribute value of a complex syntax that a search filter has on a subordinate entry.
Most LDAP syntaxes have corresponding ASN.1 type definitions, though they are usually not reproduced or referenced alongside the formal definition of the LDAP syntax. Syntaxes defined with only a character string encoding, i.e., without an explicit or implied corresponding ASN.1 type definition, cannot use the component matching capabilities described in this document unless and until a semantically equivalent ASN.1 type definition is defined for them.
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.
2. Conventions
2. Conventions
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.
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.
Legg Standards Track [Page 4] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 4] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
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.
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.
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.
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.
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.
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.
3. ComponentAssertion
3. ComponentAssertion
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.
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.
A ComponentAssertion is described by the following ASN.1 type (assumed to be defined with "EXPLICIT TAGS" in force):
A ComponentAssertion is described by the following ASN.1 type (assumed to be defined with "EXPLICIT TAGS" in force):
ComponentAssertion ::= SEQUENCE {
component ComponentReference (SIZE(1..MAX)) OPTIONAL,
useDefaultValues BOOLEAN DEFAULT TRUE,
rule MATCHING-RULE.&id,
value MATCHING-RULE.&AssertionType }
ComponentAssertion ::= SEQUENCE { component ComponentReference (SIZE(1..MAX)) OPTIONAL, useDefaultValues BOOLEAN DEFAULT TRUE, rule MATCHING-RULE.&id, value MATCHING-RULE.&AssertionType }
ComponentReference ::= UTF8String
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).
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).
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
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
Legg Standards Track [Page 5] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 5] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
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.
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.
The fields of a ComponentAssertion are described in detail in the following sections.
The fields of a ComponentAssertion are described in detail in the following sections.
3.1. Component Reference
3.1. Component Reference
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]:
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]:
component-reference = ComponentId *( "." ComponentId )
ComponentId = identifier /
from-beginning /
count /
from-end / ; extends Clause 14
content / ; extends Clause 14
select / ; extends Clause 14
all
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 = "-"
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 = "*"
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
positive-number = non-zero-digit *decimal-digit
decimal-digit = %x30-39 ; "0" to "9"
non-zero-digit = %x31-39 ; "1" to "9"
decimal-digit = %x30-39 ; "0" to "9" non-zero-digit = %x31-39 ; "1" to "9"
Legg Standards Track [Page 6] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 6] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
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.
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.
The <Value> rule is described by the Generic String Encoding Rules (GSER) [9].
The <Value> rule is described by the Generic String Encoding Rules (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.
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.
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.
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.
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.
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.
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.
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.
3.1.1. Component Type Substitutions
3.1.1. Component Type Substitutions
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 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.
Legg Standards Track [Page 7] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 7] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
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.
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.
If the ASN.1 type is a tagged type then the component type is taken to be the type without the tag.
If the ASN.1 type is a tagged type then the component type is taken to be the type without the tag.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
3.1.2. Referencing SET, SEQUENCE and CHOICE Components
3.1.2. Referencing SET, SEQUENCE and CHOICE Components
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.
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.
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.
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.
Legg Standards Track [Page 8] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 8] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
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.
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.
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.
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.
The REAL type is treated as though it is the SEQUENCE type defined in Clause 20.5 of X.680 [13].
The REAL type is treated as though it is the SEQUENCE type defined in Clause 20.5 of X.680 [13].
The EMBEDDED PDV type is treated as though it is the SEQUENCE type defined in Clause 33.5 of X.680 [13].
The EMBEDDED PDV type is treated as though it is the SEQUENCE type defined in Clause 33.5 of X.680 [13].
The EXTERNAL type is treated as though it is the SEQUENCE type defined in Clause 8.18.1 of X.690 [17].
The EXTERNAL type is treated as though it is the SEQUENCE type defined in Clause 8.18.1 of X.690 [17].
The unrestricted CHARACTER STRING type is treated as though it is the SEQUENCE type defined in Clause 40.5 of X.680 [13].
The unrestricted CHARACTER STRING type is treated as though it is the SEQUENCE type defined in Clause 40.5 of X.680 [13].
The INSTANCE OF type is treated as though it is the SEQUENCE type defined in Annex C of X.681 [14].
The INSTANCE OF type is treated as though it is the SEQUENCE type defined in Annex C of X.681 [14].
The <identifier> form MUST NOT be used on any other ASN.1 type.
The <identifier> form MUST NOT be used on any other ASN.1 type.
3.1.3. Referencing SET OF and SEQUENCE OF Components
3.1.3. Referencing SET OF and SEQUENCE OF Components
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.
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.
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-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,
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,
Legg Standards Track [Page 9] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 9] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The <from-beginning>, <count>, <from-end> and <all> forms MUST NOT be used on ASN.1 types other than SET OF or SEQUENCE OF.
The <from-beginning>, <count>, <from-end> and <all> forms MUST NOT be used on ASN.1 types other than SET OF or SEQUENCE OF.
3.1.4. Referencing Components of Parameterized Types
3.1.4. Referencing Components of Parameterized Types
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.
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.
3.1.5. Component Referencing Example
3.1.5. Component Referencing Example
Consider the following ASN.1 type definitions.
Consider the following ASN.1 type definitions.
ExampleType ::= SEQUENCE {
part1 [0] INTEGER,
part2 [1] ExampleSet,
part3 [2] SET OF OBJECT IDENTIFIER,
part4 [3] ExampleChoice }
ExampleType ::= SEQUENCE { part1 [0] INTEGER, part2 [1] ExampleSet, part3 [2] SET OF OBJECT IDENTIFIER, part4 [3] ExampleChoice }
Legg Standards Track [Page 10] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 10] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
ExampleSet ::= SET {
option PrintableString,
setting BOOLEAN }
ExampleSet ::= SET { option PrintableString, setting BOOLEAN }
ExampleChoice ::= CHOICE {
eeny-meeny BIT STRING,
miney-mo OCTET STRING }
ExampleChoice:、:= 選択eeny-meeny BIT STRING、miney-折り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]INTEGERを持っているExampleTypeの価値のコンポーネントを特定します」。
The component reference "part2" identifies a component of a value of ExampleType having the ASN.1 type of [1] ExampleSet
コンポーネント参照、「part2"は[1] ExampleSetのASN.1タイプがあるExampleTypeの価値のコンポーネントを特定します」。
The component reference "part2.option" identifies a component of a value of ExampleType having the ASN.1 type of PrintableString. A ComponentAssertion could also be applied to a value of ASN.1 type ExampleSet, in which case the component reference "option" would identify the same kind of information.
コンポーネント参照"part2.option"はPrintableStringのASN.1タイプがあるExampleTypeの価値のコンポーネントを特定します。 また、ASN.1タイプExampleSetの値にComponentAssertionを当てはまることができました、その場合、「オプション」というコンポーネント参照は同じ種類の情報を特定するでしょう。
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] SET OF OBJECT IDENTIFIERの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 SET OFの2番目のインスタンスを特定します」。 インスタンスには、OBJECT IDENTIFIERの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 SET OFのインスタンスの数のカウントを特定します」。 カウントには、INTEGER(0..MAX)の対応するASN.1タイプがあります。
The component reference "part3.*" identifies all the instances in the part3 SET OF. Each instance has the ASN.1 type of OBJECT IDENTIFIER.
「part3*」というコンポーネント参照はpart3 SET OFですべてのインスタンスを特定します。 各インスタンスには、OBJECT IDENTIFIERの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-折り」というコンポーネント参照はOCTET STRINGのASN.1タイプがあるExampleTypeの価値のコンポーネントを特定します。
Legg Standards Track [Page 11] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[11ページ]。
3.1.6. Referencing Components of Open Types
3.1.6. 開放型の成分に、参照をつけます。
If a sequence of ComponentIds identifies an ObjectClassFieldType denoting an open type (e.g., ATTRIBUTE.&Type denotes an open type) then the ASN.1 type of the component varies. An open type is typically constrained by some other component(s) in an outer enclosing type, either formally through the use of a component relation constraint [15], or informally in the accompanying text, so the actual ASN.1 type of a value of the open type will generally be known. The constraint will also limit the range of permissible types. The <select> form of ComponentId may be used to identify one of these permissible types in an open type. Subcomponents of that type can then be identified with further ComponentIds.
ComponentIdsの系列が開放型を指示するObjectClassFieldTypeを特定するなら(ATTRIBUTE例えば、Typeは開放型を指示します)、コンポーネントのASN.1タイプは異なります。 一般に、開放型がコンポーネント関係規制[15]の使用を通してある他のコンポーネントによって外側の同封のタイプで通常正式に抑制されるか、またはしたがって、付随のテキストでは、非公式に、開放型の価値の実際のASN.1タイプは知られているでしょう。 また、規制は許されているタイプの範囲を制限するでしょう。 ComponentIdの<の選んだ>フォームは、開放型でこれらの許されているタイプのひとりを特定するのに使用されるかもしれません。 そして、そのタイプのサブコンポーネントを一層のComponentIdsと同一視できます。
The other components constraining the open type are termed the referenced components [15]. The <select> form contains a list of one or more values which take the place of the value(s) of the referenced component(s) to uniquely identify one of the permissible types of the open type.
開放型を抑制する他のコンポーネントが参照をつけられたコンポーネント[15]と呼ばれます。 <の選んだ>フォームは唯一開放型の許されているタイプのひとりを特定するために参照をつけられたコンポーネントの値の代理をする1つ以上の値のリストを含んでいます。
Where the open type is constrained by a component relation constraint, there is a <Value> in the <select> form for each of the referenced components in the component relation constraint, appearing in the same order. The ASN.1 type of each of these values is the same as the ASN.1 type of the corresponding referenced component. The type of a referenced component is potentially any ASN.1 type however it is typically an OBJECT IDENTIFIER or INTEGER, which means that the <Value> in the <select> form of ComponentId will nearly always be an <ObjectIdentifierValue> or <IntegerValue> [9]. Furthermore, component relation constraints typically have only one referenced component.
開放型がコンポーネント関係規制で抑制されるところに、それぞれの参照をつけられたコンポーネントのための<の選んだ>フォームには<Value>がコンポーネント関係規制にあります、同次に現れて。 それぞれのこれらの値のASN.1タイプは対応する参照をつけられたコンポーネントのASN.1タイプと同じです。 それが通常OBJECT IDENTIFIERかどのようにINTEGERであっても、参照をつけられたコンポーネントのタイプは潜在的にあらゆるASN.1タイプです。(INTEGERはComponentIdの<の選んだ>形の<Value>がいつもほとんど<ObjectIdentifierValue>か<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.
開放型がコンポーネント関係規制で抑制されないところでは、開放型を含む構文を導入する仕様は明らかに参照をつけられたコンポーネントと彼らの注文を指名するべきです、<の選んだ>フォームを使用できるように。
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.
<の選んだ>のインスタンスが外側の同封の特定の値に使用される参照をつけられたコンポーネントの値以外の値を含んでいるなら、そしてそこのタイプは開放型のための対応する成分値ではありません。
3.1.6.1. Open Type Referencing Example
3.1.6.1. 例に参照をつけている開放型
The ASN.1 type AttributeTypeAndValue [10] describes a single attribute value of a nominated attribute type.
ASN.1タイプAttributeTypeAndValue[10]は指名属性タイプのただ一つの属性値について説明します。
Legg Standards Track [Page 12] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[12ページ]。
AttributeTypeAndValue ::= SEQUENCE {
type ATTRIBUTE.&id ({SupportedAttributes}),
value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) }
AttributeTypeAndValue:、:= 系列ATTRIBUTE ATTRIBUTEイド(SupportedAttributes)、値のTypeをタイプしてください、(SupportedAttributes、@type)
ATTRIBUTE.&id denotes an OBJECT IDENTIFIER and
({SupportedAttributes}) constrains the OBJECT IDENTIFIER to be a
supported attribute type.
ATTRIBUTEイドはOBJECT IDENTIFIERを指示して、(SupportedAttributes)は、OBJECT IDENTIFIERがサポートしている属性タイプであることを抑制します。
ATTRIBUTE.&Type denotes an open type, in this case an attribute
value, and ({SupportedAttributes}{@type}) is a component relation
constraint that constrains the open type to be of the attribute
syntax for the attribute type. The component relation constraint
references only the "type" component, which has the ASN.1 type of
OBJECT IDENTIFIER, thus if the <select> form of ComponentId is used
to identify attribute values of specific attribute types it will
contain a single OBJECT IDENTIFIER value.
そして、ATTRIBUTE Typeが開放型、この場合属性値を指示する、(SupportedAttributes、@type) コンポーネントの関係は開放型が属性タイプのための属性構文のものであることを抑制する規制ですか? 唯一のコンポーネント関係規制参照は「タイプ」コンポーネント(その結果ASN.1がComponentIdの<の選んだ>フォームが特定の属性タイプの属性値を特定するのに使用されて、ただ一つのOBJECT IDENTIFIER値を含むということであるならOBJECT IDENTIFIERをタイプするもの)です。
The component reference "value" on AttributeTypeAndValue refers to the open type.
「値」というAttributeTypeAndValueに関するコンポーネント参照は開放型に言及します。
One of the X.500 standard attributes is facsimileTelephoneNumber [12], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is defined to have the following syntax.
X.500の標準の属性の1つがfacsimileTelephoneNumber[12]である、2.5、.4、.23、以下の構文を持つために、定義されます。facsimileTelephoneNumberはOBJECT IDENTIFIERと同一視されています。
FacsimileTelephoneNumber ::= SEQUENCE {
telephoneNumber PrintableString(SIZE(1..ub-telephone-number)),
parameters G3FacsimileNonBasicParameters OPTIONAL }
FacsimileTelephoneNumber:、:= 系列telephoneNumber PrintableString(SIZE(1..ub-電話番号))、パラメタG3FacsimileNonBasicParameters OPTIONAL
The component reference "value.(2.5.4.23)" on AttributeTypeAndValue specifies an attribute value with the FacsimileTelephoneNumber syntax.
コンポーネント参照、「値、(2.5 .4 .23) 」 AttributeTypeAndValueでは、FacsimileTelephoneNumber構文がある属性値は指定しています。
The component reference "value.(2.5.4.23).telephoneNumber" on AttributeTypeAndValue identifies the telephoneNumber component of a facsimileTelephoneNumber attribute value. The component reference "value.(facsimileTelephoneNumber)" is equivalent to "value.(2.5.4.23)".
コンポーネント参照、「値、(2.5、.4、.23).telephoneNumber、」 AttributeTypeAndValueでは、facsimileTelephoneNumber属性値のtelephoneNumberの部品を特定します。 コンポーネント参照「値(facsimileTelephoneNumber)」が相当している、「値、(2.5、.4、.23)、」
If the AttributeTypeAndValue ASN.1 value contains an attribute type other than facsimileTelephoneNumber then there are no corresponding component values for the component references "value.(2.5.4.23)" and "value.(2.5.4.23).telephoneNumber".
AttributeTypeAndValue ASN.1値がfacsimileTelephoneNumber以外の属性タイプを含むならコンポーネント参照のためのどんな対応する成分値もない、「値、(2.5、.4、.23)、」、「値、(2.5、.4、.23).telephoneNumber、」
Legg Standards Track [Page 13] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[13ページ]。
3.1.7. Referencing Contained Types
3.1.7. 含まれたタイプに、参照をつけます。
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.
時々、BIT STRINGかOCTET STRING価値の内容が、特定のASN.1タイプの他のASN.1値のencodingsになるのに必要です。 例えば、Certificateタイプ[11]のExtensionタイプ成分のextnValueの部品は[17] 証明書拡大価値がコード化されながらDistinguished Encoding Rules(DER)を含むのに必要であるOCTET STRINGです。 埋め込まれたコード化された値とそのコンポーネントについて言及できるのは役に立ちます。 含まれたタイプとして含まれた値とその関連タイプに言及されて、埋め込まれたコード化された値がここにあります。
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タイプがBIT STRINGであるか他のASN.1値のencodingsを含んでいて、OCTET STRINGがタイプするなら、ComponentIdの<の満足している>フォームは、含まれたタイプを特定するのに使用されるかもしれません。 そして、そのタイプのサブコンポーネントを一層のComponentIdsと同一視できます。
The contained type may be (effectively) an open type, constrained by some other component in an outer enclosing type (e.g., in a certificate Extension, extnValue is constrained by the chosen extnId). In these cases the next ComponentId, if any, MUST be of the <select> form.
含まれたタイプは(事実上)ある他のコンポーネントによって外側の同封のタイプで抑制された開放型であるかもしれません(例えば、証明書Extensionでは、extnValueは選ばれたextnIdによって抑制されます)。 これらの場合では、もしあれば次のComponentIdは<の選んだ>フォームのものであるに違いありません。
For the purpose of building component references, the content of the extnValue OCTET STRING in the Extension type is assumed to be an open type having a notional component relation constraint with the extnId component as the single referenced component, i.e.,
建築部材参照の目的のために、ExtensionタイプのextnValue OCTET STRINGの内容はすなわちただ一つの参照をつけられたコンポーネントとしてextnIdの部品がある概念的なコンポーネント関係規制を持っている開放型であると思われます。
EXTENSION.&ExtnType ({ExtensionSet}{@extnId})
拡大ExtnType(ExtensionSet、@extnId)
The data-value component of the associated types for the EMBEDDED PDV and CHARACTER STRING types is an OCTET STRING containing the encoding of a data value described by the identification component. For the purpose of building component references, the content of the data-value OCTET STRING in these types is assumed to be an open type having a notional component relation constraint with the identification component as the single referenced component.
EMBEDDED PDVとCHARACTER STRINGタイプのための関連タイプのデータ価値の成分は識別コンポーネントによって説明されたデータ価値のコード化を含むOCTET STRINGです。 建築部材参照の目的のために、これらのタイプのデータ価値のOCTET STRINGの内容はただ一つの参照をつけられたコンポーネントとして識別コンポーネントがある概念的なコンポーネント関係規制を持っている開放型であると思われます。
3.1.7.1. Contained Type Referencing Example
3.1.7.1. 例に参照をつけている含まれたタイプ
The Extension ASN.1 type [11] describes a single certificate extension value of a nominated extension type.
Extension ASN.1タイプ[11]は指名拡大タイプのただ一つの証明書拡大価値について説明します。
Legg Standards Track [Page 14] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[14ページ]。
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 -- }
拡大:、:= 系列extnId EXTENSIONイド(ExtensionSet)、重要なBOOLEAN DEFAULT FALSE、extnValue OCTET STRING--タイプの価値をコード化するDERとextnIdによって特定された拡大オブジェクトのためのExtnTypeを含んでいます--
EXTENSION.&id denotes an OBJECT IDENTIFIER and ({ExtensionSet})
constrains the OBJECT IDENTIFIER to be the identifier of a supported
certificate extension.
EXTENSIONイドはOBJECT IDENTIFIERを指示して、(ExtensionSet)は、OBJECT IDENTIFIERがサポートしている証明書拡張子に関する識別子であることを抑制します。
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.
Extensionのコンポーネント参照"extnValue"はOCTET STRINGのコンポーネント型を示します。 対応する成分値はOCTET STRING値になるでしょう。 Extensionのコンポーネント参照"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つがOBJECT IDENTIFIERと同一視されているbasicConstraintsである、2.5、.29、.19、以下の構文を持つために、定義されます。
BasicConstraintsSyntax ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
BasicConstraintsSyntax:、:= 系列cA論理演算子は誤っていて、pathLenConstraint整数(0..MAX)任意の状態でデフォルトとします。
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)、」、ExtensionでBasicConstraintsSyntax拡大価値とコンポーネント参照を指定する、「extnValue.content、(2.5、.29、.19).cA、」 BasicConstraintsSyntax拡大価値のcAの部品を特定します。
3.2. Matching of Components
3.2. コンポーネントのマッチング
The rule in a ComponentAssertion specifies how the zero, one or more component values identified by the component reference are tested by the assertion. Attribute matching rules are used to specify the semantics of the test.
ComponentAssertionの規則はゼロでありコンポーネント参照で特定された1つ以上の成分値が主張でどうテストされるかを指定します。 属性マッチング規則は、テストの意味論を指定するのに使用されます。
Each matching rule has a notional set of attribute syntaxes (typically one), defined as ASN.1 types, to which it may be applied. When used in a ComponentAssertion these matching rules apply to the same ASN.1 types, only in this context the corresponding ASN.1 values are not necessarily complete attribute values.
それぞれの合っている規則には、それが適用されるかもしれないASN.1タイプと定義された概念的なセットの属性構文(通常1)があります。 これらの合っている規則が同じASN.1タイプに当てはまるComponentAssertionで使用されると、このような関係においてはだけ対応する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
参照をつけられたコンポーネント型が予想された属性構文([0] INTEGER、integerMatchはそうするでしょうが、例えば、単にINTEGERを予想する)のタグ付けをされたそして/または、制約つきなバージョン、または開放型であるかもしれないことに注意してください。 中で説明された種類の追加タイプ代替
Legg Standards Track [Page 15] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[15ページ]。
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.
合っている規則が1つ以上の属性構文に適用される、(例えば、objectIdentifierFirstComponentMatch、[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:
ComponentAssertionがUndefinedである、:
a) the matching rule in the ComponentAssertion is not known to the
evaluating procedure,
a) ComponentAssertionの合っている規則は評価手順に知られていません。
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がUndefinedでないなら、ComponentAssertionは、少なくとも1つの成分値が値がTRUEを返すそのコンポーネントに当てはまってそうでなければ(成分値が全くないケースを含んでいる)合っている規則がFALSEに評価するもののためにあるかをTRUEに評価します。
Legg Standards Track [Page 16] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[16ページ]。
3.2.1. Applicability of Existing Matching Rules
3.2.1. 規則を合わせながら存在する適用性
3.2.1.1. String Matching
3.2.1.1. ストリングマッチング
ASN.1 has a number of built in restricted character string types with different character sets and/or different character encodings. A directory user generally has little interest in the particular character set or encoding used to represent a character string component value, and some directory server implementations make no distinction between the different string types in their internal representation of values. So rather than define string matching rules for each of the restricted character string types, the existing case ignore and case exact string matching rules are extended to apply to component values of any of the restricted character string types and any ChoiceOfStrings type [9], in addition to component values of the DirectoryString type. This extension is only for the purposes of component matching described in this document.
ASN.1には、多くの制限された文字列タイプにおける異なった文字集合による組立の、そして/または、異なった文字符号化があります。 コード化は以前はよく文字列成分価値を表していました、そして、一般に、ディレクトリユーザが特定の文字集合にわずかの関心を持っているか、またはいくつかのディレクトリサーバ実装は異なったストリングタイプの間で彼らの値の内部の表現で区別を全くしません。 それで、既存のケースは、制限された文字列タイプのどれかの成分値に適用するために文字列制限されたタイプ各人のためにストリングマッチング規則を定義するよりむしろ、広げられた正確なストリングマッチング規則を、無視して、ケースに入れます、そして、どんなChoiceOfStringsも[9]をタイプします、DirectoryStringタイプの成分値に加えて。 この拡大は本書では説明されたコンポーネントマッチングの目的のためだけのものです。
The relevant string matching rules are: caseIgnoreMatch,
caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, caseExactMatch,
caseExactOrderingMatch and caseExactSubstringsMatch. The relevant
restricted character string types are: NumericString,
PrintableString, VisibleString, IA5String, UTF8String, BMPString,
UniversalString, TeletexString, VideotexString, GraphicString and
GeneralString. A ChoiceOfStrings type is a purely syntactic CHOICE
of these ASN.1 string types. Note that GSER [9] declares each and
every use of the DirectoryString{} parameterized type to be a
ChoiceOfStrings type.
関連ストリングマッチング規則は以下の通りです。 caseIgnoreMatch、caseIgnoreOrderingMatch、caseIgnoreSubstringsMatch、caseExactMatch、caseExactOrderingMatch、およびcaseExactSubstringsMatch。 関連制限された文字列タイプは以下の通りです。 NumericString、PrintableString、VisibleString、IA5String、UTF8String、BMPString、UniversalString、TeletexString、VideotexString、GraphicString、およびGeneralString。 ChoiceOfStringsタイプはこれらのASN.1ストリングタイプの純粋に構文のCHOICEです。 GSER[9]がDirectoryStringのありとあらゆる使用を宣言することに注意してください、ChoiceOfStringsであるparameterizedタイプはタイプします。
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です。 したがって、実装が制限された文字列タイプのひとりの値にDirectoryString値をたとえるのが要求されるか、またはChoiceOfStringsはタイプします。 異なったストリングタイプには選ばれた代替手段がある2DirectoryStringsを比較するとき、そうであるように、対応するキャラクタが両方の文字集合で「表-可能」である限り、比較は続きます。 さもなければ、マッチングはFALSEを返します。
3.2.1.2. Telephone Number Matching
3.2.1.2. 電話番号マッチング
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,
X.520[12]の早版は強制的なPrintableStringとしてtelephoneNumber属性の構文を与えました。 X.520の4番目の版は、TelephoneNumberというASN.1型名を強制的なPrintableStringと同一視して、属性と主張構文としてTelephoneNumberを使用します。 コンポーネントマッチングの目的のために
Legg Standards Track [Page 17] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[17ページ]。
telephoneNumberMatch and telephoneNumberSubstringsMatch are permitted to be applied to any PrintableString value, as well as to TelephoneNumber values.
よくTelephoneNumber値のようにtelephoneNumberMatchとtelephoneNumberSubstringsMatchによってどんなPrintableString値にも適用されることが許可されています。
3.2.1.3. Distinguished Name Matching
3.2.1.3. 分類名マッチング
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.
DistinguishedNameタイプはRDNSequenceがタイプするのと同じになるように課題で定義されて、しかしながら、RDNSequenceは他の型定義に直接時々使用されます。 また、コンポーネントマッチングの目的のために、distinguishedNameMatchによってRDNSequenceタイプの値に適用されることが許可されています。
3.2.2. Additional Useful Matching Rules
3.2.2. 追加役に立つ合っている規則
This section defines additional matching rules that may prove useful in ComponentAssertions. These rules may also be used in extensibleMatch search filters [3].
このセクションはComponentAssertionsで有用であることが分かるかもしれない追加合っている規則を定義します。 また、これらの規則はextensibleMatch検索フィルタ[3]で使用されるかもしれません。
3.2.2.1. The rdnMatch Matching Rule
3.2.2.1. rdnMatchの合っている規則
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でDistinguished Name(DN)で他のRDNsへの尊敬なしで特定のRelative Distinguished Names(RDNs)を合わせることができるのは時々役に立ちます。 rdnMatchの合っている規則は、DNのコンポーネントRDNsがテストされるのを許容します。
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名'rdnMatch'構文1.2.36.79672281の.1、.5、.0)
( 1.2.36.79672281.1.5.0 DESC 'RDN' )
(1.2、.36、.79672281、.1、.5、.0DESC'RDN')
The LDAP-specific encoding for a value of the RDN syntax is given by the <RelativeDistinguishedNameValue> rule [9].
<RelativeDistinguishedNameValue>規則[9]でRDN構文の値のためのLDAP特有のコード化を与えます。
The X.500-style definition for rdnMatch is:
rdnMatchのためのX.500-スタイル定義は以下の通りです。
rdnMatch MATCHING-RULE ::= {
SYNTAX RelativeDistinguishedName
ID { 1 2 36 79672281 1 13 3 } }
rdnMatchは以下をマッチングで統治します:= 構文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比較メソッドを使用して。
Legg Standards Track [Page 18] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[18ページ]。
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特有のコード化がRDNsの注文を逆にすることに注意するのは重要です。 それで、「cnはスティーブンLeggと等しいです、o=Adacel、c=Au」としてLDAPに表されたDNに関してRDN「cn=スティーブンLegg」がコンポーネント参照に対応している、「3インチ、またはあるいはまた、「1インチ。」
3.2.2.2. The presentMatch Matching Rule
3.2.2.2. presentMatchの合っている規則
At times it would be useful to test not if a specific value of a particular component is present, but whether any value of a particular component is present. The presentMatch matching rule allows the presence of a particular component value to be tested.
時には、特定のコンポーネントのどんな値も存在しているか否かに関係なく、テストするのは特定のコンポーネントの特定の値が存在していて、役に立つのではなく、役に立つでしょう。 presentMatchの合っている規則は、特定の成分価値の存在がテストされるのを許容します。
The LDAP-style definitions for presentMatch and its assertion syntax are:
presentMatchのためのLDAP-スタイル定義とその主張構文は以下の通りです。
( 1.2.36.79672281.1.13.5 NAME 'presentMatch'
SYNTAX 1.2.36.79672281.1.5.1 )
(1.2.36.79672281.1.13.5名'presentMatch'構文1.2.36.79672281の.1、.5、.1)
( 1.2.36.79672281.1.5.1 DESC 'NULL' )
(1.2.36.79672281.1.5.1DESC'ヌル')
The LDAP-specific encoding for a value of the NULL syntax is given by the <NullValue> rule [9].
<NullValue>規則[9]でNULL構文の値のためのLDAP特有のコード化を与えます。
The X.500-style definition for presentMatch is:
presentMatchのためのX.500-スタイル定義は以下の通りです。
presentMatch MATCHING-RULE ::= {
SYNTAX NULL
ID { 1 2 36 79672281 1 13 5 } }
presentMatchは以下をマッチングで統治します:= 構文のヌルID、1 2、36 79672281、1、13、5
When used in a extensible match filter item, presentMatch behaves like the "present" case of a regular search filter. In a ComponentAssertion, presentMatch evaluates to TRUE if and only if the component reference identifies one or more component values, regardless of the actual component value contents. Note that if useDefaultValues is TRUE then the identified component values may be (part of) a DEFAULT value.
広げることができるマッチフィルタの品目で使用されると、presentMatchは通常の検索フィルタの「現在」のケースのように振る舞います。 そして、ComponentAssertion、presentMatch、TRUEに関する評価、コンポーネント参照が実際のコンポーネント価値内容にかかわらず1つ以上の成分値を特定する場合にだけ。 特定された成分値がuseDefaultValuesがTRUEであるならそうであることに注意してください、(離れている、)、DEFAULT値。
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.
そうでなければ、SET OF値が現在であって、欠けるなら、存在しているようにComponentIdの<カウント>フォームによって参照をつけられる概念的なカウントを取ります。 ASN.1記法において、欠けているSET OF値が現在の、しかし、空のSET OF値と明瞭に異なっていることに注意してください。 それは、区別が重要であるかどうか決めるのにASN.1記法を使用することで仕様まで達しています。 しばしば、空のSET OFの部品と欠けているSET OFの部品は意味的に同等であるとして扱われます。 SET OF値がpresentMatchを提示しますが、空にすることであるなら、ゼロに合わせるために現在であって等しいとSET OFコンポーネントSHALLリターンTRUEと概念的なカウントSHALLに見なされてください。
Legg Standards Track [Page 19] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[19ページ]。
3.2.3. Summary of Useful Matching Rules
3.2.3. 役に立つ合っている規則の概要
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 | |
+================================+==============================+ | マッチング規則| ASN.1はタイプします。| +================================+==============================+ | bitStringMatch| ビット列| +--------------------------------+------------------------------+ | booleanMatch| 論理演算子| +--------------------------------+------------------------------+ | caseIgnoreMatch| NumericString| | caseIgnoreOrderingMatch| PrintableString| | caseIgnoreSubstringsMatch| VisibleString(ISO646String)| | caseExactMatch| IA5String| | caseExactOrderingMatch| UTF8String| | caseExactSubstringsMatch| BMPString(UCS-2、ユニコード)| | | UniversalString(UCS-4)| | | TeletexString(T61String)| | | VideotexString| | | GraphicString| | | GeneralString| | | どんなChoiceOfStringsもタイプします。| +--------------------------------+------------------------------+ | caseIgnoreIA5Match| IA5String| | caseExactIA5Match| | +--------------------------------+------------------------------+ | distinguishedNameMatch| DistinguishedName| | | RDNSequence| +--------------------------------+------------------------------+ | generalizedTimeMatch| GeneralizedTime| | generalizedTimeOrderingMatch| | +--------------------------------+------------------------------+ | integerMatch| 整数| | integerOrderingMatch| | +--------------------------------+------------------------------+ | numericStringMatch| NumericString| | numericStringOrderingMatch| | | numericStringSubstringsMatch| | +--------------------------------+------------------------------+ | objectIdentifierMatch| オブジェクト識別子| +--------------------------------+------------------------------+ | octetStringMatch| 八重奏ストリング| | octetStringOrderingMatch| | | octetStringSubstringsMatch| |
Legg Standards Track [Page 20] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[20ページ]。
+--------------------------------+------------------------------+
| presentMatch | any ASN.1 type |
+--------------------------------+------------------------------+
| rdnMatch | RelativeDistinguishedName |
+--------------------------------+------------------------------+
| telephoneNumberMatch | PrintableString |
| telephoneNumberSubstringsMatch | TelephoneNumber |
+--------------------------------+------------------------------+
| uTCTimeMatch | UTCTime |
| uTCTimeOrderingMatch | |
+--------------------------------+------------------------------+
+--------------------------------+------------------------------+ | presentMatch| どんなASN.1もタイプします。| +--------------------------------+------------------------------+ | 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.
ENUMERATEDとNULLとレアルと特にRELATIVE-OID ASN.1タイプの値の平等マッチングにセクション6.2で定義されたallComponentsMatchの合っている規則は使用できることに注意してください。
4. ComponentFilter
4. ComponentFilter
The ComponentAssertion allows the value(s) of any one component type in a complex ASN.1 type to be matched, but there is often a desire to match the values of more than one component type. A ComponentFilter is an assertion about the presence, or values of, multiple components within an ASN.1 value.
ComponentAssertionは複雑なASN.1タイプのどんなコンポーネント型の値も合わせさせますが、1つ以上のコンポーネント型の値を合わせる願望がしばしばあります。 A ComponentFilterが存在、または値に関する主張である、ASN.1価値の中の複数のコンポーネント。
The ComponentFilter assertion, an expression of ComponentAssertions, evaluates to either TRUE, FALSE or Undefined for each tested ASN.1 value.
ComponentFilter主張(ComponentAssertionsの式)はそれぞれのテストされたASN.1価値のためにTRUE、FALSEまたはUndefinedをどちらかに評価します。
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 }
ComponentFilter:、:= 選択[3]ComponentFilterではなく、項目[0]ComponentAssertionと、[1]SEQUENCE OF ComponentFilterか、[2]SEQUENCE OF ComponentFilter
Note: despite the use of SEQUENCE OF instead of SET OF for the "and" and "or" alternatives in ComponentFilter, the order of the component filters is not significant.
以下に注意してください。 ComponentFilterにおける、SET OFの代わりにSEQUENCE OFの“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.
そして、ComponentAssertionであるA ComponentFilterが、ComponentAssertionがTRUEであるかどうかTRUEに評価して、ComponentAssertionがFALSEであるかどうかFALSEに評価する、そうでなければ、Undefinedに評価します。
Legg Standards Track [Page 21] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[21ページ]。
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.
そして、コンポーネントフィルタの系列の“and"が系列が空であるか、それぞれのコンポーネントのフィルタであるならTRUEに評価する、評価、TRUEに少なくとも1個のコンポーネントフィルタがFALSEであるかどうかFALSEに評価する、そうでなければ、Undefinedに評価します。
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.
そして、コンポーネントフィルタの系列の“or"が系列が空であるか、それぞれのコンポーネントのフィルタであるならFALSEに評価する、評価、FALSEに少なくとも1個のコンポーネントフィルタがTRUEであるかどうかTRUEに評価する、そうでなければ、Undefinedに評価します。
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"が、コンポーネントフィルタがFALSEであるかどうかTRUEに評価して、コンポーネントフィルタがTRUEであるかどうかFALSEに評価する、そうでなければ、Undefinedに評価します。
5. The componentFilterMatch Matching Rule
5. componentFilterMatchの合っている規則
The componentFilterMatch matching rule allows a ComponentFilter to be applied to an attribute value. The result of the matching rule is the result of applying the ComponentFilter to the attribute value.
componentFilterMatchの合っている規則は、ComponentFilterが属性値に適用されるのを許容します。 マッチング規則の結果はComponentFilterを属性値に適用するという結果です。
The LDAP-style definitions for componentFilterMatch and its assertion syntax are:
componentFilterMatchのためのLDAP-スタイル定義とその主張構文は以下の通りです。
( 1.2.36.79672281.1.13.2 NAME 'componentFilterMatch'
SYNTAX 1.2.36.79672281.1.5.2 )
(1.2.36.79672281.1.13.2名'componentFilterMatch'構文1.2.36.79672281の.1、.5、.2)
( 1.2.36.79672281.1.5.2 DESC 'ComponentFilter' )
(1.2、.36、.79672281、.1、.5、.2DESC'ComponentFilter')
The LDAP-specific encoding for the ComponentFilter assertion syntax is specified by GSER [9].
ComponentFilter主張構文のためのLDAP特有のコード化はGSER[9]によって指定されます。
As a convenience to implementors, an equivalent ABNF description of the GSER encoding for ComponentFilter is provided here. In the event that there is a discrepancy between this ABNF and the encoding determined by GSER, GSER is to be taken as definitive. The GSER encoding of a ComponentFilter is described by the following equivalent ABNF:
作成者への便利として、ComponentFilterのためのGSERコード化の同等なABNF記述をここに提供します。 GSERで決定しているこのABNFとコード化の間には、食い違いがある場合、GSERは決定的であるとしてみなされることになっています。 ComponentFilterのGSERコード化は以下の同等なABNFによって説明されます:
ComponentFilter = filter-item /
and-filter /
or-filter /
not-filter
または、そして、ComponentFilterがフィルタ品目/と等しい、-、フィルタ、/、-、フィルタ、/フィルタでない
filter-item = item-chosen ComponentAssertion
and-filter = and-chosen SequenceOfComponentFilter
or-filter = or-chosen SequenceOfComponentFilter
not-filter = not-chosen ComponentFilter
または、または、そして、そして、フィルタ品目=項目に選ばれたComponentAssertion、-、フィルタ、等しさ、-、選ぶ、SequenceOfComponentFilter、-、フィルタ、等しさ、-、選ぶ、SequenceOfComponentFilterはComponentFilterが選ばれなかった=をフィルターにかけません。
Legg Standards Track [Page 22] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[22ページ]。
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:"
項目に選ばれた=%x69.74.65.6D.3A。 「項目:」 そして、-、選ぶ、=%x61.6E.64.3A。 そして、「:、」 または、-、選ぶ、=%x6F.72.3A。 または、「:、」 選ばれなかった=%x6E.6F.74.3A。 「:、」
SequenceOfComponentFilter = "{" [ sp ComponentFilter
*( "," sp ComponentFilter) ] sp "}"
SequenceOfComponentFilterが等しい、「「[sp ComponentFilter*、(「」、sp ComponentFilter] sp、」、」
ComponentAssertion = "{" [ sp component "," ]
[ sp useDefaultValues "," ]
sp rule ","
sp assertion-value sp "}"
component = component-label msp StringValue
useDefaultValues = use-defaults-label msp BooleanValue
rule = rule-label msp ObjectIdentifierValue
assertion-value = value-label msp Value
「ComponentAssertionが等しい、「「[spの部品、」、」、]、[sp useDefaultValues、」、」、]、sp規則、」、」 sp主張価値のsp、」、」 成分=コンポーネントラベルmsp StringValue useDefaultValues=デフォルトがラベルする使用msp BooleanValue規則=規則ラベルmsp ObjectIdentifierValue主張価値は値ラベルmsp価値と等しいです。
component-label = %x63.6F.6D.70.6F.6E.65.6E.74 ; "component"
use-defaults-label = %x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75
%x65.73 ; "useDefaultValues"
rule-label = %x72.75.6C.65 ; "rule"
value-label = %x76.61.6C.75.65 ; "value"
コンポーネントラベル=%x63.6F.6D.70.6F.6E.65.6E.74。 デフォルトがラベルする「コンポーネント」使用=%x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75%x65.73。 「useDefaultValues」規則ラベル=%x72.75.6C.65。 値ラベル=%x76.61.6C.75.65は「統治します」。 「値」
sp = *%x20 ; zero, one or more space characters
msp = 1*%x20 ; one or more space characters
sp=*%x20。 1*%ゼロ、1間隔文字msp=x20。 1つ以上の間隔文字
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特有のencodingsのABNF記述は明確にか一貫して属性値のコンポーネントの部品を通常図で表わしません。 任意のコンポーネントデータ型のためにコード化される通常の、そして、一定の文字列が、ComponentAssertionで主張値をコード化するのに必要です。 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 } }
componentFilterMatchは以下をマッチングで統治します:= 構文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
ComponentAssertionが潜在的にどんな合っている規則も使用できるので、componentFilterMatchを含んでいて、componentFilterMatchは入れ子にされるかもしれません。 入れ子にされたcomponentFilterMatchでの参照に比例しているコンポーネント
Legg Standards Track [Page 23] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[23ページ]。
the component corresponding to the containing ComponentAssertion. In Section 7, an example search on the seeAlso attribute shows this usage.
含んでいるComponentAssertionに対応するコンポーネント。 セクション7では、seeAlso属性における例の検索はこの用法を示しています。
6. Equality Matching of Complex Components
6. 複雑なコンポーネントの平等マッチング
It is possible to test if an attribute value of a complex ASN.1 syntax is the same as some purported (i.e., assertion) value by using a complicated ComponentFilter that tests if corresponding components are the same. However, it would be more convenient to be able to present a whole assertion value to a matching rule that could do the component-wise comparison of an attribute value with the assertion value for any arbitrary attribute syntax. Similarly, the ability to do a straightforward equality comparison of a component value that is itself of a complex ASN.1 type would also be convenient.
複雑なASN.1構文の属性値が或るものが対応するコンポーネントが同じであるならテストする複雑なComponentFilterを使用することによって値を意味したのと(すなわち、主張)同じであるなら、テストするのは可能です。 しかしながら、どんな任意の属性構文のためにも主張値で属性値のコンポーネント的な比較ができた合っている規則に全体の主張値を提示できるのは、より便利でしょう。 また、同様に、それ自体がいる成分価値の簡単な平等比較をする能力も便利です複雑なASN.1が、タイプする。
It would be difficult to define a single matching rule that simultaneously satisfies all notions of what the equality matching semantics should be. For example, in some instances a case sensitive comparison of string components may be preferable to a case insensitive comparison. Therefore a basic equality matching rule, allComponentsMatch, is defined in Section 6.2, and the means to derive new matching rules from it with slightly different equality matching semantics are described in Section 6.3.
同時に平等の合っている意味論が何であるべきであるかに関するすべての概念を満たすただ一つの合っている規則を定義するのは難しいでしょう。 例えば、ある場合にストリングの部品の大文字と小文字を区別する比較は大文字と小文字を区別しない比較より望ましいかもしれません。 したがって、基本的な平等合っている規則(allComponentsMatch)はセクション6.2で定義されます、そして、わずかに異なった平等合っている意味論でそれから新しい合っている規則を得る手段はセクション6.3で説明されます。
The directoryComponentsMatch defined in Section 6.4 is a derivation of allComponentsMatch that suits typical uses of the directory. Other specifications are free to derive new rules from allComponentsMatch or directoryComponentsMatch, that suit their usage of the directory.
セクション6.4で定義されたdirectoryComponentsMatchはディレクトリの典型的な用途に合うallComponentsMatchの派生です。 他の仕様が新しい規則にallComponentsMatchかdirectoryComponentsMatchに無料で由来できて、その訴訟はそれらのディレクトリの使用法です。
The allComponentsMatch rule, the directoryComponentsMatch rule and any matching rules derived from them are collectively called component equality matching rules.
allComponentsMatch規則、directoryComponentsMatch規則、およびそれらから得られたどんな合っている規則もまとめてコンポーネントの平等の合っている規則と呼ばれます。
6.1. The OpenAssertionType Syntax
6.1. OpenAssertionType構文
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では、これは、MATCHING-RULE情報オブジェクトの任意のSYNTAX分野を省略することによって、示されます。 次に、主張構文は実際の用法で目標属性の構文をデフォルトとします、合っている規則の記述がそうでなく言わない場合。 MatchingRuleDescriptionのLDAP特有のコード化におけるSYNTAX分野が義務的であるので、OpenAssertionType構文は同じ役割をいっぱいにするために定義されます。 すなわち、OpenAssertionType構文はX.500 MATCHING-RULE情報オブジェクトの省略されたSYNTAX分野に意味的に同等です。 属性構文として属性型定義にOpenAssertionTypeを使用してはいけません。
Legg Standards Track [Page 24] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[24ページ]。
Unless explicitly varied by the description of a particular matching rule, if an OpenAssertionType assertion value appears in a ComponentAssertion its LDAP-specific encoding is described by the <Value> rule in GSER [9], otherwise its LDAP-specific encoding is the encoding defined for the syntax of the attribute type to which the matching rule with the OpenAssertionType assertion syntax is applied.
OpenAssertionType主張価値がComponentAssertionに現れて、特定の合っている規則の記述で明らかに変えられない場合、LDAP特有のコード化はGSER[9]で<Value>規則で説明されます。さもなければ、LDAP特有のコード化はOpenAssertionType主張構文がある合っている規則が適用されている属性タイプの構文のために定義されたコード化です。
The LDAP definition for the OpenAssertionType syntax is:
OpenAssertionType構文のためのLDAP定義は以下の通りです。
( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' )
(1.2、.36、.79672281、.1、.5、.3DESC'OpenAssertionType')
6.2. The allComponentsMatch Matching Rule
6.2. allComponentsMatchの合っている規則
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、.5、.3)
The X.500-style definition for allComponentsMatch is:
allComponentsMatchのためのX.500-スタイル定義は以下の通りです。
allComponentsMatch MATCHING-RULE ::= {
ID { 1 2 36 79672281 1 13 6 } }
allComponentsMatchは以下をマッチングで統治します:= ID、1 2、36 79672281、1、13、6
When allComponentsMatch is used in a ComponentAssertion the assertion syntax is the same as the ASN.1 type of the identified component. Otherwise, the assertion syntax of allComponentsMatch is the same as the attribute syntax of the attribute to which the matching rule is applied.
allComponentsMatchがComponentAssertionで使用されるとき、主張構文は特定されたコンポーネントのASN.1タイプと同じです。 さもなければ、allComponentsMatchの主張構文はマッチングが統治される属性の属性構文が適用されているのと同じです。
Broadly speaking, this matching rule evaluates to true if and only if corresponding components of the assertion value and the attribute or component value are the same.
概して、この合っている規則が本当に評価する、そして、値と属性か成分値が同じであるという主張の唯一の、しかし、対応するコンポーネント。
In detail, equality is determined by the following cases applied recursively.
詳細に、平等は再帰的に適用された以下のケースで決定します。
a) Two values of a SET or SEQUENCE type are the same if and only if,
for each component type, the corresponding component values are
either,
a) そして、SETかSEQUENCEタイプの2つの値が同じである、対応する成分値が各コンポーネント型のためのどちらか場合にだけ
1) both absent,
1) ともに休みます。
2) both present and the same, or
または2) 現在であって、かつ同じである。
3) absent or the same as the DEFAULT value for the component, if a
DEFAULT value is defined.
DEFAULT値が定義されるならDEFAULTがコンポーネントのために評価するのと3) 休むか、または同じです。
Legg Standards Track [Page 25] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[25ページ]。
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).
彼らのそれぞれの関連SEQUENCEタイプに従って、EMBEDDED PDV、EXTERNAL、無制限なCHARACTER STRING、またはINSTANCE OFタイプの値は比較されます(セクション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) SEQUENCE OFタイプの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) SET OFタイプの2つの値が同じである、すなわち両方の値には、単に値では、同じ数のインスタンスがあって、それぞれの異なったインスタンスは同じくらいが付番する回の両方の値で起こって、写しを含んでいますが、どんなオーダーでもそうする同じインスタンスがあります。
d) Two values of a CHOICE type are the same if and only if, both
values are of the same chosen alternative and the component values
are the same.
d) CHOICEタイプの2つの値が同じである、唯一、両方の値は同じ選ばれた代替手段のものであり、成分値は同じです。
e) Two BIT STRING values are the same if and only if the values have
the same number of bits and corresponding bits are the same. If
the BIT STRING type is defined with a named bit list then trailing
zero bits in the values are treated as absent for the purposes of
this comparison.
e) 2つのBIT STRING値が同じである、値に同じ数のビットと対応するビットがある場合にだけ、同じくらいはそうです。 BIT STRINGタイプが命名された噛み付いているリストで定義されるなら、値における引きずっているゼロ・ビットはこの比較の目的のために休んだ状態で扱われます。
f) Two BOOLEAN values are the same if and only if both are TRUE or
both are FALSE.
f) 2つのブール値が同じである、両方がTRUEか両方である場合にだけ、FALSEはそうです。
g) Two values of a string type are the same if and only if the values
have the same number of characters and corresponding characters
are the same. Letter case is significant. For the purposes of
allComponentsMatch, the string types are NumericString,
PrintableString, TeletexString (T61String), VideotexString,
IA5String, GraphicString, VisibleString (ISO646String),
GeneralString, UniversalString, BMPString, UTF8String,
GeneralizedTime, UTCTime and ObjectDescriptor.
g) ストリングタイプの2つの値が同じである、値に同じ数のキャラクタと対応するキャラクタがある場合にだけ、同じくらいはそうです。 レターケースは重要です。 allComponentsMatchの目的のために、ストリングタイプは、NumericStringと、PrintableStringと、TeletexString(T61String)と、VideotexStringと、IA5Stringと、GraphicStringと、VisibleString(ISO646String)と、GeneralStringと、UniversalStringと、BMPStringと、UTF8Stringと、GeneralizedTimeと、UTCTimeとObjectDescriptorです。
h) Two INTEGER values are the same if and only if the integers are
equal.
h) そして、2つのINTEGER値が同じである、整数が等しい場合にだけ。
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つのENUMERATED値が同じである、列挙項目識別子である場合にだけ、同じくらい(同等に、識別子に関連している値は整数であるなら等しい)はそうです。
j) Two NULL values are always the same, unconditionally.
j) 2つのNULL値がいつも無条件に同じです。
k) Two OBJECT IDENTIFIER values are the same if and only if the
values have the same number of arcs and corresponding arcs are the
same.
k) 2つのOBJECT IDENTIFIER値が同じである、値に同じ数のアークと対応するアークがある場合にだけ、同じくらいはそうです。
Legg Standards Track [Page 26] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[26ページ]。
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つのOCTET STRING値が同じである、値に同じ数の八重奏と対応する八重奏がある場合にだけ、同じくらいはそうです。
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つのレアル値が同じである、特別な値もそうでなく、それらがともに同じ特別な値であるか彼らが同じベースを持って、同じ実数を表す場合にだけ。 レアルの特別な値は、ゼロと、PLUS-INFINITYとMINUS-INFINITYです。
n) Two RELATIVE-OID values are the same if and only if the values
have the same number of arcs and corresponding arcs are the same.
The respective starting nodes for the RELATIVE-OID values are
disregarded in the comparison, i.e., they are assumed to be the
same.
n) 2つのRELATIVE-OID値が同じである、値に同じ数のアークと対応するアークがある場合にだけ、同じくらいはそうです。 RELATIVE-OID値のためのそれぞれの始めのノードは比較で無視されます、すなわち、同じであると思われます。
o) Two values of an open type are the same if and only if both are of
the same ASN.1 type and are the same according to that type. If
the actual ASN.1 type of the values is unknown then the
allComponentsMatch rule evaluates to Undefined.
o) 開放型の2つの値が同じである、両方が同じASN.1のものである場合にだけタイプしてください、そして、そのタイプに従った同じくらいはタイプします。 値の実際のASN.1タイプであるなら、未知はallComponentsMatch規則がUndefinedに評価するその時ですか?
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規則は使用されるかもしれません。
6.3. Deriving Component Equality Matching Rules
6.3. コンポーネントの平等の合っている規則を引き出します。
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
============+===============
|
|
コンポーネント| マッチング規則============+=============== | |
Legg Standards Track [Page 27] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[27ページ]。
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が参照(例えば、DistinguishedName)をタイプするか、またはテーブルに関するComponentコラムのASN.1内蔵型名(例えば、INTEGER)は、指名平等合っている規則が命名されたタイプのすべての値に適用されることであると指定します、文脈にかかわらず。
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はコンポーネント参照を追加している状態で参照をタイプします。「(a」によって切り離される、」、)、指名合っている規則が命名されたタイプの値の特定されたコンポーネントだけに適用されると指定します。 同じ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.
概念的に、派生規則の合っている意味論について決める目的のための派生規則のために基底部規則のためのテーブルの行をテーブルの行に追加します。 Notionallyに、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.
外側の含有の指定値がタイプする行(例えば、DistinguishedName)は内側のコンポーネント型(例えば、RelativeDistinguishedName)の値を指定しながら、行の上で優先します、テーブルでの彼らの注文にかかわらず。 また、タイプの値がそれ自身か、異なった外側のタイプの値のコンポーネントとして現れることができる場合にだけ、内側のタイプの成分値に行を指定するのは役に立ちます。 例えば、DistinguishedNameのための行がある場合にだけ、DistinguishedNameの一部でないRelativeDistinguishedName成分値にRelativeDistinguishedNameのための行は適用できます。 基底部規則のためのテーブルの外側のタイプの値のための行は派生規則のためのテーブルの内側のタイプの値のために行の上で優先します。
Where more than one row applies to a particular component value the earlier row takes precedence over the later row. Thus rows in the table for the derived rule take precedence over any rows for the same component in the table for the base rule.
1つ以上の行が特定の成分値に適用されるところに、以前の行は後の行に優先します。 したがって、派生規則のためのテーブルの行は基底部規則のためのテーブルの同じコンポーネントのためにどんな行の上でも優先します。
6.4. The directoryComponentsMatch Matching Rule
6.4. directoryComponentsMatchの合っている規則
The directoryComponentsMatch matching rule is derived from the allComponentsMatch matching rule.
allComponentsMatchの合っている規則からdirectoryComponentsMatchの合っている規則を得ます。
Legg Standards Track [Page 28] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[28ページ]。
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名'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 } }
directoryComponentsMatchは以下をマッチングで統治します:= 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.
セクション6.3で説明されたコンベンションを使用して、directoryComponentsMatchの合っている意味論は以下のテーブルによって説明されます。
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
ASN.1はタイプします。| マッチング規則=========================================+======================== 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) DistinguishedNameタイプは、RDNSequenceがタイプするのと同じになるように課題で定義されます。 或るものは直接DistinguishedNameよりむしろ参照RDNSequenceをタイプします(例えば、NameとLocalName)。 RDNSequenceを指定すると、これらのすべてのDNのようなタイプがキャプチャします。
2) A RelativeDistinguishedName value is only matched by rdnMatch if
it is not part of an RDNSequence value.
2) RelativeDistinguishedName値はそれがRDNSequence価値の一部でない場合にだけ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
3) FacsimileTelephoneNumber ASN.1タイプ[12]の電話番号成分は強制的なPrintableStringと定義されます。 別々にFacsimileTelephoneNumber価値の一部であるPrintableString成分値は特定できます。
Legg Standards Track [Page 29] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[29ページ]。
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.
特許説明書の作成書FacsimileTelephoneNumber.telephoneNumberによるPrintableStringタイプの他の成分であり、したがって、選択的にそのtelephoneNumberMatchを適用できます。 X.520の4番目の版はタイプTelephoneNumberにはあるようにFacsimileTelephoneNumberのtelephoneNumberの部品を定義します、FacsimileTelephoneNumber.telephoneNumberの部品のための行を余分にして。
The directoryComponentsMatch rule may be used as the defined equality matching rule for an attribute.
定義された平等マッチングが属性のために統治されるようにdirectoryComponentsMatch規則は使用されるかもしれません。
7. Component Matching Examples
7. コンポーネントの合っている例
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>encodingsです)メモ。 アスタリスク、明快の目的、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の図式の操作上の属性の上の検索について説明します。属性は、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 }
ObjectClassDescription:、:= 系列識別子OBJECT-CLASS. イド、名前SET OF DirectoryString ub-図式OPTIONAL、記述DirectoryString ub-図式OPTIONAL、時代遅れのBOOLEAN DEFAULT FALSE、情報[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 }
ObjectClassInformation:、:= 系列subclassOf SET OF OBJECT-CLASSイドOPTIONAL(構造的な親切なObjectClassKind DEFAULT義務[3]SET OF ATTRIBUTE)、イドOPTIONAL(選択科目[4]SET OF ATTRIBUTE)、およびイドOPTIONAL
Legg Standards Track [Page 30] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg規格は2004年2月にRFC3687LDAPとX.500のコンポーネントの合っている規則を追跡します[30ページ]。
ObjectClassKind ::= ENUMERATED {
abstract (0),
structural (1),
auxiliary (2) }
ObjectClassKind:、:= 列挙されます。要約(0)、構造的な(1)、補助物(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 OBJECT IDENTIFIER ASN.1タイプに、ATTRIBUTEイドとイドは同等です。 OBJECT-CLASSイドの値はオブジェクトのクラスのためのOBJECT IDENTIFIERです。 ATTRIBUTEイドの値は属性タイプのためのOBJECT IDENTIFIERです。
The following search filter finds the object class definition for the object class identified by the OBJECT IDENTIFIER 2.5.6.18:
以下の検索フィルタは、オブジェクトのクラスのためのオブジェクトクラス定義がOBJECT IDENTIFIER2.5.6で.18を特定したのがわかります:
(objectClasses:componentFilterMatch:=
item:{ component "identifier",
rule objectIdentifierMatch, value 2.5.6.18 })
(objectClasses:componentFilterMatch:=項目:、objectIdentifierMatch、値2.5の.6が、コンポーネント「識別子」と裁決する、.18、)
A match on the "identifier" component of objectClasses values is equivalent to the objectIdentifierFirstComponentMatch matching rule applied to attribute values of the objectClasses attribute type. The componentFilterMatch matching rule subsumes the functionality of the objectIdentifierFirstComponentMatch, integerFirstComponentMatch and directoryStringFirstComponentMatch matching rules.
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.
The following search filter finds the object class definition for the object class called foobar:
The following search filter finds the object class definition for the object class called foobar:
(objectClasses:componentFilterMatch:=
item:{ component "name.*",
rule caseIgnoreMatch, value "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".
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".
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:
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:
(objectClasses:componentFilterMatch:=
item:{ component "name.0", rule integerMatch, value 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:
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:
Legg Standards Track [Page 31] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 31] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
(objectClasses:componentFilterMatch:=
item:{ component "description",
rule presentMatch, value NULL })
(objectClasses:componentFilterMatch:= item:{ component "description", rule presentMatch, value NULL })
The presentMatch returns TRUE if the description component is present and FALSE otherwise.
The presentMatch returns TRUE if the description component is present and FALSE otherwise.
The following search filter finds object class definitions that don't have descriptions:
The following search filter finds object class definitions that don't have descriptions:
(objectClasses:componentFilterMatch:=
not:item:{ component "description",
rule presentMatch, value NULL })
(objectClasses:componentFilterMatch:= not:item:{ component "description", rule presentMatch, value NULL })
The following search filter finds object class definitions with the word "bogus" in the description:
The following search filter finds object class definitions with the word "bogus" in the description:
(objectClasses:componentFilterMatch:=
item:{ component "description",
rule caseIgnoreSubstringsMatch,
value { any:"bogus" } })
(objectClasses:componentFilterMatch:= item:{ component "description", rule caseIgnoreSubstringsMatch, value { any:"bogus" } })
The assertion value is of the SubstringAssertion syntax, i.e.,
The assertion value is of the SubstringAssertion syntax, i.e.,
SubstringAssertion ::= SEQUENCE OF CHOICE {
initial [0] DirectoryString {ub-match},
any [1] DirectoryString {ub-match},
final [2] DirectoryString {ub-match} }
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:
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:
(objectClasses:componentFilterMatch:=
item:{ component "obsolete", rule booleanMatch, value 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:
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 })
(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
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
Legg Standards Track [Page 32] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 32] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
filter finds only object class definitions where the "obsolete" component has been explicitly set to FALSE, rather than implicitly defaulting to FALSE:
filter finds only object class definitions where the "obsolete" component has been explicitly set to FALSE, rather than implicitly defaulting to FALSE:
(objectClasses:componentFilterMatch:=
item:{ component "obsolete", useDefaultValues FALSE,
rule booleanMatch, value 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.
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.
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:
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:
(objectClasses:componentFilterMatch:=
item:{ component "information.kind",
rule allComponentsMatch, value auxiliary })
(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:
The following search filter finds auxiliary object classes with commonName (cn or 2.5.4.3) as a mandatory attribute:
(objectClasses:componentFilterMatch:=and:{
item:{ component "information.kind",
rule allComponentsMatch, value auxiliary },
item:{ component "information.mandatories.*",
rule objectIdentifierMatch, value cn } })
(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:
The following search filter finds auxiliary object classes with commonName as a mandatory or optional attribute:
(objectClasses:componentFilterMatch:=and:{
item:{ component "information.kind",
rule allComponentsMatch, value auxiliary },
or:{
item:{ component "information.mandatories.*",
rule objectIdentifierMatch, value cn },
item:{ component "information.optionals.*",
rule objectIdentifierMatch, value cn } } })
(objectClasses:componentFilterMatch:=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
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
Legg Standards Track [Page 33] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 33] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
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:
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:
(objectClasses:componentFilterMatch:=
item:{ component "name.0",
rule integerOrderingMatch, value 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:
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:
(objectClasses:componentFilterMatch:=or:{
not:item:{ component "name", rule presentMatch, value NULL },
item:{ component "name.0",
rule integerOrderingMatch, value 3 } })
(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.
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.
NameAndOptionalUID ::= SEQUENCE {
dn DistinguishedName,
uid UniqueIdentifier OPTIONAL }
NameAndOptionalUID ::= SEQUENCE { dn DistinguishedName, uid UniqueIdentifier OPTIONAL }
The following search filter finds values of the uniqueMember attribute containing the author's DN:
The following search filter finds values of the uniqueMember attribute containing the author's DN:
(uniqueMember:componentFilterMatch:=
item:{ component "dn",
rule distinguishedNameMatch,
value "cn=Steven Legg,o=Adacel,c=AU" })
(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.
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.
DistinguishedName ::= RDNSequence
DistinguishedName ::= RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue
Legg Standards Track [Page 34] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 34] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType ({SupportedAttributes}),
value AttributeValue ({SupportedAttributes}{@type}) }
AttributeTypeAndValue ::= SEQUENCE { type AttributeType ({SupportedAttributes}), value AttributeValue ({SupportedAttributes}{@type}) }
AttributeType ::= ATTRIBUTE.&id
AttributeType ::= ATTRIBUTE.&id
AttributeValue ::= ATTRIBUTE.&Type
AttributeValue ::= ATTRIBUTE.&Type
ATTRIBUTE.&Type is an open type. A value of ATTRIBUTE.&Type is constrained by the type component of AttributeTypeAndValue to be of the attribute syntax of the nominated attribute type. Note: the fourth edition of X.500 extends and renames the AttributeTypeAndValue SEQUENCE type.
ATTRIBUTE.&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.
The seeAlso attribute has the DistinguishedName syntax. The following search filter finds seeAlso attribute values containing the RDN, "o=Adacel", anywhere in the DN:
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:componentFilterMatch:=
item:{ component "*", rule rdnMatch, value "o=Adacel" })
(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):
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:componentFilterMatch:=
item:{ component "-1",
rule rdnMatch, value "cn=Steven Legg" })
(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":
The following search filter finds all seeAlso attribute values naming entries in the DIT subtree of "o=Adacel,c=AU":
(seeAlso:componentFilterMatch:=and:{
item:{ component "1", rule rdnMatch, value "c=AU" },
item:{ component "2", rule rdnMatch, value "o=Adacel" } })
(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:
The following search filter finds all seeAlso attribute values containing the naming attribute types commonName (cn) and telephoneNumber in the same RDN:
(seeAlso:componentFilterMatch:=
item:{ component "*", rule componentFilterMatch,
value and:{
item:{ component "*.type",
rule objectIdentifierMatch, value cn },
item:{ component "*.type",
rule objectIdentifierMatch,
value telephoneNumber } } })
(seeAlso:componentFilterMatch:= item:{ component "*", rule componentFilterMatch, value and:{ item:{ component "*.type", rule objectIdentifierMatch, value cn }, item:{ component "*.type", rule objectIdentifierMatch, value telephoneNumber } } })
Legg Standards Track [Page 35] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 35] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
The following search filter would find all seeAlso attribute values containing the attribute types commonName and telephoneNumber, but not necessarily in the same RDN:
The following search filter would find all seeAlso attribute values containing the attribute types commonName and telephoneNumber, but not necessarily in the same RDN:
(seeAlso:componentFilterMatch:=and:{
item:{ component "*.*.type",
rule objectIdentifierMatch, value cn },
item:{ component "*.*.type",
rule objectIdentifierMatch, value telephoneNumber } })
(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:
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:
(seeAlso:componentFilterMatch:=
item:{ component "*.*.value.(2.5.4.11)",
rule caseIgnoreSubstringsMatch,
value { any:"Adacel" } })
(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.
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.
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:
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:
(&(!(productCodes:integerOrderingMatch:=3))
(productCodes:integerOrderingMatch:=8))
(&(!(productCodes:integerOrderingMatch:=3)) (productCodes:integerOrderingMatch:=8))
An entry whose productCodes attribute contains only the values 1 and 10 will match the above filter. The first subfilter is satisfied by the value 10 (10 is not less than 3), and the second subfilter is satisfied by the value 1 (1 is less than 8). The following search filter can be used instead to only match entries that have a productCodes value in the range 3 to 7, because the ComponentFilter is evaluated against each productCodes value in isolation:
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:componentFilterMatch:= and:{
not:item:{ rule integerOrderingMatch, value 3 },
item:{ rule integerOrderingMatch, value 8 } })
(productCodes:componentFilterMatch:= and:{ not:item:{ rule integerOrderingMatch, value 3 }, item:{ rule integerOrderingMatch, value 8 } })
Legg Standards Track [Page 36] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 36] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
An entry whose productCodes attribute contains only the values 1 and 10 will not match the above filter.
An entry whose productCodes attribute contains only the values 1 and 10 will not match the above filter.
8. Security Considerations
8. Security Considerations
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 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.
9. Acknowledgements
9. Acknowledgements
The author would like to thank Tom Gindin for private email discussions that clarified and refined the ideas presented in this document.
The author would like to thank Tom Gindin for private email discussions that clarified and refined the ideas presented in this document.
10. IANA Considerations
10. IANA Considerations
The Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry [8] as indicated by the following templates:
The Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry [8] as indicated by the following templates:
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): 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
Legg Standards Track [Page 37] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 37] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
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): 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): 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): 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
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.
The object identifiers have been assigned for use in this specification by Adacel Technologies, under an arc assigned to Adacel by Standards Australia.
11. References
11. References
11.1. Normative References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Legg Standards Track [Page 38] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 38] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[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): Attribute Syntax Definitions", RFC 2252, December 1997.
[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. and T. Howes. "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[7] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377, September
2002.
[7] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[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., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[9] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
Types", RFC 3641, October 2003.
[9] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 Types", RFC 3641, October 2003.
[10] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
Information Technology - Open Systems Interconnection - The
Directory: Models
[10] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, Information Technology - Open Systems Interconnection - The Directory: Models
[11] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
Information Technology - Open Systems Interconnection - The
Directory: Authentication Framework
[11] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998, Information Technology - Open Systems Interconnection - The Directory: Authentication Framework
[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 Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, Information technology - Open Systems Interconnection - The Directory: Selected attribute types
[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 Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation
[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 Recommendation X.681 (07/02) | ISO/IEC 8824-2:2002, Information technology - Abstract Syntax Notation One (ASN.1): Information object specification
Legg Standards Track [Page 39] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 39] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
[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 Recommendation X.682 (07/02) | ISO/IEC 8824-3:2002, Information technology - Abstract Syntax Notation One (ASN.1): Constraint specification
[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 Recommendation X.683 (07/02) | ISO/IEC 8824-4:2002, Information technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications
[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 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)
12.2. Informative References
12.2. Informative References
[18] Howes, T., "The String Representation of LDAP Search Filters",
RFC 2254, December 1997.
[18] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
[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 Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, Information Technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services
12. Intellectual Property Statement
12. Intellectual Property Statement
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.
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.
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.
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.
Legg Standards Track [Page 40] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 40] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
13. Author's Address
13. Author's Address
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
Phone: +61 3 8530 7710 Fax: +61 3 8530 7888 EMail: steven.legg@adacel.com.au
Legg Standards Track [Page 41] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
Legg Standards Track [Page 41] RFC 3687 LDAP and X.500 Component Matching Rules February 2004
14. Full Copyright Statement
14. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2004). All Rights Reserved.
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.
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.
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.
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
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Legg Standards Track [Page 42]
Legg Standards Track [Page 42]
一覧
スポンサーリンク
