Re: draft-ietf-ldapbis-protocol - controls

I have used the term "appropriate" as I interpret its meaning from 
RFC2251 and [protocols] where it is used as "appropriate for the 
operation". I would consider this to be constrained by the control 
specification and any implementation constraints imposed by the server 
implementation.

- Mark.

P.S. My apologies to any who recieved my previous posting more than once.

Howard Chu wrote:
> Mark Ennis wrote:
> 
>> As indicated in the message Jim referenced, our server will ignore the 
>> criticality flag of a control it recognises. However, this does not 
>> entirely address the issue Howard raised.
> 
> 
>> In a distributed environment, a server receiving a request may need to 
>> chain this request to a number of other servers, where the support of 
>> various controls in the different servers may be different. Where a 
>> given server receiving a chained request does not support a control, 
>> it will base its processing decision on the criticality of the 
>> control. So even if the server which received the request from the 
>> client can support a given control, the control will potentially be 
>> ignored for some part of the result set. This results in the effective 
>> behaviour of the server, which received the original request from the 
>> client, ignoring the non-critical control for some contexts, even 
>> though it does support the control. This is the way our server 
>> effectively behaves.
> 
> 
> Yes, exactly. If we persist with this mandate that servers return errors 
> for recognized, unusable non-critical controls, and tell client writers 
> to prepare for these error cases, we will have clients relying on these 
> error returns when the result is in fact unreliable. That is clearly a 
> broken spec.
> 
>> The only way around this, at present, would seem to be to force all 
>> the controls in a chained request to be critical, which would seem to 
>> be counter to the client's request that the processing of a 
>> non-critical control is optional.
> 
> 
> Right.
> 
>>
>> Our policy is to handle controls, in general, in the way John 
>> McMeeking described, which is to ignore unsupported and inapropriate 
>> non-critical controls.
> 
> 
> Please, we're all using the word "appropriate" in these responses but 
> not all with same meaning. I believe your response and John's response 
> are the more liberal interpretation, not "appropriate as defined by the 
> control's specification", but it would be best to be clear and explicit.
> 
>>
>> - Mark.
>>
>> Jim Sermersheim wrote:
>>
>>>> From another vendor:
>>>
>>>
>>> http://www.openldap.org/lists/ietf-ldapbis/200403/msg00055.html
>>>
>>>
>>>>>> "Jim Sermersheim" <[email protected]> 3/29/05 5:08:37 PM >>>
>>>
>>>
>>>
>>>
>>> Our implementations do this:
>>>  
>>> Is the control recognized and appropriate (as specified) for the 
>>> operation?
>>>    Yes, process the operation
>>>    No, Is it marked critical?
>>>       Yes, fail with unavailable critical extension
>>>       No, Ignore the control and process the operation
>>>  
>>> This has been discussed at length in the past, and consensus was that 
>>> this was the original intent and that this is what should be conveyed 
>>> in the new document.
>>>  
>>> IIRC, there were interoperability side effects of allowing 
>>> "appropriate" to mean anything the server wishes it to mean.
>>>  
>>> Jim
>>>
>>>
>>>>>> "Kurt D. Zeilenga" <[email protected]> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
> 
>