RE: Abandon Modify

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

At 06:03 PM 2002-07-08, Ramsay, Ron wrote:
>Sorry, Kurt, I couldn't get past the first page.
>
>Abandon is not confirmed, correct, but ModDN is.

Not if abandoned.

>Therefore, you may not
>reuse id=1000 until receiving a response to the ModDN (possibly
>'abandoned').

An abandoned operation has no response.  LDAP has no
'abandoned' result code.

>I assume id=1001 may be reused immediately.

No, because processing of abandon may take some time and during
that time that message id might still be active.

>I note the X.500 doesn't allow abandon of update operations.

Yes.  It is unclear whether LDAP has a similar restriction.



>Ron.
>
>-----Original Message-----
>From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>Sent: Tuesday, 9 July 2002 4:53
>To: Mark Wahl
>Cc: mpana@metasolv.com; hmowafy@telcordia.com; ietf-ldapbis@OpenLDAP.org
>Subject: Re: Abandon Modify
>
>
>At 09:09 AM 2002-07-08, Mark Wahl wrote:
>>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? 
>
>No.  My example was flawed.
>
>The root of the problem is the protocol's assumption that
>any operation can be immediately abandoned.  However, some
>operations may take significant time/resources to abandon
>and some operations may not be abandonable once some amount
>of processing has been performed.
>
>Unless the server serializes operations, I don't see how it
>could implement Abandon semantics.
>
>I've changed the request to a modDN (as whole subtree rename
>operations are quite expensive in many implementations).
>
>Consider a client which sends:
>        modDN request (id=1000)
>        abandon request (id=1001) for modify request (id=1000)
>        search request (id=1002)
>
>If the client receives a search response for id=1002 before any
>response for the modDN request id=1000, it is to assume that
>the id=1000 is reusable as the modDN request is assumed to
>be abandoned.
>
>However, if the server doesn't serialize these operations, the
>modDN request may still be in progress of completion or abandonment.
>If so, a client were to send a second search request with id=1000,
>it would get protocol error (because the message id is still in use).
>
>So, there are the changes I suggest:
>
>Section 4.1.1:
>              
>Replace:          
>   A client MUST NOT reuse the message id of an abandonRequest or of the
>   abandoned operation until it has received a response from the server
>   for another request invoked subsequent to the abandonRequest, as the
>   abandonRequest itself does not have a response.     
>  
>with:
>   A client MUST NOT reuse the message id of an abandonRequest or of
>   an abandoned operation, unless it has subsequently completed
>   (successfully or not) a bind operation, as these operations may
>   still be in progress.
>
>and replace Section 4.11 (in total) with:
>
>4.11. Abandon Operation
>
>   The function of the Abandon Operation is to allow a client to request
>   that the server abandon an outstanding operation.  The Abandon
>   Request is defined as follows:
>
>        AbandonRequest ::= [APPLICATION 16] MessageID
>
>   The MessageID MUST be that of a an operation which was requested
>   earlier in this connection.
>
>   (The abandon request itself has its own message id.  This is distinct
>    from the id of the earlier operation being abandoned.)
>
>   As there is no response defined in the Abandon Operation and
>   no response to the abandoned operation, there is no clear
>   indication provided to the client as to whether the request
>   was (or will be) honored or not.
>
>   Not all operations can be abandoned or only abandonable during
>   certain stages of processing.  In particular, servers may not
>   be capable of rolling back complex modifications to the DIT
>   once they have been committed.
>
>   Servers are not required to be able and willing to honor all
>   (or any) Abandon request.  If the server is unable or unwilling
>   to honor the Abandon request, the server MUST ignore the Abandon
>   request.  That is, the operation for which the client requested
>   to be abandon is to be processed as if no Abandon request was
>   made.
>
>   A server MAY abandon operation even after it has provided
>   intermediate responses for that operation.  Of course,
>   the server MUST ensure that only properly encoded LDAPMessage
>   PDUs are transmitted.  For example, a server which receives
>   an Abandon request (which it intends to honor) for an Search
>   Operation in the midst of transmitting entry and reference
>   results may cease transmitting results but must ensure that
>   LDAPMessage PDUs sent are properly encoded.
>  
>   Clients MUST NOT send abandon requests for the same operation
>   multiple times, and MUST also be prepared to receive results from
>   operations it has requested to be abandoned (since the operation
>   to abandon may have completed before the Abandon request was
>   received or the Abandon request not honored).
>
>   Servers MUST discard abandon requests for message IDs they do not
>   recognize, for operations which cannot be abandoned, and for
>   operations which have already been abandoned.