[ Keep copying to the openldap-technical@openldap.org list ]
On Thu, May 02, 2013 at 02:15:02PM +0000, Emmanuel Dreyfus wrote:
It almost works. My only concern is that it is possible to create an object where LHS of DN is not in object's attributes. Like this:
dn: foo=x,o=org objectClass: fooClass foo: y
There was some argument about that a few years ago. I am sure that the intention of X.500 was for values in the RDN to be *chosen from* values in the entry. X.501(1988) section 8.1(g) defines an RDN:
A set of attribute value assertions, each of which is true, concerning the distinguished values of a particular entry.
Unfortunately, somewhere along the line one or more LDAP implementations permitted values in the RDN to be *in addition to* the values in the entry. This was a pain as it was not clear how search filters etc should behave, but some people with loud voices apparently became dependent on it. I remember someone (probably Kurt) saying at one point that the behaviour was wrong but someone had written it into the standards so it had to be supported.
However, LDAP is now defined by RFC4512 which says this:
2.3.1. Relative Distinguished Names
Each entry is named relative to its immediate superior. This relative name, known as its Relative Distinguished Name (RDN) [X.501], is composed of an unordered set of one or more attribute value assertions (AVA) consisting of an attribute description with zero options and an attribute value. These AVAs are chosen to match attribute values (each a distinguished value) of the entry.
I read that as equivalent to the original X.501 definition, so maybe we should now treat the behaviour you see as a bug.
Which version of slapd are you using? When I try this on 2.4.35 the extra value from the RDN gets copied into the entry so although the LDIF being loaded is not strictly correct it does result in a conformant entry. What does your entry look like when you read it back?
Andrew