Re: protocol-22 comments

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.

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