Re: Please tell me I have something configured wrong...

["Tony Thompson" <tony.thompson@stone-ware.com>]

Would it be safe to say that I am being ignored at this point?  Would any argument that I make ever persuade the development team to change this in OpenLDAP or is it the way it is and it will never be changed?

>>> "Tony Thompson" <tony.thompson@stone-ware.com> 08/22/02 03:01PM >>>
>>Well, I did some digging in the RFCs and I really can't find anything that says the LDAP
>server can't handle the DN a little better.  Can you point me specifically to the RFC and 
>section that deals with this topic?
>
>The relevant portion of the technical specification X.501(93)
>which describes the X.500 models used in LDAP.  There are
>(at least) three basic reasons for this behavior:
>
>1) user application data is, just that, data which is maintained
>   by user applications;

I think it could be argued that a DN is not really user application data.  A DN uniquely identifies an entry in the DIT or it is essentially a pointer when stored in an attribute.  So isn't it used by the directory (or the user) to refer to another object in the directory?

>2) it is not feasible to ensure referential integrity across
>   the distributed DIT;

There are a bunch of commercial directory vendors out there that seem to have found a feasible way to ensure referential integrity in a distributed evironment.

>3) a single update to the directory changes the contents
>   of a single entry.

I pulled the X.501 spec down from the ITU and I am still can't really find anything that specifically says that the DS is not allowed to maintain referential integrity with DN attributes.  I was browsing through the X.511 spec and found an indication that maintaining attribute values with DNs is valid in a Modify DN operation.  So from that, why wouldn't it also be allowed for other operations (like Remove Entry) or even the example that I gave of adding a DN as a "member" of a group?

Here is X.511 reference:

11.4 Modify DN

11.4.1 Modify DN syntax
....

NOTE 5 * Some offline activity may be required following this operation to preserve consistency, for example to update attributes
in any entries that hold Distinguished Name values that refer to the renamed or moved entry(ies).