Re: StartTLS responseName became optional

If it was not clear in my previous response, there are other
cases where it is appropriate for a server not supporting an
extended operation to return a result code other than
protocolError.  For instance, it would be reasonable for
a server which is busy to return busy, or for a server which
believes another server is better able to response to
return a referral, or a server which has an internal
error to return other, or operationsError when the
request cannot be processed due to issues with other
operations.

A client which assumes that responseName is
absent only when the resultCode is protocolError is
broken.  We need to ensure the specification language
is clear to the fact that clients not to expect a
responseName in an extended operation response.
 
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 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.