Definition -- Matching Rule

Definition: Matching Rule

A matching rule is a schema element that defines how the server should interact with values of an attribute. There are three standard types of matching rules:

  • Equality matching rules are used to determine whether one attribute value is equal to another. This determination is generally made based on the normalized value, and ignores insignificant differences (for example, differences in capitalization or extra spaces).
  • Substring matching rules are used to determine whether a value contains a given substring.

In addition to these standard matching rules, Sun OpenDS SE defines a fourth type:

  • Approximate matching rules are used to determine whether one value is approximately equal to another. The definition of "approximately equal to" may vary, but one common use is "sounds like".

Common examples of matching rules include:

  • booleanMatch – An equality matching rule that determines whether two Boolean values are equal to each other.
  • caseExactMatch – An equality matching rule that determines whether two string values are equal to each other, without ignoring differences in capitalization.
  • caseExactOrderingMatch – An ordering matching rule that is used to determine the relative order between two string values, without ignoring differences in capitalization.
  • caseExactSubstringsMatch – A substring matching rule that is used to determine whether a string value contains a given substring, without ignoring differences in capitalization.
  • caseIgnoreMatch – An equality matching rule that determines whether two string values are equal to each other, ignoring differences in capitalization.
  • caseIgnoreOrderingMatch – An ordering matching rule that is used to determine the relative order between two string values, ignoring differences in capitalization.
  • caseIgnoreSubstringsMatch – A substring matching rule that is used to determine whether a string value contains a given substring, ignoring differences in capitalization.
  • distinguishedNameMatch – An equality matching rule that determines whether two DNs are equal to each other, ignoring extra spaces around commas separating RDN components and equal signs separating RDN names from values. The individual RDN values will be compared based on the matching rules associated with the corresponding RDN attributes.
  • generalizedTimeMatch – An equality matching rule that determines whether two generalized time values are equal to each other.
  • generalizedTimeOrderingMatch – An ordering matching rule that is used to determine the relative order between two generalized time values.
  • integerMatch – An equality matching rule that determines whether two integer values are equal to each other.
  • integerOrderingMatch – An ordering matching rule that is used to determine the relative order between two integer values.
  • octetStringMatch – An equality matching rule that determines whether two values are exactly equal to each other using a byte-for-byte comparison.

In most cases, the directory server will use matching rules in a completely "behind the scenes" manner without the client needing to know about it. Whenever the client references a given attribute type, then the server will automatically know to use the appropriate matching rules for that attribute. However, it is also possible for the client to request that the server use a specific matching rule when performing an operation through the use of an extensible match filter.

The set of matching rules defined in the server may be determined by retrieving the matchingRules attribute of the subschema subentry. For more information about matching rules, see the Understanding Matching Rules document.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Sun Microsystems community and they might not be employed or in any way formally affiliated with Sun Microsystems. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Sun nor any other party necessarily agrees with them.

Copyright 1994-2009 Sun Microsystems, Inc.
Powered by Atlassian Confluence
Sun Guidelines on Public Discourse Privacy Policy Terms of Use Trademarks Site Map Employment Investor Relations Contact