Summary

  • RFC 1107 proposed a three-stage programme for an Internet and National Research Network White Pages service; its own status section says the proposal was not a committed community research activity.
  • The plan’s main work was comparative field trials followed by implementation and deployment preparation. Reliable people records, naming authority, access rules, clients and protocol support remained part of the problem.

A telephone directory works only when somebody collects names, keeps addresses current and decides who may see or amend each entry. RFC 1107 brought that administrative burden into the design of an Internet “White Pages” service: a way to find people and information useful for reaching them, including electronic mailboxes, calendars or file servers. Its companion idea, “Yellow Pages,” concerned finding network resources through their attributes. The distinction mattered because locating a person was not simply another host-name lookup.

Karen Sollins published “A Plan for Internet Directory Services” in July 1989. It reported a two-day meeting held in February, attended by a small group representing academic, commercial and government interests. The participants reached a consensus on how a White Pages service might be achieved in three years. The status paragraph then sets a boundary around that consensus: this was a proposal for comment, not a committed research activity of the Internet community. “Three years” described a possible programme, conditioned on strong funding and encouragement. It did not certify an approved budget, project launch or eventual deployment.

The proposed sequence was designed to postpone a final architecture choice until the options had faced a field trial. X.500 looked like the likeliest basis because it offered rich directory semantics and was becoming an international standard. Yet the memo also identified gaps in the specification and concern about its strict hierarchy. The first stage was therefore to compare at least one X.500 implementation—Quipu was the one considered ready enough at the time—with Profile and DEC’s DNANS. Profile offered descriptive, non-hierarchical naming; DNANS had designed answers for access control, replication and caching.

A second X.500 implementation was desirable so evaluators could tell whether a difficulty came from the specification or from Quipu itself.

That comparison required more than putting three server programs on a network. RFC 1107 proposed a common format for gathered naming data and shared data-management tools, so several systems could use the same records and be compared directly. The trial was also supposed to expose the work X.500 did not settle: collecting and updating information, distributing and replicating it, controlling reads and writes, protecting integrity, designing clients, managing load and supporting more than one protocol suite.

The authors recommended experiments with a limited and relatively sympathetic user community, with a separate DECnet-oriented community for DNANS. A trial could show how systems behaved under chosen conditions; it could not establish that every organization would participate or accept the eventual rules.

Scale made those conditions consequential. The memo estimated a science and research community of about ten million users, roughly ten searches per person each week and 10^8 searches per week—about 170 per second on average, with much higher peaks. It called for capacity of at least 10^7 entries and concluded that a distributed, multiple-server solution was the sensible target. These were planning estimates, not measurements of a deployed service. The same section warns that search costs could grow with system size and that caching, distribution and update patterns would affect performance.

A national-scale directory could fail as a human service even if its database answered technically valid queries: stale contact details would make it untrusted, while slow searches would discourage use.

The schedule assigned the field trials roughly the first year, implementation the second, and widespread deployment the third, while all three stages were to begin as soon as possible and overlap. Stage 2 would use the trial results to select one system or combine useful features, then produce reliable servers and varied human and program interfaces. Stage 3 was less settled. The meeting had not discussed its details. The memo lists the work still needed: collect and manage records, place servers, distribute and teach client software, manage the service, and delegate authority over sections of the namespace and their contents.

Even deployment planning was supposed to run alongside the earlier work.

That unfinished list is the most revealing part of the plan. A directory’s namespace is a control surface: someone must decide who can create an organizational branch, which server holds it, which attributes are collected, who may read them, and who corrects an error. RFC 1107 notes that organizations might reject delegating authority over their names and that individuals or employers might restrict access to personnel information. The service’s usefulness depended on cross-organization discovery, but participation depended on local control and confidence in the records.

RFC 1107 therefore records a serious planning consensus, not a historical guarantee. It turned “Internet White Pages” into a sequence of testable engineering and management questions, and put data gathering and authority beside protocol selection. The three-year target was credible only if those questions acquired owners, resources and evidence. The memo itself leaves that execution record open.

Sources