[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Abandon Modify
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). 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 <d.w.chadwick@salford.ac.uk> 07/18/02 06:50PM >>>
"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
*****************************************************************