Subject: RE: Abandon Modify

From: [email-masked]
Date: Fri, 28 Jun 2002 14:13:51 -0400

In section 4.6, rfc 2251 specifies: "The entire list of entry modifications
MUST be performed in the order they are listed, as a single atomic
operation."

Wrt. the Abandon operation, the rfc specifies in section 4.11: "Clients
[...] MUST also be prepared to receive results from operations it has
abandoned (since these may have been in transit when the abandon was
requested)."

So:
- given the requirement for atomicity, the modification either happens
entirely or not at all
- if a server receives an AbandonRequest too late in the process, the
ModifyResponse may still be returned. This is an indication for the client
that the AbandonRequest has been ignored/discarded by the server.
- however, "if the connection fails, whether the modification occurred or
not is indeterminate" (rfc2251 section 4.6). 

Regards,
Mircea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 28, 2002 1:07 PM
To: [email-masked]
Subject: Abandon Modify

Has any thought been given to the handling of an Abandon request for a
Modify operation?

I don't see much discussion or clarification in 2251, Sec 4.11, on how to
handle an Abandon in the middle of processing a modify operation,
especially that the client does not get a response on any Abandon requests.

It could be too late to honor the Abandon request but the client will never
know.

I may have missed earlier decisions on this, but was this deemed acceptable
by the working group?

Does the server administrator have a choice, say to reject "Abandons" on
all Update requests?

Thanks
Hala

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 28 Jun 2002 21:30:37 -0700

IMO, the LDAP Abandon operation should be deprecated in favor of
the LDAP Cancel operation [draft-zeilenga-ldap-cancel-xx.txt]
(which has X.500 Abandon operation sematics), or minimally,
clarified to be only applicable to search operations.

The problem with the Abandon operation is that it requires
the server to serialize certain operations to ensure it
doesn't give the client a false sense that the operation
to be abandon was abandoned.  (This semantic is implied
by the last paragraph of Section 4.1.1.1.)

Consider a client which sends a modify request followed
immediately be a search request.  If the server responds
to the search before the modify then the client is to
assume that the modify was abandoned.  But this may not
be the case.  Hence, the server has to defer responding
to the Search until it either abandons the Modify or
responds to the Modify.

Kurt