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

["Salter, Thomas A" <Thomas.Salter@unisys.com>]

Another reason to use a control instead of an extended operation is when the
base operation makes sense without the control, and can be carried out by a
server that does not recognize the control.  

Consider these three scenarios:
1. the server understands the control.
2. the server does not support the control and the control is critical.
3. the server does not support the control and the control is not critical.

In #1, the server just does what the control says to do.
In #2, the server rejects the operation (either because it's a V3 server and
honors the critical flag, or because it's V2 and can't parse the request.)

#3 is the interesting case.  If the server does not recognize the
non-critical delete subtree control, it will try to perform a regular
delete.  If the entry happens to be a leaf entry, the delete will be
successful.  If it's not a leaf, the operation fails with the "not a leaf"
entry.  

Thus a delete subtree control works correctly in more cases than a delete
subtree extended operation.  That is, delete subtree is successful even if
the server does not recognize the control, if the subtree happens to consist
of exactly one entry (a leaf entry).

Tom

 > -----Original Message-----
 > From: Bruce Greenblatt [mailto:bgreenblatt@dtasi.com]
 > Sent: Friday, July 02, 1999 12:26 PM
 > To: Salter, Thomas A; 'ietf-ldapext@netscape.com'
 > Subject: RE: LDAP Tree Delete Control -
 > draft-armijo-ldap-treedelete-01.txt
 > 
 > 
 > At 11:46 AM 7/1/99 -0400, Salter, Thomas A wrote:
 > >I think if you take that position to an extreme, you'll 
 > never use controls
 > >for anything.  The RFCs should specify explicitly what 
 > every form of an
 > >operation will do.  A control by its very nature changes (and thus
 > >contradicts) that.
 > >
 > 
 > I was just worried that this change might break some LDAP 
 > implementations.
 > 
 > >In this case, changing delete into delete tree feels (to 
 > me) like a natural
 > >use for a control.  It's a lot like the change of ModifyRDN 
 > into ModifyDN
 > >that happened from V2 to V3.
 > 
 > To me it is different, given the whole partial success, and 
 > client feedback
 > requirements that were voiced in response to the little draft that I
 > posted.  In going from V2 to V3, many things were changed, 
 > and we were
 > expecting to cause trouble and to break applications.
 > 
 > >
 > >I guess the actual choice between control and an extended 
 > operation is more
 > >art than science.  I'd lean towards using a control 
 > whenever the parameters
 > >work out 'nicely' and the function is about the same.  
 > 
 > 
 > I agree with your point here.  I'd add that I'd lean towards using an
 > extended operation whenever there is more than a tiny chance 
 > of breaking an
 > existing LDAP implementation (server or client application)...
 > 
 > >
 > >
 > > > -----Original Message-----
 > > > From: Bruce Greenblatt [mailto:bgreenblatt@dtasi.com]
 > > > Sent: Thursday, July 01, 1999 12:06 AM
 > > > To: Michael Armijo (Exchange); 'ietf-ldapext@netscape.com'
 > > > Subject: RE: LDAP Tree Delete Control -
 > > > draft-armijo-ldap-treedelete-01.txt
 > > > 
 > > > 
 > > > I certainly understand the text of the draft.  I'm pointing 
 > > > out that I was
 > > > reluctant to create a control that explicitly contradicts 
 > > > the operation to
 > > > which it is intended to be attached.  RFC 2251 is certainly 
 > > > silent on the
 > > > issue of what a control may do (at least there is 
 > nothing obvious in
 > > > 4.1.12).  I'd just be cautious in this instance in creating 
 > > > a control that
 > > > appears to allow the delete operation to contradict the protocol
 > > > specification.  What's the advantage in using a control for 
 > > > this versus an
 > > > extended operation?
 > > > 
 > > > Bruce
 > >
 > >
 > >
 >