Re: protocol-22 comments

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

At 02:05 PM 4/16/2004, Hallvard B Furuseth wrote:
>Jim Sermersheim writes:
>>>>> Hallvard B Furuseth h.b.furuseth@usit.uio.no> 3/9/04 7:20:19 AM >>
>>>> 4.1.11. Controls
>>>> Additionally, unless order-dependent semantics are given in a
>>>> specification, the order of a combination of controls in the SEQUENCE
>>>> is ignored.
>>>
>>> This implies that controls (A, B) MUST behave identically with controls
>>> (B, A). I think it should be, "the effect of the ordering of a
>>> combination of controls in the SEQUENCE is unspecified"?
>> 
>> When the control specification doesn't describe these ordering
>> semantics, interoperability problems arise where one server may
>> arbitrarily assign semantics to the order of two controls, and another
>> may not. Clients will come to expect behavior that is not specified.
>>  
>> Is there a reason for allowing order semantics as unspecified which
>> outweighs the interoperability problems that come with it?
>
>Only a vague suspicion that it may put a burden on implementations.  I
>wonder if the simplest way to be sure this requirement is obeyed might
>be for the server to order request controls in ascending order by Octet
>String Ordering Match, or something, before parsing them. Which seems
>a bit excessive to me.

And will fail... consider for instance the prior requirement to
order options within an attribute description.

>I'm thinking partly of controls that are executed one at a time rather
>than setting a variable and acting on it later.

I think that's a bad way to think of controls.  Controls carrying
extension information.  All appropriate and recognized information
(e.g., the control type is appropriate and recognized) is made use
of in processing THE operation.

>However, also consider
>what to do if the same control appears twice,

For most controls, that's a protocol error.  Unless the control
specification says the control can appear multiple times, it cannot.
This should be made clear in [Protocol].

>but containing different
>parameters, and the control is implemented by setting a variable for the
>operation to that parameter.  With the current text, the server is
>required to always pick e.g. the parameter with lowest value, instead of
>just using the parameter in the last control.  Or it could detect the
>situation and return unwillingToPerform, but then it will still need
>extra state info in order to notice the situation.

I am curious as what current implementations do when presented
with multiple controls of the same type within a single PDU.
OpenLDAP, IIRC, treats this as an error condition.

Kurt