Subject: Re: Comments on draft-seilenga-lldap-cancel-00.txt

From: "Timothy Hahn" <[email-masked]>
Date: Wed, 24 Jan 2001 14:56:19 -0500

Kurt,

I see, from re-reading X.511 and the abandon description there that the 
original request should return the abandoned (in your description, 
canceled) indication.

This would seem to force the issue of having to add a value to the 
resultCode enumeration in the LDAPResult sequence.

While I am concerned about protocol element updates without some sort of 
version indication noting their addition, I understand your intent and 
your choice to augment the resultCode for the canceled value.  And if 
we're updating resultCode anyway, adding in the other three doesn't seem 
that much more of a leap.

The more general question of what are acceptable amendments to the ASN.1 
is an interesting topic that I hope the list discusses.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

To:     Timothy Hahn/Endicott/IBM@IBMUS
cc:     [email-masked] 
Subject:        Re: Comments on draft-seilenga-lldap-cancel-00.txt

Note that the 'canceled' resultCode is to be returned by
canceled operation, not the cancel operation.  I find it
inappropriate to overload this condition onto any other
resultCode.  They already have defined semantics.  The
semantics of being canceled is orthogonal to these
semantics.  Hence, I believe adding an additional resultCode
is, IMO, justified.  I could make similar arguments
with respect to the other result codes.

However, I think the basic issue here is whether or not a
protocol extension to LDAP can amend the ASN.1.  I believe
limited amendments can be made, including:
        - additional elements may be added to sequences, and
        - additional choices may be added,
        - additional values may be added to enumerations.

The base specification states how implementations faced with
unrecognized protocol elements should behave.  However, I
do believe that no extensions should be provided without
mutual agreement of the protocol peers.

Kurt

At 12:31 PM 1/24/01 -0500, Timothy Hahn wrote:

>Greetings,
>
>In section 4.1, the existing return codes for the protocol are being 
added to with four additional values.  The values seem appropriate only 
for the Cancel extended operation.
>
>I suggest that the existing return codes are not changed.  Rather, I 
suggest that the Cancel Response contain:
>
>CancelResponseValue ::= SEQUENCE {
>        cancelResultCode ENUMERATED {
>                canceled (0),
>                noSuchOperation (1),
>                tooLate (2),
>                cannotCancel (3)
>        }
>}
>
>This way, the existing protocol data elements are not infringed upon by 
the added extended operation.
>
>My other commnets are editorial and will be sent directly to Kurt.
>
>Regards,
>Tim Hahn
>
>Internet: [email-masked]
>Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
>phone: 607.752.6388     tie-line: 8/852.6388
>fax: 607.752.3681

---

From: "Timothy Hahn" <[email-masked]>
Date: Wed, 24 Jan 2001 20:50:49 -0500

Ron,

Sounds ok to me.

Regards,
Tim Hahn

To:     Timothy Hahn/Endicott/IBM@IBMUS, [email-masked]
cc: 
Subject:        RE: Comments on draft-seilenga-lldap-cancel-00.txt

I think it is worth looking more closely at the result codes.

cancelled is the result returned in the original request (success is the
result returned in the abandon response but this doesn't appear).

noSuchOperation, tooLate and cannotCancel are returned in the abandon
response (there is no original request).

Therefore, only 'cancelled' need ba added to RFC 2251. All the others 
could
appear in a special

    CancelResponseValue ::= ENUMERATED { success(0), noSuchOperation(1),
tooLate(2), cannotCancel(3) }.

(I don't see any reason for the (redundant) SEQUENCE.)

Ron.

-----Original Message-----
From: Timothy Hahn [mailto:[email-masked]]
Sent: Thursday, 25 January 2001 4:32
To: [email-masked]
Subject: Comments on draft-seilenga-lldap-cancel-00.txt

Greetings,

In section 4.1, the existing return codes for the protocol are being added
to with four additional values.  The values seem appropriate only for the
Cancel extended operation.

I suggest that the existing return codes are not changed.  Rather, I 
suggest
that the Cancel Response contain:

This way, the existing protocol data elements are not infringed upon by 
the
added extended operation.

Regards,
Tim Hahn

---

From: "Salter, Thomas A" <[email-masked]>
Date: Thu, 25 Jan 2001 10:20:28 -0600

Perhaps you need one new result code of "error, see extended response".
This is generic enough for use by all extended operations but doesn't
overload the existed status codes.

 > From: Kurt D. Zeilenga [mailto:[email-masked]]
 > Sent: Wednesday, January 24, 2001 8:31 PM
 > To: Ramsay, Ron
 > Cc: [email-masked]; [email-masked]
 > At 12:00 PM 1/25/01 +1100, Ramsay, Ron wrote:
 > >Therefore, only 'cancelled' need ba added to RFC 2251. All 
 > the others could
 > >appear in a special
 > > 
 > Yeah, but, the extendedResponse would need to return a resultCode.
 > One could say it always returned success and the client should
 > look at the response value for details.  That is, the operation
 > could return:
 >         success with response value success,
 >         success with response value noSuchOperation,
 >         success with tooLate,
 >        success with cannotCancel,
 >        protocolError, and
 >         other non-success resultCodes (especially in
 >           the face of extension by control)
 > 
 > Overloading success is bad.  Overloading other resultCodes
 > is equally bad.
 > 
 > IMO, adding new resultCodes is the most sound approach.
 > 
 > PS: SEQUENCE provides extensibility
 >