Re: Protocol: control specifications.

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

I really should digest the implications of the control RFCs I just
posted before replying to some of this, but anyway:

Kurt D. Zeilenga writes:
>At 05:41 PM 1/9/2004, Jim Sermersheim wrote:
>> So, what I think is being asked is this:
>> 
>> If a control specification states: The criticality of the XYZ control
>> is always TRUE, and some client sends the XYZ control with
>> criticality of FALSE, what is the server to do?
> 
>    If the server recognizes the control type and it is appropriate for
>    the operation, the server will make use of the control when
>    performing the operation.
>
> otherwise, the control is to be ignored.
>
>> Similar but more explicitly, if the control specification says: The
>> criticality of the XYZ control SHALL be TRUE, and some client sends
>> the XYZ control with criticality of FALSE, what is the server to do?
> 
> (...)
> otherwise, the unsupportedCriticalExtension is to returned.

I don't like to make a difference between these two cases:

I hope you do not wish to give the control spec the same right to
override criticality=TRUE sent by the client.  I haven't quite
thought through the consequences of that, but it feels a lot more
dangerous.

If not, then figuring out whether the effective criticality is TRUE
or FALSE gets rather complicated, and I'm not sure I see the
justification for that.

Also, the difference between these two texts is very small.  An
control spec author might choose one when he meant the other, and a
reader of the spec might assume one when the author meant the other.
It's just like the disagreement in this tread about the wording in
RFC2251.  So we'd have to demand that the specs are worded very
carefully, and perhaps go through existing control specs and update
them to clarify this.

>> If in either of these scenarios, it seems correct for the server to
>> always fail the operation (in order to ensure some aspect of
>> interoperability), then somewhere there should be language to that
>> effect.
> 
> Exactly, if RFC 2251 had intended this, the text:
>    If the server recognizes the control type and it is appropriate for
>    the operation, the server will make use of the control when
>    performing the operation.
> 
> would have be qualified as only apply when the criticality had a value
> consistent with the control's specification.

Not so, because that text is about how to perform the operation when
it _is_ performed, not about whether or not to perform it.

>> Personally, I think such language would belong in the specific
>> control specification, and likely, the appropriate resultCode is
>> protocolError.
> 
> Authors of such documents should be very careful in including such
> language as it likely to cause far more problems that it will ever
> solve.  (...)

I agree.

It should be possible to put such additional semantics in the
controlValue instead, if one needs to.

Also, I don't see much benefit from giving control specs this
freedom, when it's all about an error anyway so the correct thing to
do is to fix the client.

>> On the other hand, if it always inappropriate for any specification
>> to mandate behavior when a client violates an imperative regarding
>> criticality, then I guess it's always server-defined.
> 
> My suggestion is worded as a strong recommendation, not a mandate.

But if we keep the text which lets the spec mandate criticality, the
spec is still free to give recommendations.  Or we could mention
that explicitly in [Protocol].

> It's also
> worded as a requirement upon the document defining the control,

That's no advantage, if I understand the context correctly:-)

> not as a
> restriction upon extent of which control can extend the operation.

I didn't understand that.  Can you rephrase?

>> And on yet some other hand, maybe it is inappropriate for a control
>> specification to use imperatives. I think that's a discussion to be
>> had on its own. Certainly RFC 2251 reads as though the control
>> specifications will contain imperatives (implied through the term "is
>> always").
> 
> I believe it is assumed that control specifications will use imperatives
> where appropriate.

I read both your suggested text and your arguments up to now as
denying them that possibility.  If you wish to allow the spec to
mandate criticality, please add it to your suggested text.  Also,
are you talking about client-supplied criticality, the criticality
which the server assumes, or both?  If the former, is it possible
that we actually agree about something - that even if we take your
suggested text, you would allow servers to treat wrong criticality
as an error if they wished?

-- 
Hallvard