RFC 1588

White Pages Meeting Report

📅 published February 1994, from ietf

RFC 1588: WHITE PAGES MEETING REPORT 🦋

Part 1 of 8, more coming bestie! ✨

okay so this is the RFC 1588 report, written by J. Postel and C. Anderson from ISI (so iconic). It's dated February 1994, and its category is Informational, which means it's just sharing info for the Internet community. The title block doesn't list anything this document obsoletes or updates. 💅

STATUS OF THIS MEMO 🌸

ngl this section is the "read the fine print" part 🙈 It says this memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited, so share it with everyone 💜

INTRODUCTION ✨

okay so this report is all about a meeting that happened at the November IETF (Internet Engineering Task Force) in Houston, TX, on November 2, 1993. The whole point was to talk about the future of white pages directory services for the Internet and different ways to build them 🧚

Here's the backstory: USC/Information Sciences Institute (ISI) ran the meeting, as proposed to the National Science Foundation (NSF). The big question was whether the X.500 directory is a practical way to give the Internet white pages service in the near future. They also wanted to find and discuss any other options. Main character energy 👑

Before the meeting, an electronic mail mailing list got set up, and people talked over email for two weeks. So the convo had already started way before anyone showed up in Houston 📧

1. EXECUTIVE SUMMARY 🔥

This report is organized around four questions, so let's go through them one by one 🍓

  1. What functions should a white pages directory perform?

There are two functions the white pages service must provide: searching and retrieving 💖

Searching is the ability to find people when you only have some fuzzy info about them. The example is "Find the Postel in southern California". Searches can often return a list of matches 🔍

The idea of indexing has been around for a while. The IN-ADDR tree in the Domain Name System (DNS) is one example. What's new is that these discussions gave everyone a fresh appreciation for how important it is. Users want fast searching across the distributed database on attributes that are different from the database structure. Pre-computed indices give them that, though only for specified searches 🌈

Retrieval means getting extra info that's connected to a person, like an address, a telephone number, an email mailbox, or a security certificate 📮

Security certificates (a type of info associated with an individual) are essential for end-to-end authentication, integrity, and privacy in Internet applications. Building secure applications on the Internet depends on a directory system that can retrieve the security certificate for an individual. For example, the privacy enhanced electronic mail (PEM) system has been developed and is ready to go into service, but it's held back by the lack of an easy-to-use directory of security certificates. Honestly so frustrating 😭 An open question is whether or not such a directory needs to be internally secure 🔐

  1. What approaches will provide us with a white pages directory?

It's evident that several technologies are and will be in use. To provide a white pages directory service that works with multiple technologies, we should promote interoperation. We should also work toward a specification of the simplest common communication form that's still powerful enough to provide the necessary functionality. This "common ground" approach aims to provide the ubiquitous WPS (White Pages Service) with high functionality and a low entry cost 🫶

  1. What are the problems to be overcome?

It must be much easier to be part of the Internet white pages than to bring up an X.500 DSA (Directory Service Agent), yet we must make good use of the X.500 DSAs that are already deployed. Simpler white pages services (such as Whois++) must be defined to promote multiple implementations. To promote reliable operation, there must be some central management of the X.500 system. A common naming scheme must be identified and documented. A set of index-servers, and indexing techniques, must be developed. The storage and retrieval of security certificates must be provided 🧩

  1. What should the deployment strategy be?

Some central management must be provided, and easy-to-use user interfaces (such as the Gopher "gateway") must be widely deployed. The selection of a naming scheme must be documented. We should capitalize on the existing infrastructure of already deployed X.500 DSAs. The "common ground" model should be adopted. A specification of the simplest common communication form must be developed. Information about how to set up a new server (of whatever kind) in "cookbook" form should be made available 🍳

RECOMMENDATIONS 💜

  1. Adopt the common ground approach. Encourage multiple client and server types, and the standardization of an interoperation protocol between them. The clients may be simple clients, front-ends, "gateways", or embedded in other information access clients, such as Gopher or WWW (World Wide Web) client programs. The interoperation protocol will define message types, message sequences, and data fields. An element of this protocol should be the use of Universal Record Locators (URLs) ✨
  2. Promote the development of index-servers. The index-servers should use several different methods both for gathering data for their indices, and for searching their indices 🌸
  3. Support a central management for the X.500 system. To get the best advantage of the effort already invested in the X.500 directory system, it is essential to provide the relatively small amount of central management necessary to keep the system functioning 👑
  4. Support the development of security certificate storage and retrieval from the white pages service. One practical approach is initially to focus on getting support from the existing X.500 directory infrastructure. This effort should also include design and development of the storage and retrieval of security certificates for other white pages services, such as Whois++ 🔐

2. HISTORY 🦋

okay so the history goes way back. In February 1989, the FRICC (Federal Research Internet Coordinating Committee) started a meeting on Internet white pages service. The discussions that followed resulted in RFC 1107 [1], which offered some technical conclusions. Widespread deployment was supposed to have happened by mid-1992 🕰️

RFC 1107: K. Sollins, "Plan for Internet Directory Services", [1].

Several other RFCs have been written suggesting deployment strategies and plans for an X.500 Directory Service. They are:

RFC 1275: S. Hardcastle-Kille, "Replication Requirements to provide an Internet Directory using X.500", [2].

RFC 1308: C. Weider, J. Reynolds, "Executive Introduction to Directory Services Using the X.500 Protocol", [3].

RFC 1309: C. Weider, J. Reynolds, S. Heker, "Technical Overview of Directory Services Using the X.500 Protocol", [4].

RFC 1430: S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby & S. Kent, "A Strategic Plan for Deploying an Internet X.500 Directory Service", [5].

Also, a current working draft submitted by A. Jurg of SURFnet, entitled "Introduction to White pages services based on X.500", describes why we need a global white pages service and why X.500 is the answer [6] 💅

The North America Directory Forum (NADF) also did some useful work setting conventions for commercial providers of X.500 directory service. Their series of memos is relevant to this discussion. (See RFC 1417 for an overview of this note series [7].) In particular, NADF standing document 5 (SD-5) "An X.500 Naming Scheme for National DIT Subtrees and its Application for c=CA and c=US" is of interest for its model of naming based on civil naming authorities [8] 🍁

Deployment of an X.500 directory service, including that under the PSI (Performance Systems International) White Pages Pilot Project and the PARADISE Project, is significant and continues to grow, albeit at a slower rate than the Internet 🌱

3. QUESTIONS 💅

Four questions were posed to the discussion list 💬

  1. What functions should a white pages directory perform?
  2. What approaches will provide us with a white pages directory?
  3. What are the problems to be overcome?
  4. What should the deployment strategy be?

3.A. WHAT FUNCTIONS SHOULD A WHITE PAGES DIRECTORY PERFORM? 🎀

The basic function of a white pages service is to find people and information about people. That's the whole vibe 🧚

When finding people, the service should work fast when searching for people by name, even if the information about location or organization is vague. When finding information about people, the service should retrieve info associated with them, like a phone number, a postal or email address, or even a certificate for security applications (authentication, integrity, and privacy). Sometimes a directory service also provides extra info about people, like a list of publications, a description of current projects, or a current travel itinerary 📚

Back in 1989, RFC 1107 detailed 8 requirements of a white pages service: (1) functionality, (2) correctness of information, (3) size, (4) usage and query rate, (5) response time, (6) partitioned authority, (7) access control, (8) multiple transport protocol support. It also listed 4 additional features that would make it more useful: (1) descriptive naming that could support a yellow pages service, (2) accountability, (3) multiple interfaces, and (4) multiple clients 🌈

Since RFC 1107 was written, many additional functions have been identified. A White Pages Functionality List is attached as Appendix 1. The problem is harder now. The Internet is much bigger, and there are many more options available (Whois++, Netfind, LDAP (Lightweight Direct Access Protocol), different versions of X.500 implementations, etc.) 🌍

A white pages directory should be flexible and have low resource requirements, and it should fit into other systems that may be in use today. It should not cost a lot, so that future transitions are not too costly. There should be the ability to migrate to something else if a better solution becomes available. There should be a way to share local directory information with the Internet in a seamless fashion and with little extra effort. And the query responses should be reliable and consistent enough that automated tools could be used 🤖✨

To be continued... 🌈

3.B. WHAT APPROACHES WILL PROVIDE US WITH A WHITE PAGES DIRECTORY? 🦋

okay so people have different needs and tastes, which means a big chunk of the final answer is gonna be about bridging all these different solutions together 🌈 we're already seeing a Gopher to X.500 gateway, a Whois++ to X.500 gateway, and the beginnings of a WWW to X.500 gateway 🫶. Gopher can talk to CSO (a phonebook service developed by University of Illinois), WAIS (Wide Area Information Server), etc. WWW can talk to everything 😭 and Netfind knows about several other protocols 🧚

Gopher and WAIS totally "achieved orbit" just by giving people a way to share and access useful info ✨ neither one had to be everywhere at once 🌸. For white pages though, if the service doesn't answer specific user queries some reasonable proportion of the time, users see it as a failure 💀. One way to get a high hit rate in an exponentially growing Internet is a proactive data gathering architecture (like what archie and Netfind do, e.g., as realized by archie and Netfind) 🔥. Replication, authentication, etc. are super important, ngl, but they're irrelevant if nobody uses the service 🙈

There are pluses and minuses to a proactive data gathering method 🎀. On the plus side, one can build a large database quickly. On the minus side, one can get garbage in the database 🗑️. One possibility is to use a proactive approach to (a) acquire data for administrative review before it's added to the database, and/or (b) check the data for consistency with the real world. Additionally, there is some question about the legality of proactive methods in some countries ⚖️

One solution is to combine existing technology and infrastructure to provide a good white pages service, based on a X.500 core plus a set of additional index/references servers 💖. DNS can be used to "refer" to the appropriate zone in the X.500 name space, using WAIS or Whois++, to build up indexes to the X.500 server which will be able to process a given request. These can be index-servers or centroids or something new 🧩

Some X.500 purists might feel this approach muddles the connecting fabric among X.500 servers, since the site index, DNS records, and customization gateways are all outside of X.500 😤. On the other hand, making X.500 reachable from a common front-end would give sites added incentive to install X.500 servers 🌟. Plus, it provides an immediate (if interim) solution to the need for a global site index in X.500. Since the goal is to have a good white pages service, X.500 purity is not essential 💅

It may be that some parts of the white pages problem can't be addressed without "complex technology" 🤔. A solution that lets the user climb up the ladder of complexity according to taste, perceived need, and available resources may be a much healthier approach 🪜. However, experience to date with simpler solutions (Whois++, Netfind, archie) shows that a good percentage of the problem of finding information can be handled with simpler approaches. Users know this and will resist attempts to make them pay the full price for the full solution when it isn't needed 🙅‍♀️. Managers and funders may be concerned with how complex the technology is, but users are generally more concerned with the quality and ease of use of the service ✨. A danger in supporting a mix of technologies is that the service becomes so variable that the loose constraints of weak service in some places make users see the whole system as too loose and weak 😬

Some organizations won't operate services they can't get for free or try cheaply before investing time and money 💸. Some people prefer a bare-bones, no-support solution that only gives them 85 percent of what they want 🥲. Paying for the service wouldn't be a problem for many sites, once the value of the service has been proven 💜. Although there is no requirement to provide free software for everybody, we do need viable funding and support mechanisms. A solution cannot simply be dictated with any expectation that it will stick 🙃

Finally, are there viable alternative technologies to X.500 now, or do we need to design something new? What kind of time frame are we talking about for development and deployment? And will the new technology be extensible enough to provide for the as-yet-unimagined uses that directory services will be required to handle 5 years from now? And will this directory service ultimately provide more capabilities than just white pages? 🔮

3.C. WHAT ARE THE PROBLEMS TO BE OVERCOME? 🧩

okay bestie, there are two classes of problems to dig into: technology issues and infrastructure 💖

TECHNOLOGY:

How do we populate the database and make software easily available? 🤷‍♀️

Many people suggest that a public domain version of X.500 is necessary before a widespread X.500 service is operational 📣. The current public domain version is said to be difficult to install and to bring into operation, but many organizations have successfully installed it and have had their systems up and running for some time 💪. Note that the current public domain program, quipu, is not quite standard X.500, and is more suited to research than production service 🧪. Many people who tried earlier versions of quipu abandoned X.500 because of its costly start-up time and inherent complexity 💀

The ISODE (ISO Development Environment) Consortium is currently developing newer features and is addressing most of the major problems 🛠️. However, there's a perception that the companies in the consortium have yet to turn these improvements into actual products, though the consortium says the companies have commercial off-the-shelf (COTS) products available now 🤨. The improved products are certainly needed now, since if they're too late to be deployed, other solutions will be implemented in lieu of X.500 ⏰

The remaining problem with an X.500 White Pages is having a high quality public domain DSA 🎯. The ISODE Consortium will make its version available for no charge to Universities (or any non-profit or government organization whose primary purpose is research), but if that leaves a sizeable group using the old quipu implementation, then there is a significant problem 🚨. In such a case, an answer may be for some funding to upgrade the public version of quipu 💰

In addition, the quipu DSA should be simplified so that it's easy to use 🎀. Tim Howes' new disk-based quipu DSA solves many of the memory problems in DSA resource utilization 🧠. If someone fixes the DSA resource utilization problem, makes it fairly easy to install, makes it freely available, and publishes a popular press book about it, X.500 may have a better chance of success 📚✨

The client side of X.500 needs more work 🖥️. Many people would rather not put in the extra effort to get X.500 up. X.500 has a steep learning curve 📈. There's a perception that the client side also needs a complex Directory User Interface (DUI) built on ISODE, yet there are alternative DUIs, such as those based on LDAP 🌸. Another aspect of the client side is that access to the directory should be built into other applications like gopher and email (especially for accessing PEM X.509 certificates) 🔐

We also need data conversion tools to make the transition between different systems possible. For example, NASA had more than one system to convert 🚀

Searching abilities for X.500 need to be improved. LDAP is a great help, but the following capabilities are still needed 🔍:

  • commercial grade, easily maintainable servers with back-end database support.
  • clients that can do exhaustive search and/or cache useful information and use heuristics to narrow the search space in case of ill-formed queries.
  • index servers that store index information on a "few" key attributes that DUIs can consult in narrowing the search space. How about index attributes at various levels in the tree that capture the information in the corresponding subtree?

Work still needs to be done with Whois++ to see if it will scale to the level of X.500 🤞

An extended Netfind is attractive because it would work without any additional infrastructure changes (naming, common schema, etc.), or even the addition of any new protocols 🦋

INFRASTRUCTURE:

The key issues are central management and naming rules 👑

X.500 isn't run as a service in the U.S., so those using X.500 in the U.S. can't be assured of the reliability of root servers 😬. X.500 cannot be taken seriously until there is some central management and coordinated administration support in place. Someone has to be responsible for maintaining the root, and this effort is comparable to maintaining the root of the DNS 🌐. PSI provided this service until the end of the FOX project [9]. Should they receive funding to continue this? Should it be a commercial enterprise? Or should this function be added to the duties of the InterNIC? 🤔

New sites need help getting their servers up and linked to a central server 🫶

There are two dimensions along which to consider the infrastructure: 1) general purpose vs. specific, and 2) tight vs. loose information framework 🧭

General purpose leads to more complex protocols. The generality is an overhead, but it gives the potential to provide a framework for a wide variety of services 🌈. Special purpose protocols are simpler, but they may lead to duplication or restricted scope 🙈

A tight information framework costs effort to coerce existing data and to build structures. Once it's in place, it gives better manageability and more uniform access ✨. The tight information framework can be subdivided further into: 1) the naming approach, and 2) the object and attribute extensibility 🧩

Examples of systems placed in this space are: a) X.500 is a general purpose and tight information framework, b) DNS is a specific and tight information framework, c) there are various research efforts in the general purpose and loose information framework, and d) Whois++ employs a specific and loose information framework 🗺️

We need to look at which parts of this spectrum we need to provide services for. This may lead to concluding that several services are desirable 💜

3.D. WHAT SHOULD THE DEPLOYMENT STRATEGY BE? 🎀

okay bestie, no solution is gonna pop up just because somebody wrote really good specs 💅 it has to fit the way the Internet actually adopts tech. look at WAIS and Gopher, they blew up by following the same vibe:

  • A small group goes off and builds a piece of software that supplies badly needed functionality at feasible effort to providers and users.
  • The community rapidly adopts the system as a de facto standard.
  • Many people join the developers in improving the system and standardizing the protocols.

so what can this report do to help make that happen for Internet white pages? 🤔

Deployment Issues. 🧩

  • a strict hierarchical layout is not suitable for all directory applications, so we should not force fit it 🙅‍♀️
  • a typical organization's hierarchical information is itself often proprietary, so they may not want to divulge it to the outside world 🔒

it will always be true that institutions (not just commercial ones) will always have some information they do not wish to display to the public in any directory 🙈 this is especially true for institutions that want to protect themselves from headhunters and sales personnel 💀

  • there is the problem of multiple directory service providers, but see NADF work on "Naming Links" and their "CAN/KAN" technology [7] ✨

a more general approach, such as using a knowledge server (or a set of servers), might be better 🧠 the knowledge servers would have to know about which server to contact for a given query, and thus may refer to either service provider servers or directly to institution-operated servers. the key problem is how to collect the knowledge and keep it up to date 😭 there are some questions about the viability of "naming links" without a protocol modification.

  • guidelines are needed for methods of searching and using directory information 📚
  • a registration authority is needed to register names at various levels of the hierarchy, to ensure uniqueness or adoption of the civil naming structure as delineated by the NADF 📝

it is true that deployment of X.500 has not seen exponential growth the way other popular services on the Internet have 😩 but rather than abandoning X.500 now, these efforts (which are attempting to address some of the causes) should continue to move forward. certainly installation complexity and performance problems with the quipu implementation need solutions 🛠️ and these problems are being worked on.

one concern with the X.500 service has been the lack of ubiquitous user agents. very few hosts run the ISODE package 🥲 the use of LDAP improves this situation. the X.500-gopher gateway has had the greatest impact on providing wide-spread access to the X.500 service, and since adding X.500 as a service on the ESnet Gopher, the use of the ESnet DSA has risen dramatically 📈

another serious problem affecting the deployment of X.500, at least in the U.S., is the minimal support given to building and maintaining the necessary infrastructure since the demise of the Fox Project [9] 😤 without funding for this effort, X.500 may not stand a chance in the United States.

4. REVIEW OF TECHNOLOGIES ✨

there are now many systems for finding information 🔍 some of these are oriented to white pages, some include white pages, and others currently ignore white pages. in any case, it makes sense to review these systems to see how they might fit into the provision of an Internet white pages service 💜

4.A. X.500 🦋

okay so X.500 is giving "gorgeous on paper, exhausting in real life" 💅 ngl it has SO many good things. It's flexible, distributed, secure, way better than paper directories, and applications can use it, not just humans. It's designed as a uniform database facility with replication, modification, and authorization. Because it's distributed, it's literally built for a large global White Pages directory 🌍 In principle the searching is ✨chef's kiss✨: you can search at any level or in any subtree of the DIT (Directory Information Tree). There are DUIs for all types of workstations, and it's an international standard 💜 In theory X.500 can give vastly better directory service than other systems. In practice though, X.500 is difficult, too complicated, and inconvenient to use 💀 It should provide a better service. X.500 can be used to provide a white pages service, although some of its features might not be needed just for white pages 🎀

There are three reasons X.500 deployment has been slow, and they're mostly the same reasons people don't like it 😭

  1. The available X.500 implementations (mostly quipu based on the ISODE) are very large and complicated software packages that are hard to work with. This is partly because they solve the general X.500 problem, rather than the subset needed to provide an Internet white pages directory. So a chunk of the code and complexity is effectively unused 🙈

The LDAP work has basically eliminated this concern on the client side, since LDAP is both simple and lightweight 🧚 Yet the complexity problem still exists on the server side, so people keep having trouble bringing up data for simple clients to access.

It's been suggested that the complexity in X.500 comes from the protocol stack and the ISODE base. If that's true, then LDAP may be simple because it uses TCP directly without the ISODE base. An X.500 server that took the same approach might also be "simple," or at least simpler. Also, the difficulty of getting an X.500 server up may be about finding the data to put in it, so it could be a general data management problem rather than an X.500-specific one 🤔

There is some evidence that eventually a large percentage of directory service use may come from applications rather than direct user queries. For example, there are mail-user-agents that are X.500 capable, with an integrated DUA (Directory User Agent) 📬

  1. You have to "know a lot" to get a directory service up and running with X.500 🥴 You have to know about object classes and attributes to get your data into X.500. You have to get a distinguished name for your organization and come up with an internal tree structure. You have to contact someone before you can "come online" in the pilot. It's not like gopher, where you type "make," tell a few friends, and you're up and running 🙃

Note that a gopher server is not a white pages service. As noted elsewhere in this report, there are a number of issues that apply to white pages service that gopher doesn't address.

Some of these problems could be alleviated by putting better procedures in place. Getting connected to X.500 shouldn't be any harder than getting connected to the DNS, for example. However, a certain amount of complexity may be inherent in directory services. Just compare Whois++ and X.500:

  • X.500 has object classes. Whois++ has templates.
  • X.500 has attributes. Whois++ has fields.
  • X.500 has distinguished names. Whois++ has handles.
  1. Getting data to populate the directory, converting it into the proper form, and keeping it up-to-date turns out to be a hard problem 😤 Often this means talking to the administrative computing department at your organization.

This problem exists regardless of the protocol used. It should be easy to access this data through the protocol you're using, but that says more about implementations than it does about the protocol. Of course, if the only X.500 implementation you have makes it really hard to do, and the Whois++ implementation you have makes it easy, it's hard for that not to reflect on the protocols 🫠

The fact that sites like University of Michigan, University of Minnesota, Rutgers University, NASA, LBL, etc. are running X.500 in serious production mode shows that the problem has more to do with the current state of X.500 software and procedures. It takes a lot of effort to get it going. The level of effort required to keep it going is relatively very small ✨

The yellow pages problem is not really a problem. If you look at it the traditional phonebook-style yellow pages way, then X.500 can do the job just like the phone book does. Just organize the directory based on different (i.e., non-geographical) criteria. If you want to "search everything," then you need to prune the search space. To do this you can use the Whois++ centroids idea, or something similar. But this idea is as applicable to X.500 as it is to Whois++. Maybe X.500 can use the centroids idea most effectively 🦋

Additionally, it should be noted that there is not one single Yellow Pages service. According to the type of query, there could be several, such as querying by role, by location, or by email address 🗺️

No one is failing to run X.500 because they perceive it fails to solve the yellow pages problem. The reasons are more likely one or more of the three above 🙌

X.500's extra complexity is paying off for University of Michigan. They started with just people information in their tree. Once that infrastructure was in place, it was easy for them to add more things, like mailing lists and email groups, yellow pages applications such as a documentation index, a directory of images, and so on 📚

The ESnet community is using X.500 right now to provide a White Pages service. Users succeed every day in searching for information about colleagues given only a name and an organizational affiliation, and yes, they do load data into X.500 from an Oracle database 💾

LBL finds X.500 very useful 🛰️ They can look up DNS information, find what Zone a Macintosh is in, look up departmental information, view the current weather satellite image, and look up people information.

LDAP should remove many of the complaints about X.500. Implementing a number of LDAP clients is very easy and has all the functionality needed. Perhaps DAP should be scrapped 😤

Another approach is interfacing X.500 servers to WWW (the interface is sometimes called XWI). Using the mosaic program from the NCSA, one can access X.500 data 🌐

INTERNET X.500 🌈

The ISO/ITU may not make progress on improving X.500 in the time frame required for an Internet white pages service. One approach is to have the Internet community (e.g., the IETF) take responsibility for developing a subset or profile of the part of X.500 it will use, and for developing solutions for the ambiguous and undefined parts of X.500 that are necessary to provide a complete service.

Tasks this approach might include are:

  1. Internet (IETF) control of the base of the core service white pages infrastructure and standard.
  2. Base the standard on the 1993 specification, especially replication and access control.
  3. For early deployment, choose which parts of the replication protocol are really urgently needed. It may be possible to define a subset and to make it mandatory for the Internet.
  4. Define an easy and stable API (Application Program Interface) for key access protocols (DAP, LDAP).
  5. Use a standard knowledge model.
  6. Make sure that high performance implementations will exist for the most important servers, roles principally for the upper layers of the DSA tree.
  7. Make sure that servers will exist that will be able to efficiently get the objects (or better the attributes) from existing traditional databases for use at the leaves of the DSA tree.

4.B. WHOIS++ 💅

The very first discussions of this protocol started in July 1992. In less than 15 months there were 3 working public domain implementations, at least 3 more on the way, and a Whois++ front-end to X.500. On top of that, the developers working on the resource location system infrastructure (URL/URI) have committed to implementing it on top of Whois++ because of its superior search capabilities 🔥

Some of the main problems with getting a White Pages directory going have been: (1) search, (2) lack of public domain versions, (3) implementations are too large, (4) high start up cost, and (5) the implementations don't make a lot of sense for a local directory, particularly for small organizations. Whois++ can and does address all these problems very nicely. 🎀

Search is built into Whois++, and there is a strong commitment from the developers to keep this a high priority 🔍

The protocols are simple enough that someone can write a server in 3 days, and people have done it 🤯 If the protocols stay simple, it will always be easy for someone to whip out a new public domain server. In this respect, Whois++ is much like WAIS or Gopher 🧚

The typical Whois++ implementation is about 10 megabytes, including the WAIS source code that provides the data engine. Even assuming a rough doubling of the code as additional necessary functionality is built in, that's still quite reasonable, and it compares favorably with the available implementations of X.500 💖 In addition, WAIS is disk-based from the start and is optimized for local searching. Thus, this requires only disk storage for the data and the indexes. In a recent test, Chris Weider used a 5 megabyte source data file with the Whois++ code. The indices came to about another 7 megabytes, and the code was under 10 megabytes. The total is 22 megabytes for a Whois++ server. 📦

The available Whois++ implementations take about 25 minutes to compile on a Sun SPARCstation IPC. Indexing a 5 megabyte data file takes about another 20 minutes on an IPC. Installation is very easy 🙌 In addition, since the Whois++ server protocol is designed to be only a front-end, organizations can keep their data in any form they want 🍓

Whois++ makes sense as a local directory service 🏡 The implementations are small, install quickly, and the raw query language is very simple. The simplicity of the interaction between the client and the server makes it easy to experiment with and to write clients for, something that wasn't true of X.500 until LDAP. In addition, Whois++ can be run strictly as a local service, with integration into the global infrastructure done at any time 🦋

It is true that Whois++ is not yet a fully functional White Pages service, and it requires a lot of work before it will be. However, X.500 is not that much closer to the goal than Whois++ is 🙈

Work needs to be done on replication and authentication of data. The current Whois++ system does not lend itself to delegation. Research is still needed to improve the system and see if it scales well 💜

4.C. NETFIND 🔍

Okay so the white pages service with the most coverage on the whole Internet right now is Mike Schwartz' Netfind 🦋 ngl it's giving main character energy. Netfind works in two stages: 1) find out where to ask, and 2) start asking.

Stage one runs on a database of netnews articles, UUCP maps, NIC WHOIS databases, and DNS traversals, and that's what maps organizations and localities to domain names. Stage two is all the finger queries, Whois queries, smtp expns and vrfys, and DNS lookups 💅

The key feature of Netfind is that it's proactive ✨ It doesn't need the sysadmin to bring up a new server, stuff it with all kinds of information, keep that info in sync, worry about updates, etc. It just works 🫶

A suggestion was made that Netfind could be used to populate the X.500 directory. A tool might run a series of Netfind queries and make the matching X.500 entries as it goes, so X.500 entries would be "discovered" as people look for them using Netfind 🧚 Others don't think this is feasible 💀

Another (less exciting, tbh) merger of Netfind and X.500 is to have Netfind add X.500 as one of the places it looks for organizations (and people) 🌸

A search can lead you to where a person has an account (e.g., law.xxx.edu) and then… you find out the DNS services for that domain have a problem, or the finger service is unavailable, or the machines are not running Unix (there are lots of VMS machines and IBM mainframes still out there 🙈). In addition, there are security gateways 🔒 The trends in computing are toward powerful portables and mobile computing, and hence Netfind's approach may not work. However, Netfind proves to be an excellent yellow-pages service for domain information in DNS servers. Give it a set of keywords and it lists a set of possible domain names 🍓

Suppose we store a pointer in DNS to a white-pages server for a domain. We can use Netfind to come up with a list of servers to search, query those servers, then combine the responses. However, we need a formal method of gathering white-pages data. Informal methods won't work and may even get into legal problems 🚫

The user search phase of Netfind is a short-term solution to providing an Internet white pages. For the longer term, the site discovery part of Netfind is more relevant, and more work has been put into that part over the past 2 years than into the user search phase 🔥

Given Netfind's "installed customer base" (25k queries per day, users in 4875 domains in 54 countries), that is a LOT of besties 👑 One approach that might make sense is to use Netfind as a migration path to a better directory, and gradually phase Netfind's user search scheme out of existence. The idea of putting a record in DNS that points to the directory service to search at a site is a good start 💖

One idea for further development is to have the DNS record point to a "customization" server that a site can install to tailor the way Netfind (or whatever replaces Netfind) searches their site. This would give sites a choice of degrees of effort and levels of service. The least common denominator is what Netfind presently does: DNS/SMTP/finger. A site could upgrade by installing a customization server that points to the best hosts to finger, or that says "we don't want Netfind to search here" (if people are sufficiently concerned about the legal/privacy issues, the default could be changed so that searches must be explicitly enabled). The next step up is to use the customization server as a gateway to a local Whois, CSO, X.500, or home grown white pages server. In the long run, if X.500 (or Whois++, etc.) really catches on, it could subsume the site indexing part of Netfind and use the above approach as an evolution path to full X.500 deployment. However, other approaches may be more productive 🤷‍♀️ One key to Netfind's success has been not relying on organizations to do anything to support Netfind, however the customization server breaks this model 😭

Netfind is very useful. Users don't have to do anything to wherever they store their people data to have it "included" in Netfind. But just like archie, it would be more useful if there were a more common structure to the information it gives you, and therefore to the information contained in the databases it accesses. It's this common structure that we should be encouraging people to move toward 🎀

As a result of suggestions made at the November meeting, Netfind has been extended to make use of URL information stored in DNS records. Based on this mechanism, Netfind can now interoperate with X.500, WHOIS, and PH, and can also allow sites to tune which hosts Netfind uses for SMTP or Finger, or restrict Netfind from searching their site entirely 🌈

4.D. ARCHIE 📂

Archie is a success because it's a directory of files that are accessible over the network. Every FTP site makes a "conscious" decision to make its files available for anonymous FTP over the network. The mechanism archie uses to gather the data is the same one used to transfer the files, so the success rate is near 100% 💯 In a similar vibe, if Internet sites make a "conscious" decision to make white-pages data available over the network, it's possible to link those servers to create a world-wide directory, such as X.500, or build an index that helps isolate the servers to be searched, Whois++. Users don't have to do anything to their FTP archives to have them included in archie. But everybody recognizes that it could be more useful if only there were some more common structure to the information, and to the information contained in the archives. Archie came after the anonymous FTP sites were in wide-spread use. Unfortunately for white-pages, we are building tools, but there is no data 😩

4.E. FINGER 👀

The Finger program lets you get either information about an individual with an account, or a list of currently logged in users, from a host running the server. It can be used to check a suggestion that a particular individual has an account on a particular host. This does not provide an efficient method to search for an individual 🙃

4.F. GOPHER 🕳️

A "gateway" between Gopher and X.500 has been created so that one can examine X.500 data from a Gopher client. Similar "gateways" are needed for other white pages systems 🧩

4.G. WWW 🕸️

One extension to WWW would be an attribute type for the WWW URI/URL, with the possibility for any client to request from the X.500 server (1) either the locator (so the client would decide whether or not to access the actual data), or (2) for clients not capable of accessing this data, the data itself (packed) in the ASN.1 encoded result.

This would give access to potentially any piece of information available on the network through X.500, and in the white pages case, to photos or voice messages for persons 📸🎙️

This solution is preferable to one that stores this multimedia information directly in the directory, because it allows WWW capable DUIs to access directly any piece of data, no matter how large. This work on URIs is not WWW-specific 🌍

5. ISSUES 🌷

5.A. DATA PROTECTION 🔐

Outside of the U.S., nearly all developed countries have rather strict data protection acts (mostly to ensure privacy) that govern any database of personal data 🛡️

It is mandatory for the people in charge of such white pages databases to have full control over the information that can be stored and retrieved in such a database, and to provide access controls over the information that is made available.

If modification is allowed, then authentication is required. The database manager must be able to prevent users from making available unallowed information.

When we're dealing with personal records, the issues are a little more involved than exporting files. We can not allow trawling of data, and we need access controls so that several applications can use the directory, and hence we need authentication 🚧

X.500 might have developed faster if security issues weren't part of the implementation. There's tension between quick lightweight implementations and the attempt to operate in a larger environment with business issues incorporated. The initial belief was that data is owned by the people who put the data into the system. However, most data protection laws appoint the organizations holding the data responsible for the quality of the data of their individuals. Experience also shows that the people most affected by inaccurate data are the people trying to access the data. These problems apply to all technologies 😤

5.B. STANDARDS 📏

Several types of standards are needed: (1) standards for interoperation between different white pages systems (e.g., X.500 and Whois++), (2) standards for naming conventions, and (3) and standards within the structured data of each system (what fields or attributes are required and optional, and what their data types are) 📋

The standards for interoperation may be developed from the work now in progress on URLs, with some additional protocol developed to govern the types of messages and message sequences 🔗

Both the naming of the systems and the naming of individuals would benefit from consistent naming conventions. The use of the NADF naming scheme should be considered 🏷️

When structured data is exchanged, standards are needed for the data types and the structural organization. In X.500, a lot of effort has gone into defining various structures or schemas, and yet few standard schemas have emerged 🙄

There's a general consensus that a "cookbook" for Administrators would make X.500 implementation easier and more attractive. These are essential for getting X.500 into wider use. It's also essential that other technologies, such as Whois++, Netfind, and archie, have complete user guides available 📖💜

5.C. SEARCHING AND RETRIEVING 🔍

Okay so the big complaint 😭, especially from people who were obsessed with a centralized database (like the InterNIC Whois service), is that you can't just search for all the John Doe's in the whole world anymore 💀. Since the directory has to be distributed, there is literally no way to answer that question without paying extra cost 💸.

This is a problem with any distributed directory. You just can't search every leaf in the tree in any reasonable amount of time 🙅‍♀️. You need some mechanism to limit how many servers have to be contacted, and the traditional move is hierarchy 🌳. That means the searcher needs some idea of how the directory is structured. It also runs into one of the classic problems with hierarchical databases: if you need to search on a characteristic that is NOT part of the hierarchy, you're back to searching every node in the tree, or you can search an index (see below) 🫠.

So basically:

  • the larger the directory the more need for a distributed solution (for upkeep and managability).
  • once you are distributed, the search space for any given search MUST be limited.
  • this makes it necessary to provide more information as part of the query (and thus makes the directory harder to use).

Any directory system can be used in a way that makes searching less than easy 🙃. With a User Friendly Name (UFN) query, a user can usually find an entry (presuming it exists) without a lot of trouble ✨. Using additional listings (as per NADF SD-5) helps hide geographic or civil naming infrastructure knowledge requirements 🎀.

Search power is a function of DSA design in X.500, not a function of Distinguished Naming 💅. Search can be aided by adding non-distinguishing attributes in X.500, and by using the NADF Naming Scheme it's possible to lodge an entry anywhere in the DIT that you believe is where people will look for it 🗂️.

One approach to the distributed search problem is to create another, less distributed database to search, like an index 📚. You do this by running a (non-interactive) pre-search and collecting the results in an index. When a user wants a real time search, they first search the index to find pointers to the right data records in the distributed database 🧭. One example of this is building centroids that contain index information. There may be a class of servers that hold indices, called "index-servers" 🖥️.

5.D. INDEXING 📇

The move for fast searching is indexing, no cap 🔥. You pre-compute an index of people from across the distributed database and hold that index on an index server. When a user wants to search for someone, they contact the index-server first. The index-server searches its index data and returns a pointer (or a few pointers) to the specific databases that hold data on people matching the search criteria 🎯. Other systems doing something comparable are archie (for FTP file archives), WAIS, and Netfind 🦋.

5.E. COLLECTION AND MAINTENANCE 🧹

The information has to be "live," meaning it actually gets used 🌸. A good way to make sure of that is to use the data (maybe locally) for something other than white pages, because if it isn't being used, most people won't bother keeping it up to date 🥱. The phone book's white pages have an advantage here: the local phone company is in contact with the listee monthly through the billing system. If the address is wrong, bills don't get delivered, and that's feedback that the address needs fixing 📬. The phone number has even better contact, since the local phone company must know it for their basic service to work properly 📞. This is the part of directory functionality that pushes toward a distributed directory system for the Internet 🌈.

One approach is to use existing databases to supply the white pages data 🗄️. It'd then be helpful to define a particular use of SQL (Structured Query Language) as a standard interface language between those databases and the X.500 DSA or another white pages server 🧩. After that, you either need the directory service to access the existing database using an interface language it already knows (e.g., SQL), or you need tools that periodically update the directory database from the existing database 🔄. Some sort of "standard" query format (and protocol) for directory queries, with "standard" field names, will be needed to make this work in general 💜. Honestly, both X.500 and Whois++ kind of provide this ✨. The catch is that this approach means customizing every existing database so it can talk to the "standard" query format 😮‍💨.

Some people strongly believe the white pages service needs to be built from the bottom up, with each organization supplying and maintaining its own information 🏢. They also think that information has to be the same -- or a portion of the same -- information the organization uses locally. Otherwise the global information will be stale and incomplete 🥀.

One way to make this work is to distribute software that:

  • is useful locally,
  • fits into the global scheme,
  • is available free, and
  • works on most Unix systems.

With respect to privacy, it would be good for the local software to have controls that let you put company sensitive information into the locally maintained directory and export only a portion of it to outsiders 🔐🫶.

5.F. NAMING STRUCTURE 🏷️

We need a clear naming scheme that can associate a name with attributes without any possible ambiguities 🙌. It has to stay stable over time but still be able to cope with changes 🔄. It should have a clear idea of naming authorities and be able to store information required by authentication mechanisms (e.g., PEM or X.509 certificates) 🔑.

The NADF is working to establish a National Public Directory Service 🇺🇸. The plan is to use existing Civil Naming Authorities to register entry owners' names, and to handle the shared-entry problem with a shared public DIT run by competing commercial service providers 🤝. Right now, we don't really know how [un]successful the NADF will be at pulling this off 🤷‍♀️.

The NADF eventually concluded that the directory should be organized so entries can be found where people (or other entities) will look for them 👀. That's better than where civil naming authorities would file their archival name registration records 🗃️.

There are some incompatibilities between the NADF Naming Scheme, the White Pages Pilot Naming Scheme, and the PARADISE Naming Scheme. This should be resolved 🛠️.

5.G. CLAYMAN PROPOSAL 🏺

RFC 1107 offered a "strawman" proposal for an Internet Directory Service 👒. The next step after a strawman is sometimes called "clayman," and this section presents a clayman proposal 🧱.

We assume only white pages service is being provided, and we let sites run whatever access technologies they want to, with whatever access controls they're comfy with 🛋️.

The architecture can then work like this: the discovery process leads to a set of URLs 🔗. A URL is like an address, but it's a typed address with identifiers and an access method, not a protocol 🧾. The client sorts the URLs and may discard any it can't deal with 🗑️. The client talks to "meaningful URLs" (such as Whois, Finger, X.500) 💬.

This approach gives servers that want to make information available a low entry cost ✨. It also gives us a Darwinian selection of access technologies, coalescence in the Internet marketplace, and a white pages service that will tend toward homogeneity and ubiquity 🌍.

Some issues for further study are: what discovery technology to use (Netfind together with Whois++ including centroids?) 🤔; how to handle non-standard URLs (one possible solution is to put a server on top of these non-standard URLs, which reevaluates the pointer and acts as a front-end to a database) 🧰; which data model to use (Finger or X.500) 📊; and how to utilize a common discovery technology (e.g., centroids) in a multiprotocol communication architecture 🧩.

The rationale for this meta-WPS approach is that it builds on current practices while striving to provide a ubiquitous directory service 🌟. There are lots of efforts going on to develop WPS based on different protocols, so one can envisage a future with a meta-WPS that combines an intelligent user agent and a distributed indexing service to access the requested data from any available WPS 🧚. The user-perceived functionality of such a meta-WPS will necessarily be restricted to the lowest common denominator 😬. Hopefully, through "market" forces, the number of protocols will decrease (or converge) and the functionality will increase 📈.

The degree to which proactive data gathering is permitted may be limited by national laws ⚖️. It may be appropriate to gather data about which hosts have databases, but not about the data in those databases 🙈.

6. CONCLUSIONS 🎀

We're now revisiting the questions we set out to answer and briefly describing the key conclusions 💖.

6.A. WHAT FUNCTIONS SHOULD A WHITE PAGES DIRECTORY PERFORM? 👑

After all that discussion, we've concluded there are two functions the white pages service must provide: searching and retrieving 🫶.

Searching is the ability to find people given some fuzzy information about them, like "Find the Postel in southern California" 🌴. Searches may often return a list of matches 📋.

Recognizing how important indexing is for searching is a major conclusion of these discussions 🔥. It's clear that users want fast searching across the distributed database on attributes that are different from the database structure ⚡. Pre-computed indices might be able to satisfy that desire 🦋.

Retrieval is obtaining additional information associated with a person, such as address, telephone number, email mailbox, and security certificate 📮.

This last one, security certificates, is a type of information associated with an individual that is essential for end-to-end authentication, integrity, and privacy in Internet applications 🔐✨. Secure applications on the Internet depend on a directory system for retrieving the security certificate associated with an individual 😭. The PEM system has been developed and is ready to go into service, but it's currently held back by the lack of an easy-to-use directory of security certificates 🥺.

PEM security certificates are part of the X.509 standard 📜. If X.500 is going to be set aside, other alternatives will need to be explored 🧭. If X.500 distinguished naming is scrapped, some other structure will need to come into existence to replace it 💅.

6.B. WHAT APPROACHES WILL PROVIDE US WITH A WHITE PAGES DIRECTORY? 🦋

okay so it's giving multiple technologies, all in use at once, and that's totally fine!! The real move is making them interoperate 🫶 The usual way to do that is with conventions or standards for the interfaces and communication forms between the different systems. What we actually need is a spec for the simplest common communication form that's still powerful enough to do the job ✨ Then you can have a bunch of different user interfaces on any number of client systems, all talking to different kinds of servers. The IETF working group (WG) way of making standards seems super well suited to this, honestly 💅

This "common ground" approach is all about giving the ubiquitous WPS high functionality with a low entry cost 🌸 It can happen by pulling out the issues that are shared across the competing WPS and having them worked on in specific, dedicated IETF WGs (for example, data model coordination). The IETF is going to keep developing X.500 and Whois++ as two separate things 🦋 Their work gets broken down into small, focused WGs that tackle specific technical issues, borrowing ideas from both X.500 and Whois++. The goal is common standards for information formats, the data model, and access protocols. Wherever possible, what one of these WGs produces will be used in both Whois++ and X.500, though some WGs will probably still work on stuff that's specific to just one of the protocols. The IDS (Integrated Directory Services) WG keeps going on the non-protocol-specific issues. To get coordination that leads to convergence instead of divergence 👑, the applications area directorate will give guidance to the Application Area Directors as well as the various WGs, and the User Services Area Council (USAC) brings the user perspective.

6.C. WHAT ARE THE PROBLEMS TO BE OVERCOME? 🧩

There are a few problems we can solve to make progress toward a white pages service happen faster 🏃‍♀️ We need:

  • To make it much easier to be part of the Internet white pages than bringing up an X.500 DSA, while still making good use of the X.500 DSAs that are already deployed.
  • To define new, simpler white pages services (such as Whois++) so that loads of people can create implementations.
  • To provide some central management of the X.500 system to promote good operation.
  • To select a naming scheme.
  • To develop a set of index-servers, and indexing techniques, to provide for fast searching.
  • To provide for the storage and retrieval of security certificates.

6.D. WHAT SHOULD THE DEPLOYMENT STRATEGY BE? 🚀

We should capitalize on the X.500 DSAs that are already out there 💖 That means some central management has to be provided, and easy-to-use user interfaces (like the Gopher "gateway") need to be widely deployed.

  • Document the selection of a naming scheme (e.g., the NADF scheme).
  • Adopt the "common ground" model. Encourage the development of several different services, with a goal of interworking between them.
  • Develop a specification of the simplest common communication form that's powerful enough to provide the necessary functionality. The IETF working group method of developing standards seems well suited to this problem.
  • Make available information about how to set up new servers (of whatever kind) in "cookbook" form.

7. SUMMARY ✨

Lots of issues got raised, but there are just a few where we recommend action be taken to support specific elements of the overall white pages system 🎀

RECOMMENDATIONS

  1. Adopt the common ground approach: give all protocols equal access to all data. In other words, encourage multiple client and server types, and the standardization of an interoperation protocol between them. The clients might be simple clients, front-ends, "gateways", or embedded in other information access clients, like Gopher or WWW client programs. The interoperation protocol will define some message types, message sequences, and data fields. An element of this protocol should be the use of URLs.
  2. Promote the development of index-servers. The index-servers should use several different methods of gathering data for their indices, and several different methods for searching their indices.
  3. Support a central management for the X.500 system. To get the best advantage of the effort already invested in the X.500 directory system, it is essential to provide the relatively small amount of central management needed to keep the system functioning.
  4. Support the development of security certificate storage and retrieval from the white pages service. The most practical approach is to initially focus on getting this supported by the existing X.500 directory infrastructure. It should also include design and development of the storage and retrieval of security certificates in other white pages services, such as Whois++.

8. REFERENCES 📚

Here are the receipts, all of them 🧾

[1] Sollins, K., "Plan for Internet Directory Services", RFC 1107, M.I.T. Laboratory for Computer Science, July 1989.

[2] Hardcastle-Kille, S., "Replication Requirements to provide an Internet Directory using X.500, RFC 1275, University College London, November 1991.

[3] Weider, C., and J. Reynolds, "Executive Introduction to Directory Services Using the X.500 Protocol", FYI 13, RFC 1308, ANS, USC/Information Sciences Institute, March 1992.

[4] Weider, C., Reynolds, J., and S. Heker, "Technical Overview of Directory Services Using the X.500 Protocol", FYI 14, RFC 1309, ANS, USC/Information Sciences Institute,, JvNC, March 1992.

[5] Hardcastle-Kille, S., Huizer, E., Cerf, V., Hobby, R., and S. Kent, "A Strategic Plan for Deploying an Internet X.500 Directory Service", RFC 1430, ISODE Consortium, SURFnet bv, Corporation for National Research Initiatives, University of California, Davis, Bolt, Beranek, and Newman, February 1993.

[6] Jurg, A., "Introduction to White pages services based on X.500", Work in Progress, October 1993.

[7] The North American Directory Forum, "NADF Standing Documents: A Brief Overview", RFC 1417, The North American Directory Forum", NADF, February 1993.

[8] NADF, An X.500 Naming Scheme for National DIT Subtrees and its Application for c=CA and c=US", Standing Document 5 (SD-5).

[9] Garcia-Luna, J., Knopper, M., Lang, R., Schoffstall, M., Schraeder, W., Weider, C., Yeong, W, Anderson, C., (ed.), and J. Postel (ed.), "Research in Directory Services: Fielding Operational X.500 (FOX)", Fox Project Final Report, January 1992.

9. GLOSSARY 💅

Abbreviation decoder ring, just for you 💍

API - Application Program Interface
COTS - commercial off the shelf
CSO - a phonebook service developed by University of Illinois
DAP - Direct Access Protocol
DIT - Directory Information Tree
DNS - Domain Name System
DUI - Directory User Interface
DUA - Directory User Agent
DSA - Directory Service Agent
FOX - Fielding Operational X.500 project
FRICC - Federal Research Internet Coordinating Committee
IETF - Internet Engineering Task Force
ISODE - ISO Development Environment
LDAP - Lightweight Direct Access Protocol
NADF - North American Directory Forum
PEM - Privacy Enhanced Mail
PSI - Performance Systems International
SQL - Structured Query Language
QUIPU - an X.500 DSA which is a component of the ISODE package
UFN - User Friendly Name
URI - Uniform Resource Identifier
URL - Uniform Resource Locator
WAIS - Wide Area Information Server
WPS - White Pages Service
WWW - World Wide Web

9. ACKNOWLEDGMENTS 🫶

This report is put together from the words of the following participants in the email discussion and the meeting 💌 The authors picked and combined the material, but all the good ideas belong to the participants, and any bad ideas are on the authors 🙈

Allan Cargille                  University of Wisconsin
Steve Crocker                   TIS
Peter Deutsch                   BUNYIP
Peter Ford                      LANL
Jim Galvin                      TIS
Joan Gargano                    UC Davis
Arlene Getchell                 ES.NET
Rick Huber                      INTERNIC - AT&T
Christian Huitema               INRIA
Erik Huizer                     SURFNET
Tim Howes                       University of Michigan
Steve Kent                      BBN
Steve Kille                     ISODE Consortium
Mark Kosters                    INTERNIC - Network Solutions
Paul Mockapetris                ARPA
Paul-Andre Pays                 INRIA
Dave Piscitello                 BELLCORE
Marshall Rose                   Dover Beach Consulting
Sri Sataluri                    INTERNIC - AT&T
Mike Schwartz                   University of Colorado
David Staudt                    NSF
Einar Stefferud                 NMA
Chris Weider                    MERIT
Scott Williamson                INTERNIC - Network Solutions
Russ Wright                     LBL
Peter Yee                       NASA

10. SECURITY CONSIDERATIONS 💀

Okay, real talk, this section is a big deal 🚨 This memo does have comments about privacy and security sprinkled throughout, but there is no serious analysis of security considerations for a white pages or directory service in this memo. That gap is not something to shrug off, bestie 😭

11. AUTHORS' ADDRESSES 🎀

Who to reach out to 💌

Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292

Phone: 310-822-1511
Fax:   310-823-6714
EMail: Postel@ISI.EDU


Celeste Anderson
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292

Phone: 310-822-1511
Fax:   310-823-6714
EMail: Celeste@ISI.EDU

APPENDIX 1 ✨

Okay so this White Pages Functionality List was cooked up by Chris Weider, then glowed up by everyone in the current discussion about an Internet white pages service 💅

Functionality list for a White Pages / Directory services 🎀

Serving information on People only

1.1 Protocol Requirements 💖

  • a) Distributability
  • b) Security
  • c) Searchability and easy navigation
  • d) Reliability (in particular, replication)
  • e) Ability to serve the information desired (in particular, multi-media information)
  • f) Obvious benefits to encourage installation
  • g) Protocol support for maintenance of data and 'knowledge'
  • h) Ability to support machine use of the data
  • i) Must be based on Open Standards and respond rapidly to correct deficiencies
  • j) Serve new types of information (not initially planned) only only upon request
  • k) Allow different operation modes

1.2 Implementation Requirements 🦋

  • a) Searchability and easy navigation
  • b) An obvious and fairly painless upgrade path for organizations
  • c) Obvious benefits to encourage installation
  • d) Ubiquitous clients
  • e) Clients that can do exhaustive search and/or cache useful information and use heuristics to narrow the search space in case of ill-formed queries
  • f) Ability to support machine use of the data
  • g) Stable APIs

1.3 Sociological Requirements 🌈

  • a) Shallow learning curve for novice users (both client and server)
  • b) Public domain servers and clients to encourage experimentation
  • c) Easy techniques for maintaining data, to encourage users to keep their data up-to-date
  • d) (particularly for organizations) The ability to hide an organization's internal structure while making the data public.
  • e) Widely recognized authorities to guarantee unique naming during registrations (This is specifically X.500 centric)
  • f) The ability to support the privacy / legal requirements of all participants while still being able to achieve good coverage.
  • g) Supportable infrastructure (Perhaps an identification of what infrastructure support requires and how that will be maintained)

The convo started out all about White Pages, but lots of participants believe that a Yellow Pages service should be built into a White Pages scheme 🍓

Functionality List for Yellow Pages service 💜

Yellow pages services, with data primarily on people

2.1 Protocol Requirements 🧚

  • a) all listed in 1.1
  • b) Very good searching, perhaps with semantic support OR
  • b2) Protocol support for easy selection of proper keywords to allow searching
  • c) Ways to easily update and maintain the information required by the Yellow Pages services
  • d) Ability to set up specific servers for specific applications or a family of applications while still working with the WP information bases

2.2 Implementation Requirements 🌸

  • a) All listed in 1.2
  • b) Server or client support for relevance feedback

2.3 Sociological Requirements 🫶

  • a) all listed in 1.3

Advanced directory services for resource location (not just people data) 🔥

3.1 Protocol Requirements 👑

  • a) All listed in 2.1
  • b) Ability to track very rapidly changing data
  • c) Extremely good and rapid search techniques

3.2 Implementation Requirements 🎀

  • a) All listed in 2.2
  • b) Ability to integrate well with retrieval systems
  • c) Speed, Speed, Speed

3.3 Sociological Requirements 🙈

  • a) All listed in 1.3
  • b) Protocol support for 'explain' functions: 'Why didn't this query work?'
📦 where this page comes from