[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Protocol: control specifications.

At 01:46 AM 1/6/2004, Hallvard B Furuseth wrote:
>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.

This disallows servers in being liberal in what they accept (in this
case).

While I thinking 'teaching programmers' approach is fine for the lab,
I disagree that this approach is appropriate for the Internet as the
lesson may given upon the deployer not the programmer.

>>> 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...

I think it is inappropriate for control specifications to attach
additional semantics to the criticality field as criticality
should only matter to implementations which don't make use of the
control.

>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."

I think this is a bad idea here.  Such requirements can lead to
interoperability problems with control specifications are updated.
Consider the need to update a specification from "clients MUST provide
criticality field of TRUE" to "clients SHOULD provide criticality field
of TRUE".  Such a change could not be made if we require servers to
error where the criticality is not TRUE.

Control specifications should detail under what circumstances the
control generator should mark the control critical or non-critical.
However, they should not detail any semantics upon the implementation
processing that control as those are defined in the general protocol
semantics.

Kurt