rfc1309.txt

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

   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.