[Date Prev][Date Next]
Re: Abandon Modify
"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 126.96.36.199.)
> 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 188.8.131.52. If it hasn't then I'm not sure what the
semantic of 184.108.40.206 is being implied here. Could you clarify?
Sun Microsystems Inc.