doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc1588.txt b/doc/rfc/rfc1588.txt
new file mode 100644
index 0000000..4f34b2a
--- /dev/null
+++ b/doc/rfc/rfc1588.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Network Working Group                                          J. Postel
+Request for Comments: 1588                                   C. Anderson
+Category: Informational                                              ISI
+                                                           February 1994
+
+
+                       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.
+
+INTRODUCTION
+
+   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
+      specified searches.
+
+      Retrieval is obtaining additional information associated with a
+      person, such as an address, telephone number, email mailbox, or
+      security certificate.
+
+      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
+      secure.
+
+   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
+      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++.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Anderson                                               [Page 3]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+2. HISTORY
+
+   In February 1989, a meeting on Internet white pages service was
+   initiated by the FRICC (Federal Research Internet Coordinating
+   Committee) and the ensuing discussions resulted in RFC 1107 [1] that
+   offered some technical conclusions.  Widespread deployment was to
+   have taken place 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 has done 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 a 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.
+
+
+
+
+
+Postel & Anderson                                               [Page 4]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+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.
+
+   In finding people, the service should work fast when searching for
+   people by name, even if the information regarding location or
+   organization is vague.  In finding information about people, the
+   service should retrieve information associated with people, such as a
+   phone number, a postal or email address, or even a certificate for
+   security applications (authentication, integrity, and privacy).
+   Sometimes additional information associated with people is provided
+   by a directory service, such as 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; 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 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, should have low resource
+   requirements, and should fit into other systems that may be currently
+   in use; 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
+
+
+
+Postel & Anderson                                               [Page 5]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+   fashion and with little extra effort; the query responses should be
+   reliable enough and consistent enough that automated tools could be
+   used.
+
+3.B. WHAT APPROACHES WILL PROVIDE US WITH A WHITE PAGES DIRECTORY?
+
+   People have different needs, tastes, etc.  Consequently, a large part
+   of the ultimate solution will include bridging among these various
+   solutions.  Already we see 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.  Netfind knows about several other protocols.
+
+   Gopher and WAIS "achieved orbit" simply by providing means for people
+   to export and to access useful information; neither system had to
+   provide ubiquitous service.  For white pages, if the service doesn't
+   provide answers to specific user queries some reasonable proportion
+   of the time, users view it as as failure.  One way to achieve a high
+   hit rate in an exponentially growing Internet is to use a proactive
+   data gathering architecture (e.g., as realized by archie and
+   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 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 being added to the database, and/or (b) to 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 provide added
+   incentive for sites 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,
+
+
+
+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 cannot
+   be addressed without "complex technology".  A solution that allows
+   the user to progress 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) indicates that a good percentage of the
+   problem of finding information can be addressed with simpler
+   approaches.  Users know this and will resist attempts to make them
+   pay the full price for the full solution when it is not needed.
+   Whereas managers and funders may be concerned with the complexity of
+   the technology, 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 may become so variable that the
+   loose constraints of weak service in some places lead users to see
+   the whole system as too loose and weak.
+
+   Some organizations will not operate services that they cannot get for
+   free or they cannot 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 would not
+   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 can not be simply 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 will be required of directory services 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?
+
+   There are two classes of problems to be examined; 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 wide spread X.500 service is operational.  The
+   current public domain version is said to be difficult to install and
+
+
+
+Postel & Anderson                                               [Page 7]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+   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 due to 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 is the 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 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 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 is easy to
+   use.  Tim Howes' new disk-based quipu DSA solves many of the memory
+   problems in DSA resource utilization.  If one 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 expend the extra effort to get X.500 up.  X.500 takes a sharp
+   learning curve.  There is 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,
+   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 great
+   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-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 is not run as a service in the U.S., and therefore those using
+   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 central
+   management and coordinated administration support in place.  Someone
+   has to be responsible for maintaining the root; 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 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 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 gives the potential to provide a framework for a
+   wide variety of services.  Special purpose protocols are simpler, but
+   may lead to duplication or restricted scope.
+
+   Tight information framework costs effort to coerce existing data and
+   to build structures.  Once in place, it gives better managability and
+   more uniform access.  The tight information framework can be
+
+
+
+Postel & Anderson                                               [Page 9]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+   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.  This may lead to concluding that several services are
+   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 information
+   technology.  The information systems that have gained real momentum
+   in the Internet (WAIS, Gopher, etc.) followed the model:
+
+   -- 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.
+
+   What can this report do to help make this happen for Internet white
+   pages?
+
+   Deployment Issues.
+
+   -- A strict hierarchical layout is not suitable for all directory
+      applications and hence we should not force fit it.
+
+   -- A typical organization's hierarchical information itself is often
+      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 display
+      to the public in any directory.  This is especially true for
+      Institutions that want to protect themselves from headhunters, and
+      sales personnel.
+
+
+
+
+
+
+Postel & Anderson                                              [Page 10]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+   -- 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
+   as have other popular services on the Internet.  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.  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.
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Anderson                                              [Page 11]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+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
+
+   Several arguments in X.500's favor are its flexibility, distributed
+   architecture, security, superiority to paper directories, and that it
+   can be used by applications as well as by humans.  X.500 is designed
+   to provide a uniform database facility with replication,
+   modification, and authorization.  Because it is distributed, it is
+   particularly suited for a large global White Pages directory.  In
+   principle, it has good searching capabilities, allowing searches at
+   any level or in any subtree of the DIT (Directory Information Tree).
+   There are DUIs available for all types of workstations and X.500 is
+   an international standard.  In theory, X.500 can provide vastly
+   better directory service than other systems, however, in practice,
+   X.500 is difficult, too complicated, and inconvenient to use.  It
+   should provide a better service.  X.500 is a technology that may be
+   used to provide a white pages service, although some features of
+   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 are
+   largely 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.  In practice, this means that a
+      portion of the code/complexity is effectively unused.
+
+      The LDAP work has virtually eliminated this concern on the client
+      side of things, as LDAP is both simple and lightweight.  Yet, the
+      complexity problem still exists on the server side of things, so
+      people continue to have trouble bringing up data for simple
+      clients to access.
+
+      It has been suggested that the complexity in X.500 is due to the
+      protocol stack and the ISODE base.  If this is true, then LDAP may
+      be simple because it uses TCP directly without the ISODE base.  A
+      version of X.500 server that took the same approach might also be
+      "simple" or at least simpler.  Furthermore, the difficulty in
+      getting an X.500 server up may be related to finding the data to
+
+
+
+Postel & Anderson                                              [Page 12]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+      put in the server, and so may be a general data management problem
+      rather than an X.500 specific problem.
+
+      There is some evidence that eventually a large percentage of the
+      use of directory services may be from applications rather than
+      direct user queries.  For example, mail-user-agents exist that are
+      X.500 capable with an integrated DUA (Directory User Agent).
+
+   2) 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, and as
+      noted elsewhere in this report, there are a number of issues that
+      apply to white pages service that are not addressed by gopher.
+
+      Some of these problems could be alleviated by putting in place
+      better procedures.  It should not any be harder to get connected
+      to X.500 than it is to get connected to the DNS, for example.
+      However, there is a certain amount of complexity that 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.
+
+   3) 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 there are sites like University of Michigan, University
+   of Minnesota, Rutgers University, NASA, LBL, etc. running X.500 in
+   serious production mode shows that the problem has more to do with
+   the current state of X.500 software procedures.  It takes a lot of
+   effort to get it going.  The level of effort required to keep it
+   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 it
+   in 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, but that according to the type of query there could be
+   several such as querying by role, by location, 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.
+   University of Michigan started with just people information in their
+   tree.  Once that infrastructure was in place, it was easy for them to
+   add more things to handle mailing lists/email groups, yellow pages
+   applications like a documentation index, directory of images, etc.
+
+   The ESnet community is using X.500 right now to provide a White Pages
+   service; users succeed everyday 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 lookup DNS information, find
+   what Zone a Macintosh is in, lookup departmental information, view
+   the current weather satellite image, and lookup 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 the interfacing of 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 that part of X.500 it will use,
+   and developing solutions for the ambiguous and undefined parts of
+   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 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 are on the way, and a Whois++
+   front-end to X.500.  In addition, the developers who are 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.
+
+
+
+
+
+
+
+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, 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 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 make 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.  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.  The
+   current Whois++ system does not lend itself to delegation.  Research
+   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. NETFIND
+
+   Right now, the white pages service with the most coverage in the
+   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, UUCP
+   maps, NIC WHOIS databases, and DNS traversals, which then maps
+   organizations and localities to domain names.  The second stage
+   consists of finger queries, Whois queries, smtp expns and vrfys, and
+   DNS lookups.
+
+   The key feature of Netfind is that it is proactive.  It doesn't
+   require that the system administrator bring up a new server, populate
+   it with all kinds of information, keep the information in sync, worry
+   about update, etc.  It just works.
+
+   A suggestion was made that Netfind could be used as a way to populate
+   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 for
+   them using Netfind.  Others do not believe this is feasible.
+
+   Another perhaps less interesting merger of Netfind and X.500 is to
+   have Netfind add X.500 as one of the places it looks to find
+   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 that
+   domain, or the finger service is unavailable, or the machines are not
+   be 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 towards the use of 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 - given a set of keywords 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 these servers, then combine the responses.  However, we
+   need a formal method of gathering white-pages data and informal
+   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 to
+   providing an Internet white pages.  For the longer term, the
+   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 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), 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 the DNS to point 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 provide 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.
+
+
+
+
+
+
+Postel & Anderson                                              [Page 18]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+4.D. ARCHIE
+
+   Archie is a success because it is a directory of files that are
+   accessible over the network.  Every FTP site makes a "conscious"
+   decision to make the files available for anonymous FTP over the
+   network.  The mechanism that archie uses to gather the data is the
+   same as that used to transfer the files.  Thus, the success rate is
+   near 100%.  In a similar vein, if Internet sites make a "conscious"
+   decision to make white-pages data available over the network, it is
+   possible to link these servers to create a world-wide directory, such
+   as X.500, or build an index that helps to 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 that allows one to get either information about an
+   individual with an account, or a list of currently logged in users,
+   from a host running the server, 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 (thus the client would decide to access or not
+   the actual data), or (2) for client 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.
+
+
+
+
+
+
+Postel & Anderson                                              [Page 19]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+   This solution is preferable to one consisting of storing 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 (to ensure privacy mostly) that governs
+   any database on 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 are 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 were not part of
+   the implementation.  There is 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 who are 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 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 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, much effort has
+   gone into the definition of various structures or schemas, and yet
+   few standard schemas have emerged.
+
+   There is a general consensus that a "cookbook" for Administrators
+   would make X.500 implementation easier and more attractive.  These
+   are essential for getting X.500 in wider use.  It is also essential
+   that other technologies such as Whois++, Netfind, and archie also
+   have complete user guides available.
+
+5.C. SEARCHING AND RETRIEVING
+
+   The main complaint, especially from those who enjoyed using a
+   centralized database (such as the InterNIC Whois service), is the
+   need to search for all the John Doe's in the world.  Given that the
+   directory needs to be distributed, there is no way of answering this
+   question without incurring additional 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 to provide some mechanism to limit the number of servers that
+   need to be contacted.  The traditional way to handle this is with
+   hierarchy.  This requires the searcher to have some idea of the
+   structure of the directory.  It also comes up against one of the
+   standard problems with hierarchical databases - if you need to search
+   based on a characteristic that is NOT part of the hierarchy, you are
+   back to searching every node in the tree, or you can search an index
+   (see below).
+
+   In general:
+
+   -- 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).
+
+
+
+Postel & Anderson                                              [Page 21]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+   Any directory system can be used in a manner 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 to 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 addition in X.500 of
+   non-distinguishing attributes, and by using the NADF Naming Scheme it
+   is possible to lodge an entry anywhere in the DIT that you believe is
+   where it will be looked for.
+
+   One approach to the distributed search problem is to create another
+   less distributed database to search, such as an index.  This is done
+   by doing a (non-interactive) pre-search, and collecting the results
+   in an index.  When a user wants to do a real time search, one first
+   searches the index to find pointers to the appropriate data records
+   in the distributed database.  One example of this is the building of
+   centroids that contain index information.  There may be a class of
+   servers that hold indices, called "index-servers".
+
+5.D. INDEXING
+
+   The suggestion for how to do fast searching is to do indexing.  That
+   is to pre-compute an index of people from across the distributed
+   database and hold that index in an index server.  When a user wants
+   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.
+
+
+
+
+
+Postel & Anderson                                              [Page 22]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+   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
+
+
+
+Postel & Anderson                                              [Page 23]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+   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
+
+   RFC 1107 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
+
+
+
+Postel & Anderson                                              [Page 24]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+   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.
+
+
+
+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.  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.
+
+
+
+Postel & Anderson                                              [Page 26]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Anderson                                              [Page 27]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+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++.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Anderson                                              [Page 28]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+8.  REFERENCES
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Anderson                                              [Page 29]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Anderson                                              [Page 30]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+Postel & Anderson                                              [Page 31]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Anderson                                              [Page 32]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+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.
+
+
+
+Postel & Anderson                                              [Page 33]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+      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
+
+
+
+
+
+
+Postel & Anderson                                              [Page 34]
+
+RFC 1588                   White Pages Report              February 1994
+
+
+   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?'
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Anderson                                              [Page 35]
+
\ No newline at end of file