Application Working Group                               Bruce Greenblatt
Internet Draft
<draft-greenblatt-defema-00.txt>
Expires in six months


                  Directory Entries From Email Address


Status of this Memo


        This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   andits 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.  Internet-Drafts may be updated, replaced, or made obsolete
   by other documents at any time. It is not appropriate to use
   Internet-Drafts as reference material or to cite them other than as a
   "working draft" or "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 ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

        Distribution of this document is unlimited.

        Abstract

        This draft describes various means for finding a user's direc-
   tory entry in a LDAP directory presuming that the user's electronic
   mail address is known. This draft does not presume any specific DIT
   structure or schema modifications.

   1.  Mechanism

        It is crucial to the success of finding services in the Internet
   that SRV records as defined in [1] be deployed. This draft shows how
   these records can be used in a straightforward manner to assist in
   the location of user records. First, assume that a users email
   address is of the form:  name@domain, and domain is of the form: dcn.
   ... .dc0.tld, where: tld is a top level domain, dc0 is an IETF
   registered domain name, and dcn through dc1 are locally administer
   subdomains of dc1, and n is greater than or equal to 0. Examples of



Greenblatt                                                      [Page 1]

Internet Draft                                                March 1997


   valid name forms are:

   -    bgg@novell.com

   -    user@scvwd.ca.us

   -    foo@bar2.bar1.bar0.za

        In order to find the directory entry that corresponds to these
   email addresses, the dc0.tld component of the addresses is first
   extracted and used in a DNS lookup for an LDAP service according to
   the mechanisms defined in [1]. If such a service is found, then an
   LDAP subtree search for a person object with a "mail" attribute EQUAL
   to the known email address is then used. It is presumed that most
   directory services will be optimized for fast lookups based on email
   addresses. If the email address is valid, and the LDAP server for the
   registered domain either has an entry for the person, or can generate
   a referal to another directory server (possibly non-LDAP, e.g. X.500,
   Whois++, etc.), then we're done, and we have (or will shortly have)
   the directory entry in question.

        On the other hand, if the search fails, there are several ave-
   nues available to help find this user.


   -    the timeLimit parameter of the session control can be raised to
        a higher limit.

   -    do a SUBSTRING search against the "mail" attribute with just the
        name component

   -    an LDAP service for the dc1.dc0.tld can be looked up, again
        according to the definitions in [1]

   -    a well known indexing [2] Internet directory service can be
        queried for the email address

        Note that it is possible that there is no directory entry for
   the user, in which case all possible lookups will fail. If the user's
   email address and directory entry are controlled by different domains
   with no links between the two domains, it will not be possible to
   find the user's directory entry from the email address initially, but
   if an Indexed Internet directory that has retrieved the user's direc-
   tory entry from the second domain, then it is likely that the Indexed
   Internet directory will be able to generate a referal to the
   appropriate domain, even though we initially started out with no
   direct information about that domain. For example, a directory ser-
   vice for a small Internet Service Provider (smallisp.com) might be



Greenblatt                                                      [Page 2]

Internet Draft                                                March 1997


   maintained by a wider area Directory Service (bigldap.org) on a con-
   tract basis. Thus, the search for an LDAP service for smallisp.com
   might fail, but the ldap lookup to the Indexing Internet Directory
   would result in a referal to bigldap.com. What is more likely to be
   the case is that smallisp.com will create an SRV record for its LDAP
   service that points to bigldap.com.

   2.  References

   []  A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the location
        of services (DNS SRV)," RFC 2052, October 1996.

   []  J. Allen, "The Common Indexing Protocol (CIP)," Internet Draft
        (work in progress) 19 November 1996.  Author's Address





































Greenblatt                                                      [Page 3]