protocol-27 comments#2

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

> 2. Conventions 

>    The term "SASL layer" refers to a layer inserted between the 
>    connection and the LDAP exchange that utilizes Simple Authentication 
>    and Security Layer ([SASL]) to protect the exchange of LDAP PDUs. 

s/connection/connection or TLS layer/?

> 4. Elements of Protocol 

>    ellipses (...) 
>    have been supplied in ASN.1 types that are explicitly extensible as 
>    discussed in [LDAPIANA].

With the latest [LDAPIANA], this is no longer true for Search Scope,
Filter Choice and ModifyRequest Operation Type.

>    Clients may

     attempt to?

([Models] section 5.1 says the server SHALL provide it, but only "subject to
access control and other restrictions".)

>    determine the protocol versions a server supports by 
>    reading the 'supportedLDAPVersion' attribute from the root DSE (DSA-
>    Specific Entry) [Models]. 

> 4.1.1.1. Message ID 

>    after the final response is received, or a subsequent bind 
>    completes). Otherwise the behavior is undefined. For this purpose, 
>    note that abandon and abandoned operations do not send responses. 

s/abandoned/successfully abandoned/?  We - or maybe just I - used that
phrase earlier, but I don't remember what happened.

BTW, maybe capitalize 'abandon' and therefore also 'bind'.

>    attribute values may be equivalent as described by Section 2.3 

> 4.1.9. Result Message 
>     
>    To various 
>    requests, servers will return responses of LDAPResult or responses 
>    containing the components of LDAPResult

This is not quite right.  There are no pure LDAPResult responses; the
tag is different.  I haven't thought of a brief and clear enough
replacement text to be worth bothering with, though.  Maybe "tagged
LDAPResults", I'm not sure.

>    to indicate the final status 
>    of a protocol operation request. 

>    The diagnosticMessage field of this construct may, at the server's 
>    option, be used to return a string containing a textual, human-
>    readable (terminal control and page formatting characters should be 
>    avoided) diagnostic message.

I may have mentioned this before, but I can't find it in the archive:
It might be useful to suggest or RECOMMEND either to treat
diagnosticMessages as supplements to the result code in error messages,
or to recommend the opposite (diagnosticMessages intended to stand alone
without displaying the result code).  I think common practice is the
former, but I don't really know.

> A.2 Result Codes 

>         protocolError (2) 
>            For extended operations only, this code indicates that the 
>            server does not support (by design or configuration) the 
>            extended operation associated with the requestName. 

No, it can also mean that or one of the other things that can cause
protocolError, has happened.  Use e.g. "is also used to indicate".

>         insufficientAccessRights (50) 
>            Indicates that the client does not have sufficient access 
>            rights to perform the operation. 

I suggest:
             Note that the client may not even have access to learn
             that, and might instead receive e.g. noSuchObject as if the
             operation's target object did not exist.

> Appendix C - Changes 

What is a "clarification"?  I thought it meant it is not intended to
change what the spec means, but it is used differently several places
here.  I remember Kurt insisted that something was a clarification while
I insisted it was a change some time ago, too.  E.g. at least these look
like changes to me:

> C.1 Changes made to RFC 2251: 
> C.1.3 Section 4 
>    - Clarified where the extensibility features of ASN.1 apply to the 
>      protocol. This change also affected various ASN.1 types. 
> C.1.4 Section 4.1.1 
>    - There was a mandatory requirement for the server to return a 
>      Notice of Disconnection and drop the connection when a PDU is 
>      malformed in a certain way. This has been clarified such that the 
>      server SHOULD return the Notice of Disconnection, and MUST drop 
>      the connection. 
> C.1.5 Section 4.1.1.1 
>    - Clarified that the messageID of requests MUST be non-zero. 
>    - Clarified when it is and isn't appropriate to return an already 
>      used message id. RFC 2251 accidentally imposed synchronous server 
>      behavior in its wording of this. 



> C.1.13 Section 4.2.1 

>      Each SASL negotiation is, generally, independent of other SASL 
>      negotiations.

No.  [SASL] section 6.3 (Multiple authentications) says:

   If a security layer is in effect and a subsequent
   SASL negotiation selects no security layer, the original security
   layer remains in effect.

> C.1.15 Section 4.3 
>  
>    - Required both peers to cease transmission and close the LDAP 
>      exchange for the unbind operation. 

s/LDAP exchange/connection/.

> C.1.21 Section 4.6 
>                                       
>    - Removed restriction that required an EQUALITY matching rule in 
>      order to perform value delete modifications. It is sufficiently 
>      documented that in absence of an equality matching rule, octet 
>      equality is used. 

No, [Models] 2.5.1. Attribute Types reverted to

  If no equality matching is specified for the attribute type:

    - individual values of a multi-valued attribute are not to be
      independently added or deleted;

as in X.500.  Come to think of it, while it is indeed documented, a
reference from [protocol] 4.6 (Modify Operation) to that section in
[Models] might be useful.

> C.3 Changes made to RFC 3771: 
>   
>    - In general, all technical language was transferred in whole. 

We kept the semantics (I think), but we rewrote it, including redefining
what it means for two IntermediateResponses to have different type.

>      Supporting and background language seen as redundant due to its 
>      presence in this document was omitted. 

========================================================================

Editorial comments:

The draft has lost its form feeds.

> 1.1. Relationship to Obsolete Specifications 
>     
>    This document is an integral part of the LDAP Technical Specification 
>    [Roadmap]

Nitpick:  This statement deserves a better heading than 'Relationship to
Obsolete Specifications'.

>    which obsoletes the previously defined LDAP technical 
>    specification, RFC 3377, in its entirety. 

>    This document obsoletes RFC 2830, Sections 2 and 4 in entirety.

'in entirety' looks strange here.  Doesn't seem necessary below either.

>    This document also obsoletes RFC 3771 in entirety. 

> 4.1.7. Attribute and PartialAttribute 

>    No two

Add "of the" for clarity?

> 4.7. Add Operation 

>    - attributes: the list of attributes that, along with those from the 
>      RDN, make up the content of the entry being added. Clients MAY or 
>      MAY NOT include the RDN attribute in this list. Clients MUST 

s/RDN attribute/RDN attribute(s)/.

> Appendix C - Changes 

>    This appendix summarizes substantive changes made to RFC 2251 and RFC 
>    2830. 

And RFC 3771.

BTW, it would be easier to check for changes to a specific thing if each
header was named "Section foo (section foo's title in the old RFC)".  Or
a shortened title if the result would span multiple lines.
(I can make the changes if you wish.)

> C.1.23 Section 4.9 

>    - Specified what happens when the attributes of the newrdn are no 
>      present on the entry. 

s/no/not/.

> C.2 Changes made to RFC 2830: 
> C.2.1 Section 2.3 
>  
>    - Removed wording indicating that referrals can be returned from 
>      StartTLS 

Missing period.

-- 
Hallvard