Subject: Protocol: control criticality for non-response messages

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 18 Dec 2003 13:25:35 -0700

>>> Hallvard B Furuseth < [email-masked] > 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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 18 Dec 2003 22:21:10 +0100

Jim Sermersheim writes:
>> mean 'abandon this operation only if something or other succeeds'?
> 

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.

>> criticality=TRUE in requests withohut response:
>>
> 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