As per Relevance of the word february, we have this rfc below:
Network Working Group J.
Request for Comments: 1588 C.
Category: Informational
February 1994
WHITE PAGES MEETING
STATUS OF THIS
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This report describes the results of a meeting held at the
IETF (Internet Engineering Task Force) in Houston, TX, on November 2,
1993, to discuss the future of and approaches to a white
directory services for the Internet
As proposed to the National Science Foundation (NSF), USC/
Sciences Institute (ISI) conducted the meeting to discuss
viability of the X.500 directory as a practical approach to
white pages service for the Internet in the near future and
identify and discuss any alternatives
An electronic mail mailing list was organized and discussions
held via email for two weeks prior to the meeting
1. EXECUTIVE
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
information about them. Such as "Find the Postel in
California". Searches may often return a list of matches
While the idea of indexing has been around for some time, such
the IN-ADDR tree in the Domain Name System (DNS), a
acknowledgment of its importance has emerged from
Postel & Anderson [Page 1]
RFC 1588 White Pages Report February 1994
discussions. Users want fast searching across the
database on attributes different from the database structure
Pre-computed indices satisfy this desire, though only
specified searches
Retrieval is obtaining additional information associated with
person, such as an address, telephone number, email mailbox,
security certificate
Security certificates (a type of information associated with
individual) are essential for the use of end-to-
authentication, integrity, and privacy in Internet applications
The development of secure applications in the Internet
dependent on a directory system for retrieving the
certificate associated with an individual. For example,
privacy enhanced electronic mail (PEM) system has been
and is ready to go into service, and is now hindered by the
of an easily used directory of security certificates. An
question is whether or not such a directory needs to be
secure
2) What approaches will provide us with a white pages directory
It is evident that there are and will be several technologies
use. In order to provide a white pages directory service
accommodates multiple technologies, we should
interoperation and work toward a specification of the
common communication form that is powerful enough to provide
necessary functionality. This "common ground" approach aims
provide the ubiquitous WPS (White Pages Service) with a
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
to bring up a X.500 DSA (Directory Service Agent), yet we
make good use of the already deployed X.500 DSAs. Simpler
pages services (such as Whois++) must be defined to
multiple implementations. To promote reliable operation,
must be some central management of the X.500 system. A
naming scheme must be identified and documented. A set of index
servers, and indexing techniques, must be developed. The
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
interfaces (such as the Gopher "gateway"), must be
deployed. The selection of a naming scheme must be documented
We should capitalize on the existing infrastructure of
deployed X.500 DSAs. The "common ground" model should be adopted
A specification of the simplest common communication form must
developed. Information about how to set up a new server (
whatever kind) in "cookbook" form should be made available
1. Adopt the common ground approach. Encourage multiple client
server types, and the standardization of an
protocol between them. The clients may be simple clients
front-ends, "gateways", or embedded in other information
clients, such as Gopher or WWW (World Wide Web) client programs
The interoperation protocol will define message types,
sequences, and data fields. An element of this protocol
be the use of Universal Record Locators (URLs).
2. Promote the development of index-servers. The index-
should use several different methods both for gathering data
their indices, and for searching their indices
3. Support a central management for the X.500 system. To get
best advantage of the effort already invested in the X.500
directory system it is essential to provide the relatively
amount of central management necessary to keep the
functioning
4. Support the development of security certificate storage
retrieval from the white pages service. One practical
is initially to focus on getting support from the existing X.500
directory infrastructure. This effort should also
design and development of the storage and retrieval of
certificates for other white pages services, such as Whois++.
Postel & Anderson [Page 3]
RFC 1588 White Pages Report February 1994
2.
In February 1989, a meeting on Internet white pages service
initiated by the FRICC (Federal Research Internet
Committee) and the ensuing discussions resulted in RFC 1107 [1]
offered some technical conclusions. Widespread deployment was
have taken place by mid-1992.
RFC 1107: K. Sollins, "Plan for Internet Directory Services",
[1].
Several other RFCs have been written suggesting deployment
and plans for an X.500 Directory Service
They are
RFC 1275: S. Hardcastle-Kille, "Replication Requirements
provide an Internet Directory using X.500", [2].
RFC 1308: C. Weider, J. Reynolds, "Executive Introduction
Directory Services Using the X.500 Protocol", [3].
RFC 1309: C. Weider, J. Reynolds, S. Heker, "Technical
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
entitled, "Introduction to White pages services based on X.500",
describes why we need a global white pages service and why X.500
the answer [6].
The North America Directory Forum (NADF) also has done some
work setting conventions for commercial providers of X.500
service. Their series of memos is relevant to this discussion. (
RFC 1417 for an overview of this note series [7].) In particular
NADF standing document 5 (SD-5) "An X.500 Naming Scheme for
DIT Subtrees and its Application for c=CA and c=US" is of
for its model of naming based on civil naming authorities [8].
Deployment of a X.500 directory service including that under the
(Performance Systems International) White Pages Pilot Project and
PARADISE Project is significant, and continues to grow, albeit at
slower rate than the Internet
Postel & Anderson [Page 4]
RFC 1588 White Pages Report February 1994
3.
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
information about people
In finding people, the service should work fast when searching
people by name, even if the information regarding location
organization is vague. In finding information about people,
service should retrieve information associated with people, such as
phone number, a postal or email address, or even a certificate
security applications (authentication, integrity, and privacy).
Sometimes additional information associated with people is
by a directory service, such as a list of publications, a
of current projects, or a current travel itinerary
Back in 1989, RFC 1107 detailed 8 requirements of a white
service: (1) functionality, (2) correctness of information, (3) size
(4) usage and query rate, (5) response time, (6)
authority, (7) access control, (8) multiple transport
support; and 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 the writing of RFC 1107, many additional functions have
identified. A White Pages Functionality List is attached as
1. The problem is harder now, the Internet is much bigger, and
are many more options available (Whois++, Netfind, LDAP (
Direct Access Protocol), different versions of X.500 implementations
etc.)
A white pages directory should be flexible, should have low
requirements, and should fit into other systems that may be
in use; it should not cost a lot, so that future transitions are
too costly; there should be the ability to migrate to something else
if a better solution becomes available; there should be a way
share local directory information with the Internet in a
Postel & Anderson [Page 5]
RFC 1588 White Pages Report February 1994
fashion and with little extra effort; the query responses should
reliable enough and consistent enough that automated tools could
used
3.B. WHAT APPROACHES WILL PROVIDE US WITH A WHITE PAGES DIRECTORY
People have different needs, tastes, etc. Consequently, a large
of the ultimate solution will include bridging among these
solutions. Already we see a Gopher to X.500 gateway, a Whois++
X.500 gateway, and the beginnings of a WWW to X.500 gateway.
can talk to CSO (a phonebook service developed by University
Illinois), WAIS (Wide Area Information Server), etc. WWW can talk
everything. Netfind knows about several other protocols
Gopher and WAIS "achieved orbit" simply by providing means for
to export and to access useful information; neither system had
provide ubiquitous service. For white pages, if the service doesn'
provide answers to specific user queries some reasonable
of the time, users view it as as failure. One way to achieve a
hit rate in an exponentially growing Internet is to use a
data gathering architecture (e.g., as realized by archie
Netfind). Important as they are, replication, authentication, etc.,
are irrelevant if no one 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
minus side, one can get garbage in the database. One possibility
to use a proactive approach to (a) acquire data for
review before being added to the database, and/or (b) to check
data for consistency with the real world. Additionally, there
some question about the legality of proactive methods in
countries
One solution is to combine existing technology and infrastructure
provide a good white pages service, based on a X.500 core plus a
of additional index/references servers. DNS can be used to "refer
to the appropriate zone in the X.500 name space, using WAIS
Whois++, to build up indexes to the X.500 server which will be
to process a given request. These can be index-servers or
or something new
Some X.500 purists might feel this approach muddles the
fabric among X.500 servers, since the site index, DNS records,
customization gateways are all outside of X.500. On the other hand
making X.500 reachable from a common front-end would provide
incentive for sites to install X.500 servers. Plus, it provides
immediate (if interim) solution to the need for a global site
in X.500. Since the goal is to have a good white pages service
Postel & Anderson [Page 6]
RFC 1588 White Pages Report February 1994
X.500 purity is not essential
It may be that there are parts of the white pages problem that
be addressed without "complex technology". A solution that
the user to progress up the ladder of complexity, according to taste
perceived need, and available resources may be a much
approach. However, experience to date with simpler
(Whois++, Netfind, archie) indicates that a good percentage of
problem of finding information can be addressed with
approaches. Users know this and will resist attempts to make
pay the full price for the full solution when it is not needed
Whereas managers and funders may be concerned with the complexity
the technology, users are generally more concerned with the
and ease of use of the service. A danger in supporting a mix
technologies is that the service may become so variable that
loose constraints of weak service in some places lead users to
the whole system as too loose and weak
Some organizations will not operate services that they cannot get
free or they cannot try cheaply before investing time and money
Some people prefer a bare-bones, no support solution that only
them 85 percent of what they want. Paying for the service would
be a problem for many sites, once the value of the service has
proven. Although there is no requirement to provide free
for everybody, we do need viable funding and support mechanisms.
solution can not be simply dictated with any expectation that it
stick
Finally, are there viable alternative technologies to X.500 now or
we need to design something new? What kind of time frame are
talking about for development and deployment? And will the
technology be extensible enough to provide for the as yet
uses that will be required of directory services 5 years from now
And will this directory service ultimately provide more
than just white pages
3.C. WHAT ARE THE PROBLEMS TO BE OVERCOME
There are two classes of problems to be examined; technology
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
necessary before a wide spread X.500 service is operational.
current public domain version is said to be difficult to install
Postel & Anderson [Page 7]
RFC 1588 White Pages Report February 1994
to bring into operation, but many organizations have
installed it and have had their systems up and running for some time
Note that the current public domain program, quipu, is not
standard X.500, and is more suited to research than
service. Many people who tried earlier versions of quipu
X.500 due to its costly start up time, and inherent complexity
The ISODE (ISO Development Environment) Consortium is
developing newer features and is addressing most of the
problems. However, there is the perception that the companies in
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
certainly needed now, since if they are too late in being deployed
other solutions will be implemented in lieu of X.500.
The remaining problem with an X.500 White Pages is having a
quality public domain DSA. The ISODE Consortium will make
version available for no charge to Universities (or any non-profit
government organization whose primary purpose is research) but
that leaves a sizeable group using the old quipu implementation,
there is a significant problem. In such a case, an answer may be
some funding to upgrade the public version of quipu
In addition, the quipu DSA should be simplified so that it is easy
use. Tim Howes' new disk-based quipu DSA solves many of the
problems in DSA resource utilization. If one fixes the DSA
utilization problem, makes it fairly easy to install, makes it
available, and publishes a popular press book about it, X.500
have a better chance of success
The client side of X.500 needs more work. Many people would
not expend the extra effort to get X.500 up. X.500 takes a
learning curve. There is a perception that the client side
needs a complex Directory User Interface (DUI) built on ISODE.
there are alternative DUIs, such as those based on LDAP.
aspect of the client side is that access to the directory should
built into other applications like gopher and email (especially
accessing PEM X.509 certificates).
We also need data conversion tools to make the transition
different systems possible. For example, NASA had more than
system to convert
Searching abilities for X.500 need to be improved. LDAP is
help, but the following capabilities are still needed
Postel & Anderson [Page 8]
RFC 1588 White Pages Report February 1994
-- commercial grade easily maintainable servers with back-
database support
-- clients that can do exhaustive search and/or cache
information and use heuristics to narrow the search space in
of ill-formed queries
-- index servers that store index information on a "few"
attributes that DUIs can consult in narrowing the search space
How about index attributes at various levels in the tree
capture the information in the corresponding subtree
Work still needs to be done with Whois++ to see if it will scale
the level of X.500.
An extended Netfind is attractive because it would work without
additional infrastructure changes (naming, common schema, etc.),
even the addition of any new protocols
INFRASTRUCTURE
The key issues are central management and naming rules
X.500 is not run as a service in the U.S., and therefore those
X.500 in the U.S. are not assured of the reliability of root servers
X.500 cannot be taken seriously until there is some
management and coordinated administration support in place.
has to be responsible for maintaining the root; this effort
comparable to maintaining the root of the DNS. PSI provided
service until the end of the FOX project [9]; should they
funding to continue this? Should this be a commercial enterprise
Or should this function be added to the duties of the InterNIC
New sites need assistance in getting their servers up and linked to
central server
There are two dimensions along which to consider the infrastructure
1) general purpose vs. specific, and 2) tight vs. loose
framework
General purpose leads to more complex protocols - the generality
an overhead, but gives the potential to provide a framework for
wide variety of services. Special purpose protocols are simpler,
may lead to duplication or restricted scope
Tight information framework costs effort to coerce existing data
to build structures. Once in place, it gives better managability
more uniform access. The tight information framework can
Postel & Anderson [Page 9]
RFC 1588 White Pages Report February 1994
subdivided further into: 1) the naming approach, and 2) the
and attribute extensibility
Examples of systems placed in this space are: a) X.500 is a
purpose and tight information framework, b) DNS is a specific
tight information framework, c) there are various research efforts
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
services. This may lead to concluding that several services
desirable
3.D. WHAT SHOULD THE DEPLOYMENT STRATEGY BE
No solution will arise simply by providing technical specifications
The solution must fit the way the Internet adopts
technology. The information systems that have gained real
in the Internet (WAIS, Gopher, etc.) followed the model
-- A small group goes off and builds a piece of software
supplies badly needed functionality at feasible effort
providers and users
-- The community rapidly adopts the system as a de facto standard
-- Many people join the developers in improving the system
standardizing the protocols
What can this report do to help make this happen for Internet
pages
Deployment Issues
-- A strict hierarchical layout is not suitable for all
applications and hence we should not force fit it
-- A typical organization's hierarchical information itself is
proprietary; they may not want to divulge it to the outside world
It will always be true that Institutions (not just commercial
will always have some information that they do not wish to
to the public in any directory. This is especially true
Institutions that want to protect themselves from headhunters,
sales personnel
Postel & Anderson [Page 10]
RFC 1588 White Pages Report February 1994
-- There is the problem of multiple directory service providers,
see NADF work on "Naming Links" and their "CAN/KAN"
[7].
A more general approach such as using a knowledge server (or a
of servers) might be better. The knowledge servers would have
know about which server to contact for a given query and thus
refer to either service provider servers or directly
institution-operated servers. The key problem is how to
the knowledge and keep it up to date. There are some
about the viability of "naming links" without a
modification
-- Guidelines are needed for methods of searching and using
information
-- A registration authority is needed to register names at
levels of the hierarchy to ensure uniqueness or adoption of
civil naming structure as delineated by the NADF
It is true that deployment of X.500 has not seen exponential
as have other popular services on the Internet. But rather
abandoning X.500 now, these efforts, which are attempting to
some of the causes, should continue to move forward.
installation complexity and performance problems with the
implementation need solutions. These problems are being worked on
One concern with the X.500 service has been the lack of
user agents. Very few hosts run the ISODE package. The use of
improves this situation. The X.500-gopher gateway has had
greatest impact on providing wide-spread access to the X.500 service
Since adding X.500 as a service on the ESnet Gopher, the use of
ESnet DSA has risen dramatically
Another serious problem affecting the deployment of X.500, at
in the U.S., is the minimal support given to building and
the necessary infrastructure since the demise of the Fox Project [9].
Without funding for this effort, X.500 may not stand a chance in
United States
Postel & Anderson [Page 11]
RFC 1588 White Pages Report February 1994
4. REVIEW OF
There are now many systems for finding information, some of these
oriented to white pages, some include white pages, and
currently ignore white pages. In any case, it makes sense to
these systems to see how they might fit into the provision of
Internet white pages service
4.A. X.500
Several arguments in X.500's favor are its flexibility,
architecture, security, superiority to paper directories, and that
can be used by applications as well as by humans. X.500 is
to provide a uniform database facility with replication
modification, and authorization. Because it is distributed, it
particularly suited for a large global White Pages directory.
principle, it has good searching capabilities, allowing searches
any level or in any subtree of the DIT (Directory Information Tree).
There are DUIs available for all types of workstations and X.500
an international standard. In theory, X.500 can provide
better directory service than other systems, however, in practice
X.500 is difficult, too complicated, and inconvenient to use.
should provide a better service. X.500 is a technology that may
used to provide a white pages service, although some features
X.500 may not be needed to provide just a white pages service
The are three reasons X.500 deployment has been slow, and these
largely the same reasons people don't like it
1) The available X.500 implementations (mostly quipu based on
ISODE) are very large and complicated software packages that
hard to work with. This is partly because they solve the
X.500 problem, rather than the subset needed to provide
Internet white pages directory. In practice, this means that
portion of the code/complexity is effectively unused
The LDAP work has virtually eliminated this concern on the
side of things, as LDAP is both simple and lightweight. Yet,
complexity problem still exists on the server side of things,
people continue to have trouble bringing up data for
clients to access
It has been suggested that the complexity in X.500 is due to
protocol stack and the ISODE base. If this is true, then LDAP
be simple because it uses TCP directly without the ISODE base.
version of X.500 server that took the same approach might also
"simple" or at least simpler. Furthermore, the difficulty
getting an X.500 server up may be related to finding the data
Postel & Anderson [Page 12]
RFC 1588 White Pages Report February 1994
put in the server, and so may be a general data management
rather than an X.500 specific problem
There is some evidence that eventually a large percentage of
use of directory services may be from applications rather
direct user queries. For example, mail-user-agents exist that
X.500 capable with an integrated DUA (Directory User Agent).
2) You have to "know a lot" to get a directory service up and
with X.500. You have to know about object classes and
to get your data into X.500. You have to get a distinguished
for your organization and come up with an internal tree structure
You have to contact someone before you can "come online" in
pilot. It's not like gopher where you type "make", tell a
friends, and you're up and running
Note that a gopher server is not a white pages service, and
noted elsewhere in this report, there are a number of issues
apply to white pages service that are not addressed by gopher
Some of these problems could be alleviated by putting in
better procedures. It should not any be harder to get
to X.500 than it is to get connected to the DNS, for example
However, there is a certain amount of complexity that may
inherent in directory services. Just compare Whois++ and X.500.
X.500 has object classes. Whois++ has templates. X.500
attributes. Whois++ has fields. X.500 has distinguished names
Whois++ has handles
3) Getting data to populate the directory, converting it into
proper form, and keeping it up-to-date turns out to be a
problem. Often this means talking to the administrative
department at your organization
This problem exists regardless of the protocol used. It should
easy to access this data through the protocol you're using,
that says more about implementations than it does about
protocol. Of course, if the only X.500 implementation you
makes it really hard to do, and the Whois++ implementation
have makes it easy, it's hard for that not to reflect on
protocols
The fact that there are sites like University of Michigan,
of Minnesota, Rutgers University, NASA, LBL, etc. running X.500
serious production mode shows that the problem has more to do
the current state of X.500 software procedures. It takes a lot
effort to get it going. The level of effort required to keep
going is relatively very small
Postel & Anderson [Page 13]
RFC 1588 White Pages Report February 1994
The yellow pages problem is not really a problem. If you look at
in the traditional phonebook-style yellow pages way, then X.500
do the job just like the phone book does. Just organize
directory based on different (i.e., non-geographical) criteria.
you want to "search everything", then you need to prune the
space. To do this you can use the Whois++ centroids idea,
something similar. But this idea is as applicable to X.500 as it
to Whois++. Maybe X.500 can use the centroids idea most effectively
Additionally, it should be noted that there is not one single
Pages service, but that according to the type of query there could
several such as querying by role, by location, by email address
No one is failing to run X.500 because they perceive it fails
solve the yellow pages problem. The reasons are more likely one
more of the three above
X.500's extra complexity is paying off for University of Michigan
University of Michigan started with just people information in
tree. Once that infrastructure was in place, it was easy for them
add more things to handle mailing lists/email groups, yellow
applications like a documentation index, directory of images, etc
The ESnet community is using X.500 right now to provide a White
service; users succeed everyday in searching for information
colleagues given only a name and an organizational affiliation;
yes, they do load data into X.500 from an Oracle database
LBL finds X.500 very useful. They can lookup DNS information,
what Zone a Macintosh is in, lookup departmental information,
the current weather satellite image, and lookup people information
LDAP should remove many of the complaints about X.500.
a number of LDAP clients is very easy and has all the
needed. Perhaps DAP should be scrapped
Another approach is the interfacing of X.500 servers to WWW (
interface is sometimes called XWI). Using the mosaic program
the NCSA, one can access X.500 data
INTERNET X.500
The ISO/ITU may not make progress on improving X.500 in the
frame required for an Internet white pages service. One approach
to have the Internet community (e.g., the IETF) take
for developing a subset or profile of that part of X.500 it will use
and developing solutions for the ambiguous and undefined parts
X.500 that are necessary to provide a complete service
Postel & Anderson [Page 14]
RFC 1588 White Pages Report February 1994
Tasks this approach might include are
1. Internet (IETF) control of the base of the core service
pages infrastructure and standard
2. Base the standard on the 1993 specification,
replication and access control
3. For early deployment choose which parts of the
protocol are really urgently needed. It may be possible to
a subset and to make it mandatory for the Internet
4. Define an easy and stable API (Application Program Interface)
key access protocols (DAP, LDAP).
5. Use a standard knowledge model
6. Make sure that high performance implementations will exist for
most important servers, roles principally for the upper layers
the DSA tree
7. Make sure that servers will exist that will be able to
get the objects (or better the attributes) from
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.
less than 15 months there were 3 working public
implementations, at least 3 more are on the way, and a Whois++
front-end to X.500. In addition, the developers who are working
the resource location system infrastructure (URL/URI) have
to implementing it on top of Whois++ because of its superior
capabilities
Some of the main problems with getting a White Pages directory
have been: (1) search, (2) lack of public domain versions, (3)
implementations are too large, (4) high start up cost, and (5)
implementations don't make a lot of sense for a local directory
particularly for small organizations. Whois++ can and does
all these problems very nicely
Search is built into Whois++, and there is a strong commitment
the developers to keep this a high priority
Postel & Anderson [Page 15]
RFC 1588 White Pages Report February 1994
The protocols are simple enough that someone can write a server in 3
days. And people have done it. If the protocols stay simple,
will always be easy for someone to whip out a new public
server. In this respect, Whois++ is much like WAIS or Gopher
The typical Whois++ implementation is about 10 megabytes,
the WAIS source code that provides the data engine. Even assuming
rough doubling of the code as additional necessary functionality
built in, that's still quite reasonable, and compares favorably
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
recent test, Chris Weider used a 5 megabyte source data file with
Whois++ code. The indices came to about another 7 megabytes, and
code was under 10 megabytes. The total is 22 megabytes for a Whois++
server
The available Whois++ implementations take about 25 minutes
compile on a Sun SPARCstation IPC. Indexing a 5 megabyte data
takes about another 20 minutes on an IPC. Installation is very easy
In addition, since the Whois++ server protocol is designed to be
a front-end, organizations can keep their data in any form they want
Whois++ makes sense as a local directory service.
implementations are small, install quickly, and the raw
language is very simple. The simplicity of the interaction
the client and the server make it easy to experiment with and
write clients for, something that wasn't true of X.500 until LDAP
In addition, Whois++ can be run strictly as a local service,
integration into the global infrastructure done at any time
It is true that Whois++ is not yet a fully functional White
service. It requires a lot of work before it will be so. 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.
current Whois++ system does not lend itself to delegation.
is still needed to improve the system and see if it scales well
Postel & Anderson [Page 16]
RFC 1588 White Pages Report February 1994
4.C.
Right now, the white pages service with the most coverage in
Internet is Mike Schwartz' Netfind. Netfind works in two stages: 1)
find out where to ask, and 2) start asking
The first stage is based on a database of netnews articles,
maps, NIC WHOIS databases, and DNS traversals, which then
organizations and localities to domain names. The second
consists of finger queries, Whois queries, smtp expns and vrfys,
DNS lookups
The key feature of Netfind is that it is proactive. It doesn'
require that the system administrator bring up a new server,
it with all kinds of information, keep the information in sync,
about update, etc. It just works
A suggestion was made that Netfind could be used as a way to
the X.500 directory. A tool might do a series of Netfind queries
making the corresponding X.500 entries as it progresses
Essentially, X.500 entries would be "discovered" as people look
them using Netfind. Others do not believe this is feasible
Another perhaps less interesting merger of Netfind and X.500 is
have Netfind add X.500 as one of the places it looks to
organizations (and people).
A search can lead you to where a person has an account (e.g.,
law.xxx.edu) only to find a problem with the DNS services for
domain, or the finger service is unavailable, or the machines are
be running Unix (there are lots of VMS machines and IBM
still out there). In addition, there are security gateways.
trends in computing are towards the use of powerful portables
mobile computing and hence Netfind's approach may not work. However
Netfind proves to be an excellent yellow-pages service for
information in DNS servers - given a set of keywords it lists a
of possible domain names
Suppose we store a pointer in DNS to a white-pages server for
domain. We can use Netfind to come up with a list of servers
search, query these servers, then combine the responses. However,
need a formal method of gathering white-pages data and
methods will not work and may even get into legal problems
Postel & Anderson [Page 17]
RFC 1588 White Pages Report February 1994
The user search phase of Netfind is a short-term solution
providing an Internet white pages. For the longer term,
applicability of the site discovery part of Netfind is more relevant
and more work has been put into that part of the system over the
2 years than into the user search phase
Given Netfind's "installed customer base" (25k queries per day,
in 4875 domains in 54 countries), one approach that might make
is to use Netfind as a migration path to a better directory,
gradually phase Netfind's user search scheme out of existence.
idea of putting a record in the DNS to point to the directory
to search at a site is a good start
One idea for further development is to have the DNS record point to
"customization" server that a site can install to tailor the
Netfind (or whatever replaces Netfind) searches their site.
would provide sites a choice of degrees of effort and levels
service. The least common denominator is what Netfind
does: DNS/SMTP/finger. A site could upgrade by installing
customization server that points to the best hosts to finger, or
says "we don't want Netfind to search here" (if people
sufficiently concerned about the legal/privacy issues, the
could be changed so that searches must be explicitly enabled).
next step up is to use the customization server as a gateway to
local Whois, CSO, X.500, or home grown white pages server. In
long run, if X.500 (or Whois++, etc.) really catches on, it
subsume the site indexing part of Netfind and use the above
as an evolution path to full X.500 deployment. However,
approaches may be more productive. One key to Netfind's success
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
they store their people data to have it "included" in Netfind.
just like archie, it would be more useful if there were a more
structure to the information it gives you, and therefore to
information contained in the databases it accesses. It's this
structure that we should be encouraging people to move toward
As a result of suggestions made at the November meeting, Netfind
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
uses for SMTP or Finger, or restrict Netfind from searching
site entirely
Postel & Anderson [Page 18]
RFC 1588 White Pages Report February 1994
4.D.
Archie is a success because it is a directory of files that
accessible over the network. Every FTP site makes a "conscious
decision to make the files available for anonymous FTP over
network. The mechanism that archie uses to gather the data is
same as that used to transfer the files. Thus, the success rate
near 100%. In a similar vein, if Internet sites make a "conscious
decision to make white-pages data available over the network, it
possible to link these servers to create a world-wide directory,
as X.500, or build an index that helps to isolate the servers to
searched, Whois++. Users don't have to do anything to their
archives to have them included in archie. But everybody
that it could be more useful if only there were some more
structure to the information, and to the information contained in
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.
The Finger program that allows one to get either information about
individual with an account, or a list of currently logged in users
from a host running the server, can be used to check a
that a particular individual has an account on a particular host
This does not provide an efficient method to search for
individual
4.F.
A "gateway" between Gopher and X.500 has been created so that one
examine X.500 data from a Gopher client. Similar "gateways"
needed for other white pages systems
4.G.
One extension to WWW would be an attribute type for the WWW URI/
with the possibility for any client to request from the X.500
(1) either the locator (thus the client would decide to access or
the actual data), or (2) for client not capable of accessing
data, the data itself (packed) in the ASN.1 encoded result
This would give access to potentially any piece of
available on the network through X.500, and in the white pages
to photos or voice messages for persons
Postel & Anderson [Page 19]
RFC 1588 White Pages Report February 1994
This solution is preferable to one consisting of storing
multimedia information directly in the directory, because it
WWW capable DUIs to access directly any piece of data no matter
large. This work on URIs is not WWW-specific
5.
5.A. DATA
Outside of the U.S., nearly all developed countries have
strict data protection acts (to ensure privacy mostly) that
any database on personal data
It is mandatory for the people in charge of such white
databases to have full control over the information that can
stored and retrieved in such a database, and to provide
controls over the information that is made available
If modification is allowed, then authentication is required.
database manager must be able to prevent users from making
unallowed information
When we are dealing with personal records the issues are a
more involved than exporting files. We can not allow trawling
data and we need access-controls so that several applications can
the directory and hence we need authentication
X.500 might have developed faster if security issues were not part
the implementation. There is tension between quick
implementations and the attempt to operate in a larger
with business issues incorporated. The initial belief was that
is owned by the people who put the data into the system, however
most data protection laws appoint the organizations holding the
responsible for the quality of the data of their individuals
Experience also shows that the people most affected by
data are the people who are trying to access the data.
problems apply to all technologies
5.B.
Several types of standards are needed: (1) standards
interoperation between different white pages systems (e.g., X.500
Whois++), (2) standards for naming conventions, and (3) and
within the structured data of each system (what fields or
are required and optional, and what are their data types).
Postel & Anderson [Page 20]
RFC 1588 White Pages Report February 1994
The standards for interoperation may be developed from the work
in progress on URLs, with some additional protocol developed
govern the types of messages and message sequences
Both the naming of the systems and the naming of individuals
benefit from consistent naming conventions. The use of the
naming scheme should be considered
When structured data is exchanged, standards are needed for the
types and the structural organization. In X.500, much effort
gone into the definition of various structures or schemas, and
few standard schemas have emerged
There is a general consensus that a "cookbook" for
would make X.500 implementation easier and more attractive.
are essential for getting X.500 in wider use. It is also
that other technologies such as Whois++, Netfind, and archie
have complete user guides available
5.C. SEARCHING AND
The main complaint, especially from those who enjoyed using
centralized database (such as the InterNIC Whois service), is
need to search for all the John Doe's in the world. Given that
directory needs to be distributed, there is no way of answering
question without incurring additional cost
This is a problem with any distributed directory - you just can'
search every leaf in the tree in any reasonable amount of time.
need to provide some mechanism to limit the number of servers
need to be contacted. The traditional way to handle this is
hierarchy. This requires the searcher to have some idea of
structure of the directory. It also comes up against one of
standard problems with hierarchical databases - if you need to
based on a characteristic that is NOT part of the hierarchy, you
back to searching every node in the tree, or you can search an
(see below).
In general
-- the larger the directory the more need for a distributed
(for upkeep and managability).
-- once you are distributed, the search space for any given
MUST be limited
-- this makes it necessary to provide more information as part of
query (and thus makes the directory harder to use).
Postel & Anderson [Page 21]
RFC 1588 White Pages Report February 1994
Any directory system can be used in a manner that makes
less than easy. With a User Friendly Name (UFN) query, a user
usually find an entry (presuming it exists) without a lot of trouble
Using additional listings (as per NADF SD-5) helps to hide
or civil naming infrastructure knowledge requirements
Search power is a function of DSA design in X.500, not a function
Distinguished Naming. Search can be aided by addition in X.500
non-distinguishing attributes, and by using the NADF Naming Scheme
is possible to lodge an entry anywhere in the DIT that you believe
where it will be looked for
One approach to the distributed search problem is to create
less distributed database to search, such as an index. This is
by doing a (non-interactive) pre-search, and collecting the
in an index. When a user wants to do a real time search, one
searches the index to find pointers to the appropriate data
in the distributed database. One example of this is the building
centroids that contain index information. There may be a class
servers that hold indices, called "index-servers".
5.D.
The suggestion for how to do fast searching is to do indexing.
is to pre-compute an index of people from across the
database and hold that index in an index server. When a user
to search for someone, he first contacts the index-server.
index-server searches its index data and returns a pointer (or a
pointers) to specific databases that hold data on people that
the search criteria. Other systems which do something comparable
this are archie (for FTP file archives), WAIS, and Netfind
5.E. COLLECTION AND
The information must be "live" - that is, it must be used. Often
way to ensure this is to use the data (perhaps locally) for
other than white pages. If it isn't, most people won't bother
keep the information up to date. The white pages in the phone
have the advantage that the local phone company is in contact
the listee monthly (through the billing system), and if the
is not up to date, bills don't get delivered, and there is
that the address is wrong. There is even better contact for
phone number, since the local phone company must know that for
basic service to work properly. It is this aspect of
functionality that leads towards a distributed directory system
the Internet
Postel & Anderson [Page 22]
RFC 1588 White Pages Report February 1994
One approach is to use existing databases to supply the white
data. It then would be helpful to define a particular use of
(Structured Query Language) as a standard interface language
the databases and the X.500 DSA or other white pages server.
one needs either to have the directory service access the
database using an interface language it already knows (e.g., SQL),
to have tools that periodically update the directory database
the existing database. Some sort of "standard" query format (
protocol) for directory queries, with "standard" field names will
needed to make this work in general. In a way, both X.500
Whois++ provide this. This approach implies customization at
existing database to interface to the "standard" query format
Some strongly believe that the white pages service needs to
created from the bottom up with each organization supplying
maintaining its own information, and that such information has to
the same -- or a portion of the same -- information the
uses locally. Otherwise the global information will be stale
incomplete
One way to make this work is to distribute software that
- is useful locally
- fits into the global scheme
- is available free,
- works on most Unix systems
With respect to privacy, it would be good for the local software
have controls that make it possible to put company
information into the locally maintained directory and have only
portion of it exported for outsiders
5.F. NAMING
We need a clear naming scheme capable of associating a name
attributes, without any possible ambiguities, that is stable
time, but also capable of coping with changes. This scheme
have a clear idea of naming authorities and be able to
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
entry owners' names, and to deal with the shared-entry problem with
shared public DIT supported by competing commercial
Postel & Anderson [Page 23]
RFC 1588 White Pages Report February 1994
providers. At this point, we do not have any sense at the moment
to how [un]successful the NADF may be in accomplishing this
The NADF eventually concluded that the directory should be
so entries can be found where people (or other entities) will
for them, not where civil naming authorities would place
archival name registration records
There are some incompatibilities between use of the NADF
Scheme, the White Pages Pilot Naming Scheme, and the PARADISE
Scheme. This should be resolved
5.G. CLAYMAN
RFC 1107 offered a "strawman" proposal for an Internet
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
sites run whatever access technologies they want to (with
access controls they feel comfortable).
Then the architecture can be that the discovery process leads to
set of URLs. A URL is like an address, but it is a typed
with identifiers, access method, not a protocol. The client
the URLs and may discard some that it cannot deal with. The
talks to "meaningful URLs" (such as Whois, Finger, X.500).
This approach results in low entry cost for the servers that want
make information available, a Darwinian selection of
technologies, coalescence in the Internet marketplace, and a
pages service will tend toward homogeneity and ubiquity
Some issues for further study are what discovery technology to
(Netfind together with Whois++ including centroids?), how to
non-standard URLs (one possible solution is to put server on top
these (non-standard URLs) which reevaluates the pointer and acts as
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)
a multiprotocol communication architecture
The rationale for this meta-WPS approach is that it builds on
practices, while striving to provide a ubiquitous directory service
Since there are various efforts going on to develop WPS based
various different protocols, one can envisage a future with a meta
WPS that uses a combination of an intelligent user agent and
distributed indexing service to access the requested data from
available WPS. The user perceived functionality of such a meta-
Postel & Anderson [Page 24]
RFC 1588 White Pages Report February 1994
will necessarily be restricted to the lowest common denominator.
will hope that through "market" forces, the number of protocols
will decrease (or converge), and that the functionality
increase
The degree to which proactive data gathering is permitted may
limited by national laws. It may be appropriate to gather data
which hosts have databases, but not about the data in
databases
6.
We now revisit the questions we set out to answer and
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
functions the white pages service must provide: searching
retrieving
Searching is the ability to find people given some fuzzy
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
conclusion of these discussions. It is clear that users want
searching across the distributed database on attributes
from the database structure. It is possible that pre-
indices can satisfy this desire
Retrieval is obtaining additional information associated with
person, such as address, telephone number, email mailbox,
security certificate
This last, security certificates, is a type of information
with an individual that is essential for the use of end-to-
authentication, integrity, and privacy, in Internet applications
The development of secure application in the Internet is dependent
a directory system for retrieving the security certificate
with an individual. The PEM system has been developed and is
to go into service, but is now held back by the lack of an
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
explored. If X.500 distinguished naming is scrapped, some
structure will need to come into existence to replace it
Postel & Anderson [Page 25]
RFC 1588 White Pages Report February 1994
6.B. WHAT APPROACHES WILL PROVIDE US WITH A WHITE PAGES DIRECTORY
It is clear that there will be several technologies in use.
approach must be to promote the interoperation of the
technologies. This is traditionally done by having conventions
standards for the interfaces and communication forms between
different systems. The need is for a specification of the
common communication form that is powerful enough to provide
necessary functionality. This allows a variety of user interfaces
any number of client systems communicating with different types
servers. The IETF working group (WG) method of developing
seems well suited to this problem
This "common ground" approach aims to provide the ubiquitous WPS
a high functionality and a low entry cost. This may done by
out issues that are common for various competing WPS and
work on these in specific and dedicated IETF WGs (e.g., data
coordination). The IETF will continue development of X.500
Whois++ as two separate entities. The work on these two
will be broken down in various small and focussed WGs that
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
a WG will be used in both Whois++ and X.500, although it is
that several WGs may work on issues that remain specific to one
the protocols. The IDS (Integrated Directory Services) WG
to work on non-protocol specific issues. To achieve
that leads to convergence rather than divergence, the
area directorate will provide guidance to the Application
Directors as well as to the various WGs, and the User Services
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
towards a white pages service more rapid. We need
To make it much easier to be part of the Internet white pages
bringing up a X.500 DSA, yet making good use of the already
X.500 DSAs
To define new simpler white pages services (such as Whois++)
that numerous people can create implementations
To provide some central management of the X.500 system to
good operation
To select a naming scheme
Postel & Anderson [Page 26]
RFC 1588 White Pages Report February 1994
To develop a set of index-servers, and indexing techniques,
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
deployed X.500 DSAs. This means that some central management must
provided, and easy to use user interfaces (such as the
"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
several different services, with a goal of interworking
them
-- Develop a specification of the simplest common communication
that is powerful enough to provide the necessary functionality
The IETF working group method of developing standards seems
suited to this problem
-- Make available information about how to set up new servers (
what ever kind) in "cookbook" form
Postel & Anderson [Page 27]
RFC 1588 White Pages Report February 1994
7.
While many issues have been raised, there are just a few where
recommend the action be taken to support specific elements of
overall white pages system
1. Adopt the common ground approach - give all protocols
access to all data. That is, encourage multiple client
server types, and the standardization of an
protocol between them. The clients may be simple clients
front-ends, "gateways", or embedded in other information
clients, such as Gopher or WWW client programs.
interoperation protocol will define some message types,
sequences, and data fields. An element of this protocol
be the use of URLs
2. Promote the development of index-servers. The index-
should use several different methods of gathering data for
indices, and several different methods for searching
indices
3. Support a central management for the X.500 system. To get
best advantage of the effort already invested in the X.500
directory system it is essential to provide the relatively
amount of central management necessary to keep the
functioning
4. Support the development of security certificate storage
retrieval from