Subject: RE: Misuse of the term "association" in [Protocol]

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 4 Oct 2004 11:36:01 +1000

Kurt,

I note that you are not listening to me, and I guess that it OK. But this problem will not go away until you drop this strange "LDAP exchange" thing. It DOES NOT, at least in English, mean the ongoing exchange of protocol data. The meaning of "exchange" is similar to "swap", unless you think of the PSTN exchange, but I don't think this helps your case, either.

The only chance for sanity here is to keep "association" and drop "exchange".

Ron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kurt D. Zeilenga
Sent: Saturday, 2 October 2004 01:54
To: [email-masked]
Subject: Misuse of the term "association" in [Protocol]

I believe it is best to removing use of the term "LDAP association"
(and, hence, its definition) from [Protocol] as [Protocol]'s use
of it is not consistent with how that term is used in [AuthMeth]
discussion of authentication, authorization, and other security
factors.

As Hallvard noted, in most cases, the term "LDAP exchange" should
have been used where the term "LDAP association" was used.  In other
cases, the term "association" (where used to refer to a LDAP
association) can simply be avoided in [Protocol] or is used in
a manner which appears to clear.

I have reviewed each occurrence of the word "association" in
[Protocol] technical specification and believe the following
changes should be made:

The section 2 text:
>   The term "association" refers to the association of the LDAP exchange
>   and its current authentication and authorization state. 
should be removed.

The 4.1.1.1 text:
>   The message ID of a request MUST have a non-zero value different from
>   the values of any other uncompleted requests in the LDAP association 
>   of which this message is a part.
should read:
>   The message ID of a request MUST have a non-zero value different from
>   the values of any other uncompleted requests in the LDAP exchange. 

The 4.1.1.1 text:
>   A client MUST NOT send a request with the same message ID as an
>   earlier request on the same LDAP association unless it can be        
>   determined that the server is no longer servicing the earlier request
>   (e.g. after the final response is received, or a subsequent bind
>   completes).
should read:
>   A client MUST NOT send a request with the same message ID as an
>   earlier request in the LDAP exchange unless it can be       
>   determined that the server is no longer servicing the earlier request
>   (e.g. after the final response is received, or a subsequent bind
>   completes).

The 4.2 text:
>version: A version number indicating the version of the protocol   
>     to be used in this LDAP association.
should read:
>version: A number indicating the version of the protocol
>to be used.

The 4.3 text:
>   The function of the Unbind Operation is to terminate an LDAP         
>   association and close the connection.
should read:
>   The function of the Unbind Operation is to terminate an LDAP         
>   exchange and close the connection.

The 4.3 text:
>   The Unbind Operation has no response defined. Upon transmission of  
>   the UnbindRequest, each protocol peer is to consider the LDAP       
>   association terminated, MUST cease transmission of messages to the
>   other peer, and MUST close the connection.
should read:
>   The Unbind Operation has no response defined. Upon transmission of  
>   the UnbindRequest, each protocol peer is to consider the LDAP       
>   exchange terminated, MUST cease transmission of messages to the
>   other peer, and MUST close the connection.

The 4.4.1. text:
>   Upon transmission of the Notice of Disconnection, the server is to
>   consider the LDAP association terminated, MUST cease transmission of
>   messages to the client, and MUST close the connection.
should read:
>   Upon transmission of the Notice of Disconnection, the server is to
>   consider the LDAP exchange terminated, MUST cease transmission of
>   messages to the client, and MUST close the connection.

The 4.5.3 text:
>   In order to complete the search, the client issues a new search
>   operation for each SearchResultReference that is returned. Note that
>   the abandon operation described in Section 4.11 applies only to a
>   particular operation sent on an association between a client and
>   server. The client must abandon subsequent search operations it
>   wishes to individually.
should read:
>   In order to complete the search, the client issues a new search
>   operation for each SearchResultReference that is returned. Note that
>   the abandon operation described in Section 4.11 applies only to a
>   particular operation sent on the LDAP exchange between a client and
>   server. The client must abandon subsequent search operations it
>   wishes to individually.

The 4.6 text:
>   If the association changes or the connection fails,  
>   whether the modification occurred or not is indeterminate.
should read:
>   If the LDAP exchange is terminated, or the Modify operation
>   is abandoned due to subsequent operation which requires all
>   outstanding operations to be abandoned (e.g., the Bind
>   operation), whether the modification completed successfully
>   or not is indeterminate.

The section 4.11 text:
>   The function of the Abandon Operation is to allow a client to request
>   that the server abandon an uncompleted operation.
should read:
>   The function of the Abandon Operation is to allow a client to request
>   that the server abandon an uncompleted operation previously requested
>   in the LDAP exchange.
(The above clarification facilitates the below change.) 

The section 4.11 text:
>   The MessageID is that of an operation which was requested earlier in
>   this LDAP association.
should read:
>   The MessageID is that of an earlier request whose response is
>   outstanding.

The section 6 text:
>   Server implementors should plan for the possibility of an identity in
>   and association being deleted, renamed, or modified, and take   
>   appropriate actions to prevent insecure side effects. Likewise,
>   server implementors should plan for the possibility of an associated
>   identity's credentials becoming invalid, or an identity's privileges
>   being changed. The ways in which these issues are addressed are    
>   application and/or implementation specific.
should read:
>   Server implementors should plan for the possibility of that
>   information used to establish security factors may change
>   (due to protocol or external events) during the course of
>   the LDAP exchange, and even during the performance of a
>   particular operation, and should take steps to avoid
>   insecure side effects of these changes.  The ways in
>   which these issues are addressed are application and/or
>   implementation specific.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 03 Oct 2004 22:09:25 -0700

At 06:36 PM 10/3/2004, Ramsay, Ron wrote:
>I note that you are not listening to me, and I guess that it OK. But this problem will not go away until you drop this strange "LDAP exchange" thing. 

I previously responded to comments regarding the "LDAP exchange"
term.  I see no reason to repeat my comments (especially since
Hallvard did).

In this thread, I have made a suggestion intended to address
a separate issue, consistent use of the term "LDAP association".

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 4 Oct 2004 14:56:43 +0200

Ramsay, Ron writes:
> I note that you are not listening to me, and I guess that it OK. But
> this problem will not go away until you drop this strange "LDAP
> exchange" thing. It DOES NOT, at least in English, mean the ongoing
> exchange of protocol data.

Nor is it defined that way in [Protocol].  Did you see my message
  http://www.openldap.org/lists/ietf-ldapbis/200410/msg00002.html
?

> The only chance for sanity here is to keep "association" and drop

That would be wrong, since "association" is defined as something
different.  We could rename the term "LDAP exchange" to something else
(which would get the current definition of "LDAP exchange") after making
Kurt's changes.  If you wish to suggest a better term, read this thread
first:

  http://www.openldap.org/lists/ietf-ldapbis/200404/msg00023.html

Personally I prefer several other terms over "LDAP exchange", but I
don't feel strongly about it.

-- 
Hallvard