On 11/29/2012 06:49 AM, Ludwig Krispenz wrote:
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.
I think you are right. The DN matching rule should be consulted during
an ADD operation to check if the DN already exists. This would include
space folding. Let's open up a ticket in trac for this.
Thanks,
-NGK
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
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
