Subject: Re: New draft - LDAP control for modify and delete on multipleentries

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 17 Aug 2000 09:20:21 -0700

At 06:44 AM 8/17/00 -0600, Haripriya S wrote:
>  - Currently a modify or delete operation doesn't return any partial responses,

So extend them!

> As the request control is the one that imposes search semantics,

If you don't want to extend modify/delete, extend search to do
modify/delete.  This is no more perverted than extending modify/delete
to do search... and search provides the responses types needed (you
can even be the first to return extended response PDUs in response
a search request... as allowed by 2251).

However, I think both your proposal and the above are suboptimal.
Using (a generalization of) extendedPartialResponse with delete/modify,
IMO, is a much better approach.  I believe such a generalization
is in the works.

>the control response was designed to carry its specific responses, rather than change the base operation's response. 

But the delete/modify operation's semantics was never designed to
support subtrees.  To support subtrees well partial responses are needed.
Without partial responses, you cannot return per entry/continuation
responses as separate PDUs, which will either force providing per
operation atomic properties or require abandon to be disallowed
on these operations.  However, users want entry level atomic
properties on such operations with the ability to abandon
in-progress operations which act on more than one entry.  Because
of this, the single response approach to non-base scoped operations
is, IMO, inadequate. 

> - This (scope & filter conrols) looks like a good idea to me. But will there be any reallife scenario's where we want to do a filtering, without the scope specified? 

Yes. And scoping without filtering.  Scope and filter are orthogonal
to each other... so specifying them separately seems natural to me.
Combining them into one control may be natural for others.  But
two v. one control is really just syntax, it shouldn't change the
semantics as long as both are OPTIONAL.

Kurt