Re: Protocol: control specifications.

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

Kurt D. Zeilenga writes:
>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).

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

Good point.

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

-- 
Hallvard