Re: protocol-28 comments

>>> Hallvard B Furuseth <[email protected]> 12/7/04 1:10:34 PM
>>>
>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.

oops.

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

ok

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

I see this as being more of a protocol issue and less of a data model
issue (though it does crossover). I think it's still useful and might
not be redundant, so I'll leave it unless there is more discussion.

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

Maybe I was watching Monty Python and the Holy Grail when I did that.

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

yes, on both counts.

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

hmm, this has always been this way. Same issue with
SearchResultReference (in RFC 2251).  I will turn the comments into
prose and append them to the paragraph starting with "Each entry
returned in a SearchResultEntry will contain...".

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

got it (and a few other typos)

>-- 
>Hallvard

Thanks,

JIm