Subject: Re: protocol-22 comments

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 12 Mar 2004 07:45:06 -0800

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 12 Mar 2004 10:03:49 -0800

I've been thinking a bit more about the different uses of "connections"
in the document.  It seems that "LDAP connection" is used both to
refer to the underlying transport connection as well as the LDAP-level
connection (e.g., the layer in which LDAP messages are exchanged),
and that this is causing some confusion in the specification.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 12 Mar 2004 19:55:16 +0100

> connection (e.g., the layer in which LDAP messages are exchanged),

Can you give an example of the latter?  I can't find any.

> and that this is causing some confusion in the specification.

The definition "LDAP connection" = "underlying transport protocol
connection" does seem confusing, the name sounds more like the LDAP-
level connection.  As you thought it meant in your response to my
'protocol-22 comments'.  Maybe the term should be dropped in favor of
"connection", which is already defined to mean the same thing.
([Protocol] section 2, [Authmeth] section 2.1.)

BTW, I've just been trying to construct a problem with this by messing
up the terminology: Define another service than LDAP over TCP, one which
has a layer between the transport and the LDAP (or LDAP+TLS/SASL)
protocol.  Then the "connection" and the "transport protocol" in the
drafts will have to refer to that layer, not the actual transport.  Some
language like "misdirecting the connection" in [Authmeth] will then be
wrong, since misdirection will occur at the underlying level.  I can't
think of a worse problem than that at the moment, but I haven't exactly
checked all occurrences of "connections" to see if there is a problem.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 12 Mar 2004 11:05:49 -0800

>Can you give an example of the latter?  I can't find any.

How about the use of the term "TLS-protected LDAP connection"?
TLS is not protecting the underlying connection, it's protecting
the exchange of LDAP messages.

And, is the association really at the underlying connection or
at the LDAP exchange?

In processing a bind, the spec says "to bind on the existing
connection" when the Bind, when TLS or SASL have been establish,
certainly is done on the underlying connection.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 12 Mar 2004 21:31:32 +0100

> the exchange of LDAP messages.

True.  I suggest to use "LDAP connection with TLS protection".

> And, is the association really at the underlying connection or

I can't see that it matters.  The connection and the exchange are
associated, in a 1-1 manner.  When you have one, you have the other.
And data passes through the connection, not through the association.
(At least I hope so.  If anything sends an LDAPMessage "over the
association", it should be fixed.)

> certainly is done on the underlying connection.

Again I don't see that it matters.  But actually I think this one is
correct: "To bind" is an action, not a protocol element.  The client
performs it through the interface it has to the server, in the manner
required by the interface.  And the interface is the connection.
Just as "to fetch a document over HTTP" does not imply that the
resulting document includes the HTTP header.
OTOH, "to send a bind request" over the connection would be wrong.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 13 Mar 2004 12:40:06 +0100

> unless order-dependent semantics are provided.

Oops, sorry.  I meant to address the part after the comma in the

> The problem we current face is that effect of ordering is

Hm?  I thought you just agreed that it _is_ specified.

>         combination details order-specific semantics.

As far as I can tell, that says the same as the original text.
But I think the original was clearer.

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

Yes, move it to 4.1.10 (Referral), which currently doesn't say when
referrals may be returned, just what they mean.  No other protocol
operations in section 4 mention referrals (except the subsection about
continuation references under Search).

I just noticed an error in 4.1.10 (Referral):

>   The referral result code indicates that the contacted server does not 
>   hold the target entry of the request.

So does noSuchObject.  I suggest:

    A referral indicates that the contacted server cannot perform the
    operation, but one or more other servers can.

I tried at first to formulate it in terms of naming contexts, but that
got too clumsy.  Some operations cannot be performed if the server
doesn't hold the naming context for the entry which the operation
applies to, while others cannot be performed if it doesn't _master_ that
naming context.

>      (note the same OBJECT IDENTIFIER may be used for both)

Fine.

>>     Request, such as those provided by lower layer security services.

Note that 'authorization identity' is not defined or used elsewhere in
[Protocol].  The paragraph is fairly self-contained anyway, so I hope
that's all right.  Could add an [Authmeth] reference.

> talking about matching using the equality matching rule.

I prefer s/is equivalent to/matches/, and s/non-equivalent/FALSE/
further down, as I suggested in the thread about no EQUALITY matching
rule.  I don't know of any other "equivalent" things that need fixing.

> connection

Yes, it is.  That's what "LDAP connection" is defined as in Section 2.
--> New thread '"connections" (Was: protocol-22 comments)'.

I suppose it might be an idea to spell out "transfer protocol
connection" in this case; if so the phrase "LDAP connection" in nearby
sections should be replaced with the same.

>> the paragraph belongs in a separate section '5.2.2 Connection Closure

Um... on second thought, it fits better as section 4.2 or 4.15.  This
text is about which directory operations to perform in a particular
situation.  The rest of section 5 is about transfer protocols and has
nothing to do with directory operations.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 13 Mar 2004 07:43:09 -0800

>Hm?  I thought you just agreed that it _is_ specified.

The problem we currently face in the existing TS (RFC3377) is that
the effect of ordering is unspecified.

>So does noSuchObject.

The quoted text is problematic in that a server which does hold
a target entry can return a referral.

>I suggest:

Right, referrals are be returned when the server chooses to
refer the operation to another server.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 15 Mar 2004 20:54:19 +0100

> refer the operation to another server.

s/cannot/cannot or will not/ in my suggestion?
Then server A can refer to B and C, and the client chooses B which
refers to A and C, so the client detects a loop and gives up even though
C might be willing to perform the operation.  Whether we add "cannot or
will not" or not, maybe the text should alert implementors to this
possibility.

-- 
Hallvard