Stanford University Network Directory Services:
Statement of Direction

Jeff Hodges, DCCS
24-Nov-96

---

Background

Our current SUNet directory services infrasturcture is comprised of..

• a Whois-based [1] directory service, which lists people and networked machines,
• the Domain Name System (DNS) which provides name-to-address mapping,
• and NetDB, which is the backend database we use to "feed" the above two systems.

We describe this infrastructure more fully on this page.

We feed our Whois-based directory service, known simply as Whois, not only from NetDB, but also from several institutional systems of record. These are Human Resource's CHRIS, the Registrar's NSI, and also from SLAC's and the Hospital's respective systems. This results in Whois having a "wide population", but it also results in users having to follow rather byzantine and difficult paths in order to maintain their information. This all contributes to having only a "fair" quality of information in the Whois-based directory.

Whois is the facet of our directory services infrastructure that users commonly interact with. However, the Whois protocol it is built upon is quite limited. It is strictly read-only, it is unauthenticated, and it is not extensible in a standardized fashion. Yet our user community has articulated the following requirements to us..

• easier updating of contact info (e.g. email address, homepage URL, etc)
• addition of new attributes to their entries (e.g. homepage URL)
• control over what information is divulged to whom

We cannot meet these requirements with our simple whois-based technology; we must use another technology base in order to do so. Our research into this problem resulted in the primary candidate being the newer, Internet- and OSI- standard directory technology known as X.500 [2]. This technology base was designed from the ground up to be a full-featured directory service featuring a read-write protocol, entry extensibility, authentication, access control, and other items. Many implementations are available, and a lightweight version of the protocol (LDAP) is well along the Internet standards track. This technology has wide industry support, including Netscape and Microsoft.

We are already utilizing this technology in production -- the Stanford Email Alias Service (SEAS) is based on it. Though, we've currently tailored the information content and source systems of this X.500/LDAP-based directory service for only supporting SEAS; i.e. it does not currently support arbitrary queries by casual users. The University's publicly-accessible SUNet directory service remains Whois (with all its limitations).

Our Planned Direction

As outlined above, the two major issue categories with Whois are its datafeed and technology base. We've always hoped that we could address both at the same time. However, there is a window of opportunity now to have other emerging systems and applications directly utilize the directory. Additionally, there is the continued need of the overall user population to have their requirements met.

Therefore, our planned direction is to supplant the Whois-based directory service with the X.500/LDAP-based technology we are currently using in production, i.e. turn it into our general-purpose directory service. It is known for now as "Dirsvc NG", short for Directory Service Next Generation, and it will have these advantages...

• Internet-standard directory access protocol: LDAP. This will facilitate directory access via the Web and for varioius applications.
• Dirsvc NG could be used as common access point for user self-maintenance of information.
• Supports authentication and centralized access control.
• Supports wider range of entries (e.g. departments) and attributes (e.g. URLs).
• Possible to support current Whois clients for backward compatibility.

The next steps...

• Add general-purpose directory info content to current production Dirsvc NG (i.e. send it the current Whois datafeed). Include a feed from the new SUNetID system to ensure widest possible population (SUNetID has people who are not in any other University system).
• Provide technology to facilitate directory utilization by other University systems (e.g. the Leland Web environment, SIN, Administrative applications, etc.). This would likely be done through a "SUNet Directory Services" API which in turn would be built on top of LDAP.
• Provide for user-maintenance of non-system-of-record info (e.g. advertised email address and homepage URL). Investigate the possibility of updating system-of-record info.
• Run Dirsvc NG and Whois in parallel for some time.
• Provide backward compatibility for users of Whois-based tools (e.g. MacWhois, PCWhois, Unix "whois" command, etc.). We will do this via a Whois-to-LDAP gateway. Note that this will not be exactly backwards compatible with respect to our current handling of whois-specific features (i.e. warts) such as..
  • wildcard handling
  • specific entry attributes. E.g. the "handle" attribute will disappear, and a URL attribute will be added.
• Eventually retire the current backend Whois services; i.e. supplant them with the whois-to-LDAP gateway.

Longer term goals...

• Research and plan for moving Dirsvc NG to a more full-featured X.500/LDAP implementation in order to support more fine-grained user requirements (e.g. defining which bits of info in one's entry are handed out to whom).
• Work with Communication Services and the maintainers of various systems-of-record on redesigning and reimplementing the directory's datafeed. This item dovetails with the nascent Registry project.

References

[1] rfc954 -- NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985.

[2] LDAP & X.500: Road Map & FAQ, Jeff Hodges. DCCS, Stanford University. 2-May-96. Periodically updated.

Related DCCS Projects

• The Registry Project Proposal
  
  
• The SUNetID Project

Back to the Directory Services page...