[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