RE: appropriateness of combination of controls (new suggestion)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 02:19 PM 5/11/2004, Jim Sermersheim wrote:
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 5/11/04 10:19:32 AM >>>
><snip>
>
>>By variable, I presume you mean protocol field.  
>
>Yes, I'm saying an LDAP operation is made up of all of the fields in
>the LDAPMessage.
>
>>If you meant
>>factor instead, then I would strongly disagree.  With any protocol
>>field, my concern is that any protocol field might overly complicate
>>server determination of appropriateness.  
>
>I don't think it complicates things any more than the control
>specification wishes it to. If the control specification says that
>control X is appropriate to be used with any search operation, then
>there is no complication. 
>
>It is no more complex to exclude search operations with a critical sort
>control, than to exclude search operations with a time limit. 

Your example is misleading.  Your change would allow something like:
   This control is approrpiate for search operations of scope
   baseObject and any sizeLimit OR of scope oneLevel and sizeLimit
   of 1 OR scope of subtree and timeLimit of 2.

By allowing appropriate can be based on any field, the appropriateness
check cannot effectively no longer be table driven.   Implementations
instead would have to a custom appropriateness check function for
each control, instead of using a table-driven common appropriateness
check function.

And if you allow that, you might as well allow:
  "This control is appropriate when the sky is blue."

I'm not sure that is necessarily a bad thing, but I do think it beyond
what RFC 2251 intended when it said "appropriate for the operation".

I wonder whether any implementation utilizes custom appropriate
check functions... or are all implementations table driven?

>If LDAP had defined time limit as a control, you would agree that it
>may be used to affect the appropriateness of the operation, yet because
>it's 'built-in' to the base operation, you argue that it cannot. I
>disagree with this.
>
>>I would prefer to
>>limit determination to consideration of protocolOp and controlTypes.
>
>I disagree. See above. Furthermore, one immediately questions the
>extendedReq and extendedResp protocolOps.

An oversight on my part:  protocol operation type, extended request/response
names (where applicable), and control types.

>It seems extremely limiting to
>lump all extendedReq definitions together and say that a control can or
>cannot be attached to them all. I hope that wasn't the intent of 2251.