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

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 11 May 2004 15:19:18 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 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. 

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

<snip>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 11 May 2004 17:47:53 -0700

>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?

>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