Re: protocol-26: starttls result codes

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

At 04:49 PM 9/20/2004, Kurt D. Zeilenga wrote:
>Though I vaguely recall discussing Start TLS result codes
>before, I couldn't find any statement of consensus in this
>area.  (If you know of such a statement, please advise.)
>
>There are cases where it where a server should be allowed
>to return codes other than those currently listed in RFC
>2830.  As certain codes should always be returnable by
>any LDAP operation, such as unavailableCriticalExtension,
>I have always interpreted the RFC 2830 as precluding the

s/precluding/NOT precluding/  ugh.

>return of codes not listed, but simply as specifying
>StartTLS-specific meaning of codes beyond their common
>meaning.  (I note that our implementation returns, at times,
>codes other than those listed.)
>
>The [protocol] is not terrible clear whether only those
>codes explicitly discussed in 4.14.2 may be returned, or
>whether other result codes may be returned.
>
>Changing:
>>   The following result codes have these meanings for this         
>>   operation:
>
>to:
>    The following result codes have special meaning for
>    this operation:
>
>and then only list those result codes which have special
>meaning.
>
>But, I rather not describe any result code as having special
>meaning here, but instead describe situations which, consistent
>with their general meaning, particular codes should be returned.
>
>For instance, instead of saying operationsError may indicate
>that TLS was already established, I rather say that the
>StartTLS operation cannot be issued when TLS is already
>established and a violation of this requirement is to be
>considered an operationsError.
>
>Regarding protocolError, I suggest (replacing the paragraph
>about return of protocolError):
>  If the server does not support this operation (whether by design  
>  or by current configuration), the server is to return protocolError
>  as described in Section 4.12 of this document.
>
>to avoid attaching any special meaning to protocolError.
>
>Regarding unavailable, I suggest (replacing the paragraph about
>return of unavailable):
>  If the server is otherwise unwilling or unable to perform this
>  operation, the server is to return an appropriate result code
>  indicating the nature of the problem.  For instance, if the
>  TLS subsystem is not presently available, the server may
>  return indicate so by returning the unavailable result code.
>
>This avoids all special meanings and hence allowing the bullet
>list (and the text that introduces it) to be completely removed.
>
>Comments?
>
>Kurt