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

From: "Haripriya S" <[email-masked]>
Date: Fri, 18 Aug 2000 08:05:55 -0600

Hi,

> Using (a generalization of) extendedPartialResponse with delete/modify,
IMO, is a much better approach.  I believe such a generalization
is in the works.

Is somebody working on it?

> 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. 

Yes, I see your point now. Thanks for the input. As per your suggestion, I can modify the proposal as follows:

1. Retain the EntrySelection control which consists of 4 parts,
  a scope, an referencealiases field, a filter, and a set of fields for setting limits on the operation ( time, error, etc. ). This is approximately equivalent to a search operation syntax itself. Make all fields except limits fields  optional(?). Also introduce a field from the client ( optional ) specifying whether it can and wants to receive partial responses.

2. Define a general partial extended response. This can be returned by any LDAP operation. (This would have to go into LDAP rfc). The "response" portion of the extendedresponse will again be a sequence of an LDAP OID for the specific response, and the specific response itself. These can be defined specific to various extendedoperations and controls. Define a specific partialextendedresponse for continuation responses and use it for continuations needed for this operation.

3. The modifyResponse or delResponse will return the final response. Error codes specific to the request control, and the failedDNs will be returned by the EntrySelectionResponse control. The referrals field will be removed from the response control, and referrals will be returned through modifyResponse or delResponse themselves.
Another approach is to allow failedDNs also to be returned partially as and when they fail, and hence define another specific partialextendedresponse to return failedDNs too.

Hope this addresses what you are saying. Does this sound ok to everybody? I can start on this if it does.

> 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.

I can let both the fields be optional if there is no issue.

Thanks and Regards,
Haripriya