Subject: Re: protocol-22 comments

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 16 Apr 2004 23:05:54 +0200

Jim Sermersheim writes:
>>>> Hallvard B Furuseth [email-masked]> 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.

I'm thinking partly of controls that are executed one at a time rather
than setting a variable and acting on it later.  However, also consider
what to do if the same control appears twice, 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.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 16 Apr 2004 14:45:57 -0700

>String Ordering Match, or something, before parsing them. Which seems

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

>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

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