Re: protocol-27 comments#2

["Jim Sermersheim" <jimse@novell.com>]

>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 10/29/04 1:09:56 PM
>>>
>> 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/?

got it

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

I need education... Why is this no longer true?

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

ok

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

got both

>> attribute values may be equivalent as described by Section 2.3 

was there a comment I missed on this?

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

I think "will return responses containing the components of LDAPResult"
is sufficient.

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

I don't think you mean the disgnosticMessage should be used in addition
to resultCode in determining a course of action. So are you saying we
should describe behavior between a client application and a human user?

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

right, and it's too bad too (IMO), there should have been an
unavailableExtension code for this.

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

There must be a better way of putting this. How about a general
statement at the top of the result codes which says: "Some result codes
may not be disclosed to the client, or may be substituted due to access
control settings"?

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

See 'clarifications' thread
<snip>

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

I can strike that sentence and still retain the justification for the
change (in the sentences that follow it)

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

right

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

I'll fix the change appendix, and to Modify, Add, and Modify DN, I'll
add: "For attribute types which specify no equality matching, the rules
in Section 2.5.1 of [Models] are followed"

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

fixed.

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

will fix

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

changed to "Relationship to Other LDAP 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. 

If so, we need to review this across other ldapbis documents (the same
wording exists in other docuemnts)

>> 4.1.7. Attribute and PartialAttribute 
>
>> No two
>
>Add "of the" for clarity?

ok, though it reads odd to me (but that's just me)

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

right

>> Appendix C - Changes 
>
>> This appendix summarizes substantive changes made to RFC 2251 and
RFC 
>> 2830. 
>
>And RFC 3771.

yes

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

oh bother...

>> C.1.23 Section 4.9 
>
>> - Specified what happens when the attributes of the newrdn are no 
>> present on the entry. 
>
>s/no/not/.

right

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

got it

>-- 
>Hallvard

Thanks,

Jim