Re: current control combination proposals

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

At 01:24 PM 5/17/2004, Jim Sermersheim wrote:
>My worry would be those places where protocolError means something
>special.

My worry is the language in too narrow, see below.

>Here's the current (24) language:
>
>protocolError (2)
>Indicates the server received data which has incorrect structure.

This is too narrow.  Better would be say:
        Indicates the request is not well formed.

Then in 4.1.11 controls section state the a message containing
a sequence of controls whose semantics are unspecified is
considered not well formed.

The key here is that protocolError is not just for simple parsing
errors (such as when the encoding rules are violated, or when an
ASN.1 constraint is violated), but also is used when request is
otherwise invalid.



>For bind operation only, this code is also used to indicate that the
>server does not support the requested protocol version.
>
>For the extended operation only, this code indicates that the server
>does not recognize the requestName.

Recongize here generally means more than understand to know that
the some OID identifies a particular extended request.  It implies
the server is also capable of parsing the requestValue and respond
in a manner consistent with the specification of the extended
operation associated with that extended request.  That is, recognize
the requestName here implies the server implements the specification
of the extended operation that request is part of.

That is, this should be changed to:
        For extended operations only, this code indicates that the
        server does not support (by design or configuration) the
        extended operation associated with the requestName.

Likewise to the section regarding extended operations.

>For the Start TLS operation, this code may also indicate that the
>server does not currently support Start TLS (even though it may
>recognize the requestName).

I think this is unnecessary (collapses into the previous paragraph)
with the above clarification and like clarifications to sections
discussion Start TLS.

>For request operations specifying multiple controls, this may be used
>to indicate that the server cannot ignore the order of the controls as
>specified, or that the combination of the specified controls is not
>supported.

"not supported" is incorrect.  If the combination could be supported,
then a service error is more appropriate.  If however the combination
cannot be supported, because it is invalid or unspecified, then protocol
error.

>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")

Maybe it would be nice for distinguish the first case from the last
two, but under what circumstance would a client care about
distinguishing the last two cases from each other?


>Jim
>
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 5/17/04 12:39:26 PM >>>
>At 08:34 AM 5/17/2004, Chris Ridd wrote:
>>> It has been reported that existing implementations return
>>> protocolError here.  What's broke with that?
>>
>>Well, for one thing no protocol's being broken. It seems a bit
>severe.
>
>Realizing that some implementors may have taken a narrow view
>over what kinds of errors are indicated by protocolError and the
>fact that some existing implementations are using protocolError
>here, my question is more intended to ask what problems exist
>today (or could exist in the future) due to difference.
>
>If no real problems exist, then its simply a matter of clarifying
>the specification to return of protocolError is accectable here.
>(Likely be refining both the general description of the code
>as well as the text regarding treatment of nonsensical control
>combinations.)
>
>If problems exist, then we need to determine how best to resolve
>those problems.  Without a description of those problems, I and
>others cannot begin to engineer an appropriate fix.
>
>- Kurt