[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: creatorsName/modifiersName referential integrity
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.
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
> bjarvis@novell.com
>
> ------------------------------------------------------------------------
> Name: TEXT.htm
> TEXT.htm Type: Hypertext Markup Language (text/html)
> Encoding: 7bit
begin:vcard
n:Pana;Mircea
tel;pager:+1-613-364-1385
tel;fax:+1-613-591-3680
tel;work:+1-613-599-3600 x6907
x-mozilla-html:TRUE
url:http://www.newbridge.com
org:Newbridge Networks;Messaging and Directory Systems
version:2.1
email;internet:mpana@newbridge.com
title:Systems Architect
adr;quoted-printable:;;PO Box. 13600.=0D=0A600 March Road;Kanata;Ontario;K2K 2E6;Canada
fn:Mircea Pana
end:vcard