[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: LDAP Tree Delete Control - draft-armijo-ldap-treedelete-01.tx t



The inability to delete objects with subordinate entries using the delete
operation is exactly what this control is attempting to resolve.  The
restriction in RFC 2251 reflects that the semantics to handle deletion of an
object and all its descendants did not exist.  This control follows the
spirit of existing control extensions to address the limitations of the
protocol.

Michael

-----Original Message-----
From: Bruce Greenblatt [mailto:bgreenblatt@dtasi.com]
Sent: Saturday, June 26, 1999 1:17 PM
To: Michael Armijo (Exchange); 'ietf-ldapext@netscape.com'
Subject: Re: LDAP Tree Delete Control -
draft-armijo-ldap-treedelete-01.txt


In my draft on subtree operations, I'd considered using controls on
existing operations, but sentences like:

"A removeEntry operation is used to remove a leaf entry (either an object
entry or an alias entry) from the DIT."

from X.511 indicated to me that this was a very bad idea.  Similarly, RFC
2251 says this about the Delete operation:

"Note that the server will not dereference aliases while resolving the name
of the target entry to be removed, and that only leaf entries (those with
no subordinate entries) can be deleted with this operation."

Bruce


At 01:38 PM 6/25/99 -0700, Michael Armijo (Exchange) wrote:
>I have submitted the latest version of the Tree Delete control to the
>Internet-drafts editor.
>
>This update addresses some concerns regarding processing of objects.  
>
>
> <<draft-armijo-ldap-treedelete-01.txt>> 
>Content-Type: text/plain;
>	name="draft-armijo-ldap-treedelete-01.txt"
>Content-Disposition: attachment;
>	filename="draft-armijo-ldap-treedelete-01.txt"
>Content-Location: ATT-0-04C96DBC162BD311B4310000F82115F5-D
>	R2F53%7E1.TXT
>
>Attachment Converted:
"c:\eudora\attach\draft-armijo-ldap-treedelete-01.txt"
>