[Date Prev][Date Next]
RE: Abandon Modify
I don't see a defect in the way Abandon is defined by 2251. IMO it should
not be deprecated.
The way I interpret 18.104.22.168 is that upon reception of an AbandonRequest, the
server must refrain from responding to subsequent (*) requests from that
same client until it deals with the abandon. If the AbandonRequest comes too
late to be processed, then the first response sent back to the client shall
be the one for the abandoned operation.
(*) received by the server after the AbandonRequest
So, for example, if a client sends three requests before the server has a
chance to respond to any of them:
(#1)ModifyRequest followed by a
(#2)AbandonRequest(for msg.#1) and a
A. if the Modify operation can not be abandoned, the server returns a
(#1)ModifyResponse *before* returning one or more (#3)SearchResult
B. if the Modify operation is abandoned, the server will return one or more
From: Mark Wahl [mailto:Mark.Wahl@sun.com]
Sent: Monday, July 08, 2002 12:10 PM
To: Kurt D. Zeilenga
Cc: email@example.com; firstname.lastname@example.org; ietf-ldapbis@OpenLDAP.org
Subject: 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 22.214.171.124.)
> 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 126.96.36.199. If it hasn't then I'm not sure what the
semantic of 188.8.131.52 is being implied here. Could you clarify?
Sun Microsystems Inc.