Subject: Multiple "similar" controls per op

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 08 Mar 2001 20:26:50 -0700

RFC 2251 allows one to specify mutliple controls on a single operation. It doesn't disallow two or more controls of the same type to exist on the operation. This means we either need to:

a) Add text to the "recommended control specification guide" (or whatever it's called), that tells authors of control spec's to call out whether this is allowed with that particular control. Or,
b) ammend 2251 to disallow this.

I lean towards a), just to leave the door open. How do others feel. If b), we'll take it to the LDAPBIS list.

Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 08 Mar 2001 21:29:55 -0800

>I lean towards a), just to leave the door open. How do others feel. If b), we'll take it to the LDAPBIS list.

I concur.  I believe it unwise to place unnecessary limitations
upon the kinds of extensions which might be defined.  Hence, a)
seems like the most appropriate option.

Kurt

---

From: [email-masked] (Mark C Smith)
Date: Fri, 09 Mar 2001 08:47:54 -0500

"Kurt D. Zeilenga" wrote:
> > RFC 2251 allows one to specify mutliple controls on a single
> > operation. It doesn't disallow two or more controls of the same
> > type to exist on the operation. This means we either need to:
> >
> >a) Add text to the "recommended control specification guide" (or
> > whatever it's called), that tells authors of control spec's to call
> > out whether this is allowed with that particular control. Or,
> >I lean towards a), just to leave the door open. How do others feel.
> > If b), we'll take it to the LDAPBIS list.
> 

I also agree.  While I see no strong reason for using two controls
instead of, for example, a sequence within the value of a single
control, I also see no reason to prevent this if someone wants to design
an extension that way.  It would be interesting to see how various
implementations behave if they receive two controls with the same OID
today.  Possible behaviors:

1) Ignore all but the first instance of the control.

2) Ignore all but the last.

3) Generate and return an error (which one?)

4) Something else.

So we may want to provide some advice to server implementors somewhere
about what to do if a client sends two instances of a control (the best
behavior may depend on the control though, e.g., two manageDSAIT
controls vs. two server side sorting request controls). 

-Mark

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 Mar 2001 08:29:22 -0800

At 08:47 AM 3/9/01 -0500, Mark C Smith wrote:
>an extension that way.

One could design an extension that relied on ordering of a
number of controls of different kinds.  That is controls A, B, C
would cause different behavior than C, B, A or A, B, C, A.
That is, I think multiple controls of same kind may be useful
in to cases where an extension is dependent on ordering of other
controls.

For example, lets say matched values (M) and duplicate entry (D)
controls where order dependent.  That is, M D would match
than duplicate and D M would duplicate than match.  One could
then D M D.

One could also envision a sort control which took one key.
If you wanted to do multiple key sorts, you'd provide multiple
sort controls.  These controls would be order dependent and
could be combined with other order dependent controls.

Obviously the complexity of specification and implementation of
such must be balanced with its usefulness.  This is not a call for
any particular control to support such semantics.

Kurt