encoding.
MatchingRuleDescription = "(" whsp
numericoid whsp ; MatchingRule identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
"SYNTAX" numericoid
whsp ")"
Values of the matchingRuleUse list the attributes which are suitable for use with an extensible matching rule.
MatchingRuleUseDescription = "(" whsp
numericoid whsp ; MatchingRule identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" ]
"APPLIES" oids ; AttributeType identifiers
whsp ")"
Servers which support matching rules and the extensibleMatch SHOULD implement all the matching rules in section 8.
Servers MAY implement additional matching rules not listed in this document, and if they do so, MUST publish the definitions of the matching rules in the matchingRules attribute of their subschema entries. If the server supports the extensibleMatch, then the server MUST publish the relationship between the matching rules and attributes in the matchingRuleUse attribute.
For example, a server which implements a privately-defined matching rule for performing sound-alike matches on Directory String-valued attributes would include the following in the subschema entry (1.2.3.4.5 is an example, the OID of an actual matching rule would be different):
matchingRule: ( 1.2.3.4.5 NAME `soundAlikeMatch`
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
If this matching rule could be used with the attributes 2.5.4.41 and 2.5.4.15, the following would also be present:
matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )
A client could then make use of this matching rule by sending a search operation in which the filter is of the extensibleMatch choice, the matchingRule field is "soundAlikeMatch", and the type field is "2.5.4.41" or "2.5.4.15".
BNC Syntax: 2.5.21.4 NAME 'matchingRules' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation
rfc2252
ID : 1.3.6.1.4.1.1466.115.121.1.30
Values of type matchingRules are encoded as strings according to the BNF given in section 4.5.
BNC Syntax: 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description'
rfc2252
Description:
Servers which allow subschema entries to be modified by clients MUST
support the following matching rules, as they are the equality
matching rules for several of the subschema attributes.
Implementors should note that the assertion syntax of these matching
rules, an INTEGER or OID, is different from the value syntax of
attributes for which this is the equality matching rule.
If the client supplies an extensible filter using an
objectIdentifierFirstComponentMatch whose matchValue is in the
"descr" form, and the OID is not recognized by the server, then the
filter is Undefined.
BNC Syntax: 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
rfc2252
Comments