rfc1309.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 899 行 · 第 1/3 页

Network Working Group                                          C. Weider
Request for Comments: 1309                                           ANS
FYI: 14                                                      J. Reynolds
                                                                     ISI
                                                                S. Heker
                                                                    JvNC
                                                              March 1992


                Technical Overview of Directory Services
                        Using the X.500 Protocol

Status of this Memo

   This memo provides information for the Internet community. It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This document is an overview of the X.500 standard for people not
   familiar with the technology. It compares and contrasts Directory
   Services based on X.500 with several of the other Directory services
   currently in use in the Internet. This paper also describes the
   status of the standard and provides references for further
   information on X.500 implementations and technical information.

   A primary purpose of this paper is to illustrate the vast
   functionality of the X.500 protocol and to show how it can be used to
   provide a global directory for human use, and can support other
   applications which would benefit from directory services, such as
   main programs.

   This FYI RFC is a product of the Directory Information Services
   (pilot) Infrastructure Working Group (DISI).  A combined effort of
   the User Services and the OSI Integration Areas of the Internet
   Engineering Task Force (IETF).

1.  INTRODUCTION

   As the pace of industry, science, and technological development
   quickened over the past century, it became increasingly probable that
   someone in a geographically distant location would be trying to solve
   the same problems you were trying to solve, or that someone in a
   geographically distant location would have some vital information
   which impinged on your research or business.  The stupendous growth
   in the telecommunications industry, from telegraphs to telephones to
   computer networks, has alleviated the problem of being able to



DISI Working Group                                              [Page 1]

RFC 1309              Technical Overview of X.500             March 1992


   communicate with another person, PROVIDED THAT YOU KNOW HOW TO REACH
   THEM.

   Thus, along with the expansion of the telecommunications
   infrastructure came the development of Directory Services. In this
   paper, we will discuss various models of directory services, the
   limitations of current models, and some solutions provided by the
   X.500 standard to these limitations.

2  MODELS OF DIRECTORY SERVICES

2.1  The telephone company's directory services.

   A model many people think of when they hear the words "Directory
   Services" is the directory service provided by the local telephone
   company. A local telephone company keeps an on-line list of the names
   of people with phone service, along with their phone numbers and
   their address. This information is available by calling up Directory
   Assistance, giving the name and address of the party whose number you
   are seeking, and waiting for the operator to search his database. It
   is additionally available by looking in a phone book published yearly
   on paper.

   The phone companies are able to offer this invaluable service because
   they administer the pool of phone numbers. However, this service has
   some limitations. For instance, you can find someone's number only if
   you know their name and the city or location in which they live. If
   two or more people have listings for the same name in the same
   locality, there is no additional information which with to select the
   correct number. In addition, the printed phone book can have
   information which is as much as a year out of date, and the phone
   company's internal directory can be as much as two weeks out of date.
   A third problem is that one actually has to call Directory assistance
   in a given area code to get information for that area; one cannot
   call a single number consistently.

   For businesses which advertise in the Yellow Pages, there is some
   additional information stored for each business; unfortunately, that
   information is unavailable through Directory Assistance and must be
   gleaned from the phone book.

2.2 Some currently available directory services on the Internet.

   As the Internet is comprised of a vast conglomeration of different
   people, computers, and computer networks, with none of the hierarchy
   imposed by the phone system on the area codes and exchange prefixes,
   any directory service must be able to deal with the fact that the
   Internet is not structured; for example, the hosts foo.com and



DISI Working Group                                              [Page 2]

RFC 1309              Technical Overview of X.500             March 1992


   v2.foo.com may be on opposite sides of the world, the .edu domain
   maps onto an enormous number of organizations, etc.  Let's look at a
   few of the services currently available on the Internet for directory
   type services.

2.2.1 The finger protocol.

   The finger protocol, which has been implemented for UNIX systems and
   a small number of other machines, allows one to "finger" a specific
   person or username to a host running the protocol. This is invoked by
   typing, for example, "finger [e-mail]". A certain set
   of information is returned, as this example from a UNIX system finger
   operation shows, although the output format is not specified by the
   protocol:

      Login name: clw                   In real life: Chris Weider
      Directory: /usr/clw               Shell: /bin/csh
      On since Jul 25 09:43:42          4 hours 52 minutes Idle Time
      Plan:
      Home: 971-5581

   where the first three lines of information are taken from the UNIX
   operating systems information and the line(s) of information
   following the "Plan:" line are taken from a file named .plan which
   each user modifies.  Limitations of the fingerd program include: a)
   One must already know which host to finger to find a specific person,
   b) since primarily UNIX machines run fingerd, people who reside on
   other types of operating systems are not locateable by this method,
   c) fingerd is often disabled on UNIX systems for security purposes,
   d) if one wishes to be found on more than one system, one must make
   sure that all the .plan files are consistent, and e) there is no way
   to search the .plan files on a given host to (for example) find
   everyone on mazatzal.merit.edu who works on X.500.  Thus, fingerd has
   a limited usefulness as a piece of the Internet Directory.

2.2.2 whois

   The whois utility, which is available on a wide of variety of
   systems, works by querying a centralized database maintained at the
   DDN NIC, which was for many years located at SRI International in
   Menlo Park, California, and is now located at GSI. This database
   contains a large amount of information which primarily deals with
   people and equipment which is used to build the Internet.  SRI (and
   now GSI) has been able to collect the information in the WHOIS
   database as part of its role as the Network Information Center for
   the TCP/IP portion of the Internet.

   The whois utility is ubiquitous, and has a very simple interface. A



DISI Working Group                                              [Page 3]

RFC 1309              Technical Overview of X.500             March 1992


   typical whois query look like:

      whois Reynolds

   and returns information like:

      Reynolds, John F. (JFR22) [e-mail]
                                           [phone] (DSN) 830-2604
      Reynolds, John J. (JJR40) [e-mail]
                                           [phone] (DSN) 992-3817
      Reynolds, John W. (JWR46) [e-mail]
                                           (DSN) 723-3358
      Reynolds, Joseph T. (JTR10)  [e-mail]
                                       011-63-47-885-3194 (DSN) 885-3194
      Reynolds, Joyce K. (JKR1) [e-mail]             [phone]
      Reynolds, Keith (KR35)    [e-mail]             [phone]
      Reynolds, Kenneth (KR94)                            [phone]
      Reynolds, Kevin A. (KR39)    [e-mail]
                                           [phone] (DSN) 789-5441
      Reynolds, Lee B. (LBR9)   [e-mail]   [phone]

      a further lookup on Joyce Reynolds with this command line:

      whois JKR1

   returns:

      Reynolds, Joyce K. (JKR1)               [e-mail]
         University of Southern California
         Information Sciences Institute
         4676 Admiralty Way
         Marina del Rey, CA 90292
         [phone]

         Record last updated on 07-Jan-91.

   The whois database also contains information about Domain Name System
   (DNS) and has some information about hosts, major regional networks,
   and large parts of the MILNET system.

   The WHOIS database is large enough and comprehensive enough to
   exhibit many of the flaws of a large centralized database: a) As the
   database is maintained on one machine, a processor bottleneck forces
   slow response during times of peak querying activity, even if many of
   these queries are unrelated, b) as the database is maintained on one
   machine, a storage bottleneck forces the database administrators to
   severely limit the amount of information which can be kept on each
   entry in the database, c) all changes to the database have to be



DISI Working Group                                              [Page 4]

RFC 1309              Technical Overview of X.500             March 1992


   mailed to a "hostmaster" and then physically reentered into the
   database, increasing both the turnaround time and the likelihood for
   a mistake in transcription.

2.2.3 The Domain Name System

   The Domain Name System is used in the Internet to keep track of host
   to IP address mapping. The basic mechanism is that each domain, such
   as merit.edu or k-12.edu, is registered with the NIC, and at time of
   registration, a primary and (perhaps) some secondary nameservers are
   identified for that domain. Each of these nameservers must provide
   host name to IP address mapping for each host in the domain. Thus,
   the nameservice is supplied in a distributed fashion. It is also
   possible to split a domain into subdomains, with a different
   nameserver for each subdomain.

   Although in many cases one uses the DNS without being aware of it,
   because humans prefer to remember names and not IP addresses, it is
   possible to interactively query the DNS with the nslookup utility. A
   sample session using the nslookup utility:

      home.merit.edu(1): nslookup
      Default Server:  merit.edu
      Address:  35.42.1.42

      > scanf.merit.edu
      Server:  merit.edu
      Address:  35.42.1.42

      Name:   scanf.merit.edu
      Address: 35.42.1.92

      > 35.42.1.92
      Server:  merit.edu
      Address: 35.42.1.42

      Name:  [35.42.1.92]
      Address: 35.42.1.92

   Thus, we can explicitly determine the address associated with a given
   host.  Reverse name mapping is also possible with the DNS, as in this
   example:









DISI Working Group                                              [Page 5]

RFC 1309              Technical Overview of X.500             March 1992


      home.merit.edu(2): traceroute ans.net
      traceroute to ans.net (147.225.1.2), 30 hops max, 40 byte packets
        1 t3peer (35.1.1.33) 11 ms 5 ms 5 ms
        2 enss (35.1.1.1) 6 ms 6 ms 6 ms
              .................
        9 192.77.154.1 (192.77.154.1) 51 ms 43 ms 49 ms
       10 nis.ans.net (147.225.1.2) 53 ms 53 ms 46 ms

   At each hop of the traceroute, the program attempts to do a reverse
   lookup through the DNS and displays the results when successful.

   Although the DNS has served superlatively for the purpose it was
   developed, i.e. to allow maintenance of the namespace in a
   distributed fashion, and to provide very rapid lookups in the