Subject: LDAP terminology proposal

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Nov 2004 13:41:49 -0500

An ad-hoc engineering team consisting of Jim, Roger, Hallvard,
Bob, and myself offer the following proposal for WG consideration
to address LDAP session terminology issues (related to the LDAPBIS
I-Ds use of "LDAP exchange", "connection", "LDAP association" and
related terms.  The proposal basically(*) replaces the term
"LDAP exchange" as used in [Protocol] with the term "LDAP stream",
and (re)introduces the term "LDAP session".  Also, as part of this
proposal, the terms "exchange" and "association" would not take on
any LDAPBIS-specific meaning.  That is, they are (and would be)
used in the dictionary and/or RFC 2828 sense.

(* It is recognized that in some cases the old terms cannot
(or should not) simply be replaced with new terms.  Some minor
tweaking would be needed here and there, and the WG would need
to carefully review that tweaking.)

The terms would be defined as follows:

	"connection" refers to the underlying transport services 
       used to carry the protocol exchange, as well as
	associations established by these services.

	"TLS layer" refers to TLS services used in providing
	security services, as well as associations
	established by these services.

	"SASL layer" refers to SASL services used in providing
	security services, as well as associations established
	by these services.

	"LDAP stream" refers to the LDAP Message (PDU) services
	used in providing directory services, as well as associations
	established by these services.

	"LDAP session" refers to combined services (connection, TLS
	layer, SASL layer, LDAP stream) and their associations.

The following diagram illustrates how the component services
of an LDAP session relate to each other:

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

To further illustrate the use intended by this proposal, the following is
how these terms would be used in [Protocol, 4.3]:

   The function of the Unbind Operation is to terminate an LDAP session.
   The Unbind operation is not the antithesis of the Bind operation as
   the name implies. The naming of these operations is historical. The
   Unbind operation should be thought of as the "quit" operation.
   
   The Unbind Operation is defined as follows:                
     
        UnbindRequest ::= [APPLICATION 2] NULL
   
   The Unbind Operation has no response defined. The client, upon
   transmission of the UnbindRequest, and the server, upon receipt
   of the UnbindRequest are to close the LDAP session as follows:
	1) close the LDAP stream and cease sending LDAP messages,
	2) close the SASL layer (if installed),
	3) close the TLS layer (if installed), and
	4) close the connection.
   Uncompleted operations are handled as specified in Section 5.1.

Comments?

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 15 Nov 2004 12:07:21 -0500 (EST)

> 	associations established by these services.

Sorry to continue teasing at this as I know we want to close on it, but 
let me suggest "transport connection" rather than just "connection".  I 
think this would be more consistent with the use of that phrase in the TLS 
spec.  And it would make all the terms two words (or two strings, at 
least).

  - RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Nov 2004 09:44:59 -0800

At 09:07 AM 11/15/2004, RL 'Bob' Morgan wrote:

>Sorry to continue teasing at this as I know we want to close on it, but let me suggest "transport connection" rather than just "connection".  I think this would be more consistent with the use of that phrase in the TLS spec.  And it would make all the terms two words (or two strings, at least).

I have no problem with this suggestion.

Kurt

---

From: Ludovic Poitou <[email-masked]>
Date: Mon, 15 Nov 2004 19:01:46 +0100

Yes, fine with me.

Ludo

-- 
Ludovic Poitou
Directory Architect.
Directory Server Group, Grenoble, France
Sun Microsystems Inc.

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy
all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 15 Nov 2004 17:08:17 -0800 (PST)

OK, I believe we have consensus on this new terminology, and so direct the 
document editors to revise the drafts accordingly.  This affects the 
protocol and authmeth drafts, and maybe the url draft, but not any of the 
others as far as I can tell.

  - RL "Bob"

---

From: Mark Smith <[email-masked]>
Date: Tue, 16 Nov 2004 11:40:43 -0500

RL 'Bob' Morgan wrote:

>
> OK, I believe we have consensus on this new terminology, and so direct 
> the document editors to revise the drafts accordingly.  This affects 
> the protocol and authmeth drafts, and maybe the url draft, but not any 
> of the others as far as I can tell.

I modified the second and third paragraphs of [LDAPURL]'s Security 
Considerations section to avoid the term "connection" (which was used 
quite a bit).  In every instance except the last sentence of the third 
paragraph, I replaced "connection" with "LDAP session."  Here is the 
revised text:

   The use of security mechanisms when processing LDAP URLs requires
   particular care, since clients may encounter many different servers
   via URLs, and since URLs are likely to be processed automatically,
   without user intervention. A client SHOULD have a user-configurable
   policy that controls which servers the client will establish LDAP
   sessions with using which security mechanisms, and SHOULD NOT
   establish LDAP sessions that are inconsistent with this policy.  If a
   client chooses to reuse an existing LDAP session when resolving one
   or more LDAP URLs, it MUST ensure that the session is compatible with
   the URL and that no security policies are violated.

   Sending authentication information, no matter the mechanism, may
   violate a user's privacy requirements.  In the absence of specific
   policy permitting authentication information to be sent to a server,
   a client should use an anonymous LDAP session.  (Note that clients
   conforming to previous LDAP URL specifications, where all LDAP
   sessions are anonymous and unprotected, are consistent with this
   specification; they simply have the default security policy.)  Simply
   opening a transport connection to another server may violate some
   users' privacy requirements, so clients should provide the user with
   a way to control URL processing.

Comments?

-Mark

---

From: Ludovic Poitou <[email-masked]>
Date: Tue, 16 Nov 2004 18:28:22 +0100

Looks good to me.

Ludovic.

Mark Smith wrote:

> RL 'Bob' Morgan wrote:
>
>>
>> OK, I believe we have consensus on this new terminology, and so 
>> direct the document editors to revise the drafts accordingly.  This 
>> affects the protocol and authmeth drafts, and maybe the url draft, 
>> but not any of the others as far as I can tell.
>
>

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Tue, 16 Nov 2004 12:36:41 -0800 (PST)

Very nice, and shows the usefulness of the several terms.  - RL "Bob"