RFC 1107

Plan for Internet directory services

📅 published July 1989, from ietf

RFC 1107: A Plan for Internet Directory Services 💖

Okay bestie, let's get the basics down first 🎀. This one is from the Network Working Group and it's by K. Sollins of the M.I.T. Laboratory for Computer Science, dated July 1989. The header doesn't list a category, and it doesn't obsolete or update any other RFC. Its status is "offered for comment," which you'll see spelled out in the Status section below 🦋.

Table of Contents 📑

   1. Introduction                                                  1
        1.1. The Issues                                             1
        1.2. Project Summary                                        3
   2. Goals and Requirements for a White Pages Service              6
   3. Pre-existing Services                                         9
   4. Proposed Approach                                            11
        4.1. Stage 1: The Field Test                               12
        4.2. Stage 2: Implementation                               17
        4.3. Stage 3: Deployment                                   17
   5. Conclusion                                                   18

Status of This Memo 🌸

okay so this memo proposes a program to build a directory service for the Internet 🔥. It shares the results of a meeting that happened in February 1989, where people got together to look at what a service like this would need and what the options were ✨. This proposal is open for comment, and it is NOT a committed research activity of the Internet community, so no promises yet 🫶. Activity in this area is expected, so if you have thoughts, share them quickly 💨. Distribution of this memo is unlimited 🌈.

1. Introduction ✨

1.1. The Issues 💅

so the Internet is growing, and that's literally the whole reason we need this 🌍. As it expands (especially to support the full science research community in the U.S.), people are going to need all kinds of directory services 📚. The community keeps getting bigger and everyone wants email, which means we need a way to find people's mailboxes and other useful info. This is what's called a "White Pages" service 📖. So far there hasn't been a national or international white pages service that regular users can just use, which is kind of wild 💀. As part of building the National Research Network (NRN), this kind of service really matters. It needs to exist inside the NRN community, and it also needs to work across the line between the NRN and the wider global network community 🌐. This would help computer scientists talk to each other, and it would help scientists and engineers in other fields too 🫶. There's also a related thing called a "Yellow Pages" service, which lets you find Internet resources based on what they're like (their attributes) 🔍.

A "White Pages" service is one where you look people up so you can learn things about them and find them 🧚. At its simplest, it does what the phone book's white pages do: you give it a name and it gives you an address and a phone number 📞. On a network, there can be a lot of other kinds of location info too, like an electronic mailbox, an electronic calendar, or a file server where you could leave a file for someone 📁. The electronic white pages can also do way more fancy lookups 🔮. You could match on a bunch of attributes instead of just first and last name, and the search could reach across more than one local white pages service 🌟. There are already a bunch of naming and directory service specs and implementations out there, and they don't all do the same things or use the same mechanisms to do them 🎀.

Within the world of networking today, there are a few partial answers to the directory service problem 🦋. Some examples are the Internet Domain Naming Service (DNS), Clearinghouse, DECnet Network Architecture Naming Service (DNANS), Profile, and X.500 💜. DNS is the directory service most commonly used for host naming and mail delivery 📬. Clearinghouse and DNANS are the Xerox and DEC corporate naming services, respectively, and in both cases they were originally for mail delivery, though they've got other uses too 💼. Profile is part of Larry Peterson's work on descriptive naming in a non-hierarchical structure 🌈.

There's a CCITT recommendation called X.500 (ISO DIS 9594), and it defines a general directory service 📘. One of its main goals is the naming service that message handling (X.400) needs 💌. X.500 is still being developed, and it would need more evolution to cover everything the Internet needs from a service like this 🛠️. Even so, it's going to have a big impact on the Internet community 💥. It'll be the basis for commercial products, and it'll almost certainly be the directory service for lots of parts of the network world, which means it needs to at least interoperate with everything else 🤝. Some people are worried that even though X.500 is a recognized standard, it has gaps and limitations that will make it not good enough for the NRN's needs 😬.

Given all that, a meeting was held to look at current requirements and solutions for directory services 🗓️. This RFC shares what came out of that meeting, including the possibilities for a program of work in this area 🚀.

The meeting lasted two days, and it brought together people from academic, commercial, and government interests in directory services ☀️. They talked about different candidates for a white pages service and about the issues you run into when building any service like this 🧠. The group was kept small on purpose, with only a small number of representatives from each perspective invited 🌷. By the end of the second day, they had reached a consensus on how a white pages service could be achieved in three years ⏳. The next section sums that up 👑.

Okay bestie, picking up right where we left off 🫶✨

1.2. Project Summary 🎀

Okay so the meeting basically landed on five big takeaways, and I'm obsessed with how clean they are 💅:

The standards and implementations are close enough to being complete that it's totally reasonable to go for an NRN "White Pages" service 📖✨
We're close, but we still need to experiment with different levels of service, flesh out the standards, and actually write code 💻
We need an initial evaluation experiment before we make the final detailed plans for a production version 🧪
With strong funding and encouragement, a production service is possible in three years 🌈
It's giving urgent 🚨 We need to act now to provide a coherent solution. That means both having an impact on the evolving standards AND providing a unified, widespread solution before a plethora of differing solutions shows up 💀

Now, X.500 has clearcut drawbacks, ngl 🙈, but it was still picked as the most likely candidate directory service. The reasons? It has rich semantics and it's becoming the accepted international standard 👑. The problems are its incompleteness and its strict hierarchy, so the group wanted to explore these and get properly convinced it's viable. Their answer was to propose field trials as the project's first stage 🧪🦋. The trials would be limited to a small user community, maybe just computer science departments (they already know the problems really well, iykyk 🤓), and they'd be based on experimental or new software. They'd include experiments with at least an X.500 implementation, Profile, and DNANS 🍓. Each of these has strong points that totally must be considered in the evaluation:

X.500:  International standard, hierarchy, search rules and
        filters for searching attributed based names.

Profile:  Descriptive naming with a richer semantics for
          describing search criteria, an arbitrary network
          of servers.

DNANS:  Access control, replication, caching, hierarchy.

So the plan falls into three stages, and I'm lowkey in love with how they're laid out 🎀:

Stage 1: Field Trials. ✨

There are two aspects here. First, explore several different architectures for a white pages service, so implementations of X.500, Profile, and DNANS should be included 🧚. Second, figure out which issues are inherent in the X.500 specification versus which are just artifacts of one particular implementation. So, if possible, two implementations of X.500 should be included. Only one, Quipu, was developed enough to join a field trial at present, but others are under way and will follow 🌸. This stage must also include a careful and objective review of the field trials 🔥.

Stage 2: Implementation. 💖

This stage covers both the service and the user interfaces 🎀. The field trials could end up in a bunch of different conclusions: one of the services might fit the NRN's needs, or the group might propose a compromise that mixes the shortcomings of one service with the features of others to fix them 💅. Since X.500 is going to become the standard in other domains, an interface to X.500 will be necessary 🫶. And because all of these implementations are still under development, more implementation work is needed to get to production quality code 👑.

Some work will already be done on user interfaces, but way more will be needed in this stage to provide a variety of interfaces. Much emphasis should be placed on this in Stage 2 💜.

Stage 3: Deployment. 🚀

Full deployment of the white pages service needs info gathering to fill the directory, placing servers, distributing and training people on client code, placing and managing services, and delegating authority over the contents 😭. Data collection, some delegation of authority, and training for users of the client code would begin during the field trial. This stage starts concurrently with the other two. During the second year, detailed deployment planning has to happen, and this stage wraps up in three years, when widespread deployment should have happened 🌈.

To pull this off, the group identified these major projects, and honestly they're all so important 🧚‍♀️:

Further implementation of code for the field trials. ✨

Programs already exist for each one (Quipu, Profile, and DNANS), but modifications are likely needed. For example, each will need to be changed to use the common file format that user data will be gathered into 💻.

Design, development and evaluation of user interfaces. 🎀
Design and development of data gathering and management tools. 🛠️
Oversight and evaluation of the field trials. 🔍

Careful thought and planning must go into the trials, so we actually learn what's needed to do an evaluation and to plan the white pages service 🧠. The evaluation also has to produce a document that's both a general specification (assuming no single alternative gets chosen wholesale) and profiling information, so that later interoperability and conformance testing is possible 📝.

Detailed planning and later management of deployment. 🗺️

This includes delegating authority over parts of the namespace and deciding the shape of the namespace (who gets what sorts of names, basically) 👑. On top of that, there's continued and extended data collection and management, distributing the data, placing the code, and documentation and user education 💖.

Standards participation is an important part of the program. 🌍

It's critical that, as X.500 changes during the next 4 year study period, the United States takes a strong stand on any changes we envision 🇺🇸. We're also obligated to use the results of the largest field trials of this work effectively in the international arena 🫡. The group agreed this could take up to one half of one person's time in a year ⏰.

A task force or working group is necessary to provide a forum for communication and discussion. 💬

Finally, it's important to pursue this path now, both to architect a unified solution before a bunch of ad hoc solutions get deployed, and to give effective input into the X.500 standards work based on the field trials 🦋💜

2. Goals and Requirements for a White Pages Service 🎀

okay bestie, here's the wishlist for a white pages service 💅 the requirements are:

Functionality: the simple version is super straightforward 💖 you should be able to query the service with the name of a person and get back attributes about them, like their network mail address and phone number.
Correctness of information: ngl this one is huge 😭 info in a white pages service is useless and untrusted if nobody updates it regularly, and people won't use it if it's out of date or wrong. so this needs a set of management tools 🧰 data integrity is an especially difficult challenge here, because it's a different thing from info that's just syntactically correct.
Size: the science and research community is estimated at ten million users 🌍 and the number of organizations in the United States is on the order of ten to one hundred thousand 🏢.
Usage and query rate: okay this is where the math gets spicy 🌶️ compared to the typical phone book pattern of about one lookup a week per person, users of electronic mail in the science and research community will send more email messages than they currently make phone calls. so we estimate ten searches a week per user, covering electronic mail, paper mail, and telephone info. that's a query rate of 10**8 queries per week, or 170 per second on average, with much higher peak rates 📈 a single server could probably handle the average, but not the peaks, and it would leave little room for growth 😬 so a distributed, multiple server solution is the only one that makes sense 🦋.
Response time: this one's giving main character energy 👑 overall query behavior has to be considered carefully, especially when queries (like searches) aren't limited to tightly constrained sets of entries. the number of queries scales with the number of users (and the size of the system), so the white pages design must avoid per-query costs that depend on the size of the system. or else you get quadratic behavior in response time, and nobody wants that 💀

the response time also has to reflect the expected usage 💅 a phone book style query must respond in the waiting time tolerable to a user, perhaps ten seconds maximum, or one second desirable ⏱️ if the service is part of a larger service, then the needs of that larger service decide the response time.

Partitioned Authority: a wide variety of orgs would use this, from small and large companies to network service providers and government agencies 🏛️ a lot of them would find it unacceptable to hand over authority over their namespaces to some other organization 🙅‍♀️ so partitioned authority, including some access control, name assignment, and information management, must be possible 🔐.
Access Control: access control splits into two categories: read access control, and write or modify access control 🔑 read access control must exist for at least two reasons. first, orgs may need to limit access to the actual entries or parts of them, kinda like not wanting to hand out their corporate phone book or personnel records 📒 second, some orgs don't want to publicize their organizational structure 🙈 write and modify access control is needed because both individuals and orgs may want to prevent inadvertent or malicious creation or modification of info ✍️ access control matters for orgs who want to keep local control of personnel info, and for individuals who want to control access to private info about themselves 🫶.
Multiple Transport Protocol Support: within the next three years, you can't expect every org in the USA to switch to the OSI protocols 🙃 but some will, so it's important that any white pages service provides interfaces on top of both OSI protocols and TCP/IP 🌐 there's a partial OSI suite called ISODE that runs on top of TCP, and it's being distributed widely enough that it perhaps should be supported too 🧚.

In addition to these requirements, there are a number of features that would make a white pages service more useful ✨ these are:

Additional Functionality: descriptive naming with sophisticated searching based on attributes would support a more flexible human interface than simple name translation 💫 descriptive naming would also support a general yellow pages style service 📖

the form of a yellow pages service is less certain 🤔 one definition is a directory that stores a number of pre-computed inversions of the directory database, so entries can be retrieved very efficiently using these predetermined attributes of the data. another definition is a service that provides a very powerful set of search primitives, somewhat in common with a relational query language, to support retrieval of entries that match complex attribute conditions. in other words, one view is that a yellow pages service is built to avoid expensive searches, and the other is that it's built to facilitate general searches 🫠.

Accountability: accountability matters for both allocation and recovery of costs 💸 vendors may offer commercial directory services, so they'd be depending on accounting as part of their successful commercial ventures 💜.
Multiple Interfaces: there should be both human and programming interfaces to the white pages 🤖 for example, in addition to human lookups, mail services could effectively use a naming service that lets users include human-oriented names, instead of the current electronic mail addresses that are required, such as full domain names 📬.
Multiple Clients: several different clients should exist, both to provide for a variety of styles of human usage and to support the most commonly used computer environments (e.g., UNIX, VMS, MSDOS, OS2, MAC/OS) 💻🌈

3. Pre-existing Services 🌸

okay so this section is the tea on the other naming services people have proposed or built for naming people 💅 Every single one of these exists in some form, though a few are still experimental 🧪

Internet Domain Naming Service 🌐

The Internet Domain Name Service [6,1] is what we use today to name host machines 🖥️ It's built to handle the query rates and database sizes you get from looking up hosts during mail delivery. It gives you a hierarchy where authority gets delegated down the tree, and it has aliases too. There's no access control, and it's spread super widely across the whole Internet. It handles distribution, replication and caching, it's operational, and there's a big pile of practical experience behind it. It was originally meant to be extensible so it could cover naming people too 🫶 It runs on a bunch of different operating systems and uses the TCP/IP protocol suite.

The DECnet Network Architecture Naming Service (DNANS) 🧠

There's a pretty well-developed specification [5,3] for a naming service that's part of the DECnet architecture, and that architecture grew out of work at the DEC SRC in Palo Alto. It's designed to solve stuff X.500 hasn't gotten to yet, like access control, replication, and caching ✨ It was explicitly built for great scalability and management features 📈 It gives you a global hierarchy of names that get mapped into properties, so searching by properties or attributes can get expensive and annoying 😬 Right now it's only running on VMS using the DNA protocols, but the plan is to move it to UNIX and TCP in the next year.

Clearinghouse 🏢

This service [7,2] is part of the Xerox network environment, and it runs today as a global service for Xerox. They have serious experience running it, including the problems of scale that come with that 📦 It gives you a three-level hierarchy of names, each one mapped to sets of properties. Consistency is loose, since updates take their sweet time to propagate 🐢 Clearinghouse and the DEC service above both draw somewhat from an older Xerox service called Grapevine 🍇

Profile 🎓

Over at the University of Arizona, a project run by Larry Peterson [8] cooked up a white pages name service called Profile. It's all about descriptive naming and has seriously sophisticated lookup tools 🔍 Profile leans on another service, like the DNS, to navigate between Profile servers. That navigation service doesn't have to force the servers into a hierarchy, because Profile supports a non-hierarchical global structure 🕸️ Names are sets of attributes. Experimental implementations are running today, and the biggest site has about 10,000 entries. The code has been around long enough to get stable 💪 It's UNIX-based only and uses TCP.

X.500 👑

X.500 is the CCITT recommendation (also ISO/IEC/DIS 9594) [4] for a directory service. Because it's a CCITT recommendation, it evolves in four-year study periods, and one of those just wrapped up. So X.500 has a stable definition for the next four years 🔒

In X.500, all the objects form one single hierarchy, where each object is named relative to its parent and there's a single root at the very top 🌳 Each object is a set of attributes. You can search with a logical combination of attribute values, which is called a filter 🧩 A subset of those attributes makes up an object's distinguished name relative to its parent. The hierarchy in the CCITT recommendation is geographic at the top and organizational underneath. Alternatives can be defined too, but they aren't part of the CCITT or ISO documents. Also, there is no proposed mechanism for distributing information about other attribute types or object classes 🤷‍♀️ Like the other services, X.500 is distributed. It specifies cooperating servers, called Directory Server Agents (DSAs), that run under local control and management, and each one knows about one or more parts of the hierarchy 🗺️ The clients are called Directory User Agents (DUAs). It's defined to run on the OSI protocol stack. The Internet demos of X.500 run on top of the ISODE package, which gives you OSI transport on top of TCP 🔌

X.500 is incomplete, though. There are a bunch of areas where the standard says nothing, but they need to be specified for a successful implementation 🙈 Some examples are access control (although authentication is supported), replication, caching, the database itself (the shape of the hierarchy), tools to limit the scope and cost of searching, and database management tools.

There are currently a small number of X.500 implementations in progress at places like University College London (the Quipu project, on UNIX using ISODE), the University of British Columbia (UNIX-based, using their own full OSI suite), MIT (experimental, on a Symbolics Lisp Machine, Lisp, using TCP), The Wollongong Group (an offshoot of Quipu), The Retix Corporation, NIST, and at least several underway in Italy and Japan 🌍 There are probably others, and a number of other American corporations have talked about building their own. Each of these has to make its own call in the areas where X.500 is silent. Quipu is probably the most complete implementation of X.500 to date 👑 Its pilot version has about 20 DUAs across seven countries and an estimated 20,000 entries total.

4. Proposed Approach 🗺️

The conclusion of this report is that some form of X.500 is the most likely candidate 💖 The reasons are that it has rich semantics and it's going to become the international de facto standard 🌐 But there are serious problems with its incompleteness and its strict hierarchy 😬 So, to explore those and get convinced it's viable, the meeting attendees agreed on field trials as a first stage 🧪 Initially this would include experiments with at least one X.500 implementation (Quipu), Profile to explore a non-hierarchical structure and richer descriptive naming, and DNANS to explore some of the incomplete aspects of X.500 for which DNANS has architected solutions.

A three-stage plan, with all three stages starting coincidentally and as soon as possible, would provide such a service within the NRN ✨ The first stage should be complete in a year, the second in two, and the third in three. Stage 1 is field trials of three approaches to naming, with an emphasis on telling apart the X.500 specification from a particular implementation of X.500. Stage 2 is a more complete white pages service based on the conclusions from Stage 1. Stage 3 is widespread deployment of the Stage 2 implementation 🚀 The planning for Stage 3 isn't outlined here in detail, because that plan would be part of the proposed work to be done. If the field trials lead to the conclusion that none of the services is adequate, the plan for the rest of the work would need to be rescheduled 📅

If the Internet community is going to adopt X.500 (or any other standard), a bunch of design and management decisions have to be made, above and beyond the implementation decisions for the DSA 🛠️ There are lots of these, and some are significant, so the group recommended that this planning and management function be recognized as a distinct activity 💅

4.1. Stage 1: The Field Test 🧪

Field trials were agreed on as a valuable way to explore building a white pages service, for two reasons 🔬 First, the software is still in early stages of development or deployment. Some of it is production code but still a first release, and the rest is part of research projects. Second, it's important to learn from experience with a limited and sympathetic community 🫶 The suggested community was the computer science community, in particular computer science departments. That won't be entirely the case, since the computer science community in general doesn't use DECnet. So for experiments with DNANS, the NASA/DOE community was recommended 🚀 They'll be using DNANS anyway as they move to DECnet Phase V.

The twofold purpose of the field trials is to explore differing directory service architectures and to refine the study of X.500. Specifically, the goal is to tell the architectural aspects of X.500 apart from the features of one particular implementation of it 🧠 Initially the trials would include the Quipu implementation of X.500, Profile, and DNANS. A second implementation of X.500 should be identified and included as soon as possible 🙌 Part of the emphasis would be on gathering and maintaining naming information 📇 To make that easier, a single common file format for storing and accessing naming information, plus a single set of data management tools, was recommended, though no particular set was identified. The various directory services would need to be retrofitted to this file format. With that consistency, the services could all be co-resident, sharing files, which lets single locations take part in several parts of the field trials. That, in turn, allows for direct comparisons 📊

There are a number of issues that X.500 doesn't address, and they'd need resolving for a large-scale deployment like a white pages for the NRN 😭 In particular, these are: clients of the service; data collection and maintenance; distribution, replication and caching of information; access control, accountability, and information integrity; and support by non-OSI protocols. Each of the name services in the field trials would make decisions in these areas, just different ones. The field trials will let us evaluate these different mechanisms 🔍

Two other major issues must also be addressed: functionality and size 🎀 Functionality covers the nature of the interfaces to the service as well as the structure of the namespace (e.g., hierarchy). A discussion of size has to include not only the number of entries the service handles as a whole, but how those entries are distributed and the query and update patterns 📏

In general, all of these issues are tightly coupled, but they're separated here so we can understand the field trials and their potential effectiveness 🧩 They'd also be the issues that form the basis for the work done in Stage 2 of the project 💜

Functionality:

X.500 and DNANS both make really strong statements about how the namespace is organized 💅 In both, it's one single, absolute hierarchy, with soft links (aliases) and attribute-based naming that's useful for searching subtrees and for storing info about the objects in the tree. The searches are built from logical combinations of attribute values. Quipu implements the naming structure and search functionality exactly as X.500 specifies 🎀 Profile is the wildcard, though. It supports any form of relative names, not just hierarchical ones, plus a small programming language for writing the search functions ✨ Including Profile in the field trials means we get to test those more general facilities too 🦋

X.500 splits the service into two parts: the Directory Service Agent (DSA) and the client, which is the Directory User Agent (DUA). DUAs can be built independently of the white pages service implementation 🌸 Quipu, Profile, and DNANS each took a different approach to the presentation model for DUAs, so the three implementations will give us extra experience to work with 💜

Size:

A white pages service must be prepared to handle a minimum of 10**7 entries, although they may be distributed, plus a query rate of hundreds per second. It also has to be ready for much higher peak rates 🔥 If the address lookup that the DNS provides today is also supported by the white pages service, the query rate will be much higher. The designers of the field trials have to figure out whether that usage will be part of the final service, so it needs to be examined in the trials. If so, caching may be part of the solution 🧚 Response time for DUAs must be reasonable for a human sitting at a console 🙈 Modifications to the data should happen in reasonably short periods of time, though that could be measured in hours ⏰

The field trials must allow for experimentation under stressful conditions. The testing environment must have both large and small nodes, heavy and light query loads, and situations where reorganization can be tested. Reorganization may be as simple as moving one piece of the hierarchy to another point and handling naming conflicts in the new environment. X.500 doesn't address this issue, but the NRN will need it 😭

Distribution, replication, and caching:

These are areas where X.500 has very little to say, but a lot of work has been done in other distributed network naming services, especially the DNS and DNANS 🌈 There seems to be general agreement that distribution of naming services should be done on the basis of nodes in the naming structure, which also provide the basis for administrative partitioning. All the naming services described here support distribution, meaning the information is partitioned for placement on cooperating servers. Neither X.500 (and therefore Quipu) nor Profile is prepared to redistribute portions of the namespace for reallocating administrative responsibilities or load balancing, although this should be possible and DNANS is prepared to do so 👑 Replication is necessary for accessibility in a large-scale or global namespace, although again, X.500 doesn't address this. Quipu has taken a stand on it by defining master and slave copies of the data, which is similar to, but not the same as, the approach taken in the DNS. Caching is barely touched on in X.500 and not at all in Profile, but our experience with the DNS shows that caching is critical to effective operation of a distributed name service 💖 DNANS has an architected solution based on objects in the namespace as the unit of distribution and replication. Again, the DNANS solution should be explored in the field test environment 🦋

Access control, accountability, and integrity:

Access control and accountability require some degree of authentication. X.500 supports authentication based on an RSA public key algorithm, but it doesn't address universal registration, nor access control or accountability themselves. These are left as a local issue, although depending on the design of the system, they may have global implications. The integrity of the information in the name service isn't addressed anywhere 😳 Profile doesn't address these issues either, although it uses authentication based on UNIX authentication, involving user ids and passwords. DNANS takes a strong stand on access control and architects it in at the level of individual entries 🔐 Field trials will force these issues out into the open ✨

Structure of the naming tree:

In the deployment of the DNS, about one year was lost to arguments about the actual structure of the naming hierarchy. People form strong opinions about their name and fight for or against certain hierarchical structures 💀 The same issue will come up here, so advanced planning to deal with it is required.

In this case the problem is harder, because the hierarchy will be global. X.500 is an international standard, based on the assumption that there is only one instance of the tree, partitioned by country. The American White Pages Service, at least at its root, will probably be run by the NIST or its contractor 🇺🇸 We have to deal with the fact that in the short term, various implementations may not interwork, and we must work with NIST to support the needed services 🫶

Specific issues that come up related to the naming tree are:

How is delegation of control of the tree managed? For example, who decides which DSA holds which parts of the tree?
How is the creation of new parts of the tree (e.g., an organizational entry) controlled?

Support for Tree Search:

Regardless of the definition of the white pages service in the NRN, it will need to interface with the X.500 world. The X.500 naming hierarchy can be expected to become very large, so users need guidance to navigate the tree 🗺️ People need help finding their way to unknown parts of the namespace. Like other naming services, X.500 lets you install additional entries, aliases (similar to links in file systems), to give a user in one part of the tree an easy path to other interesting parts 🦋 By establishing a consistent policy for using alias entries, learning to navigate the tree can be made much easier, so as part of setting up the tree, these sorts of policies need to be defined 🧭

Definition of database structures:

A number of data structures need to be defined as part of setting up each of the services. These include, for example, the types of information stored for the entry about a person 📇 This information must be stored in the servers and passed to the clients, so these structures must be specified. In other words, the schema defining attributes and object classes must be specified for the NRN 📐

Load balancing:

The dynamic performance of the Internet system must be estimated so that the servers can be sized properly. Especially at the root of the tree, the query rate must be estimated carefully. Caching will have a strong influence on this, so traffic patterns depend heavily on the details of implementation 📊

Supporting multiple protocol suites:

At least three protocol suites are, and will continue to be, used in the NRN environment: DECnet, TCP/IP, and the OSI suite of protocols. Since the white pages service sits at the applications layer, it must run on top of at least these three protocol suites 🌐 It's important to understand the requirements the white pages service places on its transport protocols 🔍

By addressing these issues within the field trials, we'll be preparing for further development of Stage 2 ✨ A result of Stage 1 will be a detailed specification of the white pages service, possibly an extension to or modification of X.500. This should line up with the activities specifying the details required for implementation (known as "profiling") by the NIST Workshop for Implementors of OSI 📝 Also, in order to run the field trial, the information capture problem must be addressed, which means doing some of the preliminary work of Stage 3 🧠

4.2. Stage 2: Implementation 🌸

If the evaluation of Stage 1 concludes that some form of X.500 is acceptable, at least one of the two X.500 implementations included in the field trials should provide the basis for a production quality implementation of X.500 for general deployment 🎉 Further work will likely be needed based on the evaluations of the field trials. A production version of an implementation requires both reliable servers and a variety of clients, giving differing interfaces on a mixture of hardware and operating systems 💻

Especially because of the inclusion of Profile and DNANS, a variety of different DUAs will be explored by definition 🧩 Further investigation into DUAs should begin in parallel with, or in conjunction with, the field trials. There should be distinct DUAs for both programs and humans. There probably should also be human-user DUAs geared both to the naive user with simple usage patterns and to the more sophisticated user who wants to perform complex queries 🤓 It's also important to design DUAs that don't need a great deal of computing power, since small machines are still in use in great quantity. Much of the user community may not be able to afford expensive equipment upgrades 💜

Assuming that X.500 is deemed to be the specification of the service, the field trials will address many issues not included in X.500 as of 1989. Since it's important for the NRN to support interconnectivity beyond its own bounds, it behooves us to feed what we've learned back into the standards activities 🫶 This was identified as a separate activity because of the intellectual as well as the time commitment needed to do it effectively 🌈

4.3. Stage 3: Deployment ✨

okay so bestie, deployment is where the plan actually meets real life 🚀 and somebody has to set the schedule for rolling out the service AND coordinate everything as it happens 💅 that includes handling service problems as they pop up, which is a whole job of its own 😭

the details of deployment weren't talked about at the meeting, but literally several of the seeds for it were already planted back in Stages 1 and 2 🌱 the first seed is capturing and managing the information, and the second is DUA development 🦋 both of these MUST be included in Stage 1 so there's a usable environment for the trials 💖

also, the info captured in Stage 1 could get printed out as a hard copy of the white pages info 📄 and that could be handed out to every scientist and engineer involved. ngl that alone would be an early white pages service, iconic 👑 and during the early periods of both Stage 1 and Stage 2, planning for deployment SHOULD also be happening, so the switch into this third stage is smooth and not chaotic 🫶

5. Conclusion 🎀

the consensus from the meeting was that going down a path that included X.500 was both the correct direction AND feasible 🔥 though X.500 still needs more elaboration 🙈 there were several important items for further study:

first, there are a bunch of issues in X.500 that other naming services already solved, and the NRN SHOULD take advantage of those solutions 💜
second, there was some reservation about certain X.500 features, especially the imposition of a hierarchy for naming and the limited flexibility in descriptive naming 💀 the participants believe it is important to understand whether X.500 gives enough mechanisms to work around these problems by finding a higher common ground that includes the best features of all the naming services in the field trials 🌈
third, everyone agreed that X.500 is going to be an accepted and utilized standard in at least part of the networked community, so interfacing to it WILL be necessary 🧚

given all that, and the other reasons for choosing X.500, the consensus was that the plan above would bring the NRN and its community of users a useful and usable white pages service 🌸✨

References 📚

Austein, R., "The Internet Domain Name System", Proceedings of USA Decus, Massachusetts Institute Technology/LCS, 1987.
Demers, A., D. Greene, C. Hauser, W. Irish, J. Larson, S. Shenker, H. Sturgis, D. Swinehart, and D. Terry, "Epidemic algorithms for replicated database maintenance", Proceedings of the 6th Symposium on Principles of Distributed Computing, ACM, Vancouver, B.C., Canada, pp. 12-21, August 1987.
Digital Equipment Corporation, "DNA Naming Service Functional Specification Version 1.0.1", Order number: EK-DNANS-FS-001, Digital Equipment Corporation, 1988.
International Organization for Standardization, "Information Processing Systems - Open Systems Interconnection - The Directory", Draft Standard (In 8 parts), Also CCITT Recommendation X.500, 1988.
Lampson, B., "Desiging a Global Name Service," Proceedings of the 5th Symposium on Principles of Distribute Computing, ACM, Calgary, Alberta, Canada, pp. 1-10, August 1986.
Mockapetris, P., "Domain Names - Concept and Facilities", RFC 1034, USC/Information Sciences Institute, November 1987.
Oppen, D., and Y. Dalal, "The Clearinghouse: A Decentralized Agent for Locating Named Objects in a Distributed Environment", Tech. Rept. OPD-T8103, Xerox Corporation, Palo Alto, CA, October 1981.
Peterson, L., "Profile: A System for Naming Internet Resources", Tech. Rept. 20, Department of Computer Science, University of Arizona, June 1987.

Author's Address 🦋

Karen R. Sollins Massachusetts Institute of Technology Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139-1986

Phone: (617) 253-6006

EMail: SOLLINS@XX.LCS.MIT.EDU

📦 where this page comes from

ietf: rfc1107 1989-07
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms