rfc1588.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,478 行 · 第 1/5 页

   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.