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

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 29 Mar 2005 11:01:04 -0700

>>> Howard Chu [email-masked]> 3/27/05 1:09 PM >>
<snip>
>The first problem is that there is no way to indicate that a control is 
>only supported within specific contexts, as opposed to server-wide. 
>Since there is only the single rootDSE to use for advertising features, 
>it would be reasonable for clients to assume those features are 
>server-wide but in this case they are not.

The same problem applies to servers which chain operations. To me, a server with multiple backends could be viewed as a server chaining to multiple other servers. Or a server front ending a lot of other (backend) servers.
 
I don't think the advertisement of supportedControls, supportedExtensions or supportedFeatures can ever be completely relied on to represent the entire set of services when the DSA fronts multiple backends or chains to other DSAs.
 
<snip>

>So, the first issue with this text is that it does not explicitly say 
>what the server MUST do if all of these conditions are true:
>1) the server recognizes the control
>2) the server is unable to use the control on the given operation
>3) the control's criticality is FALSE

In this case, if the server really did recognize the control, then it should apply the control to the operation if the control spec allows it for that operation.

>My view is that the definition of "appropriate" covers this case - the 
>server recognizes the control but it is not appropriate for the 
>operation because the target context doesn't support the control. And so 
>it should be silently ignored. Kurt tells me my interpretation is not 
>what the WG intends. I believe for interoperability reasons it is 
>necessary to adopt my interpretation, and regardless of that decision, 
>it is necessary to provide more explicit language around what 
>"appropriate" means in this section.

Appropriate means that the control specification says it can be applied to that operation. I can add that clarification.

>On a slightly related topic, which I only noticed while investigating 
>this issue, I see that there is a specific exception noted for 
>criticality on controls attached to an Unbind operation. I don't see any 
>explanation of why, but I will assume it is because
>1) controls with Criticality TRUE may cause an otherwise valid 
>request to fail with an error response
>2) the Unbind request is defined to have no response

I need to add this to C.1.11

>The interesting points I draw from this are:
>3) contrapositive to (1), controls with Criticality FALSE may NOT 
>cause an otherwise valid request to fail with an error response
 
Sure, if the server cannot service the control for whatever reason, it will fail with an error response (see example below).

>4) the Abandon request is also defined to have no response, and thus 
>should have the same exception.
 
The outcome of Abandon is and always has been indeterminate. The outcome of Unbind was intended to be deterministic. While I agree that adding a critical control to an Abandon request seems to have very little use, it could be argued that it gives the server an extra hint at how (or whether) to apply the abandon request. 

>If (3) is true then the problem that prompted me to write this message 
>is solved. Regardless, (4) probably ought to be clarified.
 
3 is not true because the control itself may cause a number of problems which can cause failure as applied to the operation. Note that some implementations restrict access to some controls like the Virtual List View control. In the case where the server recognizes the control, it's appropriate for the operation, but the user doesn't have sufficient rights to apply it, the operation fails.

Jim

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 29 Mar 2005 11:14:07 -0800

>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: John McMeeking <[email-masked]>
Date: Tue, 29 Mar 2005 14:22:44 -0600

I've always taken the RFC 2251 language, and the protocol draft, to mean
that the server should ignore non-critical controls it doesn't know about
or are inappropriate.  That's how our server has implemented it.

As others have said, there are lots of reasons why a control might be
inappropriate for a given request, many of which a client couldn't possibly
know about ahead of time.  All the client has to go on is that the server
says it supports the control.  If the control is non-critical and a valid
control value has been supplied, the client should expect that the server
will either honor the control or ignore the control; the application
designer presumably has made the determination that either result is
acceptable.  If the server returns errors for non-critical controls -
particularly with multiple controls (paging and sorting) - what is a client
supposed to do?  It can't tell that the error is because of a control or
which control.

John  McMeeking

"Kurt D. Zeilenga" <[email-masked]> wrote on 03/29/2005 01:14:07 PM:

> >Appropriate means that the control specification says it can be
> applied to that operation. I can add that clarification.
>

Our servers have multiple backends and each backend ignores non-critical
controls it doesn't know or are not appropriate to a given operation.

> servers that FOO is not to be provided (e.g., remove the

But this still allows for the server to ignore the control.  You haven't
said that the server should fail the request because a non-critical control
couldn't be used across the entire operation.  A client shouldn't expect
different behaviors for control criticality because a given server happens
to be part of a distributed directory.