RE: Abandon Modify

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

Thanks, Kurt.

If LDAP doesn't have an 'abandoned' result code, then surely it needs one
because, correct me if I'm worong, update operations are confirmed. Or are
you saying they are sometimes confirmed.

In X.500, of course, they are always confirmed. Always, here, meaning
ALWAYS. This is enforced by ROSE.

I can't see why the abandon ID cannot be reused. I see this as valid:

o search, id = 1
o search, id = 2
o search, id = 3
o abandon target = 1, id = 4
o abandon target = 2, id = 4
o abandon target = 3, id = 4

The reason I see it as valid is that the operation is not confirmed, so the
client cannot retain the reference. Therefore, as a protocol (and not an
API), the server cannot assume the client has maintained a reference. Also,
I don't see why the server needs a reference - it should simply mark the
context of the ooperation as 'abandoned'. It's not as if the server is going
to have to pass the reference back.

I would like to hear what you have to say about uodate operations not being
confirmed in LDAP. It seems like a BIG statement.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Tuesday, 9 July 2002 11:22
To: Ramsay, Ron
Cc: Mark Wahl; mpana@metasolv.com; hmowafy@telcordia.com;
ietf-ldapbis@OpenLDAP.org
Subject: RE: Abandon Modify


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.