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 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 clw@mazatzal.merit.edu". 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 typical whois query look like:

      whois Reynolds

and returns information like:

      Reynolds, John F. (JFR22) 532JFR@DOM1.NWAC.SEA06.NAVY.MIL
                                           (702) 426-2604 (DSN) 830-2604
      Reynolds, John J. (JJR40) amsel-lg-pl-a@MONMOUTH-EMH3.ARMY.MIL
                                           (908) 532-3817 (DSN) 992-3817
      Reynolds, John W. (JWR46) EAAV-AP@SEOUL-EMH1.ARMY.MIL
                                           (DSN) 723-3358
      Reynolds, Joseph T. (JTR10)  JREYNOLDS@PAXRV-NES.NAVY.MIL
                                       011-63-47-885-3194 (DSN) 885-3194
      Reynolds, Joyce K. (JKR1) JKREY@ISI.EDU             (213) 822-1511
      Reynolds, Keith (KR35)    keithr@SCO.CO             (408) 425-7222
      Reynolds, Kenneth (KR94)                            (502) 454-2950
      Reynolds, Kevin A. (KR39)    REYNOLDS@DUGWAY-EMH1.ARMY.MIL
                                           (801) 831-5441 (DSN) 789-5441
      Reynolds, Lee B. (LBR9)   reynolds@TECHNET.NM.ORG   (505) 345-6555

      a further lookup on Joyce Reynolds with this command line:

      whois JKR1

   returns:

      Reynolds, Joyce K. (JKR1)               JKREY@ISI.EDU
         University of Southern California
         Information Sciences Institute
         4676 Admiralty Way
         Marina del Rey, CA 90292
         (310) 822-1511

         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 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:

      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 namespace, there are, of course, some limitations. Although there has been some discussion of including other types of information in the DNS, to find a given person at this time, assuming you know where she works, you have to use a combination of the DNS and finger to even make a stab at finding her. Also, the DNS has very limited search capabilities right now. The lack of search capabilities alone shows that we cannot provide a rich Directory Service through the DNS.