HP-UX Directory Server 8.1 plug-in reference

Table Of Contents
11 Writing matching rule plug-ins
This chapter explains how to write plug-in functions that handle matching rules.
11.1 Understanding matching rules
A matching rule specifies how one or more attributes of a particular syntax should be compared
against assertion values. For example, a matching rule that specifies a “sound-alike” comparison
attempts to match values that sound like the specified value. Each matching rule is identified by
a unique OID (for example, “1.2.3.4”).
LDAPv3 clients can specify a matching rule as part of a search filter in a search request. This
type of search filter is called an extensible match filter.
11.1.1 Extensible match filters
In an extensible match filter, the client specifies that it wants to use the matching rule to compare
a specified value against the values of entries in the directory. (For example, an extensible match
filter might find all entries in which the sn attribute “sounds like” melon.)
An extensible match filter contains the following information:
The OID of the matching rule or the attribute type that you want to search (or both).
The value for which to search.
A preference indicating whether to also search the attributes in the DN.
For example, if the OID 1.2.3.4 identifies a matching rule that performs “sounds like” matches,
the following extensible match filter attempts to find entries where the mail attribute “sounds
like” moxie: (mail:1.2.3.4:=moxie)
In the search filter, the client can specify the OID that identifies a matching rule, and the attribute
type. This indicates that the value in the filter should be compared against the attribute using
the matching rule.
For example, if the OID 1.2.3.4 specifies a “sound-alike” match and if the string representation
of the search filter is (uid:1.2.3.4:=moxie), it indicates that the client wants to find entries in which
the value of the uid attribute sounds like moxie.
Although the LDAPv3 standard allows clients to omit the OID or the attribute type, at this time,
the HP-UX Directory Server only supports extensible match filters that specify both the OID and
attribute type.
The filter can also specify a preference indicating whether to include DN attributes in the search.
For example, if the OID 1.2.3.4 specifies a “sound-alike” match and if the string representation
of the search filter is (sn:dn:1.2.3.4:=moxie), it indicates that the client wants to find all entries in
which the value of the sn attribute or the attributes in the DN (for example, uid, cn, ou, or o)
sound like moxie.
11.1.2 Extensible match filters in the Directory Server
Directory Server already includes support for certain matching rules, which are used to determine
the collation order and operator for searches of international data.
You can enable the Directory Server to handle your own matching rules for extensible match
searches by defining your own matching rules plug-ins and registering them with the server.
You can also build indexes to improve the performance of search operations that use extended
match filters.
11.1 Understanding matching rules 87