Subject: protocol-26: starttls result codes

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 20 Sep 2004 16:49:18 -0700

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 20 Sep 2004 20:13:56 -0700

>I have always interpreted the RFC 2830 as precluding the

s/precluding/NOT precluding/  ugh.