|
If an attribute is defined with one of the two string syntaxes, Directory String or IA5 String, the server will now honor the matching behavior specified in the schema for the attribute, correcting an error in previous releases. You can define an attribute to be case sensitive or to ignore case when matching. Previously the server allowed a matching rule to be defined, but ignored it. Internally the server treated IA5 String as case sensitive, and Directory String as case insensitive. If your server had defined attributes as IA5 String with caseIgnoreMatch, or DirectoryString with caseExactMatch, the server will now behave correctly for those attributes.
Note that the server does not distinguish between Directory String and IA5 String. Directory String allows all UTF-8 strings, while some servers may restrict attributes using IA5 String to the IA5 character set (7-bit US ASCII).
And note that the use of the term "string syntax" here refers to the content of the value. In general, all LDAP syntaxes are represented as strings. Boolean attributes, for example have the values "TRUE" or "FALSE", while the integer value 1 is represented as the string "1".
Matching rules affect the following server operations:
- Search and compare: The matching rule determines how the server compares a value in a search filter (cn=john smith) or compare operation to the attribute values in the directory. For example, (cn=John Smith) will match "john smith" because cn is defined to ignore case.
- Duplicate values: The matching rule determines if case is used when determining if a value is a duplicate of an existing attribute value. Recall that directory entries are not allowed to contain duplicate values. For example, a single entry is not allowed to contain the cn values "John Smith" and "john smith" because the cn attribute is defined to ignore case.
- Deleting values: The matching rule determines which value, if any, is to be deleted by a LDAP modify request to delete a value. For example, a request to delete the cn attribute with the value "john smith" will delete the value "John Smith".
The following matching rules are treated as "ignore case":
caseIgnoreIA5Match - 1.3.6.1.4.1.1466.109.114.2
caseIgnoreMatch - 2.5.13.2
caseIgnoreOrderingMatch - 2.5.13.3
caseIgnoreSubstringMatch - 2.5.13.4
The following matching rules are treated as "case exact":
caseExactIA5Match - 1.3.6.1.4.1.1466.109.114.2
caseExactMatch - 2.5.13.5
caseExactOrderingMatch - 2.5.13.6
caseExactSubstringMatch - 2.5.13.7
For non-string attributes, the matching rule that corresponds to the syntax must be used:
- distinguished name - distinguishedNameMatch
- integer - integerMatch (integer ordering is implied)
- boolean - none (boolean matching is implied)
- telephone number - telephoneNumberMatch, telephoneSubstringMatch
- generalized time - generalizedTimeMatch, generalizedTimeOrderingMatch
- binary - octetStringMatch (though the server does not support searching for entries matching a particular binary value)
When you define matching rules for an attribute, the equality, ordering, and substring rules must all be equivalent. You cannot mix case ignore and case exact rules in a single attribute definition. Also, for our server, it is necessary only to define the equality matching rule. The other matching rules can be defined for completeness. If your are defining a schema that will be used on other servers, it is possible that the omission of a matching rule might result, for example, in the server not allowing a search like (myattr>=abc). If no matching rule is defined, the default behavior is that string attributes are treated as case ignore.
An example of an attribute which ignores case (2.5.13.2 is the object identifier for caseIgnorematch):
|
