Re: protocol-22 comments

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:20 AM 3/9/2004, you wrote:
>>    Additionally, unless order-dependent semantics are given in a
>>    specification, the order of a combination of controls in the SEQUENCE
>>    is ignored.
>
>This implies that controls (A, B) MUST behave identically with controls
>(B, A).

unless order-dependent semantics are provided.

>I think it should be, "the effect of the ordering of a
>combination of controls in the SEQUENCE is unspecified"?

The problem we current face is that effect of ordering is
generally unspecified.

I think the sentence likely could be better worded:
        Additionally, the order of controls in a combination
        only matters if the specification describing that
        combination details order-specific semantics.

>> 4.7. Add Operation
>>    If the entry to be added would not fall within a naming context
>>    [Section 5 of Models] held by the server, and the server has
>>    knowledge of where that entry is to be located, a referral to the
>>    server(s) holding the parent entry should be returned.
>
>Unless the server chains the operation to another server (i.e. it sends
>the request to the server which masters that naming context, and returns
>the response from that server to the client).

We should avoid discussing chaining (and many other aspects of
distributed directories).   I suggest the quoted paragraph be worded
in more general terms, like:
        Where a server has knowledge that the operation should be
        referred to another server (or server(s), a referral may be
       returned to the client.

Of course, this applies in general so maybe it should be said once.

>> 4.12. Extended Operation
>
>>    Extended operations may be specified in other documents. The
>>    specification of an extended operation consists of:
>>
>>    - the OBJECT IDENTIFIER assigned to the requestName (and possibly
>>      responseName),
>
>Does this mean responseName must be empty or equal to requestName?
>This should be clarified in the paragraph about responseName.

It might be better to say:
   - the OBJECT IDENTIFIER assigned to the requestName,
   - the OBJECT IDENTIFIER, if any, assigned to the responseName
     (note the same OBJECT IDENTIFIER may be used for both)

>> 4.13. IntermediateResponse Message
>>    Although the responseName and responseValue are optional in some
>>    circumstances, generally speaking IntermediateResponse messages have
>>    a predefined responseName and a responseValue.
>
>I do not understand.  Are they any more predefined than other
>LDAPMessages?

The wording does seem a bit odd.

>> A.1 Non-Error Result Codes
>> A.2 Result Codes
>
>>         protocolError (2)
>>            Indicates the server received data which has incorrect
>>            structure.
>>
>>            For bind operation only, this code is also used to indicate
>>            that the server does not support the requested protocol
>>            version.
>
>For Start TLS, it is also used to indicate that TLS is currently
>unsupported.

Actually, I note that Start TLS needs some in this area.  I'll discuss
this in a separate post.

A.2 protocolError should however say:
        For extended operations only, this code is used to indicate
        that the server does not recognize the requestName.

>Editorial comments:
>
>> 4.2. Bind Operation
>
>>    Authorization is the use of this authentication information when
>>    performing operations.
>
>No, authorization need not make use of the authentication information.
>One could e.g. base it on IP addresses only (but only for read
>operations, I would hope:-)

One could argue that the IP address is the authentication information. :-)

>Nitpick:  The word "use" is wrong.  Putting the currently active
>authentication identity in LDAPResult.diagnosticMessage is "use" of auth
>info, but not authorization.  Not sure if this is worth bothering with,
>though.
>
>>    Authorization MAY be affected by factors
>>    outside of the LDAP Bind Request, such as those provided by lower
>>    layer security services.
>
>Here is a suggestion, though it's a bit long.  Maybe the last sentence
>should be dropped.
>
>     Authorization is the decision of which access an operation has to
>     the directory.  It may be affected by many factors, often including
>     the association's authorization identity, which again was derived
>     from or authorized via the authentication information.
>     Authorization may be affected by factors outside of the LDAP Bind
>     Request, such as those provided by lower layer security services.

Better.

>> 4.2.1. Processing of the Bind Request
>
>>    Before processing a BindRequest, all outstanding operations MUST
>>    either complete or be abandoned.
>
>This could be read as a suggestion for the client to abandon the
>operations.  I suggest:
>
>     The server MUST NOT process a BindRequest until no earlier
>     operations are outstanding.
>
>I added "earlier" because it shouldn't complete or abandon operations
>submitted _after_ the Bind.

We likely need to discuss whether a client is allowed to send requests
while a bind response is outstanding.  (another thread to start)

>>    The server may either wait for the 
>>    outstanding operations to complete, or abandon them.
>
>
>> 4.5.3. Continuation References in the Search Result
>> 4.5.3.1. Examples
>
>>    If the contacted server does not hold the base object for the search,
>>    then it will return a referral to the client.
>
>s/will/may/.
>
>> 4.10. Compare Operation
>
>>    The resultCode field is set to compareTrue, compareFalse, or an
>>    appropriate error. compareTrue indicates that the assertion value in
>>    the ava field is equivalent to a value of the attribute or subtype
>>    (according to the attribute's EQUALITY matching rule).
>
>Maybe remove the "()"'s?

s/equivalent/equal/ here and elsewhere where we are specifically
talking about matching using the equality matching rule.

>>    compareFalse
>>    indicates that the comparison of the assertion value in the ava field
>>    and the values of the attribute or subtype resulted in an Undefined
>                                                            ^^
>>    (Section 4.5.1) or non-equivalent match.
>                     ^^                ^^^^^
>s/an/only/, s/or/and/, s/match/matches/.
>
>> 4.11. Abandon Operation
>
>>    Operation responses are not sent for successfully
>>    abandoned operations,
>
>This can be read as 'the server performs abandoned operations but does
>not send their responses':-)
>
>>    thus the application of the Abandon operation
>>    is limited to uses where the client does not require an indication of
>>    its outcome.
>
>You could say "Since operation responses are not ..." and strike "thus".
>However, the reasoning is a bit unclear in any case.  I suggest:
>
>     Since the client cannot tell the difference between a successfully
>     abandoned operation and an outstanding operation yet to be
>     performed, the application of (...)

better.


>>    Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
>>    The ability to abandon other (particularly update) operations is at
>>    the discretion of the server.
>
>The last sentence is contradicted by the next paragraph.  You can move
>the sentence below the offending paragraph, or swap the two paragraphs.
>
>>    In the event that a server receives an Abandon Request on a Search
>>    Operation in the midst of transmitting responses (...)
>
>> 4.13. IntermediateResponse Message
>
>>    Similarly, it is intended that clients will explicitly solicit
>>    IntermediateResponse messages by issuing operations that specifically
>>    call for their return.
>
>Delete this, it's repeated in stronger language in the next paragraph.
>
>>         IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
>>                 responseName     [0] LDAPOID OPTIONAL,
>>                 responseValue    [1] OCTET STRING OPTIONAL }
>
>This is missing from Appendix B (Complete ASN.1 Definition).
>
>>    The value of the
>>    responseName (if present), the syntax of the responseValue (if
>>    present) and the semantics associated with a particular
>>    IntermediateResponse message MUST be specified in documents
>>    describing the extended operation or request control that uses them.
>>    Sections 4.13.1 and 4.13.2 describe additional requirements on the
>>    inclusion of responseName and responseValue in IntermediateResponse
>>    messages.
>
>I suggest you reformat this to a list of things the spec consists of,
>similar to "The specification of an extended operation consists of:..."
>in section 4.12.
>    
>> 4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse
>
>>    An extended operation that defines the return of multiple kinds of
>>    IntermediateResponse messages MUST provide and document a mechanism
>>    for the client to distinguish the kind of IntermediateResponse
>>    message being sent.  This SHALL be accomplished by using different
>>    responseName values for each type of IntermediateResponse message
>>    associated with the extended operation or by including identifying
>>    information in the responseValue of each type of IntermediateResponse
>>    message associated with the extended operation.
>
>s/type/kind/ or s/kind(s)/type(s)/.
>
>I think this can be shortened a lot:
>
>     An extended operation that defines the return of multiple kinds of
>     IntermediateResponse messages SHALL identify those different kinds
>     either by giving them different responseName values or by including
>     identifying information in their responseValues.
>
>However, this - and the original - does not allow one ExtendedRequest to
>solicit some IntermediateResponse types identified by responseName and
>some types identified by the contents of responseValue.

The language of draft-rharrison-ldap-intermediate-resp-01.txt is a bit
odd.

If we take the view that it is the responseName, and only the responseName,
that identifies a particular kind of IntermediateResponse, then we simplify
this text.  That is, while an IntermediateResponse might have an responseValue
which allows a wide range of information to be returned, such is but one
kind of IntermediateResponse.

>This does:
>
>     (...) SHALL identify those different kinds by giving them different
>     responseName values and/or including identifying information in
>     their responseValues.
>
>Finally, I suggest to factor this and the equivalent statement for
>request controls, out to section 4.13: Just move the statement and do
>s/extended operation/extended operation or request control/.

Yes.

The key requirement is that only one kind of IntermediateResponse
sent in response to an extendedRequest can have no responseName.
All other kinds of IntermediateResponse, whether also returned in
response to an extendedRequest or in response to a request control,
must have a responseName and its value must be distinguishing.


>> 4.14.1. StartTLS Request
>
>>    The client MUST NOT send any PDUs on this connection following this
>>    request until it receives a StartTLS extended response and
>
>, in case of a success response,
>
>>    completes
>>    TLS negotiations.
>
>> 4.14.2.2. Response other than "success"
>
>>    If the ExtendedResponse contains a result code other than success,
>>    (...)
>
>>    The
>>    client's current association is unaffected if the server does not
>>    support TLS.
>
>It is also unaffected if StartTLS returns non-success for some other
>reason.  Also, move it to the first paragraph.  Or maybe delete the
>sentence, since [Authmeth] covers it.
>
>> 4.14.3.2. Abrupt Closure
>>
>>    Either the client or server MAY abruptly close the TLS connection by
>>    dropping the underlying transfer protocol connection. In this
>
>s/transfer protocol connection/LDAP connection/; that's the phrase
>which is used elsewhere (e.g. in 4.14.3.1).

No.  The underlying transfer protocol connection is not an LDAP
connection as it cannot directly transfer LDAP messages.  Underlying
here is referring to the TCP (or other transport) protocol connection
and is proper.

>>    Outstanding
>>    operations are handled as specified in Section 5.2.
>
>The same applies to graceful closure.  Delete this sentence, instead put
>in 4.14.3 (Closing a TLS Connection):
>
>     If the underlying LDAP connection is dropped, outstanding
>     operations are handled as specified in Section 5.2.
>
>> 5.2. Transfer Protocols
>>
>>    This protocol is designed to run over connection-oriented, reliable
>>    transports, with all 8 bits in an octet being significant in the data
>>    stream.
>
>The ", with..." part is strange.  How about LDAP over transports that
>are not naturally divided into octets, but e.g. 36-bit units?  I suggest
>to replace it with:
>
>     , where the data stream is divided into octets (8-bit units).
>
>That all bits in an octet are significant need not be stated; that's
>what anyone would assume unless the opposite was specified.
>
>I suggest at least a paragraph break here.  In fact, I think the rest of
>the paragraph belongs in a separate section '5.2.2 Connection Closure
>Effects'.
>
>>    Protocol operations are tied to a connection, thus if the
>>    connection is closed or dropped, the operation is aborted. When this
>>    happens, any outstanding operations on the server are, when possible,
>>    abandoned, and when not possible, completed without transmission of
>>    the response.
>
>s/on the server/on the connection/.  Dropping one connection doesn't
>affect operations on another connection to the same server.
>
>The "thus..." is wrong: _aborting_ an operation might leave an update
>operation halfway done.  The next sentence corrects it, but I suggest to
>just drop the offending sentence:
>
>     Protocol operations are tied to a connection.  If the connection is
>     closed or dropped, any outstanding operations on the connection
>     are, (...)
>     
>>    Also, if the connection is closed or dropped, the
>>    client MUST NOT assume that any outstanding requests which modified
>>    the Directory have succeeded or failed.
>
>Suggest /which modified/to modify/.
>
>> 6. Security Considerations
>
>>    Requirements of authentication methods, SASL mechanisms, and TLS are
>>    described in [AuthMeth].
>
>s/Requirements of/Security considerations for/?
>
>> C.1 Changes made to made to RFC 2251:
>> C.2 Changes made to made to RFC 2830:
>> C.3 Changes made to made to [LIMR]:
>
>s/made to made to/made to/.
>
>-- 
>Hallvard