Subject: RE: Abandon Modify

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 9 Jul 2002 11:10:52 +1000

What is all this talk about serialising operations? It is not required
(every operation has an identifier). If you don't understand how it works,
ask *that* question, rather than proposing a new model of operation.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, 9 July 2002 4:25
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: 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 4.1.1.1 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
 (#3)SearchRequest,
then:
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
(#3)SearchResult

Regards,
Mircea.

-----Original Message-----
From: Mark Wahl [mailto:[email-masked]]
Sent: Monday, July 08, 2002 12:10 PM
To: Kurt D. Zeilenga
Cc: [email-masked]; [email-masked]; [email-masked]
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 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: [email-masked]
Date: Tue, 9 Jul 2002 14:09:37 -0400

Why prohibit or recommend against LDAP Abandon for update operations. Isn't
b) and c)  (below) sufficient to allow server implementers to choose whether
or not to support Abandon for updates?

Mircea.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 1:22 PM
To: Ramsay, Ron
Cc: [email-masked]
Subject: RE: Abandon Modify

At 09:03 PM 2002-07-08, Ramsay, Ron wrote:
>It seems a pity that the document actually precludes sending a search done
>in response to abandon. It makes sense for dumb-terminal applications but
>not for more sophisticated processing - when should you relase the context?

No.  That would be a significant change in semantics of the
Abandon operation.

I think we, minimally, need to:
        a) further restrict reuse of message ids,
        b) clarify that servers are to ignore the abandon request
        where it is unwilling or unable to honor the request, and
        c) clarify that clients may receive responses to
        operations which they requested to be abandoned but
        which the server did not abandoned.

>But to address the issue at hand, I believe that all updates have to be
>confirmed. X.500 doesn't allow updates to be abandoned, and I don't see how
>you can argue against this. But, if you want to allow it, you then have to
>introduce the 'abandoned' error.

I don't believe it appropriate to change the semantics of the
LDAP Abandon operation.  If the DAP Abandon semantics are desired,
an operation which provides these semantics should be introduced
(see draft-zeilenga-ldap-cancel-xx.txt).

I am also concerned that the LDAP Abandon use with update
operations.  I believe this is best addressed by either prohibiting
or recommending against use of the LDAP Abandon to abandon update
operations.

Kurt

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 10 Jul 2002 10:44:19 +1000

Except that you left out

d) clients may not receive responses to operations they have attempted to
abandon.

This is pretty significant considering this thread started from the
ambiguity which arises in this situation.

Ron.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, 10 July 2002 4:10
To: [email-masked]; Ramsay, Ron
Cc: [email-masked]
Subject: RE: Abandon Modify

Mircea.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 1:22 PM
To: Ramsay, Ron
Cc: [email-masked]
Subject: RE: Abandon Modify

Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 14 Jul 2002 13:46:43 -0600

Ron,

While I agree that some kind of confirmation should be sent (likely
through an extension of the protocol), I believe the Abandon operation
implies that the operation being abandoned never returns a response
(unless the operation could not be abandoned).

I infer this from the statement:
"..., and MUST also be prepared to receive results from operations it
has abandoned..."

Obviously the original intent was that an operation will not return any
response if it is abandoned. I believe this is the way all
implementations work.

Jim

>>> "Ramsay, Ron" <[email-masked]> 07/09 6:42 PM >>>
Kurt,

I wasn't suggesting a change to the abandon operation. My suggestion
was
that all update operations should always be confirmed, which would
require
the 'abandoned' error code.

I don't even think that this is a change to the spec as the protocol
document says that servers 'will' return a response (to update
operations).

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Wednesday, 10 July 2002 3:22
To: Ramsay, Ron
Cc: [email-masked] 
Subject: RE: Abandon Modify

Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 16 Jul 2002 22:34:42 -0600

Or maybe a general statement calrifying the effect of abandon on the
response of an operation.

>>> "Ramsay, Ron" <[email-masked]> 07/15 11:09 AM >>>
Jim,

Should you perhaps change the following statement in the protocol
draft?

"   The server will return to the client a single Modify Response 
   indicating either the successful completion of the DIT modification,

   or the reason that the modification failed."

Ron.

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Monday, 15 July 2002 5:47
To: Ramsay, Ron; [email-masked] 
Cc: [email-masked] 
Subject: RE: Abandon Modify

Ron,

Obviously the original intent was that an operation will not return
any
response if it is abandoned. I believe this is the way all
implementations work.

Jim

Kurt,

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Wednesday, 10 July 2002 3:22
To: Ramsay, Ron
Cc: [email-masked] 
Subject: RE: Abandon Modify

Kurt

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 17 Jul 2002 15:45:32 +1000

"Servers may not ..." is ambiguous - it actually tends to "Servers MAY NOT
..." (Servers are required not to support abandon.)

You need to say something like "Servers need not support the abandon
operation for operations other than search."

Ron.

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Wednesday, 17 July 2002 14:39
To: Ramsay, Ron; [email-masked]
Cc: [email-masked]
Subject: RE: Abandon Modify

I'm proposing this for the last paragraph of 4.1.1.1 (Message ID)
A client MUST NOT send a request with the same message ID as an earlier
request on the same connection unless it can be determined that the
server is no longer servicing the earlier request. Otherwise the
behavior is undefined. For operations that do not return responses
(unbind, abandon, and abandoned operations), the client assumes the
operation is in progress until a subsequent bind request completes.

I'm proposing this change/addition to 4.11 (Abandon Operation)
There is no response defined in the Abandon Operation. Upon
transmission of an Abandon Operation, a client may expect that the
operation identified by the Message ID in the Abandon Request will be
abandoned. If an operation is abandoned by the server, the response to
the abandoned operation is not sent. 

Abandon and Unbind operations cannot be abandoned. Servers may not
allow other operations to be abandoned (or immediately abandoned), in
particular update operations, or operations that have been chained.

>>> "Kurt D. Zeilenga" <[email-masked]> 07/10 2:22 AM >>>

Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 17 Jul 2002 00:24:04 -0600

I would hope that readers know the difference between may not and MAY
NOT. I note that there are 6 occurances of may not in this doc.

>>> "Ramsay, Ron" <[email-masked]> 07/17 2:45 PM >>>
"Servers may not ..." is ambiguous - it actually tends to "Servers MAY
NOT
.." (Servers are required not to support abandon.)

Ron.

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Wednesday, 17 July 2002 14:39
To: Ramsay, Ron; [email-masked] 
Cc: [email-masked] 
Subject: RE: Abandon Modify

A client MUST NOT send a request with the same message ID as an
earlier

Kurt

---

From: David Chadwick <[email-masked]>
Date: Fri, 19 Jul 2002 01:27:49 +0100

Jim Sermersheim wrote:
> 
> Well, at this point, I think we have multiple interoperable
> implementations that DO NOT return responses for any operation (update
> or otherwise) that the server has deemed sucessfully abandoned. I
> believe this behavior is consistent with the original intent of the
> draft (though I personally don't like it).

I dont believe it is, in that the original intention of the draft was
that Abandon should only be used for retrieval operations. therefore the
draft did not cover the case for modify operations, although because of
poor wording people could think that it did.

David

> And I don't think we can
> change the behavior without causing implementors to update their
> executables.
> 
> I would be interested if there are server implementations that return
> responses to abandoed update operations that are meant to convey a
> successful abandon of that operation.
> 
> Jim
> 
> >>> David Chadwick <[email-masked]> 07/18/02 06:50PM >>>
> 
> "Ramsay, Ron" wrote:
> >
> > Jim,
> >
> I agree with Ron that all modify operations must send a reply.
> Otherwise
> we have the situation in an attempted abandon of a modify that the
> user
> does not get an Abandon reply and keeps on waiting for a modify reply
> which may or may not arrive depending upon whether the abandon
> succeeded
> or failed (and for which there is no way of telling, other than by
> waiting and waiting since there is no reply to the abandon)
> 
> > Ron,
> >
> I think that this is because the original wording ASSUMED that abandon
> ONLY worked for Search and Compare operations, since early LDAP was
> always intended to be a complete subset of X.500, and X.500 only
> supports abandon on retrieve (and not update)type operations. The
> sloppy
> wording was OK for the original implementors because they knew what
> the
> implicit assumptions were. Later implementors who did not know what
> X.500 was, took LDAP literally and since abandoning modifies was not
> explicitly forbidden they assumed it was allowed.  This is just
> another
> example of Tom Gilb's proverb Dont assume that everyone knows what
> your
> assumptions are
> 
> regards
> 
> David
> 
> > >It seems a pity that the document actually precludes sending a
> search
> > done
> > >in response to abandon. It makes sense for dumb-terminal
> applications
> > but
> > >But to address the issue at hand, I believe that all updates have
> to
> > be
> --
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: +44 161 295 5351  Fax +44 01484 532930
> Mobile: +44 77 96 44 7184
> Email: [email-masked]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 18 Jul 2002 10:00:02 -0600

draft (though I personally don't like it). And I don't think we can

Jim

draft?

regards

David

any
search
applications
to

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 19 Jul 2002 11:57:26 +1000

David,

I agree.

The case of a update is more critical in that, whether the abandon succeeds
or not, you still want to know the current state of the DIT. Query
operations don't change the DIT.

Ron.

-----Original Message-----
From: David Chadwick [mailto:[email-masked]]
Sent: Friday, 19 July 2002 10:28
To: Jim Sermersheim
Cc: Ramsay, Ron; [email-masked]
Subject: Re: Abandon Modify

David