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