rfc4517.txt

来自「samba最新软件」· 文本 代码 · 共 1,726 行 · 第 1/5 页

   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



Legg                        Standards Track                    [Page 25]

RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006


   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



Legg                        Standards Track                    [Page 26]

RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006


   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.



Legg                        Standards Track                    [Page 27]

RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006


   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.



Legg                        Standards Track                    [Page 28]

RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006


   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.





Legg                        Standards Track                    [Page 29]

RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006


   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.




Legg                        Standards Track                    [Page 30]

RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006


   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