[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: draft-ietf-ldapbis-protocol - controls

Jim Sermersheim wrote:
>>> Howard Chu hyc@highlandsun.com> 3/27/05 1:09 PM >> <mailto: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. 

OK, that statement is clear, but it is not helpful for client implementors.

>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.

This really doesn't make any sense. Again, in this same paragraph talking about criticality:
A value of TRUE indicates that it is unacceptable to perform
the operation without applying the semantics of the control.

The logical inference to draw from this is that a value of FALSE indicates that it *is* acceptable to perform the operation without applying the control.

Think about what an actual client is going to do with a non-critical control - if the request with the control fails, the client is just going to have to re-issue the request without the control anyway. The most logical behavior for the server is to ignore any non-critical control that cannot be applied to the operation regardless of reason. The behavior you're describing here just makes the use of controls more inefficient, requiring more transaction roundtrips to get something that the client writer thought "would be nice, but isn't essential."

Clearly if the control is marked Critical, all of these checks and error responses are essential, and the client explicitly wants to be told if the request cannot be processed exactly as requested. But when the control is not marked Critical, the client doesn't really care whether the control is applied so long as the request is processed.

--
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support