To: Timothy Hahn/Endicott/IBM@IBMUS, ietf-ldapext@netscape.com
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:hahnt@us.ibm.com]
Sent: Thursday, 25 January 2001 4:32
To: ietf-ldapext@netscape.com
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:
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