Subject: Re: appropriateness of combination of controls (new suggestion)

From: "Jim Sermersheim" <[email-masked]>
Date: Sat, 15 May 2004 10:06:16 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 5/15/04 9:47:22 AM >>>
>At 08:02 AM 5/15/2004, Jim Sermersheim wrote:
>>>>> "Kurt D. Zeilenga" <[email-masked]> 5/15/04 7:54:50 AM >>>
>>>At 10:32 PM 5/14/2004, Jim Sermersheim wrote:
>>>>It disallows combinations of other controls (like VLV and PSearch)
>>and returns an error if these are combined. I don't have code
available
>>right now or I could tell you what >the error is (I assume it's
>>unwillingToPerform). 
>>>
>>>Question: if both VLV and Psearch were marked critical, would
>>>the error you returned be different? 
>>
>>No, the routine that checks for known/appropriate controls is
different
>>from the routine(s) which will return errors for invalid
combinations.
>>We kept the former very simple (do we understand this control, and is
it
>>appropriate for this operation).  At this point of checking, we
don't
>>even know if there are more controls in the message.
>
>Do you also handle a message with two critical manageDsaIT
>controls in the same fashion?

Two manageDsaIT controls will result in a "last one wins" behavior
(regardless of criticality). The criticality is *only ever* checked when
we don't understand the control, or it's not allowed on an operation
(with no regard to other fields of the operation (including other
controls).

>Do you also handle a message with two (different) critical
>Psearch controls in the same fashion?

I'd have to look at the code to report on the exact behavior of this.
From memory, we return an error. I _can_ say that the behavior is the
same regardless of criticality.

>>It would be good to know what other implementations do. I know there
>>are some others that support VLV and PSearch. I wonder how they
handle
>>the combination?
>
>Well, I checked our code and, to my surpise, it wasn't as
>I previously described.  OpenLDAP slapd(8) response of say:
>        search+ManageDsaIT+manageDsaIT
>        search+subentries+subentries
>
>would be to return protocolError.  Given this, I retract my
>suggested text.
>
>If we're going to recommend returning an error here, I think
>we should specifically recommend return of protocol error over
>a code like unwillingToPerform.
>
>unwillingToPerform implies that the operation can be performed,
>but that this particular server is unwilling or unable to perform
>the operation (at this time).  protocol error more accurately
>reflects that the server cannot make sense of the request.

I could go either way on this. One server may be unwilling to support
controls A and B because there are undefined yet seemingly obvious
semantics which it cannot perform, while another server is able to
perform the seemingly obvious combination.

I Believe eDirectory returns unwillingToPerform since the message is
well-formed as per the ASN.1. I still need to get at the code and
check.

However, returning protocol error might nudge participants (control
specification writers) to be more careful.

Jim

---

From: Michael Ströder <[email-masked]>
Date: Mon, 17 May 2004 08:29:39 +0200

Jim Sermersheim wrote:
> (regardless of criticality).

I think a "last one wins" behavior is bad. This leads to poorly written LDAP 
clients not interoperable with different LDAP servers.

Please, be strict in cases where requests are obviously ambigous. LDAP 
clients sending those kind of requests should be treated to get fixed. IMO 
returning protocolError is appropriate in this situation.

Ciao, Michael.