Re: Protocol: control specifications.

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

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?

   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 unsupportedCriticalExtension is to returned.

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

>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.  (As many of us have learned already.)  In particular, one
should consider whether there will ever be a need to change that
language and what impact such a change would have on forwards/backwards
compatibility.  Also, one should not assume that such a check would
be trivial extension to the servers existing code handling criticality
checks (given that the check is likely in a different code path).
(Yada, yada, yada.)

>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.  It's also
worded as a requirement upon the document defining the control, not as a
restriction upon extent of which control can extend the operation.

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

> 
>Jim
> 
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 1/9/04 5:30:22 PM >>>
>At 01:05 PM 1/9/2004, Hallvard B Furuseth wrote:
>>Kurt, I'm suddenly wondering if I've misunderstood you completely,
>>and if so I don't know where. So I need a bit of clarification
>>before replying to your latest message:
>
>After a couple of draft responses, I've concluded that there
>isn't a good way to clarify my reply without taking a (big)
>step back.
>
>LDAP provides, in controls, a mechanism for extending the
>semantics of an existing operation. The extended semantics
>are associated with the type of control (an OID) and
>associated type-specific data (an octet string).
>
>This mechanism also provides a facility by which a client
>can indicate to the server that the extended semantics
>associated with any particular control instance is critical.
>That is, by marking a control critical, the client demands
>that server not proc! ess the operation if it cannot make
>use of the control.
>
>Criticality was intended to be in the eye of the client
>(based upon user input and/or guidance in the specification
>of the particular control), not the server.
>
>Also, the criticality field was not intended to have any
>other semantic. That is, the performance of the operation
>as extended by the control is not intended to be dependent
>on the criticality value.
>
>I believe that most implementations behave as I describe
>above, which I content is as intended. I also believe
>this section needs clarification to ensure future clients
>and servers implement the technical specification in
>a manner consistent with today's implementations. My
>suggestions are intended to do this.
>
>I object to your suggestions are numerous grounds:
>1) that wasn't what was intended,
>2) that isn't what is implemented,
>3) that violates interoperability principles on
>which Internet is b! uilt on (be strict in what you
>send, be liberal in what you! accept) ,
>4) that hinders subsequent revision of extension
>specifications, and
>5) it will limit how one control could extend
>an operation extended by other control(s).
>
>(The last one is new. For now, I'll leave it as something
>for you and others to think about.)
>
>Kurt