Re: draft-ietf-ldapbis-protocol - controls

[John McMeeking <jmcmeek@us.ibm.com>]

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" <Kurt@OpenLDAP.org> wrote on 03/29/2005 01: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)

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

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

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.

>
> Kurt
>
>