IDS Working Group                                            Al Grimstad
INTERNET-DRAFT                                                Rick Huber
                                                            Sri Sataluri
                                                                    AT&T
                                                           November 1996


             NAMING PLAN FOR AN INTERNET DIRECTORY SERVICE
               Filename: draft-ietf-ids-dirnaming-00.txt


Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups.  Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Distribution of this document is unlimited.  Editorial comments should
be sent directly to the authors.  Technical discussion will take place
on the IETF Integrated Directory Services mailing list,
ietf-ids@umich.edu.

           This Internet Draft expires April 15, 1997.

Abstract

Application of the conventional X.500 approach to naming has, in the
experience of the authors, proven to be an obstacle to the creation of
directory services.  We propose a new directory naming plan that
leverages the strengths of the most popular and successful Internet
naming schemes for naming objects in a hierarchical directory.  This
plan can, we believe, facilitate the creation of an Internet White
Pages Service (IWPS) by overcoming the problems encountered by those
using the conventional recommended X.500 approach to naming.

1.0 EXECUTIVE SUMMARY

The conventional approach to naming taken by the X.500 community has,
in the experience of the authors, shown itself to be an obstacle to the
creation of directory services.  The required registration
infrastructure is either non-existent or largely ignored.  The
infrastructure that does exist is cumbersome to use and tends to
produce counterproductive results.  The attributes used for naming have
been confusing for users and inflexible to managers and operators of
directory services.

We propose an alternative approach -- which can co-exist with current
X.500 naming practices -- for the construction of the Internet White
Pages Service (IWPS).  The existing infrastructure of names in the
Internet, that is, names from the Domain Name System (DNS) and mailbox
identifiers structured according to RFC822, can adequately supply the
need for names in the construction of an IWPS.  Further, with the
proper construction of the IWPS, RFC822 identifiers can play a role
that is entirely analogous to the role distinguished names play in
X.500.

Here, in summary, is our proposal.

For naming entries of users, server applications and certification
authorities in a hierarchical directory (e.g., one accessed via LDAP),
we propose the use of the user identifier attribute "uid" for the
relative distinguished name.  The value of this attribute should be an
RFC822 address, e.g.,

    uid=John.Smith@acme.com

The upper portions of the hierarchical directory tree should be
constructed using the components of registered DNS names using the
domain component attribute "dc".  The directory name for the
organization having the domain name acme.com will then be, e.g.,

    dc=acme, dc=com

Organizations can add additional directory structure, for example to
support implementation of access control lists or partitioning of their
directory information, by using registered subdomains of DNS names,
e.g.,

    dc=corporate, dc=acme, dc=com

Directory distinguished names will thus have the following structure,
e.g.,

    uid=John.Smith@acme.com, dc=acme, dc=com
    uid=Mary.Jones@acme.com, dc=corporate, dc=acme, dc=com
    uid=J.Smith@worldnet.att.net, dc=legal, dc=acme, dc=com

Searching the directory based on exact matching of the uid attribute
should be optimized in the directory service such that it is
essentially equivalent to searching using a directory distinguished
name.

External mechanisms can be used to locate the proper directory server
to query to obtain directory information.

2.0 THE PROBLEM

The X.500 Directory model [1] can be used to create a world-wide
distributed directory. The Internet X.500 Directory Pilot has been
operational for several years and has grown to a size of about 1.5
million entries of varying quality.  The rate of growth of the pilot is
far lower than the rate of growth of the Internet during the pilot
period.

There are a substantial number of contributing factors that have
inhibited the growth of this pilot.  The common X.500 approach to
naming, while not the preponderant problem, has contributed in several
ways to limit the growth of an Internet White Pages Service based on
X.500.

2.1 Naming Problems

The conventional way to construct names in the X.500 community is
documented as an informative (i.e., not officially standardized) Annex
B to X.521. The relative distinguished name (RDN) of a user consists of
a common name (cn) attribute. This is meant to be what, in the user's
particular society, is customarily understood to be the name of that
user. The distinguished name of a user is the combination of the name
of some general object, such as an organization or a geographical unit,
with the common name. There are two main defects to this style of name
construction.

First, the common name attribute, while seeming to be user-friendly,
cannot be used generally as an RDN in practice.  In any significant set
of users to be named under the same Directory Information Tree (DIT)
node there will be collisions on common name.  There is no way to
overcome this other than either forcing uniqueness on common names,
something they do not possess, or using an additional attribute to
prevent collisions.  This additional attribute normally needs to be
unique in a much larger context to have any practical value.  The end
result is a RDN that is very long and unpopular with users.

Second, and more serious, X.500 has not been able to use any
significant number of pre-existing names.  Since X.500 naming models
typically use organization names as part of the hierarchy [2, 3],
organization names must be registered.  As organization names are
frequently tied to trademarks and are used in sales and promotions,
registration can be a difficult and acrimonious process.

The North American Directory Forum (NADF, now the North Atlantic
Directory Forum but still the NADF) proposed to avoid the problem of
registration by using names that were already registered in the "civil
naming infrastructure" [3].  Directory distinguished names would be
based on an organization's legal name as recognized by some
governmental agency (county clerk, state secretary of state, etc.) or
other registering entity such as ANSI.

This scheme has the significant advantage of keeping directory service
providers out of disputes about the right to use a particular name, but
it leads to rather obscure names.  Among these obscurities, the legal
name almost invariably takes a form that is less familiar and longer
than what users typically associate with the organization.  For
example, in the US a large proportion of legal organization names end
with the text ", Inc." as in "Acme, Inc."  Moreover, in the case of the
US, the civil naming infrastructure does not operate nationally, so the
organization names it provides must be located under state and regional
DIT nodes, making them difficult to find while browsing the directory.
NADF proposes a way to algorithmically derive multi-attribute RDNs
which would allow placement of entries or aliases in more convenient
places in the DIT, but these derived names are cumbersome and
unpopular.  For example, suppose Nadir is an organization that is
civilly registered in New Jersey under the name "Nadir Networks, Inc."
Its civil distinguished name (DN) would then be

    o="Nadir Networks, Inc.", st=New Jersey, c=US

while its derived name which is unambiguous under c=US directly is

    o="Nadir Networks, Inc." + st=New Jersey, c=US

More generally, the requirement for registration of organizations in
X.500 naming has led to the establishment of national registration
authorities whose function is mainly limited to assignment of X.500
organization names.  Because of the very limited attraction of X.500,
interest in registering an organization with one of these national
authorities has been minimal. Finally, multi-national organizations are
frustrated by a lack of an international registration authority.

2.2 Directory Models

The Internet community proposed the Light-weight Directory Access
Protocol [4], initially, as an access method for X.500 directories.
However, more recently, many different directories are starting to use
LDAP as an access protocol.  Many software companies have endorsed the
LDAP protocol and are starting to sell stand-alone hierarchical
directories that use LDAP as the access protocol.

The meeting documented in RFC1588, held in conjunction with the Houston
IETF in November 1993, has the following as one of its conclusions
[5]:

      It is evident that there are and will be several [directory]
      technologies in use.  In order to provide a white pages directory
      service that accommodates multiple technologies, we should
      promote interoperation and work toward a specification of the
      simplest common communication form that is powerful enough to
      provide the necessary functionality.  This "common ground"
      approach aims to provide the ubiquitous WPS (White Pages Service)
      with a high functionality and a low entry cost.

In other words, at that time (November 1993) people already felt that
X.500 was not the one and only answer; we needed to try out other tools
and look for ways to tie all the resulting directories together.  The
Internet community gave X.500 a fair chance [6] but it did not succeed
on a large enough scale to become the overall Internet White Pages
Service (IWPS).

The X.500 Directory, via its knowledge model, attempts to build a
world-wide directory in a top-down fashion.  This approach has only met
with partial success.  The advent of the LDAP protocol and its
popularity and the possible ubiquitous availability of stand-alone LDAP
directory server technology will, in our opinion, stimulate the
creation of directories in a bottom-up fashion.  These directory
servers or directory islands will be loosely tied together via LDAP
referrals and other external mechanisms.

2.3 Addressing the Problems

This paper describes a directory naming plan that is a radical
departure from the traditional X.500 naming scheme -- the X.500 scheme
has not been generally accepted by the Internet community and has been
found to be very clumsy in implementing and administering directory
services by the authors.

This naming plan is straightforward to implement by both classic X.500
systems and islands of stand-alone LDAP servers. Its unique strength
lies in its use of the existing Internet naming schemes -- RFC822
addresses and the Domain Name System. Further, by use of an attribute,
the user ID attribute, and a tree structure based on the DNS, the plan,
if broadly implemented, may well simplify the construction of external
mechanisms to locate appropriate LDAP servers.

The naming plan focus is on naming Internet user and server
applications.  It is not applicable to objects such as the X.500
residential person which typically lack e-mail mailboxes (we believe
that such entries are useless in this day and age).  Because it is a
hierarchical plan using typed attribute values (tags), the naming plan
can co-exist with other hierarchical plans using other typed attributes
such as a plan for residential persons and the conventional X.521 Annex
B plan.

3.0 TECHNOLOGICAL ASSUMPTIONS

We assume that our fundamental protocol interface to systems offering
general directory services will be the TCP/IP-based Lightweight
Directory Access Protocol (LDAP) [4].  Objects are named in this
protocol in a hierarchical fashion and represented as described in RFC
 [7].  We also assume that user authentication and other security
services based on it will increasingly depend on the use of the Secure
Sockets Layer (SSL) or variant protocol and the structure of user and
server certificates (certified public cryptographic keys) as described
in an Internet Draft [8].

4.0 RFC822 IDENTIFICATION

The one universally accepted scheme of user identification (actually
user maildrop identification) in the Internet today is the RFC822 [9]
syntax for e-mail addresses. The syntax of an RFC822 identifier is:

    local@domain

where

    "domain"      is a hierarchically structured identifier as defined
                  by the Domain Name System (DNS), and

    "local"       is an identifier for a user (literally a maildrop)
                  that is valid within the domain "domain".

Examples of such identifiers are J.Smith@acme.com and
S.Johnson@corporate.acme.com.

Each user for whom information is maintained in a directory service
will have at least one e-mail address structured according to RFC822.
While the user may well have many such addresses, one will be selected
for the purpose of user identification.  We call this the
"distinguished" e-mail address or the "distinguished" RFC822 identifier
for the user.

5.0 DIRECTORY DISTINGUISHED NAMES

5.1 Overview of Distinguished Names

The general structure of a name in LDAP, termed a distinguished name
(DN), is:

    attribute, attribute, ... attribute

An "attribute" is a pairing of a type identifier and a value separated
by "=". For example, cn=Samuel Johnson is an attribute with type
identifier "cn", short for common name, and value "Samuel Johnson".

The order of the attributes in a DN is significant. Like DNS
identifiers, DNs are hierarchical and "little endian", that is, the
most global piece comes last. An example of a DN is:

    cn=Samuel Johnson, o=Famous Lexicographers, c=GB

where:

    cn=Samuel Johnson means the attribute type "cn" has the value
    "Samuel Johnson",

    o=Famous Lexicographers means that the attribute type "o", short
    for organization name, has the value "Famous Lexicographers", and

    c=GB means that the attribute type "c", short for country name, has
    the value "GB", the international abbreviation for the country
    Great Britain.

The set of all DNs forms a tree structure that is called the Directory
Information Tree (DIT).

5.2 Directory Distinguished Names

Suppose an organization, e.g., Acme, wants to bring up a Directory
Service.  It either has a registered DNS name or it should get one.

Given a DNS name, we will use a form of DN construction largely based
on RFC1279 [10].  This RFC shows how to map an RFC822 e-mail address to
a DN.  We differ from it in two respects: (1) we use a mapping that
starts at the root of the DIT; and (2) we use the attribute type user
ID (userid or uid) for the first attribute of the DN. The value of the
uid attribute is a complete RFC822 address that may but need not be
related to the DN of the parent entry.

The pattern for a user's DN will be:

    uid=RFC822 identifier, dc=A, ..., dc=Z

We consider each of the two attribute types, uid and dc, used to form
the DN in turn.

5.2.1 User ID (uid)

The userid (uid) attribute is defined and registered in RFC1274 [2].

The value of the user ID attribute for the user's name will be the
user's distinguished e-mail address in RFC822 syntax.  For example, if
there is a user affiliated with the organization Acme having
distinguished e-mail address J.Smith@acme.com, the uid attribute will
be:

    uid=J.Smith@acme.com

We require uid=J.Smith@acme.com to be a working e-mail address.  The
whole idea here is that users will remember a working e-mail address;
we shouldn't plague them with broken RFC822 addresses constructed for
the convenience of the directory service only.  The A or MX record for
the domain name can point to either a customer or network service
provider host.

Since an RFC822 identifier unambiguously identifies a user, it can be
used (by system processes) to search a particular directory system
(e.g. an LDAP server or a related set of LDAP servers) to find a user's
entry.  The user need not -- and we assume typically will not -- even
know his/her DN.  See Section 8.1.

Directory administrators having several RFC822 identifiers to choose
from when constructing a DN for a user should consider the following
factors:

    o Machine-independent addresses are likely to be more stable,
      resulting in directory names that change less. Thus an identifier
      such as:

          js@acme.com

      may well be preferable to one such as:

         js@blaster.third-floor.acme.com.

    o Use of some form of "handle" for the "local-part" that is distinct
      from a user's real name may result in fewer collisions and less
      user pain and suffering when a preferred handle is unavailable
      because it is already in use. Thus the identifier:

          js@acme.com

      may well be preferable to one such as:

          J.Smith@acme.com

5.2.2 Domain Component (dc)

The domain component attribute is defined and registered in RFC1274
[2].

The domain component attributes of a user's DN will normally be
constructed from the domain name of his/her distinguished e-mail
address.  That is, for the user uid=J.Smith@acme.com the domain
component attributes would typically be:

    dc=acme, dc=com

The full LDAP DN for this user would then be:

    uid=J.Smith@acme.com, dc=acme, dc=com

It is important to emphasize that the elements of the domain name of
the RFC822 identifier may, BUT NEED NOT, be the same as the domain
components of the DN.  This means that the domain components provide a
degree of freedom to support access control or other directory
structuring requirements that need not be mechanically reflected in the
user's e-mail address.  We do not want under any condition to force the
user's e-mail address to change just to facilitate a new system
requirement such as a modification in an access control structure.  It
should also be noted that while we do not require that the domain
components match the RFC822 identifier, we DO require that the
concatenated domain components form a registered domain name, that is
one that is represented in the DNS. This avoids name conflicts in the
directory hierarchy.

To provide an example of a DN which deviates from what might be
considered the default structure, consider the following scenario.

Suppose that J.Smith needs to be granted special permissions to
information in the dc=acme, dc=com part of the LDAP DIT.  Since it will
be, in general, easier to organize special users by their name
structure than via groups (an arbitrary collection of DNs), we use
subdomains for this purpose.  Suppose the special permissions were
required by users in the MIS organizational unit.  A subdomain
"mis.acme.com" is established, if it does not already exist, according
to normal DNS procedures.  The special permissions will be granted to
users with the name structure:

    uid=*, dc=mis, dc=acme, dc=com

The DN of J.Smith is this case will be:

    uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com

In principal, there is nothing to prevent the domain name elements of
the RFC822 identifier from being completely different from the domain
components of the DN.  For instance, the DN for a J.Smith could be:

    uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com

While we do not REQUIRE that the domain name part of the uid match the
dc components of the directory distinguished name, we suggest that this
be done where possible. At a minimum, if the most significant pieces of
the DN and the uid are the same (i.e., "dc=acme, dc=com" and
"acme.com") the likelihood, based on a knowledge of a user's e-mail
address, of discovering an appropriate directory system to contact to
find information about the user is greatly enhanced.

6.0 NAMING FOR CERTIFICATES

The certified public keys, certificates, used in SSL and other forms of
strong (i.e. cryptographically based) authentication are structured
according to the ITU X.509 standard.  A certificate contains two names
of importance, the name of the "subject" and the "issuer".  The subject
will be either a user or a server; the issuer will be a certification
authority.  The encoding of these names differs significantly from the
encoding of LDAP names which are simply character strings.  In
particular, the attribute types used in names are encoded as globally
unique "object identifiers."  The object identifiers relevant to the
names considered in this naming plan are assigned in either the X.500
standards (ITU X.520) or RFC1274, the COSINE and Internet X.500 Schema
[2].

6.1 User Certificates

For user certificates issued by a certification authority, the subject
name will be the proper X.509 representation of the user hierarchical
DNs described in this paper.

6.2 Server/Site Certificates

As certificates are used more and more for authentication, applications
that run as processes on systems need to be named so that they can also
be located in the directory.  Since the name of the subject is encoded
in a certificate, for application instances to be portable, we need a
naming scheme that is independent of the underlying hardware platform
and its IP address or DNS host name.

In existing Internet products that use certificates, the terms "Server
Certificate" and "Site Certificate" have been (mis-)used to identify
application instances.

We propose that application instances be named similar to individuals
as entities under a specific branch of the DIT and be given appropriate
unique RFC822 identifiers.  The RFC822 identifier so chosen is not
constrained by the naming plan.  As illustrated in the three examples
below, it can be either host-independent (1,2) or host dependent (3).
If host-independent, it can be based on a subdomain (2) of the
organization's domain name or, if such registration is convenient,
based on the domain name (1) itself.

A few examples of application instance names are:

    uid=dirsrv0@acme.com, dc=sales, dc=acme, dc=com                (1)
    uid=certsrv0@sales.acme.com, dc=sales, dc=acme, dc=com         (2)
    uid=gnarlysrv0@surf.sales.acme.com, dc=sales, dc=acme, dc=com  (3)

This name is used in the construction of the server's certificate.

A consequence of this method of constructing names is that application
instances have mailboxes. This can be thought of as an opportunity to
provide users with a predictable contact for resolution of operational
problems with the application much like postmaster@DOMAIN is the
predictable contact for e-mail problems at DOMAIN.

6.3 Certification Authority Certificates

A certification authority (CA) is the trusted guarantor for a user or
server certificate.  The CA's name appears in the "issuer" field of the
certificate it issues.  The names of several CAs are already built into
popular Internet Web browsers such as the Netscape Navigator and the
Microsoft Internet Explorer.  Some examples of such CA names are:

    cn=Certification Authority, o=AT&T, c=US
    cn=Directory Services, o=AT&T, c=US
    cn=Certificate Services, o=AT&T, c=US

These names use the traditional X.500 attributes for naming. These
attributes are common name (cn), organization name (o) and country name
(c).  To maintain compatibility, the appropriate CAs can be
incorporated in any LDAP-based directory service with these existing
names.

In future, new certification authorities should be assigned names
following the structure described in this document.

7.0 CONSUMER DIRECTORY SERVICES

Consumer customers are typically supported by on-line service
providers, such as AT&T WorldNet, America On-Line, CompuServe, etc.
Entries for these customers can also be represented in the LDAP DIT by
names with the following structure (reflecting current e-mail address
assignment practice):

    uid=J.Smith@worldnet.att.net, dc= worldnet, dc=att, dc=net

Modifications in this practice (to avoid the M.Jones99 problem) by
using additional subdomains of worldnet.att.net can be easily
accommodated by the scheme described here, but such ideas are left to
the discretion of the on-line service provider.

8.0 IMPLEMENTATION ISSUES

8.1 Directory Services Considerations

This naming plan has been designed so that a user's entry can be found
uniquely using nothing but the user's distinguished e-mail address --
assuming that the query is sent to the right LDAP directory server.
Systems having the user's DN in hand can, of course, directly access
the user's entry via LDAP.

An LDAP search request with the following components will either (1)
find uniquely the entry of a user with the provided distinguished
e-mail address, or (2) indicate that no user has the provided e-mail
address as a distinguished e-mail address:

    baseObject: root
    scope: wholeSubtree
    filter: equalityMatch (uid == distinguished e-mail address)

A search such as this is possible in LDAP servers being planned
because, unlike X.500 servers, the LDAP servers we envision are not
universally interconnected in one global system according to the X.500
knowledge model.  In X.500 such a search would propagate to all the
servers in the system; in the envisioned LDAP system it would be
limited to one server (or potentially a small set of servers).

In a world of LDAP islands, the issue of finding the right island to
which to direct a directory query arises.  The new version of LDAP
under design in the IETF [11] has a referral mechanism.  Given a query,
a server can return a referral to an other LDAP server that might hold
the data. This approach can be used to tie together the servers holding
the distributed data of an LDAP island.  By generalizing this concept
one can imagine building a simple referral server that knows about the
LDAP islands of the Internet. It would compare the naming information
in a query it receives with its knowledge of LDAP islands and return a
referral to the appropriate island.

It has been traditional in X.500 and LDAP directory services to employ
the common name (cn) attribute in naming.  While this naming plan
doesn't use the cn attribute, it should be stressed that it is still
quite important.  It will play a significant role in enabling searches
to find user entries of interest.  To this end, what is typically done
is to have multiple values of the common name attribute in the user's
entry.  Thus the entry for J.Smith@acme.com might well have the common
name attribute values "John Smith", "John Q. Smith" and "John Quincy
Smith" to optimize matching of search requests.

The attribute rfc822mailbox (or mail) is normally used to hold a user's
e-mail address in X.500 and LDAP directory services.  A user with
multiple e-mail addresses will not be assigned multiple DNs simply
because of the multiple addresses.  As described above, one of these
e-mail addresses -- a machine-independent and fairly static one -- will
be elected the distinguished e-mail address and used to construct the
DN.  If it is desirable to make available the other e-mail addresses,
they can be stored in the user's rfc822mailbox attribute.  It is
technically possible, although undesirable because potentially
confusing, that the rfc822mailbox attribute does NOT contain the
distinguished e-mail address as one of its values.

8.2 Alternative DN Structures

Some organizations may wish to be represented by a scheme based upon a
more classic X.500/NADF naming system [12].  These organizations can be
accommodated in the scheme without significant problems or naming
conflicts.

The approach we take should not preclude participation in a larger
directory service, so names held in the stand-alone LDAP directory
shouldn't collide unnecessarily with names held by other directory
service operators.  (If two directory service providers hold
information with respect to the same DN, these are two different views
of the same real world object, not two unrelated objects that
accidentally share a "name.")  Naming based on DNS meets this
criterion.  Disciplined use of X.500 naming can also meet this
criterion.

To enable a consistent searching strategy, we strongly recommend the
user ID (uid) attribute, although not part of the DN, have a valid
RFC822 identifier for the user.  The LDAP DIT structure will follow the
typical X.500/NADF approach as follows:

Organizations wishing to pursue this approach will need to register
their organization's name with the appropriate authority as generally
accepted in the X.500/NADF community. This means that US organizations
will register with ANSI.  The resort to the civil naming infrastructure
of states and counties should be actively discouraged.  The names
constructed from this civil naming infrastructure (a la NADF), while
meeting the technical criteria for non-ambiguity and right to use, are
typically long and unwieldy.

Suppose the US company "XYZ Widgets" expressed a wish to follow this
approach.  A typical user name might be

   uid=J.User@xyzwidgets.com, o="XYZ Widgets, Inc.", c=US

where o="XYZ Widgets, Inc.", c=US is an ANSI registered name.  (The
"alphanumeric string" registered with ANSI is 'XYZ Widgets, Inc.',
where the single quotes mark off what is registered but are not part of
the registered information.)

To support structured access control within the company the analogous
form to the registration of a subdomain in the mainline approach is the
creation of an organizational unit node.

8.3 Tagless Naming

The LDAP names of the form "cn=John Smith, ou= Corporate Sales, ou=
South East Region, o= Acme Service Corporation Inc., l= Monmouth,
st=New Jersey, c= US" are perpetually confusing to users.  It is also
hard for an intermediate system to add tags correctly if a user does
not supply them.

This naming plan is eminently suited for the support of tag-less
naming.  While supporting strong typing,  we use a limited number of
tags -- uid for all leaf objects and dc for all non-leaf objects, and
hence adding tags is straight-forward.  In the rare cases when users
must supply DNs, they will therefore do so without having to know about
tags.

9.0 SECURITY CONSIDERATIONS

Security considerations are not part of this paper.

10.0 ACKNOWLEDGMENTS

This plan has emerged in the course of a number of fruitful
discussions, especially with Joe Gajewski, Mark Jackson, Ryan Moats,
Tom Spencer and Chris Tzu.


11.0 REFERENCES

[]     X.500: The Directory -- Overview of Concepts, Models, and
        Service, CCITT Recommendation X.500, December, 1988.

[]     P.Barker, and S. Kille, "The COSINE and Internet X.500 Schema",
        RFC1274, 11/27/1991.

[]     The North American Directory Forum, "A Naming Scheme for c=US",
        RFC1255, September 1991.

[]     W. Yeong, T. Howes, and S. Kille, "Lightweight Directory Access
        Protocol", RFC1777, 03/28/1995. (Work is also underway in the
        IETF to produce an extended version of LDAP.)

[]     J. Postel, and C. Anderson, "White Pages Meeting Report",
        RFC1588, February 1994.

[]     Sollins, K., "Plan for Internet Directory Services", RFC 1107,
        July 1989.

[]     S. Kille, "A String Representation of Distinguished Names",
        RFC1779, 03/28/1995.

[]     A. Freier, P. Karlton, and P. Kocher, "The SSL Protocol Version
        3.0", Work in Progress, Internet Draft
        <draft-freier-ssl-version3-01.txt>, March 1996.

[]     D. Crocker, "Standard for the format of ARPA Internet text
        messages", RFC822, 08/13/1982.

[]    S. Kille, "X.500 and Domains", RFC1279, 11/27/1991.

[]    M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
        Protocol (v3)", Work in Progress, Internet Draft
        <draft-ietf-asid-ldapv3-protocol-03.txt>, October 22, 1996.

[]    The North American Directory Forum, "NADF Standing Documents: A
        Brief Overview", RFC 1417, The North American Directory Forum",
        NADF, February 1993.

.  Authors' Address

       Al Grimstad
       AT&T
       Room 1C-429, 101 Crawfords Corner Road
       Holmdel, NJ 07733-3030
       USA

       EMail:  alg@att.com

       Rick Huber
       AT&T
       Room 1B-433, 101 Crawfords Corner Road
       Holmdel, NJ 07733-3030
       USA

       EMail:  rvh@att.com

       Sri Sataluri
       AT&T
       Room 4G-202, 101 Crawfords Corner Road
       Holmdel, NJ 07733-3030
       USA

       EMail:  sri@att.com