>>> Hallvard B Furuseth <email@example.com> 12/29/03 12:40:56 PM >>>
>Kurt D. Zeilenga writes:
>> I do not see particular useful to detail how the server is to
>> behave when a client violates a particular absolute requirement
>> (or prohibition) of the controls (or other) specification.
>> Certainly, a violation of an absolute requirement/prohibition
>> is a protocol violation. Whether or not server chooses to
>> return protocolViolation or just ignore it (be liberal in what
>> you accept) or do something else can be left an implementation
>After thinking a bit more about this, I believe [Protocol] should
>require protocolViolation if the required criticality of a supported
>control is violated. That will teach programmers who use a server
>which does support the control, to write programs which will work
>right when moving to a server which does not support the control.
>For example, the No-Op control, which prevents the effects of update
>operations, has criticality TRUE. It would be rather unfortunate to
>run a program which uses it with criticality FALSE against a server
>which does not support the control.
I would rather take the less limiting approach, and place this kind of imperative in the control specification(s).