[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDAP Tree Delete Control - draft-armijo-ldap-treedelete-01.txt
Thomas,
I'd actually thought a little about this when I read in the draft that the
control may or may not be critical. I thought, "when would it make sense
for an application to not want this control to be critical". You scenario
three is the only situation that makes much sense here. Also note that in
the case of scenario 2, if you are actually trying to delete a leaf object,
you have failed an operation (unsupported critical control) that would
ordinarily succeed had the unsupported control not been present. So, using
your reasoning, scenarios two and three cancel out. I think that a much
better approach would be for LDAP client applications to read the
information in the rootDSE object to find out which controls an LDAP server
supports, and to not submit unsupported controls.
I still think that a subtree operation, and an operation against a subtree
are really different things, and I'd prefer to use an extended operation
for this purpose.
Bruce
At 01:05 PM 7/2/99 -0400, Salter, Thomas A wrote:
>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
> > >
> > >
> > >
> >
>
>
>