Subject: Re: Abandon Modify

From: Mark Wahl <[email-masked]>
Date: Mon, 08 Jul 2002 11:09:46 -0500

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 08 Jul 2002 11:53:15 -0700

At 09:09 AM 2002-07-08, Mark Wahl wrote:
>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.