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

Attribute: matchingRules

Description:
This attribute is typically located in the subschema entry.
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: 2.5.21.4 NAME 'matchingRules' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation

rfc2252

Syntax: Matching Rule Description

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

Equality Matching: objectIdentifierFirstComponentMatch

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

Your email address:
Add Your comments:

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