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@xxxxxxxxxx> Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
