Re: draft-ietf-ldapbis-protocol - controls

The server has choose to either ignore the non-critical
control for the entire operation or make use of the
non-critical control for the entire operation.

If the server has different capabilities in different portions
of the DIT (due to chaining or whatever), the server has to
deal with that in some fashion that ensures the entire
operation is processed in a manner consistent with the above.

How to make use of the control over the entire operation
depends on the control and implementation choices.  In some
cases (for instance, likely w/ managedsait), the right answer
is to mark the control as critical when forwarding it and,
if unavailable, return a search continuation for that portion
of DIT.  In other cases, the server might leave the control
non-critical in chaining (for instance, possible with
sorted results... easier to merge sorted results than
to merge unsorted results).  And it other cases, it might
be best to strip the control and handle all the
operation semantics locally (for instance, possibly with
sorted results).

But the issue here shouldn't be how the server maintains
the semantics, but what semantics the client can rely on
the server to maintain.   The client be able to rely on
each non-critical control applying to all the results or
none of the results returned for the request.

Kurt

At 08:18 PM 3/31/2005, Jim Sermersheim wrote:
>>>> Mark Ennis <[email protected]> 3/31/05 8:21:43 PM >>>
>>While I agree that the idea of testing the capabilities of the servers 
>>is not practical, I do think the idea of defining procedures for 
>>distributed operations which force controls to be critical and then 
>>process the results of distributed requests to form an appropriate 
>>response to the clients original request is potentially viable. This 
>>assumes that a control specification is not permitted to mandate that a 
>>control MUST be non-critical.
>>
>>That said, I do agree that non-critical controls should be ignored 
>>rather then result in an error code for the operation. And this would 
>>simplify procedures for distributed operations for LDAP.
>If it is not immediately known whether a control would cause an error, then at what point can a non-critical control be ignored? Prior to name resolution? Prior to operation evaluation? During operation evaluation? Before sending any responses to the client? After sending responses to the client?
> 
>Similarly, when does one know whether to return an error versus discarding an transaction which has begun and re-starting the operation sans the control?
> 
>Also, some controls define error codes to be returned for certain conditions (see VLV for example). When these conditions are met when the control is non-critical, should it also be ignored and the operation be re-applied without the control?
> 
>There are cases where allowing non-critical controls to be ignored doesn't simplify the distributed operation problem. When a control is paired with a response control which indicates whether or not the control was successfully applied, then the chaining server is still faced with having to deal with different behaviors of chained-to servers. Also, any non-critical control on search operations may succeed on an initial server, and be ignored when chained to another server. Meaning the control was partially supported. I think most people would agree that this is undesirable — a control should either be applied or ignored unless that control specification allows it to be partially applied. 
> 
>Also consider the tree delete control. A client may send this as non-critical, knowing (well, expecting) that if it's recognized and appropriate, it will be applied, and the subtree will be deleted. If it can partially fail (due to being chained or sent to multiple backends), the subtree may be partially deleted and the tree left with a hole in it.
> 
>Jim