Protocol changes

I'm submitting a new protocol I-D. Following are details of the changes:

Change 1
In response to the thread "StartTLS responseName became optional"

Section 4.12. In order to clarify why extended response names are
optional:
<old text>
   The responseName is typically not required to be present as the
   syntax and semantics of the response (including the format of the
   responseValue) is implicitly known and associated with the request by
   the messageID.

   If the Extended operation associated with the requestName is not
   supported by the server, the server MUST NOT provide a responseName

   nor a responseValue and MUST return with resultCode set to
   protocolError.

<new text>
The responseName field, when present, contains an LDAPOID which is
unique for this extended operation or response. This field is optional
(even when the extension specification specifies an LDAPOID to be
returned in the field). The field will be absent whenever the server is
unable or unwilling to determine the appropriate LDAPOID to return, for
instance when the requestName cannot be parsed or its value is not
recognized.

Where the requestName is not recognized, the server returns
protocolError (The server may return protocolError in other cases).

Section 4.14.2. To reinforce the above and further clarify:
<old text>
   When a StartTLS request is made, servers supporting the operation
   MUST return a StartTLS response message to the requestor. The
   responseName, if present, is also "1.3.6.1.4.1.1466.20037". The
   responseValue is absent.

   If the server is willing and able to negotiate TLS, it returns with
   the resultCode set to success. Refer to Section 4 of [AuthMeth] for
   details.

<new text>
When a StartTLS request is received, servers supporting the operation
MUST return a StartTLS response message to the requestor. The
responseName is "1.3.6.1.4.1.1466.20037" when provided (See 4.12). The
responseValue is always absent.

If the server is willing and able to negotiate TLS, it returns the

StartTLS response with the resultCode set to success. Upon client

receipt of a successful StartTLS response, protocol peers may

commence with TLS negotiation as discussed in Section 3 of

[AuthMeth].

In cases where a non-success result code is returned, the LDAP session is left without a TLS layer.

Section C.2.1
<added text>
- Removed requirement that the ExtendedResponse.responseName MUST be
present. There are circumstances where this is impossible, and requiring
this is at odds with language in Section 4.12.

Change 2
In response to the message "[Protocol] clarification on StartTLS
resonse (WAS:authmeth-15notes)"

Section 4.14.2.
<old text>
If the server is willing and able to negotiate TLS, it returns with the
resultCode set to success. Refer to Section 4 of [AuthMeth] for
details.
<new text>
If the server is willing and able to negotiate TLS, it returns with the
resultCode set to success. At this point the protocol peers may commence
with TLS negotiation. Refer to Section 4 of [AuthMeth] for details.

Change 3
In response to the message "IESG ldapbis-protocol comment"

Section 10
<added text>
It is requested that IANA assign upon Standards Action an LDAP Object
Identifier [LDAPIANA] to identify the ASN.1 module defined in this
document.

     Subject: Request for LDAP Object Identifier Registration
     Person & email address to contact for further information:
          Jim Sermersheim <jimse@novell.com>
     Specification: RFC XXXX
     Author/Change Controller: IESG
     Comments:
          Identifies the LDAP ASN.1 module

[[Note to RFC Editor: please replace the occurrence of
<IANA-ASSIGNED-DIRECTORY-NUMBER> in Appendix B with the IANA assigned
OID.]]

Appendix B
<old text>
Lightweight-Directory-Access-Protocol-V3

<new text>
Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1
<IANA-ASSIGNED-DIRECTORY-NUMBER>}

Change 4

In response to the message "nature of the error"

Section 4.1.9

<added>

Servers may return substituted result codes to prevent unauthorized disclosures.

Appendix A

Servers may substitute some result codes due to access controls which
prevent their disclosure.

The descriptions provided here do not fully account for result code

substitutions used to prevent unauthorized disclosures (such as

substitution of noSuchObject for insufficientAccessRights, or

invalidCredentials for insufficientAccessRights).

Change 5

Updated various outdated references to AuthMeth sections.