Re: Protocol: control specifications.

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

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

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

> 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