Re: Protocol: control specifications.

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:11 AM 1/8/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>> As I previously suggested:
>>> 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.
>
>Oops.  I notice I forgot to answer that:
>
>In terms of the current definition of criticality, this gives the
>control different semantics.

By current, do you mean RFC 2251 or [Protocol].  [Protocol] is
certainly specifying different criticality semantics than RFC 2251.
I argue that the change is inappropriate and problematic.

Anyways, when we say 'control semantics', there two portions:
that defined by the "core" protocol specification and that
defined by the extension specification (which are associated
with the the controlType and associated controlValue).  We
call this extension specification the "control specification".
That might be part of the problem.

The extension specification should not overload or otherwise
alter the criticality semantics specified by "core" protocol
specification.  That causes all kinds of problems, such as
increasing the complexity of implementation (allowing controlType
specific processing requirements associated to criticality
field may be hard to deal with in some implementations).

>If there is a need to change this, then
>the semantics of the control as currently defined is flawed.  One should
>define a new and correct control instead, just as one should usually do
>instead of changing the semantics of a control in any other major way.

Any decisions regarding versioning should considered as part
of whatever process of which the technical specification is
being maintained under.  Note our standards process certainly
allows changes, even major ones, to be made without versioning
changes (if that is deemed appropriate by the community).
I believe it is quite common practice to defer such decisions
to the community most effected by the change and to a time
in which the (extension) specification is being revised.

I can certainly thing of cases where such a change would be
quite appropriate,  for example, where the change is due more
to applicability of the extension than to alter the semantics
of the controlType and associated controlValue.

>>> 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. 
>
>About the specifications doing so, I agree.  About [Protocol] doing so,
>I still disagree, as you can see.
>
>> I offer the the following replacement text:
>>     - guidance as to what value should be provided for the criticality      
>>       field,
>
>Which even removes existing servers' license from rfc2251 to treat
>wrong criticality as an error.  Please, no.

I don't believe the text I offerred says anything about how servers
are to treat the criticality value.  However, given the history
of control designers and implementors in this area, clarification
(as I offerred) would be wise.

>> and, given the past problems with control specifications
>> adding semantics to the criticality flag, I suggest the
>> following note be added as well to this bullet item:
>>     (the processing semantics of the criticality field, defined above,
>>     should not be altered in any way by the control specification)
>
>Fine.
>
>-- 
>Hallvard