|
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?
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 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. Personally, I think such language would belong in the specific control specification, and likely, the appropriate resultCode is protocolError.
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.
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").
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 process 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 built 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 |