Subject: RE: Abandon Modify

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 9 Jul 2002 14:03:51 +1000

I looked at the latest protocol draft and saw two intersting things.

Firstly, in the description for modify (or modifyDN, but then it shouldn't
matter), I saw the words "the server will return a result".

Secondly, under the abandon request, it does not state that updates cannot
be abandoned, but the confident example concerns the search request and
there are no words about similar semantics for other operations. I'm
confident that the original authors were mindful of the X.500 semantics and
expected abandon to only apply to search, but failed to state this.

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?

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.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, 9 July 2002 13:31
To: Ramsay, Ron
Cc: Ramsay, Ron; Mark Wahl; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Abandon Modify

At 06:54 PM 2002-07-08, Ramsay, Ron wrote:
>Thanks, Kurt.
>
>If LDAP doesn't have an 'abandoned' result code, then surely it needs one
>because, correct me if I'm worong, update operations are confirmed.  Or are
>you saying they are sometimes confirmed.

Abandoned operations (whether by Abandon, Bind, or Unbind) are
not confirmed.

>In X.500, of course, they are always confirmed.

The LDAP Cancel operation [draft-zeilenga-ldap-cancel-xx.txt] provides
X.500 Abandon semantics.

>Always, here, meaning
>ALWAYS. This is enforced by ROSE.
>
>I can't see why the abandon ID cannot be reused.

Depends on how the server is implemented.  While it
is likely most servers are implemented such
that reuse of the abandon ID as you describe is not
a problem, the existing specification allows for
implementations which would not allow reuse as you
describe.  I see no reason to relax the existing
restriction, but for a need to broaden the restriction
to cover other cases where the IDs cannot be reused.

Anyways, the abandon request ID (and even the abandoned
operation ID) reuse issue is minor issue.  The more
important issue is to clarify that the client is
not provided a clear indication that the requested
abandonment was honored or not.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Jul 2002 10:22:04 -0700

>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.

>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