RFC 1308

RFC 1308: Executive Introduction to Directory Services Using the X.500 Protocol 🎀

Okay bestie, the title block first 💅 It's written by C. Weider (Advanced Network and Services) and J. Reynolds (ISI), dated March 1992. It's FYI 13 from the Network Working Group, so it's informational for the Internet community and not a standard 🧚 It doesn't obsolete or update anything, since the original doesn't list anything it replaces or changes ✨

---

Status of This Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited 🫶

Abstract 🌸

This is an Executive Introduction to Directory Services using the X.500 protocol 💖 It quickly goes over the problems with the Internet Directory Services people use right now, and then shows how X.500 fixes them 🔥

This FYI RFC came out of the Directory Information Services (pilot) Infrastructure Working Group (DISI). It was a joint effort between the User Services and the OSI Integration Areas of the Internet Engineering Task Force (IETF) 👑

---

1. Introduction ✨

The Internet is growing at a phenomenal rate, and there's no slowing down in sight 📈 Thousands of new users join every month, and new networks show up literally almost every day 🦋 It's totally possible that one day every human with a computer will be able to talk to every other one over the Internet and her sister networks 😭

But being able to talk to everyone only matters if you can find the people you need to work with 🙈 So as the Internet grows, the quality and coverage of the Directory Services available will be one of the big things that limits how well the network can be used 💅

Directory Services here doesn't just mean the stuff the phone companies' White Pages do. It also covers resource location, Yellow Pages services, mail address lookup, and so on 🍓 We'll look at what's out there today, what problems those services have, and then how the X.500 standard solves them 🧚

2. Current Services and Their Limitations 💜

To keep things short, we're only going to look at the WHOIS service and the DNS 🫶 Each one shows off a different philosophy of Directory Services, if you will 🌈

The WHOIS service is run by the Defense Data Network Network Information Center, or DDN NIC 🎀 It's currently maintained at GSI for the IP portion of the Internet. It has info about IP networks, IP network managers, a few well-known people on the Internet, and a big pile of info specifically about the MILNET systems 🔥 Since the NIC is in charge of handing out new networks from the pool of IP addresses, it can easily collect this info whenever a new network gets registered ✨ But WHOIS is big and comprehensive enough to show off a lot of the flaws of a large centralized database 💀

First, having the WHOIS database in one central place causes slow responses during peak querying times, runs into storage limits, and means the whole service goes down if the link to GSI breaks 😭

Second, centralized administration is a mess too. Any change has to be mailed off to GSI to be typed in by a human, which makes the turnaround before changes spread slower and adds another chance for the info to be wrong 🙈

These problems hit different systems to different degrees, but any system that tries to provide Directory Services through one centralized database will have them 🦋

The Domain Name Service, or DNS, holds info about how host and domain names, like "home.ans.net", map to IP addresses 🌸 That's so humans can use easy names for machines instead of strings of numbers 💖 It's maintained in a distributed way, with each DNS server providing nameservice for a limited number of domains 👑 Secondary nameservers can also be identified for each domain, so one unreachable network won't necessarily cut off nameservice 🧚 Still, even though the DNS is superlative at this, there are some problems when we try to offer other Directory Services through it 😭

First, the DNS has very limited search capabilities 💅

Second, the DNS only supports a small number of data types. Adding new ones, like photographs, would take very extensive implementation changes 💀

3. The X.500 Solution 🔥

X.500 is a CCITT protocol designed to build a distributed, global directory ✨ It offers these features:

• Decentralized Maintenance: Each site running X.500 is responsible only for its local part of the Directory, so updates and maintenance can happen instantly 🫶
• Powerful Searching Capabilities: X.500 has powerful searching facilities that let users build arbitrarily complex queries 💖
• Single Global Namespace: Much like the DNS, X.500 gives users a single homogeneous namespace 🌈 The X.500 namespace is more flexible and expandable than the DNS's 🦋
• Structured Information Framework: X.500 defines the information framework used in the Directory and allows local extensions 🎀
• Standards-Based Directory Services: Because X.500 can be used to build a standards-based directory, applications that need directory info (e-mail, automated resources locators, special-purpose directory tools) can reach a planet's worth of information in a uniform way, no matter where they're based or what they're running on 🌍✨

With just these features, X.500 is already being used to provide the backbone of a global White Pages service 👑 There's almost 3 years of operational experience with X.500, and it's used widely in Europe and Australia as well as North America 🌸 On top of that, various X.500 implementations add extra features, like photographs in G3-FAX format and color photos in JPEG format 📸 X.500 is standards based, so there are very few incompatibilities between versions, and since the namespace is consistent, any implementation can access the info in the Directory 🧚 Work is also being done on Yellow Pages services and other information resource location tasks in the Directory 💜

X.500 does have some limitations as it's currently implemented, though 😭 One price for all that search flexibility is slower searching. This happens because a) searches over part of the distributed namespace may have to traverse the network, and some implementations cache all the responses before giving them to the user, and b) some early implementations were slow at searching anyway 🙈 Another problem is that, for security reasons, only a limited amount of info goes back to the user. For example, if a search turns up 1000 hits, only 20 or so come back 💀 That number can be tuned, but someone with a big search still has to do a lot of work 💅 The Directory's performance has been increasing rapidly over the last two years, but it still can't provide real-time directory services for things like routing protocols 🔥 Work is being done to speed it up ✨

The X.500 Directory is taking us closer to the day when we'll literally have the entire world on our desktops, and X.500 will help make sure we can find whoever and whatever we need 🌈💖

4: For Further Information 🧚

If you want a more detailed technical intro to X.500 and a big bibliography, check out "Technical Overview of Directory Services Using the X.500 Protocol", by Weider, Reynolds, and Heker 📚 It's available from the NIC as FYI 14, RFC 1309 🎀 For a catalogue of X.500 implementations, look at "A Catalog of Available X.500 Implementations", ed. Lang and Wright 🦋 That one's available from the NIC as FYI 11, RFC 1292 💜

5: Security Considerations 🔒

Security issues are not discussed in this paper 🙈

6: Authors' Addresses 💌

Chris Weider
Advanced Network and Services, Inc.
2901 Hubbard, G-1
Ann Arbor, MI 48105-2437

Phone (313) 663-2482
E-mail: weider@ans.net

Joyce K. Reynolds
Information Sciences Institute
University of Southern California
4676 Admirality Way
Marina del Rey, CA 90292

Phone: (310) 822-1511
E-Mail: jkrey@isi.edu