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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:05 AM 8/18/00 -0600, Haripriya S wrote:
>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(?).

I recommend making limits OPTIONAL with DEFAULTs of no limit.

>Also introduce a field from the client ( optional ) specifying whether it can and wants to receive partial responses.

Please, no.  This only reintroduces all the issues which use
partial responses was meant to avoid...  with the addition headache
of having to support two sets of semantics.  Combining a "paritial
response" approach and "all-or-nothing" approach is not wise.  It
would be difficult to specify in a clear and concise manner and
likely hard to implement.

>2. Define a general partial extended response.
>This can be returned by any LDAP operation.

I suggest, for now, you just hijack extendedPartialResponse and make
a note in your I-D that your use of extendedPartialResponse I-D
assumes a generalization of the extendedPartialResponse I-D
will be made.  The generalization work will like progress quickly
as it's mostly "syntactical sugar".

>Define a specific partialextendedresponse for continuation responses and use it for continuations needed for this operation.

Yes.

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

No.  Return them in another partial extended response.  If you don't
separate per entry/continuation responses then the operation should
be treated as one atomic action (or you should disallow abandon).

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

Yes!

Return a partial extended response for each entry the operation acts
upon.  The response should contain the DN and the results specific
to that entry.

Use the final result response only to indicate the completion (success
or failure) of the operation.