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

From: "Haripriya S" <[email-masked]>
Date: Thu, 17 Aug 2000 06:44:12 -0600

Kurt,

>>> "Kurt D. Zeilenga" <[email-masked]> 08/16/00 11:00PM >>>
[Kurt] Is the (modify/delete) operation still performed as an atomic
operation?

  - The modify/delete operation will be atomic only on a single entry, and the operation as a whole will have the same semantics as a search and multiple modifies/deletes from the client. Imposing a total atomicity in my opinion would be difficult to implement, inefficient, and also unnecessary in most cases. Directory transaction is probably a better mechanism to address atomicity of multi-entry operations.

[Kurt] I find the use of controls to return continuations awkward at
best.  Such controls which extend operations which the "scope"
of existing operations should use extended partial responses
to return "continuations".  In fact, I don't see why we need
separate controls/responses for each of these operation.  I,
personally, would rather see:

A) extendedPartialResponses generalized such that they may
returned in response to any operation (after appropriate
client solicitation). 

  - Currently a modify or delete operation doesn't return any partial responses, and hence the desicion to let the response for modify/delete remain as it is. As the request control is the one that imposes search semantics, the control response was designed to carry its specific responses, rather than change the base operation's response. 

[Kurt]
B) scopingControl be defined to allow specification of 
"scope" information (allowing use of "one" and "subtree"
scopes).  Per entry/continuation responses may be returned.

C) filterControl be defined to allow specification of a
filter which must match before performing operation.
Per entry/continuation responses may be returned.

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

[Kurt] I would note that such extensions must be very explicit
in regards to "atomic" properties of the "operation".  I
would recommend that only entry level atomic properties be
maintained, not operation level atomic properties.

- I agree. It would be better to limit atomicity requirements to operation on a single entry, rather than the whole operation. This is the assumption made in the document.

- Thanks and Regards,
- Haripriya

---

From: Bruce Greenblatt <[email-masked]>
Date: Thu, 17 Aug 2000 09:42:43 -0700

>
>   - Currently a modify or delete operation doesn't return any partial 
> responses, and hence the desicion to let the response for modify/delete 
> remain as it is. As the request control is the one that imposes search 
> semantics, the control response was designed to carry its specific 
> responses, rather than change the base operation's response.

This is one of the reasons that I chose to use extended operations for 
subtree copy, delete and modify.  I submitted an update during the blackout 
period, and I will use this opportunity to resubmit it.  Note also,Michael 
Armijo (who I haven't heard from in a while) wrote a draft sometime back 
for a subtree delete control, which was atomic, and didn't require partial 
updates.  Have you looked at his draft?

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
See my new Book on Internet Directories: 
http://www.phptr.com/ptrbooks/ptr_0139744525.html