Re: Abandon Modify

[Mark Wahl <Mark.Wahl@sun.com>]

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