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

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



At 12:00 PM 1/25/01 +1100, Ramsay, Ron wrote:
>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) }.

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