ASID Working Group Paul J. Leach, Microsoft INTERNET-DRAFT <draft-leach-asid-ds-email-00.txt> Expires September 25, 1997 March 25, 1997 Locating DS Entries by E-mail Address Preliminary Draft 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. This draft is not a work item of the ASID working group. 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. Please send comments to the ASID working group at <ietf-asid@umich.edu>. Discussions of the working group are archived at <URL: ftp://terminator.rs.itd.umich.edu/ietf-asid/archive>. ABSTRACT The LDAPv3 protocol (as specified in [1]) is designed to be a lightweight access protocol for directory services supporting X.500 models. In addition, in an Internet context, many of the names about which users seek information are Internet email addresses. A native LDAP based directory service for the Internet should make it convenient to process such names -- there is a huge social investment DO NOT IMPLEMENT TO THIS DOCUMENT! [Page 1]
Internet-Draft Locating LDAP Servers 03/26/97 spanning two decades to get to the point where names like "john.doe@somewhere.com" can appear in newspaper articles, TV commercials, and on billboards and millions of people understand what do with them. This draft defines a very simple convention for looking up information associated with people identified by Internet email addresses - really nothing more than identifying an existing capability of LDAP, in the hopes that the convention can become widespread. Table of Contents 1. Introduction.......................................................2 2. Specification......................................................2 3. Security Considerations............................................3 4. References.........................................................3 5. Author's address...................................................3 1. Introduction We are interested in scenarios such as the following: · What is the name (telephone number, postal address, etc.) of the person whose email address is "john.doe@somecorp.com"? · What is the name of the calendar server holding free/busy time information for the person whose email address is "john.doe@somecorp.com"? 2. Specification We show how, given a person's RFC822 [4] email address and an LDAP attribute, to construct an LDAP URL [3] to fetch that attribute. We make use of the work by Kille and Wahl [2] to convert the domain name in the email address to an X.500 DN, which forms the root of a deep search for an entry with the given email address. Let "attr" be the attribute (telephone number, postal address, calendar server, etc.) that it is desired to obtain, and "person@domain " be the RFC822 email address of the person. Suppose the translation of "domain" into an X.500 DN according to [2] is DO NOT IMPLEMENT TO THIS DOCUMENT! [Page 2]
Internet-Draft Locating LDAP Servers 03/26/97 "DC=x,DC=y". Then the canonical LDAP URL to fetch the attribute is "ldap://domain/DC=s,DC=y?attr?sub?mail=person@domain". What the above URL does is specify (via the "sub" keyword) a search of the entire subtree of the directory for the person's domain for an entry whose value for the "mail" attribute is the person's email address, requesting the return of the value of the specified attribute. A note on the attribute name "mail". In [5], we have ( 0.9.2342.19200300.100.1.3 NAME 'mail' EQUALITY caseIgnoreIA5Match SUBSTRINGS caseIgnoreIA5SubstringsMatch SYNTAX 'IA5String{256}' ) and from RFC 1274 [6] we have rfc822Mailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax (SIZE (1 .. ub-rfc822-mailbox)) ::= {pilotAttributeType 3} and data OBJECT IDENTIFIER ::= {ccitt 9} pss OBJECT IDENTIFIER ::= {data 2342} ucl OBJECT IDENTIFIER ::= {pss 19200300} pilot OBJECT IDENTIFIER ::= {ucl 100} pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1} I.e., pilotAttributeType is {pilot 1} is 0.9.2342.19200300.100.1 so {pilotAttributeType 3} is 0.9.2342.19200300.100.1.3 so the OID for 'mail' is the same as for rfc822Mailbox. It would have been more obvious if [5] had used the symbolic attribute names from RFC 1274 instead of the raw OIDs. 3. Security Considerations Putting attributes associated with people in directories accessible from over the Internet must be done with due care for maintaining the privacy of the information. LDAPv3 permits, but does not require, strong authentication and privacy protocols to be used to access the directory. Unless these are in use, it is advisable that only public information should be put in a directory accessible to the Internet. DO NOT IMPLEMENT TO THIS DOCUMENT! [Page 3]
Internet-Draft Locating LDAP Servers 03/26/97 4. References [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol(v3)". Internet-Draft <draft-ietf-asid-ldapv3- protocol.txt>, ASID Working Group, June 5, 1996. [2] S. Kille, M. Wahl, An Approach for Using Domains in LDAP Distinguished Names, Internet Draft <draft-ietf-asid-ldap-domains- 00.txt>, ASID Working Group, July 31, 1996 (Work in progress) [3] T. Howes, M. Smith, RFC 1959, An LDAP URL Format, June 1996 [4] D. Crocker, RFC 822, "Standard for the format of ARPA Internet text messages", 08/13/1982 [5] Wahl, Coulbeck, Howes & Kille, "Lightweight Directory Access Protocol: Standard and Pilot Attribute Definitions",10/23/1996, <draft-ietf-asid-ldapv3-attributes-03.txt> (Work in progress) [6] P. Barker, S. Kille, RFC 1274, "The COSINE and Internet X.500 Schema", 11/27/1991 5. Author's address Paul J. Leach Microsoft 1 Microsoft Way Redmond, Washington, 98052, U.S.A. Email: paulle@microsoft.com DO NOT IMPLEMENT TO THIS DOCUMENT! [Page 4]