RE: Abandon Modify

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

Sorry, Kurt, I couldn't get past the first page.

Abandon is not confirmed, correct, but ModDN is. Therefore, you may not
reuse id=1000 until receiving a response to the ModDN (possibly
'abandoned').

I assume id=1001 may be reused immediately.

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

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.