to search for someone, he first contacts the index-server. The
index-server searches its index data and returns a pointer (or a few
pointers) to specific databases that hold data on people that match
the search criteria. Other systems which do something comparable to
this are archie (for FTP file archives), WAIS, and Netfind.
5.E. COLLECTION AND MAINTENANCE
The information must be "live" - that is, it must be used. Often one
way to ensure this is to use the data (perhaps locally) for something
other than white pages. If it isn't, most people won't bother to
keep the information up to date. The white pages in the phone book
have the advantage that the local phone company is in contact with
the listee monthly (through the billing system), and if the address
is not up to date, bills don't get delivered, and there is feedback
that the address is wrong. There is even better contact for the
phone number, since the local phone company must know that for their
basic service to work properly. It is this aspect of directory
functionality that leads towards a distributed directory system for
the Internet.
One approach is to use existing databases to supply the white pages
data. It then would be helpful to define a particular use of SQL
(Structured Query Language) as a standard interface language between
the databases and the X.500 DSA or other white pages server. Then
one needs either to have the directory service access the existing
database using an interface language it already knows (e.g., SQL), or
to have 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. In a way, both X.500 and
Whois++ provide this. This approach implies customization at every
existing database to interface to the "standard" query format.
Some strongly believe that the white pages service needs to be
created from the bottom up with each organization supplying and
maintaining its own information, and that such 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 make it possible to put company sensitive
information into the locally maintained directory and have only a
portion of it exported for outsiders.
5.F. NAMING STRUCTURE
We need a clear naming scheme capable of associating a name with
attributes, without any possible ambiguities, that is stable over
time, but also capable of coping with changes. This scheme 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,
based on the use of existing Civil Naming Authorities to register
entry owners' names, and to deal with the shared-entry problem with a
shared public DIT supported by competing commercial service
providers. At this point, we do not have any sense at the moment as
to how [un]successful the NADF may be in accomplishing this.
The NADF eventually concluded that the directory should be organized
so entries can be found where people (or other entities) will look
for them, not where civil naming authorities would place their
archival name registration records.
There are some incompatibilities between use of the NADF Naming
Scheme, the White Pages Pilot Naming Scheme, and the PARADISE Naming
Scheme. This should be resolved.
5.G. CLAYMAN PROPOSAL
RFC1107 offered a "strawman" proposal for an Internet Directory
Service. The next step after strawman is sometimes called "clayman",
and here a clayman proposal is presented.
We assume only white pages service is to be provided, and we let
sites run whatever access technologies they want to (with whatever
access controls they feel comfortable).
Then the architecture can be that the discovery process leads to a
set of URLs. A URL is like an address, but it is a typed address
with identifiers, access method, not a protocol. The client sorts
the URLs and may discard some that it cannot deal with. The client
talks to "meaningful URLs" (such as Whois, Finger, X.500).
This approach results in low entry cost for the servers that want to
make information available, a Darwinian selection of access
technologies, coalescence in the Internet marketplace, and a white
pages service 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 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.
Since there are various efforts going on to develop WPS based on
various different protocols, one can envisage a future with a meta-
WPS that uses a combination of 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. One
will hope that through "market" forces, the number of protocols used
will decrease (or converge), and that 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 now revisit the questions we set out to answer and briefly
describe the key conclusions.
6.A. WHAT FUNCTIONS SHOULD A WHITE PAGES DIRECTORY PERFORM?
After all the discussion we come to the conclusion that 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.
The recognition of the importance of indexing in searching is a major
conclusion of these discussions. It is clear that users want fast
searching across the distributed database on attributes different
from the database structure. It is possible that pre-computed
indices can satisfy this desire.
Retrieval is obtaining additional information associated with a
person, such as address, telephone number, email mailbox, and
security certificate.
This last, security certificates, is a type of information associated
with an individual that is essential for the use of end-to-end
authentication, integrity, and privacy, in Internet applications.
The development of secure application in the Internet is dependent 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 is now held back by the lack of an easily
used directory of security certificates.
PEM security certificates are part of the X.509 standard. If X.500
is going to be set aside, then other alternatives 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?
It is clear that there will be several technologies in use. The
approach must be to promote the interoperation of the multiple
technologies. This is traditionally done by having conventions or
standards for the interfaces and communication forms between the
different systems. The need is for a specification of the simplest
common communication form that is powerful enough to provide the
necessary functionality. This allows a variety of user interfaces on
any number of client systems communicating with different types of
servers. The IETF working group (WG) method of developing standards
seems well suited to this problem.
This "common ground" approach aims to provide the ubiquitous WPS with
a high functionality and a low entry cost. This may done by singling
out issues that are common for various competing WPS and coordinate
work on these in specific and dedicated IETF WGs (e.g., data model
coordination). The IETF will continue development of X.500 and
Whois++ as two separate entities. The work on these two protocols
will be broken down in various small and focussed WGs that address
specific technical issues, using ideas from both X.500 and Whois++.
The goal being to produce common standards for information formats,
data model and access protocols. Where possible the results of such
a WG will be used in both Whois++ and X.500, although it is envisaged
that several WGs may work on issues that remain specific to one of
the protocols. The IDS (Integrated Directory Services) WG continues
to work on non-protocol specific issues. To achieve coordination
that leads to convergence rather than divergence, the applications
area directorate will provide guidance to the Application Area
Directors as well as to the various WGs, and the User Services Area
Council (USAC) will provide the necessary user perspective.
6.C. WHAT ARE THE PROBLEMS TO BE OVERCOME?
There are several problems that can be solved to make progress
towards a white pages service more rapid. We need:
To make it much easier to be part of the Internet white pages than
bringing up a X.500 DSA, yet making good use of the already deployed
X.500 DSAs.
To define new simpler white pages services (such as Whois++) such
that numerous 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 existing infrastructure of already
deployed X.500 DSAs. This means that some central management must be
provided, and easy to use user interfaces (such as the Gopher
"gateway"), must 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 is 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
what ever kind) in "cookbook" form.
7. SUMMARY
While many issues have been raised, there are just a few where we
recommend the 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. That is, 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 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 necessary 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
[1] Sollins, K., "Plan for Internet Directory Services", RFC1107,
M.I.T. Laboratory for Computer Science, July 1989.
[2] Hardcastle-Kille, S., "Replication Requirements to provide an
Internet Directory using X.500, RFC1275, University College
London, November 1991.
[3] Weider, C., and J. Reynolds, "Executive Introduction to
Directory Services Using the X.500 Protocol", FYI 13, RFC1308,
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, RFC1309,
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", RFC1430, 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", RFC1417, 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
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 assembled from the words of the following participants
in the email discussion and the meeting. The authors are responsible
for selecting and combining the material. Credit for all the good
ideas goes to the participants. Any bad ideas are the responsibility
of 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
While there are comments in this memo about privacy and security,
there is no serious analysis of security considerations for a white
pages or directory service in this memo.
11. AUTHORS' ADDRESSES
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
The following White Pages Functionality List was developed by Chris
Weider and amended by participants in the current discussion of 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)
Although the original focus of this discussion was on White Pages,
many 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?'