Hi,
On 11/29/2012 03:37 PM, John Dennis wrote:
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.
there are several situations where nd normalization is required, eg
- in a search filter using a dn attribute like
"uniquemember=cn=me,o=you" should find all entries with the same
normalized value
- a search base needs to be normalized
- if an entry is added no other antry with the "same" dn must exist, my
original example.
Regards,
Ludwig
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.
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
