|
>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 10/28/04 5:46:16 PM >>>
>Quick review; I've mostly looked at changes since last draft: > >> 4.4.1. Notice of Disconnection <snip> >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. It was not on the You're right, it was not on the list. I elected to not copy this to the appendix while performing the task of removing the redundant error code specifications from 4.4.1 (something that did make it to the list). I just made a call on this — it seemed pretty clear that this was not a substantial change, and that I was just removing fluffy, vague, uneeded text.
>> 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? This is the way it was in RFC 2251. At some point, [protocol] added the SIZE (1..MAX) to the ASN.1 to make it consistent with the text. It was then found that this prevents Kurt's T/F filter spec from working without breaking protocol, so we removed the ASN.1 grammar.
>> 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. PartialAttribute allows zero elements (in the ASN.1 grammar), so an empty one may be specified. If I remember correctly, we decided this was good enough for purposes of future extension.
>> 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. That sounds like the same complaint Kurt had about the "whether the modification completed successfully or not is indeterminate". He said (something to the effect of) that makes it sound like it may have partially completed.
How about: "Whether the modification was applied or not is indeterminate..."?
>Also, I think s/received/sent/. This sentence is about what the server >does, not about what the client knows. Well, who is making the determination? The client. And the client receives the response.
>> 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:-) Hmm, well as long as we're being pedantic, do all entries which can be added by a cleint require the objectClass attribute? I've seen hints that some implementations allow DSE's of certain DSE types to exist without an objectClass attribute (I think this was a justification for the T/F filter specification). It would probably be better to say that the entry being added must conform to the data model.
>> 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. I agree, my suggestion about 'conforming to the data model' above should be generic and should apply to all update operations.
>> 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. just for readability?
>> 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.) yes.
>> the specific data in > >s/the specific/of specific/. yes.
>> 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/. I missed it even as I read it above!
>> 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. Yes, need to make it readable
>> 4.14. StartTLS Operation >> >> The Start Transport Layer Security (StartTLS) operationΖs purpose is >^^^ >s/Ζ/'/. 8-bit character. yikes
>> 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. yup, remove 'return'
>> 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. The result of a hasty edit, I'm sure
>-- >Hallvard Thanks, Jim
|