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.
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
