RE: Abandon Modify

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

What is all this talk about serialising operations? It is not required
(every operation has an identifier). If you don't understand how it works,
ask *that* question, rather than proposing a new model of operation.

-----Original Message-----
From: mpana@metasolv.com [mailto:mpana@metasolv.com]
Sent: Tuesday, 9 July 2002 4:25
To: Mark.Wahl@sun.com; Kurt@OpenLDAP.org
Cc: hmowafy@telcordia.com; ietf-ldapbis@OpenLDAP.org
Subject: RE: Abandon Modify


I don't see a defect in the way Abandon is defined by 2251. IMO it should
not be deprecated.

The way I interpret 4.1.1.1 is that upon reception of an AbandonRequest, the
server must refrain from responding to subsequent (*) requests from that
same client until it deals with the abandon. If the AbandonRequest comes too
late to be processed, then the first response sent back to the client shall
be the one for the abandoned operation.

(*) received by the server after the AbandonRequest

So, for example, if a client sends three requests before the server has a
chance to respond to any of them:
 (#1)ModifyRequest followed by a
 (#2)AbandonRequest(for msg.#1) and a
 (#3)SearchRequest,
then:
A. if the Modify operation can not be abandoned, the server returns a
(#1)ModifyResponse *before* returning one or more (#3)SearchResult
B. if the Modify operation is abandoned, the server will return one or more
(#3)SearchResult

Regards,
Mircea.


-----Original Message-----
From: Mark Wahl [mailto:Mark.Wahl@sun.com]
Sent: Monday, July 08, 2002 12:10 PM
To: Kurt D. Zeilenga
Cc: mpana@metasolv.com; hmowafy@telcordia.com; ietf-ldapbis@OpenLDAP.org
Subject: Re: Abandon Modify


"Kurt D. Zeilenga" wrote:
> 
> 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.

I don't agree with deprecating existing and interoperable features, if a
clarification can be added instead to the Draft Standard.  Deprecating 
existing work opens a slippery slope of 
 - Bind doesn't support capability X, so let's deprecate it and define a 
   "Super Bind" extension
 - Search doesn't support capability Y, so let's deprecate it and define
   a "Super Search" ...


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

I don't see why it has to do that from your description.  Do you mean
that the client is sending both requests with the same message ID?  If so
then it has violated 4.1.1.1.  If it hasn't then I'm not sure what the 
semantic of 4.1.1.1 is being implied here.  Could you clarify?  

Thanks,

Mark Wahl
Sun Microsystems Inc.