Subject: Re: "connections" (Was: protocol-22 comments)

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 16 Apr 2004 20:29:23 -0600

I like these terms thought I don't think I need them all. I'll try a
pass at replacing current terminology and report back with what
happens.

>>> "Kurt D. Zeilenga" <[email-masked]> 4/16/04 8:15:34 PM >>>
I prefer layer over connection for TLS, because starting
and stopping TLS does not close either LDAP "connection"
or transport (TCP) "connection". I also prefer to say
that a TLS closure event causes the layer to be deinstalled
as it reflects better that the LDAP and transport connections
are still established.

At 05:58 PM 4/16/2004, Jim Sermersheim wrote:
>Currently (from section 2):
>The terms "connection" and "LDAP connection" both refer to the
>underlying transport protocol connection between two protocol peers.
>The term "TLS connection" refers to a [TLS]-protected LDAP
connection.
>The terms "association" and "LDAP association" both refer to the
>association of the LDAP connection and its current authentication and
>authorization state.

What I really disliked in the current document is
defining TLS connection to mean a TLS-protected LDAP
connection but then saying that StartTLS establish
TLS on a LDAP connection. It would be okay to say
StartTLS establishes TLS protection for a LDAP connection.

>I propose we:
>/s/LDAP connection/connection
>/s/TLS connection/TLS layer (yes I know layer is redundant)
>/s/association/LDAP association

I suggest:
"stream" to refer to the underlying transport layer.
"connection" to the LDAP layer (where LDAP PDUs are exchanged)
(and used without regard to whether protective-layers are
or are not in place).
"TLS layer" to refer to layer inserted between the stream
and the connection that utilizes TLS to protect
exchanged LDAP PDUs.
"SASL layer" to refer to layer inserted between the stream
and the connection that utilizes SASL to protect
exchanged LDAP PDUs.
"protective layer" to refer to either a TLS or SASL layer
"protected connection" to refer to a connection protected
by a protective layer
"TLS-protected connection" to refer to a connection protected
by a TLS-layer
"SASL-protected connection" to refer to a connection protected
by a SASL-layer
"unprotected connection" to refer to a connection not
protected by a protective layer

(LDAP) association refers to the authentication and authorization
state (generally of the client at the server) of a connection.

I suggest also adding a picture.

+------------+ |
| connection | |
+------------+ > LDAP PDU |
+------------+ < data | 
| SASL layer | | 
+------------+ > SASL-protected data | 
+------------+ < data | 
| TLS layer | |
+------------+ > TLS-protected data | Application
+------------+ < data +------------
| stream | | Transport 
+------------+ 

Note that I don't include the association in this picture as
that refers to a state.

> The terms "association" and "LDAP association" both refer to the 
> association of the LDAP connection and its current authentication
and
> authorization state.

>This, at least is how I see it. There is the physical connection
>(connection) and the LDAP association. Sometimes there is a TLS layer
>protecting the LDAP messages on the connection.
>
>Are these terms sufficient?
>
>Jim
>
>>>> "Kurt D. Zeilenga" < [email-masked] > 3/12/04 11:03:49 AM >>>
>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: "Jim Sermersheim" <[email-masked]>
Date: Mon, 19 Apr 2004 00:37:34 -0600

I agree. Once the usage is properly broken up in the document, it'll be
easy to swap terms like 'stream' for 'transport' or whatever seems most
agreeable.
 
Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 4/18/04 11:31:55 AM >>>
At 09:58 AM 4/18/2004, Kurt D. Zeilenga wrote:
> stream
> 1. <communications> An {abstraction} referring to any flow of
> data from a source (or sender, producer) to a single sink (or
> receiver, consumer). A stream usually flows through a channel
> of some kind, as opposed to {packet}s which may be addressed
> and routed independently, possibly to multiple recipients.
> Streams usually require some mechanism for establishing a
> channel or a "{connection}" between the sender and receiver. 

Another comment: one reason not to use "stream" to refer to
the exchange of LDAP messages is that LDAP messages are
addressed independently (by message id) and routed
independently to the directory operation executed at an
higher level. That is, messages from multiple operations
(each a source) are multiplexed in the exchange.

I note that my primary interest is not which particular
terms are used where. I am primarily interested in ensuring
that our terms are well-defined and used in an unambiguous
manner. I wouldn't object to using "LDAP connection" and
"transport connection" as long as we never use the term
"connection" without qualification.

Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 19 Apr 2004 00:42:40 -0600

Also from RFC 793:
  Basic Data Transfer:

    The TCP is able to transfer a continuous stream of octets in each
    direction between its users by packaging some number of octets
into
    segments for transmission through the internet system.  

Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 19 Apr 2004 00:41:20 -0600

From RFC 793:
  Connections:

    The reliability and flow control mechanisms described above
require
    that TCPs initialize and maintain certain status information for
    each data stream.  The combination of this information, including
    sockets, sequence numbers, and window sizes, is called a
connection.
    Each connection is uniquely specified by a pair of sockets
    identifying its two sides.

    When two processes wish to communicate, their TCP's must first
    establish a connection (initialize the status information on each
    side).  When their communication is complete, the connection is
    terminated or closed to free the resources for other uses.

    Since connections must be established between unreliable hosts and
    over the unreliable internet communication system, a handshake
    mechanism with clock-based sequence numbers is used to avoid
    erroneous initialization of connections.

Kurt