|
I believe that defining appropriate to mean that the control is attached to an appropriate operation as specified by the control specification will provide the most interoperability.
I do agree that as a feature goes, it's not that useful. However, I worry that changing its meaning to something that renders a more useful feature will not only cause interoperability problems, but also that it oversteps our charter.
I prefer to defer the invention of a more useful feature to a future specification, or to the extension guidelines (where we could also invent a way for the client to know whether a non-critical control was applied).
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 3/29/05 12:14:07 PM >>> At 10:01 AM 3/29/2005, Jim Sermersheim wrote: >Appropriate means that the control specification says it can be applied to that operation. I can add that clarification. That seems what the WG has concluded, but I still for wonder if that's best. It certainly seem counter to how many implementor have interpreted the RFC 2251 language, as well as quite counter-intuitive to me. To test the waters, I implemented code in OpenLDAP 2.3beta which behaves as the WG concluded. If a client asks for paged results (regardless of critical), the server returns unwillingToPerform if it cannot honor this control for the particular search operation requested. However, this is not the behavior client developers seem to expect. They assume that if the client says paging is not critical to them, that the server should simply ignore the control if it not willing to honor the control for that operation. It seems they expect this behavior, not only based on how they RFC 2251, but how many current servers behave today. I wonder how other servers which have different capabilities in different contexts behave? I understand that many servers support configuration and monitoring contexts, it is likely that these contexts do not support all the same capabilities of DIT contexts. So, are there cases in your server (or other servers you are familiar with) ignores a recognized non-critical control attached to an applicable request? (applicable here meaning that the technical specification indicated the control was appropriate to that kind of request) Personally, I think the logic that RFC 2251 was intending was that a server should not apply non-critical controls to portions of the operation. It must up front (before initiating the operation) make a determination whether to make use of the control or to ignore it. Once it does choose to make use of the control in the operation, there is no going back. This implies, for instance, that if a client asks for non-critical FOO and the server involves other servers in the evaluation of the operation, that all the servers involved must either all provide paging or none provide FOO. If the first server decides to provide FOO, then it must indicate to the other servers that FOO is now critical. If the first server decides not to provide FOO, then it must indicate to the other servers that FOO is not to be provided (e.g., remove the control). Kurt |