Subject: FW: I-D ACTION:draft-armijo-ldap-treedelete-02.txt

From: "Michael Armijo (Exchange)" <[email-masked]>
Date: Wed, 17 Nov 1999 10:46:49 -0800

Please review the attached draft on a Tree Delete control for LDAPv3.  

I believe this control is beneficial for server and client implementations
of LDAP and should be progressed on the standards-track.  Please send
comments on this draft to the LDAPEXT discussion list.

WG Chairs:  It was previously decided that this list is the best place to
discuss this draft.  If consensus can be reached on this draft, I would like
to see it progressed through this WG.

thanks,
Michael
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 17, 1999 3:59 AM
Subject: I-D ACTION:draft-armijo-ldap-treedelete-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Tree Delete Control
	Author(s)	: M. Armijo
	Filename	: draft-armijo-ldap-treedelete-02.txt
	Pages		: 2
	Date		: 16-Nov-99
	
This document defines an LDAPv3 control that deletes an entire subtree 
of a container entry.  This control extends the scope of the LDAPv3 
delete operation as defined in RFC 2251.  This control is beneficial 
in extending the functionality of the LDAP protocol and may be useful 
in administration in an LDAP environment.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-armijo-ldap-treedelete-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-armijo-ldap-treedelete-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-armijo-ldap-treedelete-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Date: Wed, 17 Nov 1999 10:46:50 -0800

---

From: Bruce Greenblatt <[email-masked]>
Date: Thu, 18 Nov 1999 08:35:45 -0800

Michael,

There was an exchange seeral months back about this.  I still think that
these type of operations are better implemented as extended operations than
as controls to existing operations.  It seems to me that the handling of a
subtree delete that may span across multiple DSAs (aka LDAP servers) must
be substantially different than the handling of a delete for a single
object which normally can be implemented by a single DSA.  My thinking is
that if a control might substantially change how an operation is
implemented by a DSA, it should be implemented as a control.  So, I believe
that the extended operations that I proposed in:
http://search.ietf.org/internet-drafts/draft-greenblatt-ldapext-sos-00.txt
are beneficial for server and client implementations of LDAP and should be
progressed on the standards track.  

What do people think?  Should this be a control or an extended operation?
Are the other two operations that I proposed useful as well (subtree copy
and subtree modify).

Bruce

At 10:46 AM 11/17/99 -0800, you wrote:
>Content-Type: message/rfc822
>Content-Location: ATT-0-ED55699A129DD311B4390000F82115F5
>
>To: 
>Subject: 
>MIME-Version: 1.0
>X-Mailer: Internet Mail Service (5.5.2232.9)
>Content-Type: multipart/mixed;
>	boundary="----_=_NextPart_002_01BF312C.1B839887"
>
>
>Content-Type: application/octet-stream;
>	name="ATT29488"
>Content-Disposition: attachment;
>	filename="ATT29488"
>Content-Location: ATT-0-DD55721D0C9DD31195E50008C7093FF3-A
>	TT29488.txt
>
>Attachment Converted: "C:\eudora\Attach\ATT29488"
>Content-Type: message/external-body;
>	site="internet-drafts";
>	dir="draft-armijo-ldap-treedelete-02.txt";
>	mode="ftp.ietf.org";
>	access-type="anon-ftp"
>Content-Location: ATT-1-DE55721D0C9DD31195E50008C7093FF3-d
>	raft-ar.url
>
>
><ftp://internet-drafts>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: "Michael Armijo (Exchange)" <[email-masked]>
Date: Thu, 18 Nov 1999 09:01:49 -0800

I do not understand the reasoning for not using a control to extend the
delete operation for handling a tree delete.  LDAPEXT has traditionally used
controls to extend or enhance existing operations (Search, VLV).  A control
here seems obvious and beneficial to the general LDAPv3 community.

Bruce said:
"It seems to me that the handling of a
subtree delete that may span across multiple DSAs (aka LDAP servers) must
be substantially different than the handling of a delete for a single
object which normally can be implemented by a single DSA."

Agreed.  The tree delete draft takes this into account and allows the server
to deny the operation if it is not authoritative for any object(s) in the
scope of the delete.

I do not believe we should tie this functionality to other subtree
operations.  This would limit the adoption of the base functionality of
allowing a client to submit a delete request of a subtree.

-----Original Message-----
From: Bruce Greenblatt [mailto:[email-masked]]
Sent: Thursday, November 18, 1999 8:36 AM
To: Michael Armijo (Exchange)
Cc: [email-masked]
Subject: Re: FW: I-D ACTION:draft-armijo-ldap-treedelete-02.txt

Michael,

Bruce

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 18 Nov 1999 13:09:35 -0800

> Sent: Thursday, November 18, 1999 9:53 AM

<snip>

> It is really just a matter of style.

Agreed. But since we have _significant_ operational experience with the
proposed style, and since you agree is just a matter of style, why not the
proposed style?

Paul

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 18 Nov 1999 15:06:54 -0800

Michael,

Like Bruce and Mark, I suggest you consider using an Extended
Operation instead of a Delete operation control.  Use of the
Extended Operation can provides the flexibility of returning
(proposed) ExtendedPartialResponse messages.

Kurt

----
Kurt D. Zeilenga		<[email-masked]>
Net Boolean Incorporated	<http://www.boolean.net/>

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 18 Nov 1999 22:58:22 -0800

> Sent: Thursday, November 18, 1999 7:49 PM

> The question is, do you 
> really think
> that implementing a delete subtree is best implemented as a 
> control?  It
> seems so obvious to me that it isn't the best implementation.

When you said it was just a matter of style, I took that to mean that you
yourself thought that there wasn't much to choose between the two
approaches.

I agree that it could be done either way.

We obviously thought that the control was the best/cleanest/most convenient
implementation, because that's how we implemented it. It seemed to provide
the maximum amount of code sharing between regular delete and tree delete.
 
> If you were
> to have to change the definition from a yet to be 
> standardized control to a
> yet to be standardized extended operation, what do you 
> believe the impact
> would be on your product?

We would have to throw away the existing implementation, for what appears to
be mainly aesthetic improvements.

Paul