Subject: Re: current control combination proposals

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 17 May 2004 14:24:25 -0600

My worry would be those places where protocolError means something
special. Here's the current (24) language:

protocolError (2)
Indicates the server received data which has incorrect structure.

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.

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

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.

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

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 17 May 2004 15:54:52 -0700

At 01:24 PM 5/17/2004, Jim Sermersheim wrote:
>special.

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

>Here's the current (24) language:
>
>protocolError (2)

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.

>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.

>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.

>specified, or that the combination of the specified controls is not

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

>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?