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.
-- John Dennis <jdennis@xxxxxxxxxx> Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
