|
>>> Howard Chu <hyc@highlandsun.com> 3/31/05 8:01:01 PM >>>
>Jim Sermersheim wrote: >> Sorry, if the operation is chained before being applied locally, don't >> change criticality. >> >> And yes, other options are to test the capabilities of the other >> agents/backends, and to perform the behavior locally when not supported >> (a server or frontend could do this with the sorting or vlv control, but >> would have to gather all entries first. > >The idea of testing the capabilities of the other servers/backends in >advance really doesn't scale well. If you have a large distributed set >of directory servers, where any server may be the frontend for yet >another arbitrarily large set of servers, you may spend more time >querying the capabilities (and getting unreliable answers) than actually >processing the client's original request. Nor is this sort of thing >properly cachable, since different servers with different capabilities >may enter and leave the network at arbitrary times. Right, and you don't really know in advance which servers will even be chained to.
>Following this line of attack is futile. It imposes additional overhead >on the servers to collect a type of information in which the client has >absolutely no interest. It is likely futile in a chaining environment, but may work where a server has multiple backends ? I don't know. Note also that another option mentioned is to service the control locally when the remote DSA can't or won't service it. This could only be done for certain controls.
>There is nothing in RFC2251 that suggests the current LDAPbis >interpretation is either intended or correct. Call me crazy, but I'd say >a behavior that is fundamentally useless doesn't belong in the spec. When I read RFC2251, I have to disagree.
"If the server recognizes the control type and it is appropriate for the operation, the server will make use of the control when performing the operation." I agree that the word "appropriate" is subject to interpretation. I interpret it as meaning that the control specification states that it's usable with the operation. Others (I think) extend this to also including other server policies (such as access controls). Regardless of how far people stretch the definition of appropriate, I think everyone agrees that (due to multiple backends and chaining), server advertisement of support of a control cannot always be relied on to provide an authoritative answer as to the servicability of the control.
"If the control is not appropriate for the operation and criticality
field is TRUE, the server MUST NOT perform the operation, and MUST instead return the resultCode unsupportedCriticalExtension." If "appropriate" means that the server found *any* reason in which the control causes the operation to fail, this says it should return unsupportedCriticalExtension (as opposed to something like insufficientAccessRights) for critical controls.
In your view, what would be the proper definition of "appropriate"? Or if that's too limiting, what would you like the criticality to mean?
Jim
|