|
>>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 4/16/04 3:05:54 PM >>>
>>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. If there are any two controls that in any way affect each other, and if neither of the control specifications provide instructions on how they are to interact with each other (and whether order matters when doing so), then I think a server should fail the request as it has no idea how to properly execute the operation.
>I'm thinking partly of controls that are executed one at a time rather >than setting a variable and acting on it later. Any given server implementation knows which controls it implements. It also should be aware of any ways in which two controls on a single operation might affect the operation's outcome (including whether ordering changes the outcome). If the combination of controls is underspecified, and ordering will affect the outcome, the server (if following the rule in the current draft) should not process the operation (at least that's my read of it).
>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. I think the text (though not explicitly) says the server should fail this scenario (unless the control specification states what to do).
Jim
|