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

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


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

To:        Timothy Hahn/Endicott/IBM@IBMUS
cc:        ietf-ldapext@netscape.com
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: 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