Subject: Re: Protocol: control specifications.

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 18 Dec 2003 18:10:49 -0700

By way of example, I think what Hallvard means is that if a control
specification says that the control is always critical, then that
specification should also say what happens when a client misbehaves and
sends that control with criticality set to FALSE.
 
Hallvard, is that what you are saying?
 
Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 12/18/03 4:57:40 PM >>>
At 12:27 PM 12/18/2003, Jim Sermersheim wrote:
>>>> Hallvard B Furuseth < [email-masked] > 12/10/03 4:36:13
AM >>>
>>> 4.1.11. Controls 
>>
>>> This document does not specify any controls. Controls may be 
>>> specified in other documents. The specification of a control
consists 
>>> of: 
>>> (...)
>>> - whether the control is always non critical, always critical, or 
>>> optionally critical, 
>>
>>A request fails if this condition is violated?
>The control specification would define server behavior when these
behaviors are violated.

The control specification should detail any particular
criticality requirements it has on how controls should be
generated but should not detail any criticality requirements
on how controls should be processed by the receiver. The
latter needs to be covered in protocol.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 19 Dec 2003 09:27:45 +0100

> sends that control with criticality set to FALSE.

And the other way around: Criticality TRUE when required to be FALSE.

> Hallvard, is that what you are saying?

Yes.  Unless [Protocol] itself is updated to say what happens.

Maybe this message got delayed or lost:

  From: Hallvard B Furuseth <[email-masked]>
  
  Jim Sermersheim writes:
  >>>> Hallvard B Furuseth <[email-masked]> 12/10/03 4:36:13 AM
  >>>>
  >>> 4.1.11. Controls 
  >>
  >>> specified in other documents. The specification of a control consists 
  >>> of: 
  >>> (...)
  
  Then you need to add ', and the result if this constraint is violated'
  to the above text.
  
-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 19 Dec 2003 04:22:34 -0800

>Yes.  Unless [Protocol] itself is updated to say what happens.

I do not see particular useful to detail how the server is to
behave when a client violates a particular absolute requirement
(or prohibition) of the controls (or other) specification.
Certainly, a violation of an absolute requirement/prohibition
is a protocol violation.  Whether or not server chooses to
return protocolViolation or just ignore it (be liberal in what
you accept) or do something else can be left an implementation
detail.

I will note that a server implementation which "makes use" of
the control might not even bother to examine the criticality
control.  It simply not interesting to the performance of the
operation.

>Maybe this message got delayed or lost:

There was another thread a while back with comments from Roger and
I regarding these "always" statements.   Key point made was that
we need to clarify that control specification may state restrictions
upon what criticality values the sender provides.  The text should
be written in a manner which implies control specifications may
place requirements on receiver on how to handle the criticality
field.  That's covered in [Protocol].