On 11/29/2012 06:49 AM, Ludwig Krispenz wrote:
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: 126.96.36.199) 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
- 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
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.
> 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