Re: current control combination proposals

["Jim Sermersheim" <jimse@novell.com>]

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 <chris.ridd@isode.com> 5/17/04 2:45:11 PM >>>
On 17/5/04 9:24 pm, Jim Sermersheim <jimse@novell.com> 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.