On 11/29/2012 08:47 AM, Ludwig Krispenz wrote:
Hi,
I found an older post by KurtZeilenga:
http://www.openldap.org/lists/openldap-software/200501/msg00102.html
and I think RFC4517, 4.2.15. distinguishedNameMatch can be read that
the comparison has to be done by avas and so "dn: cn=user
two,dc=example,dc=com" to be compared to "cn=user
two,dc=example,dc=com" would require to normalize the two cn parts by
applying the directory string match.
Yes, you make a good point and I stand corrected. The issues turns on
the matching rules for specific attribute types, in this instance
commonName (oid: 2.5.4.3) which does use the caseIgnoreMatch rule for
Equality matching. And caseIgnoreMatch does fold whitespace. Thus you
are correct the two are equivalent, but only in the context of matching
(which is what you asked about).
I don't know the internals of 389ds and what purpose the dn
normalization plays. If in fact the purpose of dn normalization is to
optimize the equality test between DN's then it must examine the
matching rule for the *attributeType* of each AVA when comparing the
attributeValue.
I was thinking on a different level, DN's are often thought of as case
preserving but case insensitive. However for some attributes of an AVA,
an additional condition applies, white space preserving but white space
insensitive after folding. Thus some DN's will compare as equal despite
having unequal string representations (using case insensitive evaluation).
Thank you for bringing this clarification forward.
--
John Dennis <jdennis(a)redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/