|
>>> Mark Ennis <mark.ennis@eb2bcom.com> 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
|