Re: Protocol: control specifications.

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

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

I mean RFC 2251.  It says the definition of a control includes:

     - whether the control is always noncritical, always critical, or
       critical at the client's option,

To my eyes, this means that setting the control wrong is a user
error.  Good quality servers SHOULD reject such user errors, except
when that gets too hairy or cumbersome to implement.

I can see that you can instead interpret that wording alone as 'the
value of the criticality is as specified regardless of what is sent
over the protocol', but a few paragraphs above the RFC describes how
the server must act on the criticality _field_.  The 'field' refers
clearly to the criticality protocol element.

BTW, I note Jim has updated the text I quoted from rfc2251 to match
that.

> [Protocol] is
> certainly specifying different criticality semantics than RFC 2251.
> I argue that the change is inappropriate and problematic.

Well, we too argue for changes from RFC 2251, which the other of us
considers 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.

Yes, I said I agree.  My original suggestion - which Jim adopted -
was bad, and so was my compromise suggestion.  So in the protocol-20
description of a control specification:

   - whether the criticality field should be always set to TRUE, always 
     set to FALSE, or sender's choice,

I agree completely that far (and want to go further), but the
following should be deleted:

     and server behavior when 
     constraints of this nature are violated,  

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

Well, true.  I should have said, one should _normally_ define a new
control.  A major change in semantics is usually a bad idea, and
should be considered very carefully.

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

My point here is that a change in specified criticality _is_ a
change of semantics, and quite a major one in my opinion.  The
choice of whether to change the control or create a new one should
be seen in that light.

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

Huh?  The original rfc2251 text, quoted at the top of this message, says
- or can be interpreted to say, take your pick - that supplying another
criticality is a user error.  Your replacement text above does not in
any way say that, so I don't see how the server can be allowed to treat
it as an error.

OTOH, your following text does give a useful clarification:

>>>     (the processing semantics of the criticality field, defined above,
>>>     should not be altered in any way by the control specification)

-- 
Hallvard