protocol-27 comments

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

Quick review; I've mostly looked at changes since last draft:

> 4.4.1. Notice of Disconnection

Protocol-26 included result code descriptions for Notice of
Disconnection, including this:

   - unavailable: This server will stop accepting new connections and
     operations on all existing LDAP exchanges, and be unavailable for
     an extended period of time. The client may make use of an
     alternative server.

Protocol-27 defers to the result code descriptions in Appendix A.2:

        unavailable (52)
           Indicates that the server is shutting down or a subsystem
           necessary to complete the operation is offline.

and thus loses "[will] be unavailable for an extended period of time".
I'm happy with that change, but I don't remember any discussion about it
- except to keep result code descriptions in the appendix in general.

> 4.5.1. Search Request

>         Filter ::= CHOICE {
>              and             [0] SET OF filter Filter,
>              or              [1] SET OF filter Filter,

Another change I do not remember from the list: The SIZE (1..MAX) was
removed from the ASN.1 grammar (though the textual description still
requires at least one component).  Why?

> 4.6. Modify Operation

>         ModifyRequest ::= [APPLICATION 6] SEQUENCE {
>              object          LDAPDN,
>              changes         SEQUENCE OF change SEQUENCE {
>                   operation       ENUMERATED {
>                        add     (0),
>                        delete  (1),
>                        replace (2) },
>                   modification    PartialAttribute } }

I wonder if the PartialAttribute should be OPTIONAL in the grammar and
instead "REQUIRED unless otherwise specified" in the text, anticipating
new ModifyRequest operation types (per [LDAPIANA]) that need a different
data structure than PartialAttribute.  Such operations can then add
trailing sequence elements (which servers are already required to
accept) at the end of the 'change' SEQUENCE.

>    The result of the modification is indeterminate if the
>    Modify Response is not received (e.g. the LDA exchange is terminated
>    or the Modify Operation is abandoned).

I prefer the old text "whether the modification completed successfully
or not is indeterminate" over "the result of the modification is
indeterminate".  The new text seems to allow completely random effects
on the server side, even more so that Kurt's (withdrawn) suggestion
"whether the modification completed successfully" in the 'Misuse of the
term "association" in [Protocol]' thread.

Also, I think s/received/sent/.  This sentence is about what the server
does, not about what the client knows.

> 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
>      include the 'objectClass' attribute, and values of any mandatory
>      attributes of the listed object classes.

If the RDN is an objectClass, does that object class need to be
supplied?  (Not that I care if it is addressed or not, it's just a weird
example which occurred to me:-)

>    Server implementations SHOULD NOT restrict where entries can be
>    located in the Directory unless DIT structure rules are in place.
>    Some servers allow the administrator to restrict the classes of
>    entries which can be added to the Directory.

Seems to me this fits better in [Models] than [Protocol].  If left in
[Protocol], it really applies to Modify DN and Modify too (and extended
operations like Modify Password), so it's a bit misplaced under Add.

> 4.14.1. StartTLS Request

>    Sequencing problems (particularly those detailed in Section 3.1.1 of
>    [AuthMeth] result in an operationsError being returned in the
>    resultCode.

Prepend "Detected" as in authmeth section 3.1.1.

> 6. Security Considerations

>    The matchedDN and diagnosticMessage fields, as well as some
>    resultCode values (e.g., attributeOrValueExists and
>    entryAlreadyExists), could disclose the presence

     or absence

(consider an attribute which is considered by clients to have some
default value when absent.)

>    the specific data in

s/the specific/of specific/.

>    the directory which is subject to access and other administrative
>    controls. Server implementations should restrict access to protected
>    information equally under both normal and error conditions.

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

Editorial comments:

> 4.1.1.1. Message ID

>    The message ID of a request MUST have a non-zero value different from
>    the the messageID of any other uncompleted requests in the LDAP

s/the the/the/.

> 4.1.9. Result Message

>    If no aliases were
>    dereferenced while attempting to locate the entry, this will be a
>    truncated form of the name provided or if aliases were dereferenced,
>    of the resulting name, as defined in Section 12.5 of [X.511].

That sentence is pretty hard to parse.  Could you turn it around a bit?

     This will be a truncated form of the provided name if no aliases
     were dereferenced while attempting to locate the entry, or of the
     resulting name if aliases were dereferenced.

Re-insert "as defined in Section 12.5 of [X.511]" where appropritate,
I'm not sure which part of the original sentence it ties to.

> 4.14. StartTLS Operation
> 
>    The Start Transport Layer Security (StartTLS) operationÆs purpose is
                                                           ^^^
s/Æ/'/.  8-bit character.

> 4.14.2. StartTLS Response

>    For example, if the TLS
>    subsystem is not presently available, the server may return indicate
>    so by returning the unavailable resultCode.

Garbled sentence.

> 5. Protocol Encoding, Connection, and Transfer
> 5.2. Protocol Encoding
> 5.3. Transmission Control Protocol (TCP)

There is no section 5.1.  Renumber sections 5.2-5.3.

-- 
Hallvard