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

Protocol: control criticality for non-response messages



>>> Hallvard B Furuseth < h.b.furuseth@usit.uio.no > 12/10/03 4:36:13 AM >>>
>> 4.1.11. Controls
>
>> The criticality field is either TRUE or FALSE and only applies to
>> request messages that have a corresponding response message. For all
>> other messages (such as abandonRequest, unbindRequest and all
>> response messages), the criticality field SHOULD be FALSE.
>
>Why? What's wrong with a critical control which makes the abandon mean
>'abandon this operation only if something or other succeeds'?

Because there is no way or returning unavailableCriticalExtension.

>Besides, two paragraphs down, the draft does care for criticality=TRUE
>in requests withohut response:
>
> If the server does not recognize the control type or it is not
> appropriate for the operation, and the criticality field is TRUE, the
> server MUST NOT perform the operation, and for operations that have a
> response, MUST set the resultCode to unavailableCriticalExtension.

Note that it says the server "MUST set the resultCode to unavailableCriticalExtension". This imperative cannot be followed with operations that don't return responses.
Jim