|
>>> Howard Chu hyc@highlandsun.com> 3/27/05 1:09 PM >>
<snip> >The first problem is that there is no way to indicate that a control is
>only supported within specific contexts, as opposed to server-wide. >Since there is only the single rootDSE to use for advertising features, >it would be reasonable for clients to assume those features are >server-wide but in this case they are not. The same problem applies to servers which chain operations. To me, a server with multiple backends could be viewed as a server chaining to multiple other servers. Or a server front ending a lot of other (backend) servers.
I don't think the advertisement of supportedControls, supportedExtensions or supportedFeatures can ever be completely relied on to represent the entire set of services when the DSA fronts multiple backends or chains to other DSAs.
<snip>
>So, the first issue with this text is that it does not explicitly say >what the server MUST do if all of these conditions are true: >1) the server recognizes the control >2) the server is unable to use the control on the given operation >3) the control's criticality is FALSE In this case, if the server really did recognize the control, then it should apply the control to the operation if the control spec allows it for that operation.
>My view is that the definition of "appropriate" covers this case - the >server recognizes the control but it is not appropriate for the >operation because the target context doesn't support the control. And so >it should be silently ignored. Kurt tells me my interpretation is not >what the WG intends. I believe for interoperability reasons it is >necessary to adopt my interpretation, and regardless of that decision, >it is necessary to provide more explicit language around what >"appropriate" means in this section. Appropriate means that the control specification says it can be applied to that operation. I can add that clarification.
>On a slightly related topic, which I only noticed while investigating >this issue, I see that there is a specific exception noted for >criticality on controls attached to an Unbind operation. I don't see any >explanation of why, but I will assume it is because >1) controls with Criticality TRUE may cause an otherwise valid >request to fail with an error response >2) the Unbind request is defined to have no response I need to add this to C.1.11
>The interesting points I draw from this are: >3) contrapositive to (1), controls with Criticality FALSE may NOT >cause an otherwise valid request to fail with an error response Sure, if the server cannot service the control for whatever reason, it will fail with an error response (see example below).
>4) the Abandon request is also defined to have no response, and thus >should have the same exception. The outcome of Abandon is and always has been indeterminate. The outcome of Unbind was intended to be deterministic. While I agree that adding a critical control to an Abandon request seems to have very little use, it could be argued that it gives the server an extra hint at how (or whether) to apply the abandon request.
>If (3) is true then the problem that prompted me to write this message >is solved. Regardless, (4) probably ought to be clarified. 3 is not true because the control itself may cause a number of problems which can cause failure as applied to the operation. Note that some implementations restrict access to some controls like the Virtual List View control. In the case where the server recognizes the control, it's appropriate for the operation, but the user doesn't have sufficient rights to apply it, the operation fails.
Jim
>-- >-- Howard Chu >Chief Architect, Symas Corp. Director, Highland Sun >http://www.symas.com http://highlandsun.com/hyc >Symas: Premier OpenSource Development and Support |