Subject: Re: protocol-27 comments#2

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 07 Nov 2004 16:06:45 -0700

>>> Hallvard B Furuseth <[email-masked]> 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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 8 Nov 2004 01:00:33 +0100

Hi Jim, it's a relief to see I'm not the only one in "absolutely have to
get this done now"-mode:-)  Now, if I only can get through the rest of
[protocol] before next IETF...

BTW, I should have said earlier: I know it's after Last Call.  Feel free
to reply "too late" to any still outstanding [protocol] comments.

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

draft-ietf-ldapbis-protocol-27.txt does not contain '...' in the ASN.1
for SearchRequest.scope, Filter and ModifyRequest.changes.operation.
draft-ietf-ldapbis-bcp64-04.txt sections 3.9 to 3.11 explicitly say that
these are extensible.

> was there a comment I missed on this?

No, I failed to delete it when moving an editorial comment.

> I think "will return responses containing the components of LDAPResult"

I thought of something like that, but wondered if there is an ASN.1
encoding where SEQUENCE { COMPONENTS OF LDAPResult } is encoded
differently from LDAPResult.  If so, that wording is a bit misleading
too.  But I suppose that's getting excessively paranoid about wordings.

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

Right.  Inform clients that display disgnosticMessage if they
also need to display the resultCode (or preferably an explanation of it).

And therefore, also tell servers if the disgnosticMessage, if any, needs
to contain the information conveyed by the result code.

> may not be disclosed to the client, or may be substituted due to access

Softening the words sounds OK in general, but I don't understand the
"or".  Do you mean something like this (somewhat cumbersome wording):

  Some result codes may be substituted because they may not be disclosed
  to the client, e.g. due to access control settings.

...assuming the "e.g." is needed.  I don't know any other reason.

> change (in the sentences that follow it)

Actually that justification isn't clear to me in any case, but maybe
that's because I've gotten a bit lost on SASL.  But I think those
sentences will need some fixes too, like s/were/are/, s/had/has/.

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

That's why I said I could do it.  (If you send me the nroff code or
whatever the source format is.)  At least with plaintext and nroff, I
think it should be a fairly simple Perl script.  Just have to edit any
too long resulting headers afterwards.

-- 
Hallvard