time. In the latter case, if <u-differential> is provided, then
coordinated universal time can be calculated by subtracting the
differential from the local time. The <u-time-zone> SHOULD be
present in time values, and the "Z" form of <u-time-zone> SHOULD be
used in preference to <u-differential>.
The LDAP definition for the UTC Time syntax is:
( 1.3.6.1.4.1.1466.115.121.1.53 DESC ’UTC Time’ )
Note: This syntax is deprecated in favor of the Generalized Time
syntax.
The UTC Time syntax corresponds to the UTCTime ASN.1 type from
[ASN.1].
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’