proposed mods to draft-ietf-ldapext-locate-01.txt

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

Here are modifications I propose to draft-ietf-ldapext-locate-01.txt,
based on my note of 20 Jan 2000, and some other stuff.

 - RL "Bob"

---

[ This section 2 replaces the current section 2. ]

2. Introduction

The LDAPv3 protocol [1] is designed to be a lightweight access
protocol for directory services supporting X.500 models.  As a
distributed directory service, the complete set of directory
information (known as the Directory Information Base) is spread across
many different servers.  Hence there is the need to determine, when
initiating or processing a request, which servers hold the relevant
information.  In LDAP, the Search, Modify, Add, Delete, ModifyDN, and
Compare operations all specify a Distinguished Name (DN) on which the
operation is performed.  A client, or a server acting on behalf of a
client, must be able to determine the server(s) that hold the naming
context containing that DN, since that server (or one of that set of
servers) must receive and process the request.  This determination
process is called "server location".  To support dynamic distributed
operation, the information needed to support server location must be
available via lookups done at request processing time, rather than,
for example, as static data configured into each client or server.

It is possible to maintain the information needed to support server
location in the directory itself, and X.500 directory deployments
typically do so.  In practice, however, this only permits location of
servers within a limited X.500-connected set.  LDAP-specific methods
of maintaining server location information in the directory have not
yet been standardized.  This document defines an alternative method of
managing server location information using the Domain Name System.
This method takes advantage of the global deployment of the DNS, by
allowing LDAP server location information for any existing DNS domain
to be published by creating the records described below.  A full
discussion of the benefits and drawbacks of the various directory
location and naming methods is beyond the scope of this document.

RFC 2247 defines an algorithm for mapping DNS domain names into DNs.
This document defines the inverse mapping, from DNs to DNS domain
names, based on the RFC 2247 conventions, for use in this server
location method.  The server location method described in this
document is only defined for DNs that can be so mapped, i.e., those
DNs that are based on domain names.  In practice this is reasonable
because many objects of interest are named with domain names, and use
of domain-name-based DNs is becoming common.

===

[ This is a new section. ]

N.  Mapping Distinguished Names into Domain Names

This section defines a method of converting a DN into a DNS domain
name for use in the server location method described below.  Some DNs
cannot be converted into a domain name.

The output domain name is initially empty.  For each RDN component of
the DN, beginning with the first, if the attribute type is "DC", then
the attribute value is used as a domain name component (label).  The
first such value becomes the most significant (i.e., rightmost) domain
name component, and successive values occupy less significant
positions (i.e., extending leftward), in order.  If the attribute type
is not "DC", then processing stops.  If the first RDN component of the
DN is not of type "DC" then the DN cannot be converted to a domain
name.

[ At first I wrote that the conversion should include converting the
RDN attribute value to a string as per RFC 2253, but upon reflection I
think it should just use the bits, since of course DNS can in theory
handle binary labels just as well as X.500 can.  I'm not a charset
expert so I don't know if in reality an IA5 RDN value will just drop
in and become a nice ASCII DNS name.  I think, though, that RFC 2247
is deficient in that it assumes that a DNS name being converted into a
DN will always be just ASCII/IA5 strings. ]

===

Mods to items in the current section 3:

  The name of this record always has the following format:

   _<Service>._<Proto>.<Domain>

   where <Service> is always "ldap", <Proto> is a protocol that can 
   be either "udp" or "tcp", and <Domain> is the domain hosted by the 
   LDAP Server.

I think this is too loose about the relationship between the info on
the LDAP server and the name of the SRV record used to locate it.  So
change the last bit to:

 where <Service> is always "ldap", and <Proto> is a protocol that can
 be either "udp" or "tcp".  <Domain> is the domain name formed by
 converting the DN of a naming context mastered by the LDAP Server into
 a domain name using the algorithm in section N.

Also:

   Presence of such records enables clients to find the LDAP servers 
   using standard DNS query [3].

I think it's worthwhile to write down the algorithm in detail, hence
follow this with:

 A client (or server) seeking an LDAP server for a particular DN
 converts that DN to a domain name using the algorithm of section N,
 does a SRV record query using the DNS name formed as described above:

    _ldap._tcp.<Domain>

 and interprets the response as described in [6] to determine a host
 (or hosts) to contact.

This continues with:

                                  As an example, a client that searches 
   for an LDAP server in the example.net domain that supports TCP protocol 

But the LDAP client, for purposes of this document, starts with a DN,
not a domain name, so make this:

 As an example, a client that searches for an LDAP server for the DN
 "dc=example,dc=net" that supports the TCP protocol ...