RE: Semantics of LDAP Modify DN operation

[Gil Kirkpatrick <gilk@netpro.com>]

It's also consistent with the definition of a DN as the concatenation of the
RDN of the entry and the DN of its parent entry... I don't know if this is
an official x.5?? definition, but I've seen it used in several places.

-gil

> -----Original Message-----
> From:	Ed Reed [SMTP:ed_reed@novell.com]
> Sent:	Tuesday, October 05, 1999 9:32 PM
> To:	nzhang@best.com; ietf-ldapext@netscape.com; ldap@umich.edu
> Subject:	Re: Semantics of LDAP Modify DN operation
> 
> The only reasonable answer is #1...you changed the parent RDN
> of all the entries subordinate to it...so all their DNs are changed.
> 
> Losing entries, creating orphans because parents changed their
> names, or deleting entries in such cases are all irrational
> resposes to a common, every day behavior.
> 
> Ask yourself this - what happens when you rename a directory
> in a file service...what happens to the names of all the files
> subordinate to the changed directory name?
> 
> Their relative pathnames, below the changed name, remain
> the same.
> 
> Their absolute pathnames now traverse through the new
> directory name.
> 
> Note that if your file system has been storing the full path
> name by which to refer to the files, such stored absolute
> file names will face a tough decision about how the
> stored names will be modified...which is why most file
> systems would not do such a thing....
> 
> ;-)
> 
> Ed
> 
> ============================
> Ed Reed, Technologist
> Novell Product Management
> +1 801 861 3320
> 
> >>> Nick Zhang <nzhang@best.com> 10/05/99 02:11PM >>>
> What is the exact semantics of Modify DN operation?
> Example, assume we have entry for the organization
> named "foo", "o=foo, c=US", we do 
> 	ldapmodrdn "o=foo, c=US" "o=bar"
> Then what is the consequence of the operation--what happened
> to all the children of the "o=foo,c=US"?
> 
> I can see 4 possibilities:
> 1) all got renamed to "cn=employee, o=bar, c=US"
> 2) all become orphans--don't know who the parent is, but
> may not may not still be searchable
> 3) all become grandparent's childrent
> 4) all got removed
> 
> I know in LDAPv3 this has been made clear with subtree renaming.
> But let's say the Modify DN request does not have the optional
> newSuperior field--therefore, it's LDAPv2, then what should
> we interpret the consequence. There must have been discussions
> about this when LDAPv3 came up.
> 
> Thanks
> 
> --Nick
> 
>  << File: Ed Reed.vcf >>