Re: StartTLS responseName became optional

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

At 05:34 PM 7/22/2005, Hallvard B Furuseth wrote:
>I've just learned that the StartTLS responseName changed from
>mandatory to optional in Protocol-26, but I cannot find anything about
>it in the LDAPbis archive.

I believe this issue was previously discussed on the list and,
IIRC, in face-to-face meetings.  I am on the road at present
so cannot provide URLs.

>I found an explanation from Kurt elsewhere:
>
>> The specification here is considered to be in error here.
>>
>> An client which implements RFC 2830 must be capable of handling
>> responses from servers which do not implement RFC 2830.  And such
>> a server cannot be expected to know what responseName to specify,
>> this MUST is flawed.
>>
>> (...) responseName (...) is really intended only for use with
>> unsolicited notifications, not extended operation responses (as
>> they are simply not needed).
>
>I disagree.  The current spec is RFC 2830, which was written as an
>LDAPv3 extension.  As such, it describes how LDAP implementations that
>support this extension shall implement this extension.  The wording
>may be clumsy, but the real bug was introduced when the wording was
>"imported" into core LDAP and thus changed meaning.  (If it did change
>meaning, I can read it another way:-)
>
>RFC2251 section 4.12 requires protocolError in response to an
>unrecognized extended request.  So I think a client implementing RFC
>2830 may treat a StartTLS response with no responseName and result
>code other than protocolError as a protocol error.
>
>Thus, for backwards compatibility I think the spec should be that
>servers still MUST send the responseName with any other result code,
>though it wouldn't hurt to also say that clients SHOULD or MUST accept
>responses without the responseName.

I disagree.  Adding a MUST here will lead to clients being
developed which are not accepting of the current practice
of some servers not to provide a responseName in this
case.  And if such clients did exist already, they likely
have other problems.

>While it seems pointless of RFC 2830 to require the responseName,

Not only is it pointless, it is very bad for clients to
require a responseName here.  Obviously there is the unrecongized
case where the server cannot provide a responseName.  But there
are likely other cases where a server cannot generate a
responseName for some recognized control, for instance when
the server fronts for a distributed system.

>cleaning that up isn't worth breaking clients that also require the
>responseName, if any.

This is not merely protocol clean.  This is fixing existing
broken clients.  The MUST lead to development of clients
which absolutely required the responseName, even from
servers which don't implement the extension.  Client developers
MUST NOT expect a responseName (not only in response to
protocolError, but in general).

Another issue is that StartTLS technical specification,
because of its inclusion in the core TS, is used as a
template for future extended operation specifications.
Having it do something which future specifications should
not do is a bad thing.

Kurt