Re: Protocol: control specifications.

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

Jim Sermersheim writes:
>>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 12/29/03 12:40:56 PM
>>
>> 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). 

OK if control specifications are required to say how the server should
behave in this respect.  But I get the impression that this is the
alternative which Kurt likes least...

Would making this the default be an acceptable compromise?  That is,
[Protocol] could say "Unless the control specification says otherwise,
the server should return protocolViolation if the required criticality
of a supported control is violated."

-- 
Hallvard