Subject: Re: draft-ietf-ldapbis-protocol - controls

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 29 Mar 2005 17:37:07 -0700

From another vendor:
http://www.openldap.org/lists/ietf-ldapbis/200403/msg00055.html

>>> "Jim Sermersheim" <[email-masked]> 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-masked]> 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

---

From: Mark Ennis <[email-masked]>
Date: Wed, 30 Mar 2005 11:11:00 +1000

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.

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.

Our policy is to handle controls, in general, in the way John McMeeking 
described, which is to ignore unsupported and inapropriate non-critical 
controls.

- Mark.

---

From: Mark Ennis <[email-masked]>
Date: Wed, 30 Mar 2005 11:50:51 +1000

- Mark.

---

From: Howard Chu <[email-masked]>
Date: Tue, 29 Mar 2005 17:56:29 -0800

> 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.

> counter to the client's request that the processing of a non-critical 

Right.
> described, which is to ignore unsupported and inapropriate non-critical 

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.
>> 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
>>
>>
>>> Appropriate means that the control specification says it can be 
>>> applied to that operation. I can add that clarification.
>>
>>
>>

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support

---

From: Mark Ennis <[email-masked]>
Date: Wed, 30 Mar 2005 12:15:30 +1000

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:
>> 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.
> 
> 
>> 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.
> 
>