Re: Multiple "similar" controls per op

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

At 08:47 AM 3/9/01 -0500, Mark C Smith wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> At 08:26 PM 3/8/01 -0700, Jim Sermersheim 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,
>> >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.
>> 
>> 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.
>
>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.

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