summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1309.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1309.txt')
-rw-r--r--doc/rfc/rfc1309.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc1309.txt b/doc/rfc/rfc1309.txt
new file mode 100644
index 0000000..123eb26
--- /dev/null
+++ b/doc/rfc/rfc1309.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+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 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
+
+
+
+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) 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
+
+
+
+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
+ 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.
+
+3: THE X.500 MODEL OF DIRECTORY SERVICE
+
+ 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 part
+ of the Directory, so updates and maintenance can be done instantly.
+
+ * Powerful Searching Capabilities:
+ X.500 provides powerful searching facilities that allow users to
+ construct arbitrarily complex queries.
+
+ * Single Global Namespace:
+ Much like the DNS, X.500 provides a single homogeneous namespace
+ to users. The X.500 namespace is more flexible and expandable
+ 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 Works
+
+ The '88 version of the X.500 standard talks about 3 models required
+ to build the X.500 Directory Service: the Directory Model, the
+ Information Model, and the Security Model. In this section, we will
+ provide a brief overview of the Directory and Information Models
+ sufficient to explain the vast functionality of X.500.
+
+3.1.1 The Information Model
+
+ To illustrate the Information Model, we will first show how
+ information is held in the Directory, then we will show what types of
+ information can be held in the Directory, and then we will see how
+ the information is arranged so that we can retrieve the desired
+ pieces from the Directory.
+
+3.1.1.1 Entries
+
+ The primary construct holding information in the Directory is the
+ "entry". Each Directory entry contains information about one object;
+ for example, a person, a computer network, or an organization. Each
+ entry is built from a collection of "attributes", each of which holds
+ a single piece of information about the object. Some attributes which
+ might be used to build an entry for a person would be "surname",
+ "telephonenumber", "postaladdress", etc. Each attribute has an
+ associated "attribute syntax", which describes the type of data that
+ attribute contains, for example, photo data, a time code, or a string
+ of letters and numbers. As an example, let's look at part of an entry
+ for a person.
+
+ Entry for John Smith contains:
+
+ attribute ---> surName= Smith <--- attribute value
+ |---> telephoneNumber= 999-9999 <--- attribute value
+ |---> title= Janitor <--- attribute value
+ ...
+
+ The attribute syntax for the surName attribute would be
+ CaseIgnoreString, which would tell X.500 that surName could contain
+ any string, and case would not matter; the attribute syntax for the
+ telephoneNumber attribute would be TelephoneNumber, which would
+
+
+
+DISI Working Group [Page 7]
+
+RFC 1309 Technical Overview of X.500 March 1992
+
+
+ specify that telephoneNumber could contain a string composed of
+ digits, dashes, parenthesis, and a plus sign. The attribute syntax
+ for the title attribute would also be CaseIgnoreString. A good
+ analogy in database terms for what we've seen so far might be to
+ think of a Directory entry as a database record, an attribute as a
+ field in that record, and an attribute syntax as a field type
+ (decimal number, string) for a field in a record.
+
+3.1.1.2 Object Classes
+
+ At this point in our description of the information model, we have no
+ 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 to
+ specify to which object class(es) the entry belongs.
+
+ Each object class in X.500 has a definition which lists the set of
+ mandatory attributes, which must be present, and a set of optional
+ attributes, which may be present, in an entry of that class. An given
+ object class A may be a subclass of another class B, in which case
+ object class A inherits all the mandatory and optional attributes of
+ B in addition to its own.
+
+ The object classes in X.500 are arranged in a hierarchical manner
+ according to class inheritance; the following diagram shows a part of
+ the object class hierarchy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DISI Working Group [Page 8]
+
+RFC 1309 Technical Overview of X.500 March 1992
+
+
+ _____________
+ | | "top" has one mandatory
+ | top | attribute "objectClass",
+ |_____________| and nooptional attributes.
+ | | |
+ | | | every other object class is a
+ ________________| | | subclass of "top"...
+ | | ...
+ ______|________ _____|_______
+ | | | |"organization" inherits one
+ | country | | organization |mandatory attribute from
+ |_______________| |_______________|"top", "objectClass"; adds one
+ more mandatory attribute "O"
+ "country" inherits one (for organization), and has
+ mandatory attribute from "top", many optional attributes. Any
+ "objectClass", adds one more subclass of "organization"
+ mandatory attribute "c" (for would inherit all of the
+ country), and has two optional mandatory and optional
+ attributes, "description" and attributes from "organization"
+ "searchGuide". Any subclass of including the attribute which
+ "country" would inherit all of the "organization" inherited
+ mandatory and optional attributes from "top".
+ of the "country" class, including
+ the attribute which "country"
+ inherited from "top".
+
+ Figure 1.
+
+ One major benefit of the object class concept is that it is in many
+ cases very easy to create a new object class which is only a slight
+ modification or extension of a previous class. For example, if I have
+ already defined an object class for "person" which contains a
+ person's name, phone number, address, and fax number, I can easily
+ define an "Internet person" object class by defining "Internet
+ person" as a subclass of "person", with the additional optional
+ attribute of "e-mail address". Thus in my definition of the "Internet
+ Person" object class, all my "person" type attributes are inherited
+ from "person". There are other benefits which are beyond the scope of
+ this paper.
+
+3.1.1.3 X.500's namespace.
+
+ X.500 hierarchically organizes the namespace in the Directory
+ Information Base (DIB); recall that this hierarchical organization is
+ called the Directory Information Tree (DIT). Each entry in the DIB
+ occupies a certain location in the DIT. An entry which has no
+ children is called a leaf entry, an entry which has children is
+ called a non-leaf node. Each entry in the DIT contains one or more
+
+
+
+DISI Working Group [Page 9]
+
+RFC 1309 Technical Overview of X.500 March 1992
+
+
+ attributes which together comprise the Relative Distinguished Name
+ (RDN) of that entry, there is a "root" entry (which has no
+ attributes, a special case) which forms the base node of the DIT. The
+ Distinguished Name of a specific entry is the sequence of RDNs of the
+ entries on the path from the root entry to the entry in question. A
+ diagram here will help to clarify this:
+
+Level of DIT Root RDN Distinguished Name
+
+root * nothing { }
+ / | \
+country (other / | \
+things at this / | \ c=us {c=us}
+level) c=gb c=us c=ca
+ / | \
+ / | \
+ / | \
+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 a
+ diagram in the X.500 (88) Blue Book)
+
+ Each entry in this tree contains more attributes than have been shown
+ here, but in each case only one attribute for each entry has been
+ used for that entry's RDN. As noted above, any entry in the tree
+ could use more than one attribute to build its RDN. X.500 also allows
+ the use of alias names, so that the entry {c=us, o=Merit, cn=Chris
+ 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 first
+ entry.
+
+3.1.2 The Directory Model
+
+ Now that we've seen what kinds of information can be kept in the
+ Directory, we should look at how the Directory stores this
+ information and how a Directory users accesses the information. There
+ are two components of this model: a Directory User Agent (DUA), which
+ accesses the Directory on behalf of a user, and the Directory System
+ 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 collection
+ of DSAs which form the Directory, and the DSAs employ two techniques
+
+
+
+DISI Working Group [Page 10]
+
+RFC 1309 Technical Overview of X.500 March 1992
+
+
+ to allow this distribution to be transparent to the user, called
+ "chaining" and "referral". The details of these two techniques would
+ take up another page, so it suffices to say that to each user, it
+ appears that the entire global directory is on her desktop. (Of
+ course, if the information requested is on the other side of the
+ world, it may seem that the desktop directory is a bit slow for that
+ request...)
+
+3.2 The functionality of X.500
+
+ To describe the functionality of X.500, we will need to separate
+ 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 because
+ a) it is widely used in the U.S. and European Directory Services
+ 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 accrues
+ simply by virtue of the fact that it is distributed, not limited to a
+ single machine. Among these are:
+
+ * An enormously large potential namespace.
+ Since the Directory is not limited to a single machine, many
+ 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 their
+ information, facilitating much more accurate data throughout
+ the Directory.
+
+ The functionality built into the X.500(88) standard includes:
+
+ * Advanced searching capabilities.
+ The Directory supports arbitrarily complex searches at an
+ attribute level. As the object classes a specific entry
+ belongs to is maintained in the objectClass attribute, this
+ also allows Directory searches for specific types of objects.
+ Thus, one could search the c=US subtree for anyone with a last
+ name beginning with S, who also has either a fax number in the
+ (313) area code or an e-mail address ending in umich.edu.
+ This feature of X.500 also helps to provide the basic
+ 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 local
+ specialized directories can also be implemented. Locally
+ defined extensions can include new object classes, new
+ attributes, and new attribute types.
+
+ * Security issues.
+ The X.500 (88) standards define two types of security for
+ Directory data: Simple Authentication (which uses passwords),
+ and Strong Authentication (which uses cryptographic keys).
+ Simple authentication has been widely implemented, strong
+ authentication has been less widely implemented. Each of
+ these authentication techniques are invoked when a user or
+ process attempts a Directory operation through a DUA.
+
+ In addition to the global benefits of the X.500 standard, 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 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 QUIPU
+ includes:
+
+ * Access control lists.
+ An access control list is a way to provide security for each
+ attribute of an entry. For example, each attribute in a given
+ entry can be permitted for detect, compare, read, and modify
+ permissions based on the reader's membership in various groups.
+ For example, one can specify that some information in a given
+ entry is public, some can be read only by members of the
+ organization, and some can only be modified by the owner of
+ the entry.
+
+ * Replication.
+ Replication provides a method whereby frequently accessed
+ information in a DSA other than the local one can be kept by
+ the local DSA on a "slave" basis, with updates of the "slave"
+ data provided automatically by QUIPU from the "master" data
+ residing on the foreign DSA. This provides alternate access
+ points to that data, and can make searches and retrievals
+ more rapid as there is much less overhead in the form or
+ 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 not
+ designed to solve everyone's needs for all time to come. X.500 is not
+ a general purpose database, nor is it a Data Base Management System
+ (DBMS). X.500 defines no standards for output formats, and it
+ certainly doesn't have a report generation capability. The technical
+ mechanisms are not yet in place for the Directory to contain
+ information about itself, thus new attributes and new attribute types
+ are rather slowly distributed (by hand).
+
+ Searches can be slow, for two reasons: a) searches across a widely
+ distributed portion of the namespace (c=US, for example) has a delay
+ which is partially caused by network transmission times, and can be
+ compounded by implementations that cache the partial search returns
+ until everyone has reported back, and b) some implementations are
+ slow at searching anyway, and this is very sensitive to such things
+ as processor speed and available swap space. Another implementation
+ "problem" is a tradeoff with security for the Directory: most
+ implementations have an administrative limit on the amount of
+ information which can be returned for a specific search. For
+ example, if a search returns 1000 hits, 20 of those might be
+ displayed, with the rest lost. Thus a person performing a large
+ search might have to perform a number of small searches. This was
+ implemented because an organization might want to make it hard to
+ "troll" for the organization's entire database.
+
+ Also, there is at the moment no clear consensus on the ideal shape of
+ the DIT, or on the idea structure of the object tree. This can make
+ it hard to add to the current corpus of X.500 work, and the number of
+ 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 to
+ do; i.e., to provide primary directory services and "resource
+ 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 sufficient
+ to start building a Directory Service. However, many of the new
+ functions implemented in QUIPU were necessary if the Directory were
+ to function in a reasonable manner. X.500 (92) will include
+ formalized and standardized versions of those advances, including
+
+ * 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 access
+ control lists.
+
+ Each of these will provide a richer Directory, but you don't have to
+ wait for them! You can become part of the Directory today!
+
+4: WHAT X.500 CAN DO FOR YOU TODAY
+
+4.1 Current applications of X.500
+
+ X.500 is filling Directory Services needs in a large number of
+ countries. As a directory to locate people, it is provided in the
+ U.S. as the White Pages Pilot Project, run by PSI, and in Europe
+ under the PARADISE Project as a series of nation-wide pilots. It is
+ also being used by the FOX Project in the United States to provide
+ WHOIS services for people and networks, and to provide directories of
+ objects as disparate as NIC Profiles and a pilot K-12 Educators
+ directory. It is also being investigated for its ability to provide
+ resource location facilities and to provide source location for WAIS
+ servers. In fact, in almost every area where one could imagine
+ needing a directory service (particularly for distributed directory
+ services), X.500 is either providing those services or being expanded
+ to provide those services.
+
+ In particular, X.500 was envisioned by its creators as providing
+ directory services for electronic mail, specifically for X.400. It is
+ 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 to
+ the appropriate user's real mail address in a transparent fashion.
+ Similarly, Sprint is using X.500 to administrate the address space
+ for its internal X.400 mail systems.
+
+ Those of us working on X.500 feel that X.500's strengths lie in
+ providing directory services for people and objects, and for
+ providing primary resource location for a large number of online
+ services. We think that X.500 is a major component (though not the
+ only one) of a global Yellow Pages service. We would also like to
+ encourage each of you to join your national pilot projects; the more
+ coverage we can get, the easier you will be able to find the people
+ you need to contact.
+
+
+
+
+
+
+
+
+
+
+DISI Working Group [Page 14]
+
+RFC 1309 Technical Overview of X.500 March 1992
+
+
+5. For Further Information
+
+ For further information, the authors recommend the following
+ documents:
+
+ Weider, C., and J. Reynolds, "Executive Introduction to Directory
+ 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, Lawrence
+ Berkeley Laboratory, January 1992.
+
+ Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet
+ X.500 Schema", RFC 1274, University College London, November 1991.
+
+ Hardcastle-Kille, S., "Replication Requirements to provide an
+ Internet Directory using X.500", RFC 1275, University College
+ London, November, 1991.
+
+ Hardcastle-Kille, S., "Replication and Distributed Operations
+ extensions to provide an Internet Directory using X.500", RFC
+ 1276, University College London, November 1991.
+
+ Hardcastle-Kille, S., "Encoding Network Addresses to support
+ operation over non-OSI lower layers", RFC 1277, University College
+ London, November 1991.
+
+ Hardcastle-Kille, S., " A string encoding of Presentation
+ Address", RFC 1278, University College London, November 1991.
+
+ Hardcastle-Kille, S., "X.500 and Domains", RFC 1279, University
+ College London, November 1991.
+
+6. Security Considerations
+
+ Security issues are discussed in section 3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DISI Working Group [Page 15]
+
+RFC 1309 Technical Overview of X.500 March 1992
+
+
+7. Authors' Addresses
+
+ Chris Weider
+ Advanced Network and Services, Inc.
+ 2901 Hubbard G-1
+ Ann Arbor, MI 48105-2437
+
+ Phone (313) 663-2482
+ E-mail: weider@ans.net
+
+
+ Joyce K. Reynolds
+ Information Sciences Institute
+ University of Southern California
+ 4676 Admirality Way
+ Marina del Rey, CA 90292
+
+ Phone: (310) 822-1511
+ EMail: jkrey@isi.edu
+
+
+ Sergio Heker
+ JvNCnet
+ Princeton University
+ 6 von Neumann Hall
+ Princeton, NJ 08544
+
+ Phone: (609) 258-2400
+ Email: heker@nisc.jvnc.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DISI Working Group [Page 16]
+ \ No newline at end of file