This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
MatchingRule
MatchingRule

Version management

Difference between version and

At line 1 added 80 lines
!!! Overview
[{$pagename}]s are used by [LDAP Server Implementations] to compare [Attribute Values] against [Assertion Values] when performing [SearchRequest] and [Compare Request] operations [RFC 4511].
[{$pagename}]s are also used when comparing a purported [Distinguished Name] [RFC 4512] with the name of a [LDAP Entry].
[{$pagename}]s are also used in [Modify Request] to identify values to be deleted and to prevent an [attribute] from containing two equal values.
A matching rule is a [LDAP Schema] element that defines how the [DSA] should interact with values of an specific [attributeTypes]. These are the standard types of matching rules:
!! [EQUALITY] ([equalityMatch])
[EQUALITY] [{$pagename}]s are used to determine whether one attribute value is equal to another as when using the [equalityMatch] [LDAP Filter Choice]. This determination is generally made based on the [normalized value|Definition -- normalized value], and ignores insignificant differences (e.g., differences in capitalization or extra spaces).
!! [ORDERING]
[ORDERING] matching rules are used to determine the relative order between two values in a sorted list. This is used when performing [Server Side Sort Control], but it is also used for [Greater-Or-Equal SearchFilter] and [LessThan-Or-Equal SearchFilter] [LDAP Filter Choices].
!! [SUBSTR] ([substrings])
[SUBSTR] or Substring matching rules are used to determine whether a value contains a given substring.
!! [APPROXIMATE] ([approxMatch])
[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".
!! [Extensible Match]
The default search behaviour for any attribute is defined by its [{$pagename}] for the search TYPE ([EQUALITY], [SUBSTR] or [ORDERING]). The default search behaviour may be overridden by using an [Extensible Match] [LDAP SearchFilters] and specifying a [matching Rule] (either by name or by OID).
These are some [Extensible Match] Matching Rules.
* [1.2.840.113556.1.4.803] - [LDAP_MATCHING_RULE_BIT_AND] - A match is found only if all bits from the attribute match the value. This rule is equivalent to a bitwise AND operator.
* [1.2.840.113556.1.4.804] - [LDAP_MATCHING_RULE_BIT_OR] - A match is found if any bits from the attribute match the value. This rule is equivalent to a bitwise OR operator.
* [1.2.840.113556.1.4.1941] - [LDAP_MATCHING_RULE_IN_CHAIN] - This rule is limited to filters that apply to the DN. This is a special "extended match operator that walks the chain of ancestry in objects all the way ro the root until it finds a match. [See Filtering for Bit Fields|Filtering for Bit Fields]
!! [Component Matching Rules]
In most cases, the Directory Server will use [{$pagename}]s 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 [{$pagename}] when performing an operation through the use of an [Component Matching Rules]
!! [{$pagename}]s used by [DSA]
The set of [{$pagename}] defined in the [DSA] may be determined by retrieving the [{$pagename}] attribute of the [Subschema Subentry].
For more information about matching rules, see the [Understanding matching rules] document.
!! [{$pagename}]s List
Below are [{$pagename}] that are required for directory operation, or that are in common use: ([RFC 4517])
* [bitStringMatch]
* [booleanMatch]
* [caseExactIA5Match]
* [caseExactMatch]
* [caseExactOrderingMatch]
* [caseExactSubstringsMatch]
* [caseIgnoreIA5Match]
* [caseIgnoreIA5SubstringsMatch]
* [caseIgnoreListMatch]
* [caseIgnoreListSubstringsMatch]
* [caseIgnoreMatch]
* [caseIgnoreOrderingMatch]
* [caseIgnoreSubstringsMatch]
* [directoryStringFirstComponentMatch]
* [distinguishedNameMatch]
* [generalizedTimeMatch]
* [generalizedTimeOrderingMatch]
* [integerFirstComponentMatch]
* [integerMatch]
* [integerOrderingMatch]
* [keywordMatch]
* [numericStringMatch]
* [numericStringOrderingMatch]
* [numericStringSubstringsMatch]
* [objectIdentifierFirstComponentMatch]
* [objectIdentifierMatch]
* [octetStringMatch]
* [octetStringOrderingMatch]
* [telephoneNumberMatch]
* [telephoneNumberSubstringsMatch]
* [uniqueMemberMatch]
* [wordMatch]
!! [LDAP String Matching]
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop