[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Abandon Modify
"Ramsay, Ron" wrote:
>
> 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."
>
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,
>
> 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 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
> 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" <Ron.Ramsay@ca.com> 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:Kurt@OpenLDAP.org]
> Sent: Wednesday, 10 July 2002 3:22
> To: Ramsay, Ron
> Cc: ietf-ldapbis@OpenLDAP.org
> 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
--
*****************************************************************
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: D.W.Chadwick@salford.ac.uk
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
*****************************************************************
begin:vcard
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:d.w.chadwick@salford.ac.uk
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard