Proposed protocol changes

["Jim Sermersheim" <jimse@novell.com>]

All,
 
Since protocol-31, there have been a few issues raised. Following is a
list of them and my proposed edits. I plan to submit with these changes
pending any concerns.
 
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.  

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

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