RFC 4517
Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules
Pages: 53
Proposed Standard
→ Errata
Obsoletes: 2252 2256
Updates: 3698
Proposed Standard
→ Errata
Obsoletes: 2252 2256
Updates: 3698
Part 2 of 2 – Pages 25 to 53
4. Matching Rules
Matching rules are used by directory implementations to compare attribute values against assertion values when performing Search and Compare operations [RFC4511]. They are also used when comparing a purported distinguished name [RFC4512] with the name of an entry. When modifying entries, matching rules are used to identify values to be deleted and to prevent an attribute from containing two equal values. Matching rules that are required for directory operation, or that are in common use, are specified in this section.4.1. General Considerations
A matching rule is applied to attribute values through an AttributeValueAssertion or MatchingRuleAssertion [RFC4511]. The conditions under which an AttributeValueAssertion or MatchingRuleAssertion evaluates to Undefined are specified elsewhere [RFC4511]. If an assertion is not Undefined, then the result of the
assertion is the result of applying the selected matching rule. A matching rule evaluates to TRUE, and in some cases Undefined, as specified in the description of the matching rule; otherwise, it evaluates to FALSE. Each assertion contains an assertion value. The definition of each matching rule specifies the syntax for the assertion value. The syntax of the assertion value is typically, but not necessarily, the same as the syntax of the attribute values to which the matching rule may be applied. Note that an AssertionValue in a SubstringFilter [RFC4511] conforms to the assertion syntax of the equality matching rule for the attribute type rather than to the assertion syntax of the substrings matching rule for the attribute type. Conceptually, the entire SubstringFilter is converted into an assertion value of the substrings matching rule prior to applying the rule. The definition of each matching rule indicates the attribute syntaxes to which the rule may be applied, by specifying conditions the corresponding ASN.1 type of a candidate attribute syntax must satisfy. These conditions are also satisfied if the corresponding ASN.1 type is a tagged or constrained derivative of the ASN.1 type explicitly mentioned in the rule description (i.e., ASN.1 tags and constraints are ignored in checking applicability), or is an alternative reference notation for the explicitly mentioned type. Each rule description lists, as examples of applicable attribute syntaxes, the complete list of the syntaxes defined in this document to which the matching rule applies. A matching rule may be applicable to additional syntaxes defined in other documents if those syntaxes satisfy the conditions on the corresponding ASN.1 type. The description of each matching rule indicates whether the rule is suitable for use as the equality matching rule (EQUALITY), ordering matching rule (ORDERING), or substrings matching rule (SUBSTR) in an attribute type definition [RFC4512]. Each matching rule is uniquely identified with an object identifier. The definition of a matching rule should not subsequently be changed. If a change is desirable, then a new matching rule with a different object identifier should be defined instead. Servers MAY implement the wordMatch and keywordMatch matching rules, but they SHOULD implement the other matching rules in Section 4.2. Servers MAY implement additional matching rules. Servers that implement the extensibleMatch filter SHOULD allow the matching rules listed in Section 4.2 to be used in the extensibleMatch filter and SHOULD allow matching rules to be used with all attribute types known to the server, where the assertion
syntax of the matching rule is the same as the value syntax of the attribute. Servers MUST publish, in the matchingRules attribute, the definitions of matching rules referenced by values of the attributeTypes and matchingRuleUse attributes in the same subschema entry. Other unreferenced matching rules MAY be published in the matchingRules attribute. If the server supports the extensibleMatch filter, then the server MAY use the matchingRuleUse attribute to indicate the applicability (in an extensibleMatch filter) of selected matching rules to nominated attribute types.4.2. Matching Rule Definitions
Nominated character strings in assertion and attribute values are prepared according to the string preparation algorithms [RFC4518] for LDAP when evaluating the following matching rules: numericStringMatch, numericStringSubstringsMatch, caseExactMatch, caseExactOrderingMatch, caseExactSubstringsMatch, caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch, caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch, caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, directoryStringFirstComponentMatch, telephoneNumberMatch, telephoneNumberSubstringsMatch and wordMatch. The Transcode, Normalize, Prohibit, and Check bidi steps are the same for each of the matching rules. However, the Map and Insignificant Character Handling steps depend on the specific rule, as detailed in the description of these matching rules in the sections that follow.4.2.1. bitStringMatch
The bitStringMatch rule compares an assertion value of the Bit String syntax to an attribute value of a syntax (e.g., the Bit String syntax) whose corresponding ASN.1 type is BIT STRING.
If the corresponding ASN.1 type of the attribute syntax does not have a named bit list [ASN.1] (which is the case for the Bit String syntax), then the rule evaluates to TRUE if and only if the attribute value has the same number of bits as the assertion value and the bits match on a bitwise basis. If the corresponding ASN.1 type does have a named bit list, then bitStringMatch operates as above, except that trailing zero bits in the attribute and assertion values are treated as absent. The LDAP definition for the bitStringMatch rule is: ( 2.5.13.16 NAME 'bitStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) The bitStringMatch rule is an equality matching rule.4.2.2. booleanMatch
The booleanMatch rule compares an assertion value of the Boolean syntax to an attribute value of a syntax (e.g., the Boolean syntax) whose corresponding ASN.1 type is BOOLEAN. The rule evaluates to TRUE if and only if the attribute value and the assertion value are both TRUE or both FALSE. The LDAP definition for the booleanMatch rule is: ( 2.5.13.13 NAME 'booleanMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) The booleanMatch rule is an equality matching rule.4.2.3. caseExactIA5Match
The caseExactIA5Match rule compares an assertion value of the IA5 String syntax to an attribute value of a syntax (e.g., the IA5 String syntax) whose corresponding ASN.1 type is IA5String. The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point. In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
The LDAP definition for the caseExactIA5Match rule is:
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
The caseExactIA5Match rule is an equality matching rule.
4.2.4. caseExactMatch
The caseExactMatch rule compares an assertion value of the Directory
String syntax to an attribute value of a syntax (e.g., the Directory
String, Printable String, Country String, or Telephone Number syntax)
whose corresponding ASN.1 type is DirectoryString or one of the
alternative string types of DirectoryString, such as PrintableString
(the other alternatives do not correspond to any syntax defined in
this document).
The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character
string have the same number of characters and corresponding
characters have the same code point.
In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only
Insignificant Space Handling is applied in the Insignificant
Character Handling step.
The LDAP definition for the caseExactMatch rule is:
( 2.5.13.5 NAME 'caseExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseExactMatch rule is an equality matching rule.
4.2.5. caseExactOrderingMatch
The caseExactOrderingMatch rule compares an assertion value of the
Directory String syntax to an attribute value of a syntax (e.g., the
Directory String, Printable String, Country String, or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
The rule evaluates to TRUE if and only if, in the code point
collation order, the prepared attribute value character string
appears earlier than the prepared assertion value character string;
i.e., the attribute value is "less than" the assertion value.
In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only
Insignificant Space Handling is applied in the Insignificant
Character Handling step.
The LDAP definition for the caseExactOrderingMatch rule is:
( 2.5.13.6 NAME 'caseExactOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseExactOrderingMatch rule is an ordering matching rule.
4.2.6. caseExactSubstringsMatch
The caseExactSubstringsMatch rule compares an assertion value of the
Substring Assertion syntax to an attribute value of a syntax (e.g.,
the Directory String, Printable String, Country String, or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
The rule evaluates to TRUE if and only if (1) the prepared substrings
of the assertion value match disjoint portions of the prepared
attribute value character string in the order of the substrings in
the assertion value, (2) an <initial> substring, if present, matches
the beginning of the prepared attribute value character string, and
(3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if
corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for
comparison, characters are not case folded in the Map preparation
step, and only Insignificant Space Handling is applied in the
Insignificant Character Handling step.
The LDAP definition for the caseExactSubstringsMatch rule is:
( 2.5.13.7 NAME 'caseExactSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseExactSubstringsMatch rule is a substrings matching rule.
4.2.7. caseIgnoreIA5Match
The caseIgnoreIA5Match rule compares an assertion value of the IA5
String syntax to an attribute value of a syntax (e.g., the IA5 String
syntax) whose corresponding ASN.1 type is IA5String.
The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character
string have the same number of characters and corresponding
characters have the same code point.
In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only
Insignificant Space Handling is applied in the Insignificant
Character Handling step.
The LDAP definition for the caseIgnoreIA5Match rule is:
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
The caseIgnoreIA5Match rule is an equality matching rule.
4.2.8. caseIgnoreIA5SubstringsMatch
The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax
(e.g., the IA5 String syntax) whose corresponding ASN.1 type is
IA5String.
The rule evaluates to TRUE if and only if (1) the prepared substrings
of the assertion value match disjoint portions of the prepared
attribute value character string in the order of the substrings in
the assertion value, (2) an <initial> substring, if present, matches
the beginning of the prepared attribute value character string, and
(3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if
corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for
comparison, characters are case folded in the Map preparation step,
and only Insignificant Space Handling is applied in the Insignificant
Character Handling step.
( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
4.2.9. caseIgnoreListMatch
The caseIgnoreListMatch rule compares an assertion value that is a
sequence of strings to an attribute value of a syntax (e.g., the
Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE OF the DirectoryString ASN.1 type. The rule evaluates to TRUE if and only if the attribute value and the assertion value have the same number of strings and corresponding strings (by position) match according to the caseIgnoreMatch matching rule. In [X.520], the assertion syntax for this matching rule is defined to be: SEQUENCE OF DirectoryString {ub-match} That is, it is different from the corresponding type for the Postal Address syntax. The choice of the Postal Address syntax for the assertion syntax of the caseIgnoreListMatch in LDAP should not be seen as limiting the matching rule to apply only to attributes with the Postal Address syntax. The LDAP definition for the caseIgnoreListMatch rule is: ( 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) The caseIgnoreListMatch rule is an equality matching rule.4.2.10. caseIgnoreListSubstringsMatch
The caseIgnoreListSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE OF the DirectoryString ASN.1 type. The rule evaluates to TRUE if and only if the assertion value matches, per the caseIgnoreSubstringsMatch rule, the character string formed by concatenating the strings of the attribute value, except that none of the <initial>, <any>, or <final> substrings of the assertion value are considered to match a substring of the concatenated string which spans more than one of the original strings of the attribute value. Note that, in terms of the LDAP-specific encoding of the Postal Address syntax, the concatenated string omits the <DOLLAR> line separator and the escaping of "\" and "$" characters. The LDAP definition for the caseIgnoreListSubstringsMatch rule is: ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
4.2.11. caseIgnoreMatch
The caseIgnoreMatch rule compares an assertion value of the Directory
String syntax to an attribute value of a syntax (e.g., the Directory
String, Printable String, Country String, or Telephone Number syntax)
whose corresponding ASN.1 type is DirectoryString or one of its
alternative string types.
The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character
string have the same number of characters and corresponding
characters have the same code point.
In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only
Insignificant Space Handling is applied in the Insignificant
Character Handling step.
The LDAP definition for the caseIgnoreMatch rule is:
( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseIgnoreMatch rule is an equality matching rule.
4.2.12. caseIgnoreOrderingMatch
The caseIgnoreOrderingMatch rule compares an assertion value of the
Directory String syntax to an attribute value of a syntax (e.g., the
Directory String, Printable String, Country String, or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
The rule evaluates to TRUE if and only if, in the code point
collation order, the prepared attribute value character string
appears earlier than the prepared assertion value character string;
i.e., the attribute value is "less than" the assertion value.
In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only
Insignificant Space Handling is applied in the Insignificant
Character Handling step.
The LDAP definition for the caseIgnoreOrderingMatch rule is:
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseIgnoreOrderingMatch rule is an ordering matching rule.
4.2.13. caseIgnoreSubstringsMatch
The caseIgnoreSubstringsMatch rule compares an assertion value of the
Substring Assertion syntax to an attribute value of a syntax (e.g.,
the Directory String, Printable String, Country String, or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
The rule evaluates to TRUE if and only if (1) the prepared substrings
of the assertion value match disjoint portions of the prepared
attribute value character string in the order of the substrings in
the assertion value, (2) an <initial> substring, if present, matches
the beginning of the prepared attribute value character string, and
(3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if
corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for
comparison, characters are case folded in the Map preparation step,
and only Insignificant Space Handling is applied in the Insignificant
Character Handling step.
The LDAP definition for the caseIgnoreSubstringsMatch rule is:
( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreSubstringsMatch rule is a substrings matching rule.
4.2.14. directoryStringFirstComponentMatch
The directoryStringFirstComponentMatch rule compares an assertion
value of the Directory String syntax to an attribute value of a
syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory
first component of the DirectoryString ASN.1 type.
Note that the assertion syntax of this matching rule differs from the
attribute syntax of attributes for which this is the equality
matching rule.
The rule evaluates to TRUE if and only if the assertion value matches
the first component of the attribute value using the rules of
caseIgnoreMatch.
The LDAP definition for the directoryStringFirstComponentMatch
matching rule is:
( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The directoryStringFirstComponentMatch rule is an equality matching
rule. When using directoryStringFirstComponentMatch to compare two
attribute values (of an applicable syntax), an assertion value must
first be derived from one of the attribute values. An assertion
value can be derived from an attribute value by taking the first
component of that attribute value.
4.2.15. distinguishedNameMatch
The distinguishedNameMatch rule compares an assertion value of the DN
syntax to an attribute value of a syntax (e.g., the DN syntax) whose
corresponding ASN.1 type is DistinguishedName.
The rule evaluates to TRUE if and only if the attribute value and the
assertion value have the same number of relative distinguished names
and corresponding relative distinguished names (by position) are the
same. A relative distinguished name (RDN) of the assertion value is
the same as an RDN of the attribute value if and only if they have
the same number of attribute value assertions and each attribute
value assertion (AVA) of the first RDN is the same as the AVA of the
second RDN with the same attribute type. The order of the AVAs is
not significant. Also note that a particular attribute type may
appear in at most one AVA in an RDN. Two AVAs with the same
attribute type are the same if their values are equal according to
the equality matching rule of the attribute type. If one or more of
the AVA comparisons evaluate to Undefined and the remaining AVA
comparisons return TRUE then the distinguishedNameMatch rule
evaluates to Undefined.
The LDAP definition for the distinguishedNameMatch rule is:
( 2.5.13.1 NAME 'distinguishedNameMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
The distinguishedNameMatch rule is an equality matching rule.
4.2.16. generalizedTimeMatch
The generalizedTimeMatch rule compares an assertion value of the Generalized Time syntax to an attribute value of a syntax (e.g., the Generalized Time syntax) whose corresponding ASN.1 type is GeneralizedTime. The rule evaluates to TRUE if and only if the attribute value represents the same universal coordinated time as the assertion value. If a time is specified with the minutes or seconds absent, then the number of minutes or seconds (respectively) is assumed to be zero. The LDAP definition for the generalizedTimeMatch rule is: ( 2.5.13.27 NAME 'generalizedTimeMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) The generalizedTimeMatch rule is an equality matching rule.4.2.17. generalizedTimeOrderingMatch
The generalizedTimeOrderingMatch rule compares the time ordering of an assertion value of the Generalized Time syntax to an attribute value of a syntax (e.g., the Generalized Time syntax) whose corresponding ASN.1 type is GeneralizedTime. The rule evaluates to TRUE if and only if the attribute value represents a universal coordinated time that is earlier than the universal coordinated time represented by the assertion value. The LDAP definition for the generalizedTimeOrderingMatch rule is: ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) The generalizedTimeOrderingMatch rule is an ordering matching rule.4.2.18. integerFirstComponentMatch
The integerFirstComponentMatch rule compares an assertion value of the Integer syntax to an attribute value of a syntax (e.g., the DIT Structure Rule Description syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory first component of the INTEGER ASN.1 type.
Note that the assertion syntax of this matching rule differs from the
attribute syntax of attributes for which this is the equality
matching rule.
The rule evaluates to TRUE if and only if the assertion value and the
first component of the attribute value are the same integer value.
The LDAP definition for the integerFirstComponentMatch matching rule
is:
( 2.5.13.29 NAME 'integerFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
The integerFirstComponentMatch rule is an equality matching rule.
When using integerFirstComponentMatch to compare two attribute values
(of an applicable syntax), an assertion value must first be derived
from one of the attribute values. An assertion value can be derived
from an attribute value by taking the first component of that
attribute value.
4.2.19. integerMatch
The integerMatch rule compares an assertion value of the Integer
syntax to an attribute value of a syntax (e.g., the Integer syntax)
whose corresponding ASN.1 type is INTEGER.
The rule evaluates to TRUE if and only if the attribute value and the
assertion value are the same integer value.
The LDAP definition for the integerMatch matching rule is:
( 2.5.13.14 NAME 'integerMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
The integerMatch rule is an equality matching rule.
4.2.20. integerOrderingMatch
The integerOrderingMatch rule compares an assertion value of the
Integer syntax to an attribute value of a syntax (e.g., the Integer
syntax) whose corresponding ASN.1 type is INTEGER.
The rule evaluates to TRUE if and only if the integer value of the
attribute value is less than the integer value of the assertion
value.
The LDAP definition for the integerOrderingMatch matching rule is:
( 2.5.13.15 NAME 'integerOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
The integerOrderingMatch rule is an ordering matching rule.
4.2.21. keywordMatch
The keywordMatch rule compares an assertion value of the Directory
String syntax to an attribute value of a syntax (e.g., the Directory
String syntax) whose corresponding ASN.1 type is DirectoryString.
The rule evaluates to TRUE if and only if the assertion value
character string matches any keyword in the attribute value. The
identification of keywords in the attribute value and the exactness
of the match are both implementation specific.
The LDAP definition for the keywordMatch rule is:
( 2.5.13.33 NAME 'keywordMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
4.2.22. numericStringMatch
The numericStringMatch rule compares an assertion value of the
Numeric String syntax to an attribute value of a syntax (e.g., the
Numeric String syntax) whose corresponding ASN.1 type is
NumericString.
The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character
string have the same number of characters and corresponding
characters have the same code point.
In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only
numericString Insignificant Character Handling is applied in the
Insignificant Character Handling step.
The LDAP definition for the numericStringMatch matching rule is:
( 2.5.13.8 NAME 'numericStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
The numericStringMatch rule is an equality matching rule.
4.2.23. numericStringOrderingMatch
The numericStringOrderingMatch rule compares an assertion value of the Numeric String syntax to an attribute value of a syntax (e.g., the Numeric String syntax) whose corresponding ASN.1 type is NumericString. The rule evaluates to TRUE if and only if, in the code point collation order, the prepared attribute value character string appears earlier than the prepared assertion value character string; i.e., the attribute value is "less than" the assertion value. In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only numericString Insignificant Character Handling is applied in the Insignificant Character Handling step. The rule is identical to the caseIgnoreOrderingMatch rule except that all space characters are skipped during comparison (case is irrelevant as the characters are numeric). The LDAP definition for the numericStringOrderingMatch matching rule is: ( 2.5.13.9 NAME 'numericStringOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) The numericStringOrderingMatch rule is an ordering matching rule.4.2.24. numericStringSubstringsMatch
The numericStringSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Numeric String syntax) whose corresponding ASN.1 type is NumericString. The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point. In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only
numericString Insignificant Character Handling is applied in the
Insignificant Character Handling step.
The LDAP definition for the numericStringSubstringsMatch matching
rule is:
( 2.5.13.10 NAME 'numericStringSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The numericStringSubstringsMatch rule is a substrings matching rule.
4.2.25. objectIdentifierFirstComponentMatch
The objectIdentifierFirstComponentMatch rule compares an assertion
value of the OID syntax to an attribute value of a syntax (e.g., the
Attribute Type Description, DIT Content Rule Description, LDAP Syntax
Description, Matching Rule Description, Matching Rule Use
Description, Name Form Description, or Object Class Description
syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
first component of the OBJECT IDENTIFIER ASN.1 type.
Note that the assertion syntax of this matching rule differs from the
attribute syntax of attributes for which this is the equality
matching rule.
The rule evaluates to TRUE if and only if the assertion value matches
the first component of the attribute value using the rules of
objectIdentifierMatch.
The LDAP definition for the objectIdentifierFirstComponentMatch
matching rule is:
( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The objectIdentifierFirstComponentMatch rule is an equality matching
rule. When using objectIdentifierFirstComponentMatch to compare two
attribute values (of an applicable syntax), an assertion value must
first be derived from one of the attribute values. An assertion
value can be derived from an attribute value by taking the first
component of that attribute value.
4.2.26. objectIdentifierMatch
The objectIdentifierMatch rule compares an assertion value of the OID
syntax to an attribute value of a syntax (e.g., the OID syntax) whose
corresponding ASN.1 type is OBJECT IDENTIFIER.
The rule evaluates to TRUE if and only if the assertion value and the attribute value represent the same object identifier; that is, the same sequence of integers, whether represented explicitly in the <numericoid> form of <oid> or implicitly in the <descr> form (see [RFC4512]). If an LDAP client supplies an assertion value in the <descr> form and the chosen descriptor is not recognized by the server, then the objectIdentifierMatch rule evaluates to Undefined. The LDAP definition for the objectIdentifierMatch matching rule is: ( 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) The objectIdentifierMatch rule is an equality matching rule.4.2.27. octetStringMatch
The octetStringMatch rule compares an assertion value of the Octet String syntax to an attribute value of a syntax (e.g., the Octet String or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING ASN.1 type. The rule evaluates to TRUE if and only if the attribute value and the assertion value are the same length and corresponding octets (by position) are the same. The LDAP definition for the octetStringMatch matching rule is: ( 2.5.13.17 NAME 'octetStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) The octetStringMatch rule is an equality matching rule.4.2.28. octetStringOrderingMatch
The octetStringOrderingMatch rule compares an assertion value of the Octet String syntax to an attribute value of a syntax (e.g., the Octet String or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING ASN.1 type. The rule evaluates to TRUE if and only if the attribute value appears earlier in the collation order than the assertion value. The rule compares octet strings from the first octet to the last octet, and from the most significant bit to the least significant bit within the octet. The first occurrence of a different bit determines the ordering of the strings. A zero bit precedes a one bit. If the
strings contain different numbers of octets but the longer string is
identical to the shorter string up to the length of the shorter
string, then the shorter string precedes the longer string.
The LDAP definition for the octetStringOrderingMatch matching rule
is:
( 2.5.13.18 NAME 'octetStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
The octetStringOrderingMatch rule is an ordering matching rule.
4.2.29. telephoneNumberMatch
The telephoneNumberMatch rule compares an assertion value of the
Telephone Number syntax to an attribute value of a syntax (e.g., the
Telephone Number syntax) whose corresponding ASN.1 type is a
PrintableString representing a telephone number.
The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character
string have the same number of characters and corresponding
characters have the same code point.
In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only
telephoneNumber Insignificant Character Handling is applied in the
Insignificant Character Handling step.
The LDAP definition for the telephoneNumberMatch matching rule is:
( 2.5.13.20 NAME 'telephoneNumberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
The telephoneNumberMatch rule is an equality matching rule.
4.2.30. telephoneNumberSubstringsMatch
The telephoneNumberSubstringsMatch rule compares an assertion value
of the Substring Assertion syntax to an attribute value of a syntax
(e.g., the Telephone Number syntax) whose corresponding ASN.1 type is
a PrintableString representing a telephone number.
The rule evaluates to TRUE if and only if (1) the prepared substrings
of the assertion value match disjoint portions of the prepared
attribute value character string in the order of the substrings in
the assertion value, (2) an <initial> substring, if present, matches
the beginning of the prepared attribute value character string, and
(3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if
corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for
comparison, characters are case folded in the Map preparation step,
and only telephoneNumber Insignificant Character Handling is applied
in the Insignificant Character Handling step.
The LDAP definition for the telephoneNumberSubstringsMatch matching
rule is:
( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The telephoneNumberSubstringsMatch rule is a substrings matching
rule.
4.2.31. uniqueMemberMatch
The uniqueMemberMatch rule compares an assertion value of the Name
And Optional UID syntax to an attribute value of a syntax (e.g., the
Name And Optional UID syntax) whose corresponding ASN.1 type is
NameAndOptionalUID.
The rule evaluates to TRUE if and only if the <distinguishedName>
components of the assertion value and attribute value match according
to the distinguishedNameMatch rule and either, (1) the <BitString>
component is absent from both the attribute value and assertion
value, or (2) the <BitString> component is present in both the
attribute value and the assertion value and the <BitString> component
of the assertion value matches the <BitString> component of the
attribute value according to the bitStringMatch rule.
Note that this matching rule has been altered from its description in
X.520 [X.520] in order to make the matching rule commutative. Server
implementors should consider using the original X.520 semantics
(where the matching was less exact) for approximate matching of
attributes with uniqueMemberMatch as the equality matching rule.
The LDAP definition for the uniqueMemberMatch matching rule is:
( 2.5.13.23 NAME 'uniqueMemberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
The uniqueMemberMatch rule is an equality matching rule.
4.2.32. wordMatch
The wordMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String syntax) whose corresponding ASN.1 type is DirectoryString. The rule evaluates to TRUE if and only if the assertion value word matches, according to the semantics of caseIgnoreMatch, any word in the attribute value. The precise definition of a word is implementation specific. The LDAP definition for the wordMatch rule is: ( 2.5.13.32 NAME 'wordMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )5. Security Considerations
In general, the LDAP-specific encodings for syntaxes defined in this document do not define canonical encodings. That is, a transformation from an LDAP-specific encoding into some other encoding (e.g., BER) and back into the LDAP-specific encoding will not necessarily reproduce exactly the original octets of the LDAP- specific encoding. Therefore, an LDAP-specific encoding should not be used where a canonical encoding is required. Furthermore, the LDAP-specific encodings do not necessarily enable an alternative encoding of values of the Directory String and DN syntaxes to be reconstructed; e.g., a transformation from a Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific encoding and back to a DER encoding may not reproduce the original DER encoding. Therefore, LDAP-specific encodings should not be used where reversibility to DER is needed; e.g., for the verification of digital signatures. Instead, DER or a DER-reversible encoding should be used. When interpreting security-sensitive fields (in particular, fields used to grant or deny access), implementations MUST ensure that any matching rule comparisons are done on the underlying abstract value, regardless of the particular encoding used.6. Acknowledgements
This document is primarily a revision of RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working Group.
This document is based on input from the IETF LDAPBIS working group. The author would like to thank Kathy Dally for editing the early drafts of this document, and Jim Sermersheim and Kurt Zeilenga for their significant contributions to this revision.7. IANA Considerations
The Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry [BCP64] as indicated by the following templates: Subject: Request for LDAP Descriptor Registration Update Descriptor (short name): see comment Object Identifier: see comment Person & email address to contact for further information: Steven Legg <steven.legg@eb2bcom.com> Usage: see comment Specification: RFC 4517 Author/Change Controller: IESG NAME Type OID ------------------------------------------------------------------ bitStringMatch M 2.5.13.16 booleanMatch M 2.5.13.13 caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 caseExactMatch M 2.5.13.5 caseExactOrderingMatch M 2.5.13.6 caseExactSubstringsMatch M 2.5.13.7 caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 caseIgnoreListMatch M 2.5.13.11 caseIgnoreListSubstringsMatch M 2.5.13.12 caseIgnoreMatch M 2.5.13.2 caseIgnoreOrderingMatch M 2.5.13.3 caseIgnoreSubstringsMatch M 2.5.13.4 directoryStringFirstComponentMatch M 2.5.13.31 distinguishedNameMatch M 2.5.13.1 generalizedTimeMatch M 2.5.13.27 generalizedTimeOrderingMatch M 2.5.13.28 integerFirstComponentMatch M 2.5.13.29 integerMatch M 2.5.13.14 integerOrderingMatch M 2.5.13.15 keywordMatch M 2.5.13.33 numericStringMatch M 2.5.13.8 numericStringOrderingMatch M 2.5.13.9 numericStringSubstringsMatch M 2.5.13.10 objectIdentifierFirstComponentMatch M 2.5.13.30 octetStringMatch M 2.5.13.17 octetStringOrderingMatch M 2.5.13.18 telephoneNumberMatch M 2.5.13.20
telephoneNumberSubstringsMatch M 2.5.13.21
uniqueMemberMatch M 2.5.13.23
wordMatch M 2.5.13.32
The descriptor for the object identifier 2.5.13.0 was incorrectly
registered as objectIdentifiersMatch (extraneous \`s') in BCP 64.
It has been changed to the following, with a reference to
RFC 4517.
NAME Type OID
------------------------------------------------------------------
objectIdentifierMatch M 2.5.13.0
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): caseIgnoreIA5SubstringsMatch
Object Identifier: 1.3.6.1.4.1.1466.109.114.3
Person & email address to contact for further information:
Steven Legg <steven.legg@eb2bcom.com>
Usage: other (M)
Specification: RFC 4517
Author/Change Controller: IESG
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, June
2006.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006. [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation", RFC 4518, June 2006. [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. [E.123] Notation for national and international telephone numbers, ITU-T Recommendation E.123, 1988. [FAX] Standardization of Group 3 facsimile apparatus for document transmission - Terminal Equipment and Protocols for Telematic Services, ITU-T Recommendation T.4, 1993 [T.50] International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) Information Technology - 7-Bit Coded Character Set for Information Interchange, ITU-T Recommendation T.50, 1992 [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, Information Technology - Message Handling Systems (MHS): Interpersonal messaging system [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, Information Technology - Open Systems Interconnection - The Directory: Models [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, Information Technology - Open Systems Interconnection - The Directory: Selected attribute types [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation [ISO3166] ISO 3166, "Codes for the representation of names of countries". [ISO8601] ISO 8601:2004, "Data elements and interchange formats -- Information interchange -- Representation of dates and times".
[UCS] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646- 1: 1993 (with amendments). [JPEG] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 1992.8.2. Informative References
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006. [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, June 2006. [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, Information Technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
Appendix A. Summary of Syntax Object Identifiers
The following list summarizes the object identifiers assigned to the syntaxes defined in this document. Syntax OBJECT IDENTIFIER ============================================================== Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3 Bit String 1.3.6.1.4.1.1466.115.121.1.6 Boolean 1.3.6.1.4.1.1466.115.121.1.7 Country String 1.3.6.1.4.1.1466.115.121.1.11 Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 Directory String 1.3.6.1.4.1.1466.115.121.1.15 DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16 DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17 DN 1.3.6.1.4.1.1466.115.121.1.12 Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21 Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22 Fax 1.3.6.1.4.1.1466.115.121.1.23 Generalized Time 1.3.6.1.4.1.1466.115.121.1.24 Guide 1.3.6.1.4.1.1466.115.121.1.25 IA5 String 1.3.6.1.4.1.1466.115.121.1.26 Integer 1.3.6.1.4.1.1466.115.121.1.27 JPEG 1.3.6.1.4.1.1466.115.121.1.28 LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54 Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31 Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34 Name Form Description 1.3.6.1.4.1.1466.115.121.1.35 Numeric String 1.3.6.1.4.1.1466.115.121.1.36 Object Class Description 1.3.6.1.4.1.1466.115.121.1.37 Octet String 1.3.6.1.4.1.1466.115.121.1.40 OID 1.3.6.1.4.1.1466.115.121.1.38 Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39 Postal Address 1.3.6.1.4.1.1466.115.121.1.41 Printable String 1.3.6.1.4.1.1466.115.121.1.44 Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58 Telephone Number 1.3.6.1.4.1.1466.115.121.1.50 Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51 Telex Number 1.3.6.1.4.1.1466.115.121.1.52 UTC Time 1.3.6.1.4.1.1466.115.121.1.53Appendix B. Changes from RFC 2252
This annex lists the significant differences between this specification and RFC 2252.
This annex is provided for informational purposes only. It is not a normative part of this specification. 1. The IESG Note has been removed. 2. The major part of Sections 4, 5 and 7 has been moved to [RFC4512] and revised. Changes to the parts of these sections moved to [RFC4512] are detailed in [RFC4512]. 3. BNF descriptions of syntax formats have been replaced by ABNF [RFC4234] specifications. 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the use of a backslash quoting mechanism to escape separator symbols has been removed. The escaping mechanism is now explicitly represented in the ABNF for the syntaxes where this provision applies. 5. The description of each of the LDAP syntaxes has been expanded so that they are less dependent on knowledge of X.500 for interpretation. 6. The relationship of LDAP syntaxes to corresponding ASN.1 type definitions has been made explicit. 7. The set of characters allowed in a <PrintableString> (formerly <printablestring>) has been corrected to align with the PrintableString ASN.1 type in [ASN.1]. Specifically, the double quote character has been removed and the single quote character and equals sign have been added. 8. Values of the Directory String, Printable String and Telephone Number syntaxes are now required to have at least one character. 9. The <DITContentRuleDescription>, <NameFormDescription> and <DITStructureRuleDescription> rules have been moved to [RFC4512]. 10. The corresponding ASN.1 type for the Other Mailbox syntax has been incorporated from RFC 1274. 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax has been invented. 12. The Binary syntax has been removed because it was not adequately specified, implementations with different incompatible interpretations exist, and it was confused with the ;binary transfer encoding.
13. All discussion of transfer options, including the ";binary"
option, has been removed. All imperatives regarding binary
transfer of values have been removed.
14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
Terminal Identifier and Telex Number syntaxes from RFC 2256 have
been incorporated.
15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
been extended to accommodate empty "and" and "or" expressions.
16. An encoding for the <ttx-value> rule in the Teletex Terminal
Identifier syntax has been defined.
17. The PKI-related syntaxes (Certificate, Certificate List and
Certificate Pair) have been removed. They are reintroduced in
[RFC4523] (as is the Supported Algorithm syntax from RFC 2256).
18. The MHS OR Address syntax has been removed since its
specification (in RFC 2156) is not at draft standard maturity.
19. The DL Submit Permission syntax has been removed as it depends on
the MHS OR Address syntax.
20. The Presentation Address syntax has been removed since its
specification (in RFC 1278) is not at draft standard maturity.
21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
Type, LDAP Schema Description, Master And Shadow Access Points,
Modify Rights, Protocol Information, Subtree Specification,
Supplier Information, Supplier Or Consumer and Supplier And
Consumer syntaxes have been removed. These syntaxes are
referenced in RFC 2252, but not defined.
22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
Mail Preference syntax have been removed on the grounds that they
are out of scope for the core specification.
23. The description of each of the matching rules has been expanded
so that they are less dependent on knowledge of X.500 for
interpretation.
24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
been added.
25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
caseIgnoreSubstringsMatch matching rules have been added to the
list of matching rules for which the provisions for handling
leading, trailing and multiple adjoining whitespace characters
apply (now through string preparation). This is consistent with
the definitions of these matching rules in X.500. The
caseIgnoreIA5SubstringsMatch rule has also been added to the
list.
26. The specification of the octetStringMatch matching rule from
RFC 2256 has been added to this document.
27. The presentationAddressMatch matching rule has been removed as it
depends on an assertion syntax (Presentation Address) that is not
at draft standard maturity.
28. The protocolInformationMatch matching rule has been removed as it
depends on an undefined assertion syntax (Protocol Information).
29. The definitive reference for ASN.1 has been changed from X.208 to
X.680 since X.680 is the version of ASN.1 referred to by X.500.
30. The specification of the caseIgnoreListSubstringsMatch matching
rule from RFC 2798 & X.520 has been added.
31. String preparation algorithms have been applied to the character
string matching rules.
32. The specifications of the booleanMatch, caseExactMatch,
caseExactOrderingMatch, caseExactSubstringsMatch,
directoryStringFirstComponentMatch, integerOrderingMatch,
keywordMatch, numericStringOrderingMatch,
octetStringOrderingMatch and wordMatch matching rules from
RFC 3698 & X.520 have been added.
Author's Address
Steven Legg
eB2Bcom
Suite3, Woodhouse Corporate Centre
935 Station Street
Box Hill North, Victoria 3129
AUSTRALIA
Phone: +61 3 9896 7830
Fax: +61 3 9896 7801
EMail: steven.legg@eb2bcom.com
Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).