[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Abandon Modify



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


>>> "Ramsay, Ron" <Ron.Ramsay@ca.com> 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:jimse@novell.com] 
Sent: Monday, 15 July 2002 5:47
To: Ramsay, Ron; Kurt@OpenLDAP.org 
Cc: ietf-ldapbis@OpenLDAP.org 
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" <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