White Pages Meeting Report
RFC - Informational
(February 1994; No errata)
||RFC Editor Note
RFC 1588 (Informational)
||Send notices to
Network Working Group J. Postel
Request for Comments: 1588 C. Anderson
Category: Informational ISI
WHITE PAGES MEETING REPORT
STATUS OF THIS MEMO
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This report describes the results of a meeting held at the November
IETF (Internet Engineering Task Force) in Houston, TX, on November 2,
1993, to discuss the future of and approaches to a white pages
directory services for the Internet.
As proposed to the National Science Foundation (NSF), USC/Information
Sciences Institute (ISI) conducted the meeting to discuss the
viability of the X.500 directory as a practical approach to providing
white pages service for the Internet in the near future and to
identify and discuss any alternatives.
An electronic mail mailing list was organized and discussions were
held via email for two weeks prior to the meeting.
1. EXECUTIVE SUMMARY
This report is organized around four questions:
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 given some fuzzy
information about them. Such as "Find the Postel in southern
California". Searches may often return a list of matches.
While the idea of indexing has been around for some time, such as
the IN-ADDR tree in the Domain Name System (DNS), a new
acknowledgment of its importance has emerged from these
Postel & Anderson [Page 1]
RFC 1588 White Pages Report February 1994
discussions. Users want fast searching across the distributed
database on attributes different from the database structure.
Pre-computed indices satisfy this desire, though only for
Retrieval is obtaining additional information associated with a
person, such as an address, telephone number, email mailbox, or
Security certificates (a type of information associated with an
individual) are essential for the use of end-to-end
authentication, integrity, and privacy in Internet applications.
The development of secure applications in the Internet is
dependent on a directory system for retrieving the security
certificate associated with an individual. For example, the
privacy enhanced electronic mail (PEM) system has been developed
and is ready to go into service, and is now hindered by the lack
of an easily used directory of security certificates. An open
question is whether or not such a directory needs to be internally
2) What approaches will provide us with a white pages directory?
It is evident that there are and will be several technologies in
use. In order to provide a white pages directory service that
accommodates multiple technologies, we should promote
interoperation and work toward a specification of the simplest
common communication form that is powerful enough to provide the
necessary functionality. This "common ground" approach aims to
provide the ubiquitous WPS (White Pages Service) with a high
functionality and a low entry cost.
3) What are the problems to be overcome?
It must be much easier to be part of the Internet white pages than
to bring up a X.500 DSA (Directory Service Agent), yet we must
make good use of the already deployed X.500 DSAs. 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.
Postel & Anderson [Page 2]
RFC 1588 White Pages Report February 1994
4) 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
Show full document text