As per Relevance of the word technical, we have this rfc below:
Network Working Group C.
Request for Comments: 1309
FYI: 14 J.
S.
March 1992
Technical Overview of Directory
Using the X.500
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This document is an overview of the X.500 standard for people
familiar with the technology. It compares and contrasts
Services based on X.500 with several of the other Directory
currently in use in the Internet. This paper also describes
status of the standard and provides references for
information on X.500 implementations and technical information
A primary purpose of this paper is to illustrate the
functionality of the X.500 protocol and to show how it can be used
provide a global directory for human use, and can support
applications which would benefit from directory services, such
main programs
This FYI RFC is a product of the Directory Information
(pilot) Infrastructure Working Group (DISI). A combined effort
the User Services and the OSI Integration Areas of the
Engineering Task Force (IETF).
1.
As the pace of industry, science, and technological
quickened over the past century, it became increasingly probable
someone in a geographically distant location would be trying to
the same problems you were trying to solve, or that someone in
geographically distant location would have some vital
which impinged on your research or business. The stupendous
in the telecommunications industry, from telegraphs to telephones
computer networks, has alleviated the problem of being able
DISI Working Group [Page 1]
RFC 1309 Technical Overview of X.500 March 1992
communicate with another person, PROVIDED THAT YOU KNOW HOW TO
THEM
Thus, along with the expansion of the
infrastructure came the development of Directory Services. In
paper, we will discuss various models of directory services,
limitations of current models, and some solutions provided by
X.500 standard to these limitations
2 MODELS OF DIRECTORY
2.1 The telephone company's directory services
A model many people think of when they hear the words "
Services" is the directory service provided by the local
company. A local telephone company keeps an on-line list of the
of people with phone service, along with their phone numbers
their address. This information is available by calling up
Assistance, giving the name and address of the party whose number
are seeking, and waiting for the operator to search his database.
is additionally available by looking in a phone book published
on paper
The phone companies are able to offer this invaluable service
they administer the pool of phone numbers. However, this service
some limitations. For instance, you can find someone's number only
you know their name and the city or location in which they live.
two or more people have listings for the same name in the
locality, there is no additional information which with to select
correct number. In addition, the printed phone book can
information which is as much as a year out of date, and the
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
in a given area code to get information for that area; one
call a single number consistently
For businesses which advertise in the Yellow Pages, there is
additional information stored for each business; unfortunately,
information is unavailable through Directory Assistance and must
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
people, computers, and computer networks, with none of the
imposed by the phone system on the area codes and exchange prefixes
any directory service must be able to deal with the fact that
Internet is not structured; for example, the hosts foo.com
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
maps onto an enormous number of organizations, etc. Let's look at
few of the services currently available on the Internet for
type services
2.2.1 The finger protocol
The finger protocol, which has been implemented for UNIX systems
a small number of other machines, allows one to "finger" a
person or username to a host running the protocol. This is invoked
typing, for example, "finger clw@mazatzal.merit.edu". A certain
of information is returned, as this example from a UNIX system
operation shows, although the output format is not specified by
protocol
Login name: clw In real life: Chris
Directory: /usr/clw Shell: /bin/
On since Jul 25 09:43:42 4 hours 52 minutes Idle
Plan
Home: 971-5581
where the first three lines of information are taken from the
operating systems information and the line(s) of
following the "Plan:" line are taken from a file named .plan
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
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
sure that all the .plan files are consistent, and e) there is no
to search the .plan files on a given host to (for example)
everyone on mazatzal.merit.edu who works on X.500. Thus, fingerd
a limited usefulness as a piece of the Internet Directory
2.2.2
The whois utility, which is available on a wide of variety
systems, works by querying a centralized database maintained at
DDN NIC, which was for many years located at SRI International
Menlo Park, California, and is now located at GSI. This
contains a large amount of information which primarily deals
people and equipment which is used to build the Internet. SRI (
now GSI) has been able to collect the information in the
database as part of its role as the Network Information Center
the TCP/IP portion of the Internet
The whois utility is ubiquitous, and has a very simple interface.
DISI Working Group [Page 3]
RFC 1309 Technical Overview of X.500 March 1992
typical whois query look like
whois
and returns information like
Reynolds, John F. (JFR22) 532JFR@DOM1.NWAC.SEA06.NAVY.
(702) 426-2604 (DSN) 830-2604
Reynolds, John J. (JJR40) amsel-lg-pl-a@MONMOUTH-EMH3.ARMY.
(908) 532-3817 (DSN) 992-3817
Reynolds, John W. (JWR46) EAAV-AP@SEOUL-EMH1.ARMY.
(DSN) 723-3358
Reynolds, Joseph T. (JTR10) JREYNOLDS@PAXRV-NES.NAVY.
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.
(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 JKR
returns
Reynolds, Joyce K. (JKR1) JKREY@ISI.
University of Southern
Information Sciences
4676 Admiralty
Marina del Rey, CA 90292
(310) 822-1511
Record last updated on 07-Jan-91.
The whois database also contains information about Domain Name
(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
exhibit many of the flaws of a large centralized database: a) As
database is maintained on one machine, a processor bottleneck
slow response during times of peak querying activity, even if many
these queries are unrelated, b) as the database is maintained on
machine, a storage bottleneck forces the database administrators
severely limit the amount of information which can be kept on
entry in the database, c) all changes to the database have to
DISI Working Group [Page 4]
RFC 1309 Technical Overview of X.500 March 1992
mailed to a "hostmaster" and then physically reentered into
database, increasing both the turnaround time and the likelihood
a mistake in transcription
2.2.3 The Domain Name
The Domain Name System is used in the Internet to keep track of
to IP address mapping. The basic mechanism is that each domain,
as merit.edu or k-12.edu, is registered with the NIC, and at time
registration, a primary and (perhaps) some secondary nameservers
identified for that domain. Each of these nameservers must
host name to IP address mapping for each host in the domain. Thus
the nameservice is supplied in a distributed fashion. It is
possible to split a domain into subdomains, with a
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
possible to interactively query the DNS with the nslookup utility.
sample session using the nslookup utility
home.merit.edu(1):
Default Server: merit.
Address: 35.42.1.42
> scanf.merit.
Server: merit.
Address: 35.42.1.42
Name: scanf.merit.
Address: 35.42.1.92
> 35.42.1.92
Server: merit.
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
host. Reverse name mapping is also possible with the DNS, as in
example
DISI Working Group [Page 5]
RFC 1309 Technical Overview of X.500 March 1992
home.merit.edu(2): traceroute ans.
traceroute to ans.net (147.225.1.2), 30 hops max, 40 byte
1 t3peer (35.1.1.33) 11 ms 5 ms 5
2 enss (35.1.1.1) 6 ms 6 ms 6
.................
9 192.77.154.1 (192.77.154.1) 51 ms 43 ms 49
10 nis.ans.net (147.225.1.2) 53 ms 53 ms 46
At each hop of the traceroute, the program attempts to do a
lookup through the DNS and displays the results when successful
Although the DNS has served superlatively for the purpose it
developed, i.e. to allow maintenance of the namespace in
distributed fashion, and to provide very rapid lookups in
namespace, there are, of course, some limitations. Although there
been some discussion of including other types of information in
DNS, to find a given person at this time, assuming you know where
works, you have to use a combination of the DNS and finger to
make a stab at finding her. Also, the DNS has very limited
capabilities right now. The lack of search capabilities alone
that we cannot provide a rich Directory Service through the DNS
3: THE X.500 MODEL OF DIRECTORY
X.500 is a CCITT 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
of the Directory, so updates and maintenance can be done instantly
* Powerful Searching Capabilities
X.500 provides powerful searching facilities that allow users
construct arbitrarily complex queries
* Single Global Namespace
Much like the DNS, X.500 provides a single homogeneous
to users. The X.500 namespace is more flexible and
than the DNS
* Structured Information Framework
X.500 defines the information framework used in the directory
allowing local extensions
DISI Working Group [Page 6]
RFC 1309 Technical Overview of X.500 March 1992
* Standards-Based Directory
As X.500 can be used to build a standards-based directory
applications which require directory information (e-mail
automated resource locators, special-purpose directory tools
can access a planet's worth of information in a uniform manner
no matter where they are based or currently running
3.1 Acronym City, or How X.500
The '88 version of the X.500 standard talks about 3 models
to build the X.500 Directory Service: the Directory Model,
Information Model, and the Security Model. In this section, we
provide a brief overview of the Directory and Information
sufficient to explain the vast functionality of X.500.
3.1.1 The Information
To illustrate the Information Model, we will first show
information is held in the Directory, then we will show what types
information can be held in the Directory, and then we will see
the information is arranged so that we can retrieve the
pieces from the Directory
3.1.1.1
The primary construct holding information in the Directory is
"entry". Each Directory entry contains information about one object
for example, a person, a computer network, or an organization.
entry is built from a collection of "attributes", each of which
a single piece of information about the object. Some attributes
might be used to build an entry for a person would be "surname",
"telephonenumber", "postaladdress", etc. Each attribute has
associated "attribute syntax", which describes the type of data
attribute contains, for example, photo data, a time code, or a
of letters and numbers. As an example, let's look at part of an
for a person
Entry for John Smith contains
attribute ---> surName= Smith <--- attribute
|---> telephoneNumber= 999-9999 <--- attribute
|---> title= Janitor <--- attribute
...
The attribute syntax for the surName attribute would
CaseIgnoreString, which would tell X.500 that surName could
any string, and case would not matter; the attribute syntax for
telephoneNumber attribute would be TelephoneNumber, which
DISI Working Group [Page 7]
RFC 1309 Technical Overview of X.500 March 1992
specify that telephoneNumber could contain a string composed
digits, dashes, parenthesis, and a plus sign. The attribute
for the title attribute would also be CaseIgnoreString. A
analogy in database terms for what we've seen so far might be
think of a Directory entry as a database record, an attribute as
field in that record, and an attribute syntax as a field
(decimal number, string) for a field in a record
3.1.1.2 Object
At this point in our description of the information model, we have
way of knowing what type of object a given entry represents. X.500
uses the concept of an "object class" to specify that information
and an attribute named "objectClass" which each entry contains
specify to which object class(es) the entry belongs
Each object class in X.500 has a definition which lists the set
mandatory attributes, which must be present, and a set of
attributes, which may be present, in an entry of that class. An
object class A may be a subclass of another class B, in which
object class A inherits all the mandatory and optional attributes
B in addition to its own
The object classes in X.500 are arranged in a hierarchical
according to class inheritance; the following diagram shows a part
the object class hierarchy
DISI Working Group [Page 8]
RFC 1309 Technical Overview of X.500 March 1992
_____________
| | "top" has one
| top | attribute "objectClass",
|_____________| and nooptional attributes
| | |
| | | every other object class is
________________| | | subclass of "top"...
| | ...
______|________ _____|_______
| | | |"organization" inherits
| country | | organization |mandatory attribute
|_______________| |_______________|"top", "objectClass"; adds
more mandatory attribute "O
"country" inherits one (for organization), and
mandatory attribute from "top", many optional attributes.
"objectClass", adds one more subclass of "organization
mandatory attribute "c" (for would inherit all of
country), and has two optional mandatory and
attributes, "description" and attributes from "organization
"searchGuide". Any subclass of including the attribute
"country" would inherit all of the "organization"
mandatory and optional attributes from "top".
of the "country" class,
the attribute which "country
inherited from "top".
Figure 1.
One major benefit of the object class concept is that it is in
cases very easy to create a new object class which is only a
modification or extension of a previous class. For example, if I
already defined an object class for "person" which contains
person's name, phone number, address, and fax number, I can
define an "Internet person" object class by defining "
person" as a subclass of "person", with the additional
attribute of "e-mail address". Thus in my definition of the "
Person" object class, all my "person" type attributes are
from "person". There are other benefits which are beyond the scope
this paper
3.1.1.3 X.500's namespace
X.500 hierarchically organizes the namespace in the
Information Base (DIB); recall that this hierarchical organization
called the Directory Information Tree (DIT). Each entry in the
occupies a certain location in the DIT. An entry which has
children is called a leaf entry, an entry which has children
called a non-leaf node. Each entry in the DIT contains one or
DISI Working Group [Page 9]
RFC 1309 Technical Overview of X.500 March 1992
attributes which together comprise the Relative Distinguished
(RDN) of that entry, there is a "root" entry (which has
attributes, a special case) which forms the base node of the DIT.
Distinguished Name of a specific entry is the sequence of RDNs of
entries on the path from the root entry to the entry in question.
diagram here will help to clarify this
Level of DIT Root RDN Distinguished
root * nothing { }
/ | \
country (other / | \
things at this / | \ c=us {c=us
level) c=gb c=us c=
/ | \
/ | \
/ | \
organization o=SRI o=Merit o=DEC o=Merit {c=us, o=Merit
(other things / | \
at this level) / | \
/ | \
Third level cn=Chris Weider cn=Chris Weider {c=us, o=Merit
cn=Chris Weider
Figure 2: Building a DN from RDNs (adapted from
diagram in the X.500 (88) Blue Book
Each entry in this tree contains more attributes than have been
here, but in each case only one attribute for each entry has
used for that entry's RDN. As noted above, any entry in the
could use more than one attribute to build its RDN. X.500 also
the use of alias names, so that the entry {c=us, o=Merit, cn=
Weider} could be also found through an alias entry such as {c=us
o=SRI, ou=FOX Project, cn=Drone 1} which would point to the
entry
3.1.2 The Directory
Now that we've seen what kinds of information can be kept in
Directory, we should look at how the Directory stores
information and how a Directory users accesses the information.
are two components of this model: a Directory User Agent (DUA),
accesses the Directory on behalf of a user, and the Directory
Agent, which can be viewed as holding a particular subset of the DIB
and can also provide an access point to the Directory for a DUA
Now, the entire DIB is distributed through the world-wide
of DSAs which form the Directory, and the DSAs employ two
DISI Working Group [Page 10]
RFC 1309 Technical Overview of X.500 March 1992
to allow this distribution to be transparent to the user,
"chaining" and "referral". The details of these two techniques
take up another page, so it suffices to say that to each user,
appears that the entire global directory is on her desktop. (
course, if the information requested is on the other side of
world, it may seem that the desktop directory is a bit slow for
request...)
3.2 The functionality of X.500
To describe the functionality of X.500, we will need to
three stages in the evolution of X.500: 1) the 1988 standard, 2)
X.500 as implemented in QUIPU, and 3) the (proposed) 1992 standard
We will list some of the features described in the 1988 standard
show how they were implemented in QUIPU, and discuss where the 1992
standard will take us. The QUIPU implementation was chosen
a) it is widely used in the U.S. and European Directory
Pilot projects, and b) it works well. For a survey of other X.500
implementations and a catalogue of DUAs, see [Lang].
3.2.1 Functionality in X.500 (88)
There are a number of advantages that the X.500 Directory
simply by virtue of the fact that it is distributed, not limited to
single machine. Among these are
* An enormously large potential namespace
Since the Directory is not limited to a single machine,
hundreds of machines can be used to store Directory entries
* The ability to allow local administration of local data
An organization or group can run a local DSA to master
information, facilitating much more accurate data
the Directory
The functionality built into the X.500(88) standard includes
* Advanced searching capabilities
The Directory supports arbitrarily complex searches at
attribute level. As the object classes a specific
belongs to is maintained in the objectClass attribute,
also allows Directory searches for specific types of objects
Thus, one could search the c=US subtree for anyone with a
name beginning with S, who also has either a fax number in
(313) area code or an e-mail address ending in umich.edu
This feature of X.500 also helps to provide the
functionality for a Yellow Pages service
DISI Working Group [Page 11]
RFC 1309 Technical Overview of X.500 March 1992
* A uniform namespace with local extensibility
The Directory provides a uniform namespace, but
specialized directories can also be implemented.
defined extensions can include new object classes,
attributes, and new attribute types
* Security issues
The X.500 (88) standards define two types of security
Directory data: Simple Authentication (which uses passwords),
and Strong Authentication (which uses cryptographic keys).
Simple authentication has been widely implemented,
authentication has been less widely implemented. Each
these authentication techniques are invoked when a user
process attempts a Directory operation through a DUA
In addition to the global benefits of the X.500 standard, there
many local benefits. One can use their local DSA for company
campus wide directory services; for example, the University
Michigan is providing all the campus directory services
X.500. The DUAs are available for a wide range of platforms
including X-Windows systems and Macintoshes
3.2.2 Functionality added by QUIPU
Functionality beyond the X.500 (88) standard implemented by
includes
* Access control lists
An access control list is a way to provide security for
attribute of an entry. For example, each attribute in a
entry can be permitted for detect, compare, read, and
permissions based on the reader's membership in various groups
For example, one can specify that some information in a
entry is public, some can be read only by members of
organization, and some can only be modified by the owner
the entry
* Replication
Replication provides a method whereby frequently
information in a DSA other than the local one can be kept
the local DSA on a "slave" basis, with updates of the "slave
data provided automatically by QUIPU from the "master"
residing on the foreign DSA. This provides alternate
points to that data, and can make searches and
more rapid as there is much less overhead in the form
network transport
DISI Working Group [Page 12]
RFC 1309 Technical Overview of X.500 March 1992
3.3 Current limitations of the X.500 standard and implementations
As flexible and forward looking as X.500 is, it certainly was
designed to solve everyone's needs for all time to come. X.500 is
a general purpose database, nor is it a Data Base Management
(DBMS). X.500 defines no standards for output formats, and
certainly doesn't have a report generation capability. The
mechanisms are not yet in place for the Directory to
information about itself, thus new attributes and new attribute
are rather slowly distributed (by hand).
Searches can be slow, for two reasons: a) searches across a
distributed portion of the namespace (c=US, for example) has a
which is partially caused by network transmission times, and can
compounded by implementations that cache the partial search
until everyone has reported back, and b) some implementations
slow at searching anyway, and this is very sensitive to such
as processor speed and available swap space. Another
"problem" is a tradeoff with security for the Directory:
implementations have an administrative limit on the amount
information which can be returned for a specific search.
example, if a search returns 1000 hits, 20 of those might
displayed, with the rest lost. Thus a person performing a
search might have to perform a number of small searches. This
implemented because an organization might want to make it hard
"troll" for the organization's entire database
Also, there is at the moment no clear consensus on the ideal shape
the DIT, or on the idea structure of the object tree. This can
it hard to add to the current corpus of X.500 work, and the number
RFCs on various aspects of the X.500 deployment is growing monthly
Despite this, however, X.500 is very good at what it was designed
do; i.e., to provide primary directory services and "
location" for a wide band oftypes of information
3.4 Things to be added in X.500 (92).
The 1988 version of the X.500 standard proved to be quite
to start building a Directory Service. However, many of the
functions implemented in QUIPU were necessary if the Directory
to function in a reasonable manner. X.500 (92) will
formalized and standardized versions of those advances,
* A formalized replication procedure
* Enhanced searching capacities
DISI Working Group [Page 13]
RFC 1309 Technical Overview of X.500 March 1992
* Formalization of access control mechanisms, including
control lists
Each of these will provide a richer Directory, but you don't have
wait for them! You can become part of the Directory today
4: WHAT X.500 CAN DO FOR YOU
4.1 Current applications of X.500
X.500 is filling Directory Services needs in a large number
countries. As a directory to locate people, it is provided in
U.S. as the White Pages Pilot Project, run by PSI, and in
under the PARADISE Project as a series of nation-wide pilots. It
also being used by the FOX Project in the United States to
WHOIS services for people and networks, and to provide directories
objects as disparate as NIC Profiles and a pilot K-12
directory. It is also being investigated for its ability to
resource location facilities and to provide source location for
servers. In fact, in almost every area where one could
needing a directory service (particularly for distributed
services), X.500 is either providing those services or being
to provide those services
In particular, X.500 was envisioned by its creators as
directory services for electronic mail, specifically for X.400. It
being used in this fashion today at the University of Michigan
everyone at the University has a unified mail address, e.g
Chris.Weider@umich.edu. An X.500 server then reroutes that mail
the appropriate user's real mail address in a transparent fashion
Similarly, Sprint is using X.500 to administrate the address
for its internal X.400 mail systems
Those of us working on X.500 feel that X.500's strengths lie
providing directory services for people and objects, and
providing primary resource location for a large number of
services. We think that X.500 is a major component (though not
only one) of a global Yellow Pages service. We would also like
encourage each of you to join your national pilot projects; the
coverage we can get, the easier you will be able to find the
you need to contact
DISI Working Group [Page 14]
RFC 1309 Technical Overview of X.500 March 1992
5. For Further
For further information, the authors recommend the
documents
Weider, C., and J. Reynolds, "Executive Introduction to
Services Using the X.500 Protocol", FYI 13, RFC 1308, ANS, ISI
March 1992.
Lang, R., and R. Wright, Editors, "A Catalog of Available X.500
Implementations", FYI 11, RFC 1292, SRI International,
Berkeley Laboratory, January 1992.
Barker, P., and S. Hardcastle-Kille, "The COSINE and
X.500 Schema", RFC 1274, University College London, November 1991.
Hardcastle-Kille, S., "Replication Requirements to provide
Internet Directory using X.500", RFC 1275, University
London, November, 1991.
Hardcastle-Kille, S., "Replication and Distributed
extensions to provide an Internet Directory using X.500",
1276, University College London, November 1991.
Hardcastle-Kille, S., "Encoding Network Addresses to
operation over non-OSI lower layers", RFC 1277, University
London, November 1991.
Hardcastle-Kille, S., " A string encoding of
Address", RFC 1278, University College London, November 1991.
Hardcastle-Kille, S., "X.500 and Domains", RFC 1279,
College London, November 1991.
6. Security
Security issues are discussed in section 3.
DISI Working Group [Page 15]
RFC 1309 Technical Overview of X.500 March 1992
7. Authors'
Chris
Advanced Network and Services, Inc
2901 Hubbard G-1
Ann Arbor, MI 48105-2437
Phone (313) 663-2482
E-mail: weider@ans.
Joyce K.
Information Sciences
University of Southern
4676 Admirality
Marina del Rey, CA 90292
Phone: (310) 822-1511
EMail: jkrey@isi.
Sergio
Princeton
6 von Neumann
Princeton, NJ 08544
Phone: (609) 258-2400
Email: heker@nisc.jvnc.
DISI Working Group [Page 16]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
