[Date Prev][Date Next]
Re: Protocol: control specifications.
Kurt D. Zeilenga writes:
>At 01:46 AM 1/6/2004, Hallvard B Furuseth wrote:
>>Jim Sermersheim writes:
>>>>>>Hallvard B Furuseth <email@example.com> 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
Yes. I think being liberal here is harmful, as explained previously in
this thread. If LDAP is going to be liberal in _everything_ it accepts
as a matter of principle, I have a couple of other wishes - like
eliminating error returns from string preparation.
> 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.
If the programmer tests his program, which I would hope he does, he is
the one who will get the lession.
That leaves already existing programs. For those, the deployer may
still get the lession because the server _may_ already reject controls
with wrong criticality. He will certainly get the lession if he tries
the program against a server which does not support the control - and he
is likely get it in a far less pleasant way than just seeing the program
return an error.
>>>> 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
>>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.
OK. Also, your previous point still applies.
> 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