Subject: Re: Looking for pointers..... To: Steven_Carmody@brown.edu cc: Jeff.Hodges@stanford.edu In-reply-to: Your message of Wed, 21 Oct 1998 14:35:35 -0400 Reply-to: Jeff.Hodges@stanford.edu From: Jeff.Hodges@stanford.edu X-Office: Pine Hall Rm 161; +1-650-723-2452 Date: Thu, 22 Oct 1998 10:55:11 -0700 Steve, here's a quick response to get you started. This is an in-depth topic and my/our thoughts on it seem to be constantly evolving as we learn more. > I was wondering if you could send me some pointers to information in a > couple of areas: > > 1) "conventional wisdom" on how to organize, and search, data stored in an > X.500/LDAP compatible tree. See the X.500 docs for the "conventional wisdom".. ftp://ftp.bull.com/pub/OSIdirectory/ITU/ > Obviously, there's lots of different ways to > organize the entries that represent people, groups, and things in a large > campus environment -- do you know if any attempt has been made to codify > the "accepted wisdom", or at least the issues that affect the decisions? See also David Chadwick's book. I have a ref to it on my roadmap page.. http://www.KingsMountain.com/ldapRoadmap.shtml It is more of the "conventional X.500 wisdom", btw. This wisdom is essentially that DNs are used for three things at once... - they are primary keys for entries similar to the rdbms sense. - they are human-palatable and recognizable and useful in spoken language. - they serve to map the search space; another way to say this is they provide hints about where to find stuff in the directory. We think that DNs should be used for only the first item. > 2) Do you know of any campuses that have started to define their Directory > Services strategy and architecture? and maybe have some documents > describing their thinking? Stanford and UMich. Here's a pointer to a data model of our schema.. http://www.stanford.edu/group/networking/directory/models/ DSDataModel-1998-05-01/Word_Dir_Svcs_Model_5-1-98.htm I'm working on updating & freezing this over the next few weeks. We're planning to deploy by Jan-1999. We, as opposed to conventional X.500 wisdom, ~don't~ believe that DNs must be human-palatable, or that the directory should necessarily be hierarchically arranged based on organizations. We have a very flat directory hierarchy that's partitioned depending on functional needs for access control (largely). Apps perusing the directory shouldn't have to know anything about the directory's hierarchical layout -- all searches should start at the root. Apps should be only concerned with what types of ~objects~ they deal with -- and those objects might be found anywhere in the directory. Client apps are authenticated entities (we're using Kerberos) and we use their authzID (authorization identity -- in this case, their DN) on ACLs in order to partition out who can see what types of objects. DNs for people will be based on Registry ID -- they will be immutable. You can poke at this test directory to see people entry prototypes.. > ldapsearch -h director -b dc=stanford,dc=edu objectclass=\* dn dc=Stanford, dc=edu ou=People, dc=Stanford, dc=edu regid=0000169d-b824-21d1-8300-ab400e0baa77, ou=People, dc=Stanford, dc=edu regid=1000169d-b824-21d1-8300-ab400e0baa77, ou=People, dc=Stanford, dc=edu regid=2000169d-b824-21d1-8300-ab400e0baa77, ou=People, dc=Stanford, dc=edu regid=3000169d-b824-21d1-8300-ab400e0baa77, ou=People, dc=Stanford, dc=edu We're going to use dc-based directory naming, which is a departure from conventional X.500 wisdom in that the latter promotes geo-political based naming, but we don't believe that will prove workable in the long term and so prefer to leverage off of the already globally deployed and managed DNS namespace. see.. http://info.internet.isi.edu:80/in-drafts/files /draft-hodges-ldap-dir-dn-reqs-00.txt Attached below is an ID that I'd submitted but have let expire because I've split it into two parts -- one on how we do email routing, and the other on our directory naming/layout philosophy. The latter I still need to write. The former is available here.. http://www-leland.stanford.edu/~hodges/doc /draft-ietf-asid-email-routing-su-00.txt I'm working on revising it per feedback from a couple of ietf working groups and hope to resub it 1cq99, and then try to crank out the one on naming/layout. Another little wrinkle is having a "publicly visible identifier" in people's entries -- a concept that is called the "handle" in Whois. We're going to have one, and the paper describing this analysis is here.. http://www.stanford.edu/group/networking/directory /PubliclyUniqIdentV1_0.html Here's pointers to some slideshows you may find useful... Registry & Directory Infrastructure at Stanford http://www.stanford.edu/~hodges/talks/OpenGroupApril98 /StanfordRegistryAndDirectory/index.htm Why do I need a Directory when I could use a Relational Database? http://www.stanford.edu/~hodges/talks/EMA98-DirectoryServicesRollout /Steve_Kille/index.htm Directory Services: DIT Design http://www.stanford.edu/~hodges/talks/EMA98-DirectoryServicesRollout /RommelEMA/index.htm Intro to Directories and LDAP http://www.stanford.edu/~hodges/talks/mactivity.ldap.97/deplconsid9.html ..and following pages The above is just a rough core-dump. I hope you can make some sense of it and that it helps out. Lemme know if you have questions. Jeff ----------------------------------------------------------------------------- Network Working Group Jeffrey D. Hodges INTERNET-DRAFT Stanford University 10 December 1996 X.500/LDAP-based Delivery of RFC 822 Email Messages 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. Internet Drafts may be updated, replaced, or obsoleted 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, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire in May 1997. Distribution of this draft is unlimited. 1. Abstract The "Internet X.500 Schema" [1, 2] defines an RFC-822 [3] email address attribute of a person's entry, rfc822Mailbox (aka "Mail"), but this does not address the overall set of issues involved in delivering RFC-822-based email within an administrative domain served by an X.500/LDAP-based directory service. This memo specifies a new object class and attendant attributes designed for flexible, distributed delivery of RFC-822-based email to entities represented by entries within such a directory service. 2. Motivation and Background Directory enabled email delivery has long been a goal of the overall directory service effort in the Internet [0]. Although one can claim it has been long implemented in a sort of "once removed" fashion via Jeffrey D. Hodges [Page 1] INTERNET-DRAFT X.500/LDAP-based Delivery of RFC 822 Email Dec-1996 the marriage local user account names and DNS host names via RFC-822 format addresses [3], there are no Internet standards for general purpose, directory-enabled, X.500/LDAP-based ~delivery~ of RFC-822- based email messages. RFCs exist covering the topics of directory enabled mapping between RFC-822- and X.400-based email message formats, and of directory enabled routing of X.400-based email messages [5, 6]. But, these do not cover the case of actually delivering RFC-822-based email messages to users, nor do they address the issues of providing a level of indirection for administrative domain oriented email delivery. This memo defines attributes and semantics which enable the routing and delivery of email messages addressed as "entity@domain". Additionally, it provides for more flexible and natual naming of entities. See [4] for an in-depth discussion of definitions of and requirements for uniqueness, naturalness, authenticity, permenance, and re-use of identifiers. First, the objectClass, and then the attributes are defined. A discussion of implementation and deployment experience follows. The format of definitions in this memo is as defined in [2]. 3. rfc822Delivery Object Class ( 1.3.6.1.4.1.299.1 NAME 'rfc822Delivery' SUP top STRUCTURAL MUST rfc822ForwardingMailbox MAY ( generalID $ mailAcceptingGeneralID $ preferredGeneralID $ personalPOBox ) ) This objectClass provides attributes which enable site-specific delivery of RFC-822-based email messages to an entity represented by the directory entry to which this attribute is attached. 4. Attributes This section defines the attributes belonging to the rfc822Delivery object class. 4.1. Definition of the rfc822ForwardingMailbox Attribute Jeffrey D. Hodges [Page 2] INTERNET-DRAFT X.500/LDAP-based Delivery of RFC 822 Email Dec-1996 ( 1.3.6.1.4.1.299.1 NAME 'rfc822ForwardingMailbox' 'mailDrop' DESC 'address to where admin domain MTA forwards this entry's email' EQUALITY caseIgnoreIA5Match SYNTAX IA5String ) The rfc822ForwardingMailbox attribute indicates to where a site- specific email routing & delivery system should forward rfc822-based email intendend for the person represented by this entry. 4.2. Definition of the generalID Attribute ( 1.3.6.1.4.1.299.2 NAME 'generalID' 'gID' DESC 'additional site-specific name forms for this entity' SUP name ) The generalID attribute is a set of additional indentifiers for the person represented by this entry. The precise syntax and semantics of a generalID are site-specific (within the syntactic bounds of DirectoryString). For example, the generalID may be used to parcel control of an entry's set of identifiers between a site's administration and the user represented by the entry. At Stanford, the generalID contains identifiers which are specified by the user and are typically loosely based on the person's "official name" (which we obtain from an institutional system of record, e.g. personnel or the registrar's office). These identifiers are what the person wants to be typically known as. Sytactically, we also constrain generalID values such that they may not contain blanks, or any other non-alphanumeric characters other than '.' and '-'. We use the user's "official name" as the commonName attribute value component of their entry's distinguished name. We do this because there's some administrative control and quality assurance associated with the "official name". It is unlikely to whimsically change, for instance. Then, we construct an entry's set of commonName values from the union of the "official name" value and the set of generalID values. We do this so that typical directory browsers that search on commonName (and don't know about generalID) will find the entry whether a user enters the commonName or a generalID. Jeffrey D. Hodges [Page 3] INTERNET-DRAFT X.500/LDAP-based Delivery of RFC 822 Email Dec-1996 Note that other sites may decide to implement an entirely different entry naming scheme -- e.g. they may decide to not use generalID at all. 4.3. Definition of the mailAcceptingGeneralID Attribute ( 1.3.6.1.4.1.299.3 NAME 'mailAcceptingGeneralID' 'mailAcptGID' DESC 'to which generalIDs email delivery will be accepted' SUP name ) The mailAcceptingGeneralID attribute is the subset of generalIDs for which a site-specific email delivery system should accept and deliver email for this entry. For example, at Stanford, one's "login account id" (instantiated as the "userid" attribute), is also one value of one's set of generalID values, by default, i.e. this election is outside of the user's control. The mailAcceptingGeneralID is utilized to allow a user control over which of her various name forms, as instantiated by generalID values, will accept delivery of email. The central Stanford Email Alias System will accept and route email for a given "name" only if the "name" is a valid mailAcceptingGeneralID. Note that "name" is the "local-part" of an RFC822 address being processed, e.g. the "Barbara.Jensen" portion of "Barbara.Jensen@aceindustry.com". 4.4. Definition of the preferredGeneralID Attribute ( 1.3.6.1.4.1.299.4 NAME 'preferredGeneralID' 'prefGID' DESC 'promotes preferred generalID value' SUP name ) The preferredGeneralID attribute is the generalID (from the set of generalIDs) that the person represented by this entry prefers to be known as. 4.5. Definition of the personalPOBox Attribute ( 1.3.6.1.4.1.299.5 NAME 'personalPOBox' DESC 'from where and how to access user27s email inbox' SUP url ) Jeffrey D. Hodges [Page 4] INTERNET-DRAFT X.500/LDAP-based Delivery of RFC 822 Email Dec-1996 The personalPOBox attribute describes where and how a person's mail user agent (MUA) should retrieve and/or read a person's mail. The specific string syntax of this attribute is that of a URL [10]. For example... imap://login-name@imapserver.stanford.edu/INBOX 5. Implementation and Deployment Experience to Date Close precursors of the objectClass and attributes defined in this memo (except for personalPOBox) have been in production use at Stanford University since May 1996. This system, known to users as the Stanford University Network Identifier (SUNetID) [8], allows them to promote email addresses of the form "my.name@stanford.edu" to the Internet at large, and yet actually receive their email on their system of choice within the Stanford.edu domain. The directory service is a set of replicated stand-alone LDAP server (slapd) instances [7]. The mail service is a directory-enabled version of sendmail [9], which receives email addressed to "@stanford.edu". It looks up in the directory the RFC-822 local part of addresses, using the mailAcceptingGeneralID. It then forwards the email in question based on the rfc822ForwardingMailbox attribute found in the entry returned in the lookup. This particular directory service instance is not yet being promoted as a general pupose directory. Once it is, though, users will be free to use their rfc822Mailbox (aka "mail") attribute to advertise their preferred form of their email address (see the example below). Additionally, access controls can be applied to the various attributes of users' entries so that the values of "internal" attributes, such as rfc822ForwardingMailbox, can be hidden from arbitrary queries. At the time of this writing, approximately 8000 to 10000 email messages per day are routed in this fashion. This number is small compared to the total daily email volume on the campus network, but that is due largely to the facts that this service is new and making use of it is voluntary. We expect the volume of "@stanford.edu"- addressed email to steadily grow. Approximately 26,500 people presently have directly entries. Of that, approximately 12,900 have "@stanford.edu" email delivery enabled. Directory performance has proven more than adequate. Directory queries are at the rate of only once every four seconds or so, far less than the maximum sustained "server query response" rate we obtained in testing. That rate was on the order of 12..16 queries per second. Jeffrey D. Hodges [Page 5] INTERNET-DRAFT X.500/LDAP-based Delivery of RFC 822 Email Dec-1996 6. One Example Say we have a user whose full name is Barbara Xample Jensen, which she typically writes as Barbara X. Jensen. Her domain, "aceindustry.com", sports a centralized email routing and delivery system which utilizes their general purpose LDAP/X.500-based directory service. The administrators of this infrastructure have these requirements and policies: The commonName component of people's distinguished names must come from official personnel records. Users are able to choose additional identifiers, which will be handled as generalID attribute values. The system automatically transposes embedded whitespace to "."s. GeneralID values will also be stored as CN values to facilitate queries by arbitrary browsers. Email will only be delivered to those identifiers listed in mailAcceptingGeneralID. Departments in this company have their own autonomous departmental hosts and local email environment. So users are free to set their rfc822ForwardingMailbox (aka "mailDrop") attribute themselves -- typically according to what their departmental administrators suggest. It's company policy that advertised email addresses, namely rfc822Mailbox (aka "mail"), are automatically generated by combining a users choice of preferredGeneralID with the company's domain name. Barbara has these desires about her various name forms and email delivery: She wants to be professionally known as "Barbara Jensen" and receive email addressed to "Barbara.Jensen@aceindustry.com", which is also the email address she wishes to promote at large. Additionally, she's known to her close friends and associates as "Babs Jensen" and wishes to receive email using that name form (i.e. "Babs.Jensen"), should someone use it. Her userid (and probably sercurity principle) is "bjensen", and she doesn't wish that to be known outside of her domain. She wants her email to be delivered to the host "barbsDeptHost.aceindustry.com", and she wants to use an IMAP- Jeffrey D. Hodges [Page 6] INTERNET-DRAFT X.500/LDAP-based Delivery of RFC 822 Email Dec-1996 based MUA (aka email tool) to read her mail from that machine. So, after combining Barbara's and the company administrators' requirements, Barbara's directory entry ends up looking something like this: dn: cn=Barbara X Jensen, ou=Product Development, o=Ace Industry, c=US objectClass: top objectClass: person objectClass: organizationalPerson objectClass: rfc822Delivery cn: Barbara X Jensen cn: bjensen cn: Babs.Jensen cn: Barbara.Jensen sn: Jensen title: mythical manager, product development uid: bjensen gID: bjensen gID: Babs.Jensen gID: Barbara.Jensen prefGID: Barbara.Jensen mail: Barbara.Jensen@aceindustry.com mailDrop: bjensen@barbsDeptHost.aceindustry.com mailAcptGID: Barbara.Jensen mailAcptGID: Babs.Jensen prefGID: Barbara.Jensen personalPOBox: imap://bjensen@barbsDeptHost.aceindustry.com/INBOX 7. Another Example Say we again have a user whose full name is Barbara Xample Jensen, which she typically writes as Barbara X. Jensen. Her domain, "aceindustry.com", sports a centralized email routing and delivery system which utilizes a LDAP/X.500-based directory service for this purpose, but that's all the directory service is used for. It isn't available for casual queries from arbitrary individuals. The administrators of this infrastructure have these requirements and policies: The commonName component of people's distinguished names must come from official personnel records, and be the person's "official name". Users are free to choose the local-part of their company email address, as long as it is unique. It is stored as the userid attribute value. Jeffrey D. Hodges [Page 7] INTERNET-DRAFT X.500/LDAP-based Delivery of RFC 822 Email Dec-1996 Email, received by aceindustry.com's central email system, that is addressed for a valid userid will be delivered to the email address in that entry's rfc822ForwardingMailbox attribute. People in this company have their own autonomous workstations and local email environment. So users are free to set their rfc822ForwardingMailbox (aka "mailDrop") attribute themselves and point it at the appropriate account and host. It is up to them to get it right. rfc822Mailbox (aka "mail") attributes aren't used or advertised because this directory is not intended for casual lookups by humans. Now, given this environment, Barb has these desires about her email address and delivery: Her userid on her workstation, barbsHost, is "barbj" and has been that for a long time. But she wishes to be known as "bjensen@aceindustry.com", so she sets her userid attribute to "bjensen". She sets her mailDrop value as "barbj@barbsHost.aceindustry.com". So, given this and the company administrators' requirements, Barbara's directory entry ends up looking something like this: dn: cn=Barbara X Jensen, ou=People, o=Ace Industry, c=US objectClass: top objectClass: person objectClass: organizationalPerson objectClass: rfc822Delivery cn: Barbara X Jensen sn: Jensen title: mythical manager, product development userid: bjensen mailDrop: barbj@barbsHost.aceindustry.com 8. Security considerations Security considerations are not directly discussed in this memo. Though there is some bearing on site security considerations if the attributes defined in this memo are used to facilitate some information hiding from the Internet at large. 9. Acknowledgements The SUNetID team, led by Lynn McRae, designed and implemented both Jeffrey D. Hodges [Page 8] INTERNET-DRAFT X.500/LDAP-based Delivery of RFC 822 Email Dec-1996 the SUNetID namespace service (SUNetID) and the Stanford Email Alias System (SEAS), as a part of which the rfc822Delivery objectClass and attendant attributes were designed. RL "Bob" Morgan and Booker Bense, in particular, contributed greatly to the work expressed in this document. 10. Appendix A Some of the definitions in this document refer to attribute definitions from [2]. The salient ones are reproduced here for your convenience. ( 2.5.4.41 NAME 'name' DESC 'The name attribute type is the attribute supertype from which string attribute types typically used for naming may be formed.' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{32768}' ) ( 1.3.6.1.4.1.1466.101.121.1 NAME 'url' DESC 'Uniform Resource Locator' EQUALITY caseExactIA5Match SYNTAX 'IA5String' ) 11. Appendix B Source and definitions of OIDs used in this document: stanford: enterprises.299 (iso.identifiedOrganization.dod.internet.private.enterprises.299) (1.3.6.1.4.1.299) # STANFORD OIDs ("su" == Stanford University) suAttributeType: stanford.1 suAttributeSyntax: stanford.2 suObjectClass: stanford.3 12. References [0] S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby & S. Kent, "A Strategic Plan for Deploying an Internet X.500 Directory Service", RFC 1430, February 1993. [1] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC 1274, November 1991. Jeffrey D. Hodges [Page 9] INTERNET-DRAFT X.500/LDAP-based Delivery of RFC 822 Email Dec-1996 [2] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol: Standard and Pilot Attribute Definitions", INTERNET-DRAFT, , October 1996. [3] D. Crocker, "Standard for the format of ARPA Internet text messages", RFC 822, August 1982. [4] RL "Bob" Morgan, "Stanford University Network Identity System: Scope and Requirements", Stanford University, March 1996 [5] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021 and RFC 822", RFC 1327, May 1992. [6] S. Kille, "Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses", RFC 1838, August 1995. [7] University of Michigan, "The SLAPD and SLURPD Administrators Guide", April 1996. [8] Stanford University, "SUNetID: Stanford University Network Identifier", v1.0, November 1996. [9] B. Bense, "Using LDAP with sendmail.8.8.x", October 1996. [10] C. Newman, "IMAP URL Scheme", INTERNET-DRAFT, , November 1996. 13. Author's Address Jeffrey D. Hodges Distributed Computing and Communication Systems Pine Hall Stanford University Stanford, CA 94305-4122 Email: Jeff.Hodges@Stanford.EDU Jeffrey D. Hodges [Page 10]