Subject: RE: Abandon Modify

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 15 Jul 2002 12:09:54 +1000

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,

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

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: David Chadwick <[email-masked]>
Date: Thu, 18 Jul 2002 10:50:21 +0100

>    or the reason that the modification failed."

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)

> (unless the operation could not be abandoned).

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

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

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

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