AKBKHOME Consulting Services Available : Linux, Embedded Linux, PHP and PHP-GTK, just Contact me at alan@akbkhome.com 
LDAP Schema | PHP Code doc | AKBK Home >>> Projects | Phpmole IDE | Diary | Photos  
search for in

Ldap Schema Viewer

Syntax: Matching Rule Use Description

ID : 1.3.6.1.4.1.1466.115.121.1.31

Matching rules are used by servers to compare attribute values against assertion values when performing Search and Compare operations. They are also used to identify the value to be added or deleted when modifying entries, and are used when comparing a purported distinguished name with the name of an entry.

Most of the attributes given in this document will have an equality matching rule defined.

Matching rule descriptions are written according to the following BNF. Implementors should note that future versions of this document may have expanded this BNF to include additional terms. Terms whose identifier begins with "X-" are reserved for private experiments, and MUST be followed by a 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: 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description'

rfc2252


Comments

Your email address:
Add Your comments:

Contact me at alan@akbkhome.com - especially if you have some work for me :)