Re: protocol-27 comments#2

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

>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 11/7/04 7:00:33 PM
>>>
>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.

before next IETF? You mean in the next 10 hours?
 
All comments are welcome (very appreciated actualy). It's obvious there
are edits to be made, so lateness isn't an issue at this point.

>Jim Sermersheim writes:
>>>> Hallvard B Furuseth < h.b.furuseth@usit.uio.no > 10/29/04 1:09:56
PM

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

Oh, I see what you're saying now. Will fix.


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

ok, I could say "will return responses containing the elements found in
LDAPResult"? Just trying to find a vague enough way to say it...

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

I don't like the first comment. I think [Protocol] is in the business
of explaining how the protocol works rather than client applications.
Though I do note that it says "Implementations MUST NOT display nor
attempt to decode an attribute value if its syntax is not known"

For the second comment, how about: "Diagnostic messages typically
convey information pertaining to the value of resultCode"

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

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

Ok, how about:

Servers may substitute some result codes due to access controls which
prevent their disclosure.

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

I cut it down to this:
If there are dependencies between multiple negotiations of a particular
SASL mechanism, the technical specification for that SASL mechanism
details how applications are to deal with them. LDAP should not require
any special handling.

>>>> Appendix C - Changes 
>
>>> 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...
>
>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.

I already got it -- it was ok.

Jim