Paper number 1 from DISI (Executive Overview)

["Chris Weider" <clw>]

Here it is, gang...
Sorry it's so hideously close to Atlanta time.

Directory Information Services					Chris Weider
(pilot) Infrastructure Working Group				Merit Network
INTERNET--DRAFT							Joyce Reynolds
								ISI
								Sergio Heker
								JvNC
								July 1991

  	An Executive Introduction to Directory Services 
		Using the X.500 Protocol

Status of this Memo

This paper expounds on the pressing need for Directory Services and
proposes a solution to the problem in the form of the X.500 protocols.

This document is for informational purposes only and is not intended to 
mandate the use of a particular protocol, implementation, or philosophy.
Distribution is unlimited.


INTERNET--DRAFT        Executive Introduction to X.500		July 1991

1: INTRODUCTION

As the pace of industry, science, and technological develpment 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 communicate with other people, PROVIDED THAT YOU KNOW HOW TO REACH THAT
PERSON. 

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 consistantly.

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 heirarchy imposed by
the phone system on the area codes and exchange prefixes, the directory service
must be able to deal with the fact that the machines foo.com and v2.foo.com
may be on opposite sides of the world, and that the .edu domain maps onto
an enormous number of organizations. Let's look at a few of the services 
currently available on the Internet for directory type services.


INTERNET--DRAFT        Executive Introduction to X.500          July 1991

2.2.1 fingerd

The fingerd utility, which is available on many UNIX systems, allows one to
'finger' a specific person or username at a given UNIX host. This is invoked,
for example, by typing 'finger [e-mail]'. This returns a set
of information like this: 

Login name: clw                         In real life: Chris Weider
Directory: /usr/clw                     Shell: /bin/csh
On since Jul 25 09:43:42 on console     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) only available on UNIX systems, which is an
ENORMOUS limitation, b) fingerd is often disabled on UNIX systems for security
purposes; c) If one wishes to be reached on more than one system, one must
make sure all the .plan files are consistent, and d) there is no way to 
search the .plan files on a given system to (for example) look for everyone on
mazatzal.merit.edu who works on X.500.  Thus, fingerd cannot be used as the
basis of a worldwide directory.

2.2.2 whois

The whois utility, which is available on a wide of variety of systems, works
by querying a centralized database located at SRI International in Menlo Park,
California. This database contains a large amount of information which
primarily deals with people and equipment which is used to build the Internet.
For example, in many cases a network administrator will be in the WHOIS 
database, while the administrator's backup, boss, or subordinates will not
be in the WHOIS database. SRI has been able to collect this information 
as part of its role as the Network Information Center for the TCP/IP
portion of the Internet. Every organization wishing to run a TCP/IP network
must apply to the NIC for their network numbers.

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)       [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]


INTERNET--DRAFT        Executive Introduction to X.500          July 1991

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. 

As the WHOIS service currently works, all the changes to this database are 
made by sending update to the hostmaster at nic.ddn.mil.  Then, they are 
processed by a person who reads the message and types it into the database.
As the Internet has grown and grown, the overhead involved with this
process threatens to hamper timely updates of the database. Also, only a fixed
amount of information can be kept on any one machine, no matter how large.

3: THE X.500 MODEL OF DIRECTORY SERVICE

X.500 is an OSI protocol which is designed to build a distributed, global
directory.  It offers the following features:
  
	* Decentralized Maintenance:
	Each site running X.500 is responsible ONLY for its local part of the
	Directory, so updates and maintenance can be done instantly.

	* Authoritative Local Information:
	  Since each site is responsible only for local information, backups
	need only be kept locally.

	* Structured Directory Information:
	  Since each site's information resides in a specified location in 
	the global heirarchy, Directory searches are made much more efficient.

3.1 How it works.

The abstract X.500 server contains two pieces: a Directory User Agent (DUA)
and a Directory Service Agent (DSA).  The worldwide collection of DSAs form
a vast distributed directory; the fact that the DSAs are heirarchically 
ordered allows each DSA to contact all the others without maintaining
huge location tables. The heirarchical arrangement of DSAs is called the
Directory Information Tree or DIT.

 The DIT has a null root "@", and an array of branches "o=Internet", which 
contains information about the Internet; "c=uk", which contains information
about the U.K., etc. Each of these braches has subbranches, and one can

INTERNET--DRAFT        Executive Introduction to X.500          July 1991

traverse the DIT to either a) locate the desired information directly, or
b) narrow the breadth of searching. As an example, NSFNet's site contact
information resides under "@o=Internet@ou=Site Contacts".  

Access to the DIT is gained by using a Directory User Agent, or DUA.  Each
DUA is configured to talk to the closest DSA. If a DUA asks the local DSA
for information which the local DSA does not contain, the DSA will either
a) tell the DUA where the information is and how to contact the DSA which
contains it ( a process known as 'referral' ) or b) pass on the request to
the required DSA without informing the DUA ( a process known as 'chaining' ).
In either case, the local DSA does not need to keep a large location table
because it knows where its parent node's DSA is.

As an example, if I start a DUA to talk to the Directory, my DUA will contact
the local DSA, which contains the information for, say, @c=US@o=Foo Corp.
This DSA will know where all the children of @o=Foo Corp are, and it
will also know which DSA contains @c=US.  If I ask the DUA to move to 
@c=us@o=Mega Corp., it will talk to the DSA which contains @c=US, which will
tell it where @c=us@o=Mega Corp. is.  Thus, the Directory traverses the tree
until it finds a DSA which can give you the information you have requested.

3.2 The incredible functionality of X.500

X.500, while not the greatest thing since sliced bread (you can't make a 
sandwich with X.500), is an enormously flexible system.  Some of the 
fuctionality includes:

 a)  The ability to keep large amounts of data on people, organizations, and
     resources.

 b)  The ability to search those large amounts of data in a flexible manner.

 c)  The ability to rapidly retrieve individual entries once thay have been
     located.

 d)  The ability to provide a truly authoritative Directory as each person and
     organization is responsible for their own entry.

 e)  The ability to allow each organization to determine to which extent they
     would like to participate.

 f)  The ability to allow external access to an organizations data in a very
     secure fashion.

 g)  The potential to build a truly global, standards-based Directory.

Taking each of these points in turn:

 a) Each type of entry in the Directory contains a certain number of allowable
"attributes". Attributes can be viewed as 'fields' in the person's record.
For example, a person's entry contains their name, telephone and FAX numbers,
their title, their postal and e-mail address, their favorite drink, and a 
large number of other attributes. Searches can be made on each attribute or
any combination of attributes.
  


INTERNET--DRAFT        Executive Introduction to X.500          July 1991

 b) Each subtree of the DIT is searchable, and allows wildcarding and soundex
matching on many attributes.

 c) Retrieval of an individual's record is very rapid; the major time 
constraint is the speed of the network transmitting the request.

 d) As each person and organization can be made responsible for the update of 
their own information, and the updates do not go through a central updating
authority, each person's data can be as timely as they like.

 e) The X.500 standard does not mandate the amount of information kept in
each entry, so an organization can determine how much data they'd like to
keep.  In addition, the security features of X.500 enable, for example,
those inside FOOCorp to read all of the attributes of their fellow employees,
while allowing access only to the name and telephone number attributes to
those outside FOO Corp.

 f) The X.500 standards define an 'access control list' method of security
which allows setting read, write, compare, and detect access for individual
attributes in an entry. The compare access sets permissions for searches
against a given attribute, while detect access allows detection of the
existence of a given attribute. This schema allows almost infinitely flexible
access control, and is simple to invoke.  In addition, there are mechanisms
for password control of read and write capabilities at an individual
entry level.

 g) The potential to build a truly global, standards-based Directory is perhaps
the most exciting advantage of X.500. Even at this moment one can use a single
interface program to access Directory data from London to Melbourne. As more
organizations (including yours!) bring up Directories, they are automatically
tied into the world-wide mesh. Also, work is proceeding apace to incorporate
new types of Directory information, from on-line resource information to
directories of special interest news groups, which is making the Directory
the foundation of a global 'yellow pages' service.

In addition to the global benefits of X.500, there are many local benefits.
One can use their local DSA for company or campus wide directory services;
for example, the University of Michigan is providing all the campus directory
services through X.500.  The DUAs are available for many platforms, including
X windows, Macintoshes, and IBM PC compatibles.  Some organizations are 
also pioneering automated Directory services through X.500 for such things
as email address lookup and resoultions, and for automated call forwarding.
Also, several organizations are laying the framework for an e-mail based
interface to the Directory, which will allow those without the resources to 
run DSAs to access the Directory.

3.3 Current limitations of the X.500 standard and implementations.

As flexible and forward-looking as X.500 is, it certainly was not designed
to solve everyone's needs for all time to come. X.500 is not a database
(although there is a NIST project to build an X.500 front end to a SQL
database) and it is not a Data Base Management System (DBMS). X.500 defines
no standards for output formats, and it certainly doesn't have a report
generation capability. Searches across widely distributed sets of subtrees
can take quite a while (for example, searching @c=US for 'surname= Smith').
Finally, X.500 was not designed to provide more specialized forms of 
information retrieval, as say Z39.50 is designed, and X.500 does not currently
have all the functionality required to build robust Yellow Pages service.
However, X.500 is very good at what it is designed to do; i.e. to provide
primary directory services for a wide band of types of information.


INTERNET--DRAFT        Executive Introduction to X.500          July 1991

4: FOR FURTHER INFORMATION AND SOFTWARE

4.1 For further information.

For further information, the authors recommend the Ruth Lang and Russ Wright
DISI paper for a catalog of currently available implementations of X.500,
and the Third DISI paper for an overview of some advanced applications 
involving X.500. More technical information about X.500 can be found in the
standard, and papers available from the OSI-DS working group detail the
current extensions and technical decisions for the Internet part of the 
Directory.

5: WHO WE ARE

5.1 Author's addresses

     Chris Weider, [e-mail]
     1075 Beal Avenue, 
     Ann Arbor, MI 48109

     Joyce Reynolds, [e-mail]
     University of Southern California
     Information Sciences Institute
     4676 Admirality Way
     Marina del Rey, CA 90292

     Sergio Heker, [e-mail]
     Princeton University
     6 von Neumann Hall
     Princeton, NJ 08544