protocol-28 comments

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

Items from protocol-27 discussion:

>> 4.5.1. Search Request
>
>>    - scope: Specifies the scope of the search to be performed. The
>>      semantics (as described in [X.511]) of the possible values of this
>>      field are:
>>    - derefAliases: An indicator as to how alias entries (as defined in
>>      [Models]) are to be handled in searching. The semantics of the
>>      possible values of this field are:
>
> s/possible/defined/ in these two, since other values can be defined
> later.

This was done for derefAliases, but not for scope.

>> 4.5.2. Search Result
>
>> The results of the search operation are returned as zero or more
>> searchResultEntry messages, zero or more SearchResultReference
>> messages, followed by a single searchResultDone message.
>
> replace "messages, zero or more" with "and/or" to clarify that the
> entries need not precede the references.

Changed a bit in -28, but the second "zero or more" remains.  So it can
still give the impression that the searchResultEntries are grouped
together and the SearchResultReferences are grouped together in the list
of response messages.

>> 4.7. Add Operation
>
>> - attributes: (...)
>
>> Clients MUST
>> include the 'objectClass' attribute, and values of any mandatory
>> attributes of the listed object classes. Clients MUST NOT supply
>> NO-USER-MODIFICATION attributes such as the createTimestamp or
>> creatorsName attributes, since the server maintains these
>> automatically.
>
> The same applies to Modify Operation. Maybe factor that out and replace
> with a reference to [Models], similar to what has been done with some
> Modify Operation text?

The sentence about objectClass is gone, but the NO-USER-MODIFICATION
sentence remains.  I don't really care, but I believe the decision was
to remove it when "Servers MUST ensure that entries conform to user and
system schema rules or other data model constraints" was added.

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

Editorial comments:

Sections 4.3, 4.4.1 and 4.14.3:

>   Uncompleted operations are handled as specified in Section 5.1.

No, in Section 3.1.

> 5. Protocol Encoding, Connection, and Transfer

Why s/Transport Connection/Connection/ in this title, when we did just
the opposite with renaming the connection to "transport connection"?
Is this to ensure that the title is _not_ referring to the "transport
connection" as defined in section 2?

> Appendix B.

>                       -- The LDAPString is constrained to
>                       -- <attributeSelection> in Section 4.5.1
>

s/attributeSelection/attributeSelector/.  s/4.5.1/4.5.1.7/.
Now that the original grammar is in 4.1.5 and attributeSelector in
another section, maybe the grammar comment in 4.5.1 should replace
"below" with "in Section 4.5.1.7".

>        PartialAttributeList ::= SEQUENCE OF
>                             partialAttribute PartialAttribute

Not sure if this is good or bad, but I note that this text from the
grammar in 4.5.2 is missing from Appendix B:

>        -- Note that the PartialAttributeList may hold zero elements.
>        -- This may happen when none of the attributes of an entry
>        -- were requested, or could be returned.
>        -- Note also that the partialAttribute vals set may hold zero
>        -- elements. This may happen when typesOnly is requested, access
>        -- controls prevent the return of values, or other reasons.


> C.1.21 Section 4.6 (Modify Operation) 
>
>   - Spcified the types of modification changes which might temporarily 

s/Spcified/Specified/.

-- 
Hallvard