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.
Regards,
Ludwig
On 11/29/2012 02:27 PM, John Dennis wrote:
On 11/29/2012 06:06 AM, Ludwig Krispenz wrote:
> Hello,
>
> i would like to get comments on a problem related to dn normalization.
> In 389 it is possible to create entries, where their dn only differs in
> the number of spaces inside the value of the rdn attribute, eg:
>
> ldapsearch ..... -b "dc=example,dc=com" "cn=user two" dn
> dn: cn=user two,dc=example,dc=com
> dn: cn=user two,dc=example,dc=com
>
> Note the the search filter was did contain only one space, also
> attemping to add a new cn value differing in the number of spaces fails.
>
> [ludwig@elkris perf]$ ldapmodify .....
> dn: cn=user two,dc=example,dc=com
> changetype: modify
> add: cn
> cn: user two
>
> modifying entry "cn=user two,dc=example,dc=com"
> ldap_modify: Type or value exists (20)
>
> So on the attribute level, attribute value normalization maps all
> variants to a single space, which I think is correct. In my opinion this
> should also apply
> to the use of an attribuet in the dn.
> If you try to add the second entry above in OpenLDAP the result is:
> ldap_add: already exists(68)
> And, although I have no DSEE instance available, DSEE also does not
> allow adding these two entries.
>
> It is a bit cumberome to find exactly in the RFCs what is the expected
> behaviour, but I think in the string prep description there is a step
> for removing
> insignificant space and to me it would be reasonable to apply the same
> normalization to an attribute if it is used in a dn as when used just as
> aregular attribute.
There is no RFC which says "collapse all white space in the value of
an AVA to a single space character". Values are to be interpreted
*exactly* as presented (accounting for character encoding). If you
place multiple white space characters in the value component then that
value has multiple white spaces.
Note that white space is permitted after the RDN separator character
(e.g. ,) and trailing the entire DN (i.e. after the last RDN). White
space in any other position is significant. See RFC 4514 and it's
references. Especially pay note to the examples in Section 4 which
illustrates an RDN with multiple embedded space characters.