Subject: RE: current control combination proposals

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 17 May 2004 11:42:38 +1000

Hi Jim,

I think you have to be careful in assigning an error to a particular combination of controls as this error would stick even if you subsequently wanted to use the controls together.

I don't think return of errors should be prescribed or specified. The greatest direction I would give would be, say, "if a particular combination of controls could not be performed because the implementation deemed the combination to be (inappropriate?), the error protocolError should be returned."

Ron

PS I appreciate the plain text; my mail system won't allow me to respond to messages whose encoding is Arabic.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jim Sermersheim
Sent: Saturday, 15 May 2004 07:49
To: [email-masked]
Subject: current control combination proposals

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: "Jim Sermersheim" <[email-masked]>
Date: Mon, 17 May 2004 12:00:59 -0600

>>> Chris Ridd <[email-masked]> 5/17/04 9:34:04 AM >>>
>> The resultCode enumeration is extensible.  However, we should
>
>Not flexibly - there's only a flat number space so different
implementations
>could easily collide their resultCode extensions.

To make sure collisions don't occur, one has to register new result
codes with IANA. The current set is here:
http://www.iana.org/assignments/ldap-parameters

---

From: Chris Ridd <[email-masked]>
Date: Mon, 17 May 2004 19:06:18 +0100

> http://www.iana.org/assignments/ldap-parameters

Ah, thanks for that URL.

Cheers,

Chris

---

From: Chris Ridd <[email-masked]>
Date: Mon, 17 May 2004 21:45:11 +0100

On 17/5/04 9:24 pm, Jim Sermersheim <[email-masked]> wrote:

> So when it's returned with a  bind response, the client doesn't know if
> it was due to an unsupported protocol version, a problem with multiple
> controls, or an incorrect structure (though I guess a bad sequence of
> controls can be considered as "incorrect structure")

The "incorrect structure" text doesn't suggest that to me at all. RFC 2251
notes in a couple of places that protocolError is returned when the server
is unable to parse the LDAPMessage/request, and that's just a different
problem than not being to operate on the permutation of controls offered by
the client.

Cheers,

Chris

PS apologies to the rest of the list - Alan, emails to you are being
bounced.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 17 May 2004 16:49:29 -0600

I guess it's all in the eye of the reader. But even if 'incorrect
structure' has the rigid meaning you assign to it, note that the other
uses of protocolError have as little (or less) to do with malformed
packets than this example.

Also note that the StartTLS operation updated RFC 2251 to allow
protocolError (for non-malformed messages) as it was seen as a fitting
error.

I see the proposal to allow protocolError as a response to an invalid
control combination as warranted. In essence, we're simply clarifying an
aspect of RFC 2251 which was undocumented. We have also discovered that
there are existing implementations which interpreted (or maybe
extrapolated from) RFC 2251 as it applies to this condition, and both
implementations followed the same path. That path is in accord with the
proposed change.

Jim

>>> Chris Ridd <[email-masked]> 5/17/04 2:45:11 PM >>>

> controls can be considered as "incorrect structure")

The "incorrect structure" text doesn't suggest that to me at all. RFC
2251
notes in a couple of places that protocolError is returned when the
server
is unable to parse the LDAPMessage/request, and that's just a
different
problem than not being to operate on the permutation of controls
offered by
the client.

Cheers,

Chris