Subject: current control combination proposals

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 14 May 2004 15:48:58 -0600

I'm having a hard time gauging consensus on this. Maybe distilling it to
the core changes will help:

Problem:

What behavior is to be followed when encountering a combination of
controls which is not speficied?

Proposal A:

Treat any such combination as an error.

Proposal B

Allow such combinations to be treated as an error, or to be handled in
a non-standard way.

Proposal C:

Allow certain control combinations  (including those in the problem
statement) to be considered as 'innapropriate'. This allows servers to
ignore non-critical controls and/or return unavailableCriticalExtension
for these innapropriate combinations.

Proposal D:

Same as proposal C, except allow any field of an LDAP message
(including controls) to cause the operation to be considered as
'innapropriate'. Also, stating that operation X is appropriate indicates
that all combinations of operation X are appropriate (unless otherwise
specified).

Do these capture the essence of the current proposals? If so, which do
people prefer?

For me, if we are strictly avoiding the addition of new features, I
prefer B, otherwise I prefer D.

Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 14 May 2004 15:36:06 -0700

>the core changes will help:

I think it would also help if we surveyed developers of existing
implementations to ask them how they handle various combinations
of controls.

---

From: Chris Ridd <[email-masked]>
Date: Sat, 15 May 2004 16:01:21 +0100

> implementations to ask them how they handle various combinations

Not sure I want to contribute to this thread, but here goes anyway...

Since controls are sent ordered, ie in a SEQUENCE OF, surely we need to
discuss the *permutations* of controls rather than the combinations? In
other words, does a server allow operation X with controls A+B, or with
controls B+A?

If incompatible controls are sent, but one is marked critical and one isn't,
the ordering of the encoded controls may well be significant.

I'd also suggest that an error code that's perhaps appropriate for
signalling "incompatible" controls would be constraintViolation. Sending a
protocolError seems a bit harsh.

Cheers,

Chris