[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: protocol-26: starttls result codes
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