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