Subject: creatorsName/modifiersName referential integrity

From: "Brian Jarvis" <[email-masked]>
Date: Thu, 04 Nov 1999 09:26:29 -0700

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?

My best guess is that the creatorsName and modifiersName attributes should be removed, leaving the object without those standard operational attributes.

Thoughts?

--the walrus
a.k.a. Brian Jarvis
[email-masked]

---

From: "MIRCEA PANA" <[email-masked]>
Date: Thu, 04 Nov 1999 16:12:17 -0500

Here are some issues that need to be addressed:

1. What about "manager", "secretary", "uniqueMember" or any other attribute types with syntax DN? Should they follow the same rule?

2. What if the creatorsName of Entry1 hosted by DSA1 points to the DN of an Entry2 hosted by DSA2. In case Entry2 is deleted from DSA2, should then DSA2 notify DSA1 of this operation so that DSA1 can delete the creatorsName of Entry1? How would DSA2 know which DSA(s) to
notify of its own entry deletions?

3. Similar to 2. but for ModRDN operations.

etc...

These are issues that in my opinion will be addressed in a later stage of the protocol evolution: a relational LDAP/LDUP. I believe that an ITU/X500 working group has been formed to address this interest but I have no other details.

For now my guess would be that deleting the creatorsName and modifiersName attributes is not a good thing to do.

Mircea.

Brian Jarvis wrote:

>   ------------------------------------------------------------------------
>                Name: TEXT.htm
>    TEXT.htm    Type: Hypertext Markup Language (text/html)
>            Encoding: 7bit

---

From: "MIRCEA PANA" <[email-masked]>
Date: Thu, 04 Nov 1999 16:41:39 -0500

Some thoughts derived from: creatorsName/modifiersName referential integrity

What about extending the DelRequest operation to include "replacedBy LDAPDN"? This will not solve the whole relational/DN integrity problem but it may help.

Example:
In a business environment (and not only), "manager" is an important attribute that helps building a hierarchy model. Let's consider Entry1 identified by DN1 and EntryA having a "manager" attribute with the value "DN1". If (or rather when) Entry1 is deleted then the
hierarchy is broken unless / untill the "manager" value of EntryA is replaced with an other (valid) DN. If the LDAP DelRequest would be capable of passing a "replacedBy" LDAPDN value to the DSA, then this problem could be solved automatically.

Do you see any interest in this or something similar?

Thanks,
Mircea.

---

From: Helmut Volpers <[email-masked]>
Date: Fri, 05 Nov 1999 09:00:43 +0100

Hi Brian,

> 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 ha…

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.
> 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.
I think you can have administrative prcedures which can do things like 
this for referential integrity.

Helmut
>            Encoding: base64

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 09 Nov 1999 08:34:16 -0800

Hi Brian,

My perspective is that the operational attributes should remain even if the
DN that they point to is no longer in the DIT.  When used in concert with
the features of RFC 2649 there is no confusion as to what has happened to
the original creator or last modifier of the object.

Bruce

At 09:26 AM 11/4/99 -0700, Brian Jarvis wrote:
>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?
>
>My best guess is that the creatorsName and modifiersName attributes should
be removed, leaving the object without those standard operational attributes.
>
>Thoughts?
>
>--the walrus
>a.k.a. Brian Jarvis
>[email-masked]
>
>
>Attachment Converted: "C:\eudora\Attach\TEXT11.htm"
>
>Attachment Converted: "C:\eudora\Attach\Brian Jarvis6.vcf"
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com