Re: appropriateness of combination of controls (new suggestion)

["Jim Sermersheim" <jimse@novell.com>]

Ok, my turn to be surprised. eDirectrory will return an error as I
thought when it determines there is an invalid control combination (of
the same or different type) (criticality is ignored at this point). But
the error is protocolError (not unwillingToPerform as I previously
assumed).

Actually (in case someone tests my claim on ldap.novell.com), some
combinations erroneously return invalidAttributeSyntax. This is
obviously a defect and should be fixed.

Jim

>>> "Jim Sermersheim" <jimse@novell.com> 5/15/04 10:06:16 AM >>>
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 5/15/04 9:47:22 AM >>>
>At 08:02 AM 5/15/2004, Jim Sermersheim wrote:
>>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 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