On 11/29/2012 03:37 PM, John Dennis wrote:
On 11/29/2012 08:47 AM, Ludwig Krispenz wrote:
> I found an older post by KurtZeilenga:
> 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: 18.104.22.168) 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
there are several situations where nd normalization is
- in a search filter using a dn attribute like
"uniquemember=cn=me,o=you" should find all entries with the same
- a search base needs to be normalized
- if an entry is added no other antry with the "same" dn must exist, my
If in fact the purpose of dn normalization is to optimize the
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
Thank you for bringing this clarification forward.