Re: protocol-27 comments#2

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.


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.

>>> attribute values may be equivalent as described by Section 2.3 
> 
> was there a comment I missed on this?

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

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

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

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

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

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

-- 
Hallvard