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].
 
<added to third paragraph>
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 <[email protected]>
     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
<old text>
   Servers may substitute some result codes due to access controls
which 
   prevent their disclosure.
 
<new text>
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.