StartTLS responseName became optional

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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

While it seems pointless of RFC 2830 to require the responseName,
cleaning that up isn't worth breaking clients that also require the
responseName, if any.

-- 
Hallvard
For sale: Parachute. Never opened, used once, slightly stained.