RE: Abandon Modify

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

At 11:24 AM 2002-07-08, mpana@metasolv.com wrote:
>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.

Right, it must serialize the operations involved to provide the
defined semantics.  Do you know of a server implementation which
serializes these operations?

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