RE: Abandon Modify

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

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:Kurt@OpenLDAP.org]
Sent: Tuesday, 9 July 2002 13:31
To: Ramsay, Ron
Cc: Ramsay, Ron; Mark Wahl; mpana@metasolv.com; hmowafy@telcordia.com;
ietf-ldapbis@OpenLDAP.org
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