|
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 <h.b.furuseth@usit.uio.no> 12/18/03 2:21:10 PM >>> 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 |