Subject: Re: Protocol: control criticality for non-response messages

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 18 Dec 2003 15:29:15 -0700

Ok, after re-reading your example, I can see your point on allowing a
criticality of TRUE on abandon.
 
But for unbind, I think we'd have to alter a significant amount of text
in order to allow it, and I'm not sure allowing it is beneficial. Note
that the document tells clients to drop the connection once they send an
unbind. It's not contingent on whether a critical control was or was not
supported on the server.
 
I'd like to propose allowing abandonRequest to have a TRUE criticality,
but leaving unbindRequest as is.
 
Jim

>>> Hallvard B Furuseth <[email-masked]> 12/18/03 2:21:10 PM
>>>
Jim Sermersheim writes:
>>>> 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.

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 19 Dec 2003 09:29:48 +0100

> but leaving unbindRequest as is.

Sounds good.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 22 Dec 2003 10:32:30 +0100

> but leaving unbindRequest as is.

That leaves the question of what the server should do if it receives an
unbindRequest with a control with TRUE criticality.  I suggest behaviour
should either be undefined (in which case you can drop the 'criticality
field SHOULD be FALSE' text), or that the criticality field is ignored.

-- 
Hallvard