Re: creatorsName/modifiersName referential integrity

[Roger Harrison <RHARRISON@novell.com>]

> Helmut Volpers <Helmut.Volpers@icn.siemens.de> 11/05/99 01:03AM >>>
>>Brian Jarvis schrieb:
>> 
>> RFC 2252, 5.1 Defines some standard operational attributes.  Among them are creatorsName and modifiersName, both syntax DN.  If the object listed as a creator or modifier is deleted, what should happen to the creatorsName and modifiersName attributes that refer to it?

>That is part how you handle referential integrity in your server.
>creatorsName and modifiersName you should handle the same way as any
>other attribute with DN-syntax. I think you should not delete them when
>you delete the entry. The question here is not only the delete,
>what happens if you make a modifyDN to the DN which is in the 
>creatorsName. For my opinion the CreatorsName should change whether you
>do this as an administrative task or automatically.

I agree.  There are lots of cases where an entry is referenced, and I think that changing the name of the entry should also include changing the references to it to maintain referential integrity.  Without doing so, it seems to me that, at best, the dangling references left behind are not very useful since there's no way to correlate them to an existing entry, and at worst, dangling references may be dangerous since someone may inadvertently create an entry with the same name as the one just renamed which is actually misinformation and could create security holes.
 
>> My best guess is that the creatorsName and modifiersName attributes should be removed, leaving the object without those standard operational attributes.

>I think its okay that DN's in attribute values exist which doesn't exist 
>as an entry in that Server. e.g. I think I can replicate a part of my
>DIT to some other Server with creatorsName and modifiersName in the 
>entries and doesn't replicate the Administrators entry for any reason.
>The same is the case for ACI which will be replicated complete but
>not all DN's which are in the ACI have to be replicated as entries.
 >So I think its not really okay to remove all references to a entry in
>the
>server when you remove this entry. How will this work in a distributed
>environment.

In a distributed environment, it should be sufficient that the entry exists somewhere (local or otherwise) while it is referenced. Deleting the entry should remove it from all servers that contain replicas (copies) of the entry whether a replica of the entry happens to be on the local server or not.  Leaving dangling references to a deleted entry causes me the same concerns I expressed above for dangling references to renamed entries.

>I think you can have administrative prcedures which can do things like 
>this for referential integrity.

Administrative procedures are nice, but they don't guarantee that every LDAP implementation will work the same way.  This makes life more complicated for client writers and/or administrators because they have to write special code into their clients for some LDAP implementations or they cannot deploy certain applications on some LDAP implementations. Administrative procedures are also prone to failure since they are not part of the protocol semantics.  For administrative procedures to work, administrators must either test all LDAP clients used in their environments to be sure that they maintain referential integrity (a daunting task, since one cannot enforce which LDAP clients are actually in use) or use some polling or event mechanism to maintain referential integrity on an ongoing basis.  In my opinion, both approaches leave much to be desired.  I would much prefer to see referential integrity semantics included in the LDAP protocol to support interoperability at the protocol level.

Roger Harrison
Novell, Inc.

>Helmut
>> 
>> Thoughts?
>> 
>> --the walrus
>> a.k.a. Brian Jarvis
>> bjarvis@novell.com