Re: Protocol: control specifications.

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

At 12:27 AM 12/19/2003, Hallvard B Furuseth wrote:
>Jim Sermersheim writes:
>> 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.
>
>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.

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

>  From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
>  
>  Jim Sermersheim writes:
>  >>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 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.
>  
>  Then you need to add ', and the result if this constraint is violated'
>  to the above text.
>  
>-- 
>Hallvard