I'm going to make these changes and roll the text up into Sections 4.14.1 and 4.14.2 (removing 4.14.2.1 and 4.14.2.2). [AuthMeth] Section 3.1.1 and 3.1.2 need to be updated.
Jim
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 9/20/04 5:49:18 PM >>> 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 |