Re: Protocol: control criticality for non-response messages

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Jim Sermersheim writes:
>>>> 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.

I don't see the problem.  Abandon can fail if it is sent without a
critical extension, and it can fail if it is sent with one.  In either
case, it's the programmer's responsibility to know that he won't know
if the operation succeeded.

An unbind which failed due to a critical extension is rather worse, of
course.

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

Look at the previous phrase.  It only MUST that for operations with a
response.

-- 
Hallvard