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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

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: hahnt@us.ibm.com
>Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
>phone: 607.752.6388     tie-line: 8/852.6388
>fax: 607.752.3681