Network Working Group G. Mansfield
Request for Comments: 1804 AIC Laboratories
Category: Experimental P. Rajeev
Hughes Software Systems
S. Raghavan
Indian Institute of Technology, Madras
T. Howes
University of Michigan
June 1995
Schema Publishing in X.500 Directory
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Abstract
The X.500 directory provides a powerful mechanism for storing and
retrieving information about objects of interest. To interpret the
information stored in the directory, the schema must be known to all
the components of the directory. Presently, there are no means other
than ftp to distribute schema information across the Internet. This
is proving to be a severe constraint as the Directory is growing.
This document presents a solution to the schema distribution problem
using the existing mechanisms of the directory. A naming scheme for
naming schema objects and a meta-schema for storing schema objects is
presented. The procedures for fetching unknown schema from the
directory at runtime are described.
Table of Contents
1. Introduction 2
2. Schema Management 2
3. Storage of Schema Information in the Directory 3
4. Retrieval of Schema from the Directory 5
5. The Meta-Schema 6
6. References 9
7. Security Considerations 9
8. Authors' Addresses 10
Mansfield, et al Experimental [Page 1]
RFC 1804 Schema Publishing in X.500 Directory June 1995
1. Introduction
The X.500 Directory [1] is now used for a wide range of applications
from name/address lookup to network management, from restaurant
information to bibliographic information services. This information
is distributed and managed across a network of many autonomous sites.
In order to interpret the information stored in the directory, the
components of the directory must have knowledge about the structure
and representation (schema) of the information held within the
directory.
The distributed nature of the network and the relatively slow process
of standardization have given rise to the challenging task of making
accessible the information about the schema rules themselves. A
mechanism for making the schema accessible to the functional
components of the directory is urgently required.
The 1993 X.500 Directory Standard [2] has attempted to address the
problem of schema management and distribution. The 1993 framework
does provide the means for storing and retrieving schema information
in the directory. However, the resolution of unknown OIDs will
require both the DUA and the DSA to be compliant with [2].
In this document we propose a solution using the existing mechanisms
of the directory [1] itself. We present a naming scheme for naming
schema objects and a meta-schema for storing schema objects in the
directory. The proposal allows the algorithmic resolution of unknown
objects in the directory and in the absence of 1993 X.500 Directory
Standard implementations provides an interim solution to the schema
publishing problem.
2. Schema Management
The storage and retrieval mechanism provided by the directory is
powerful and flexible. However, the key to the directory is the
knowledge of the schema rules defined for the objects represented in
the directory. To facilitate the diffusion of this knowledge
appropriate schema management mechanisms need to be designed. Schema
management involves:
o Storage of schema information in the directory
o Algorithmic access to and retrieval of schema information
in the directory
o Definition of rules for schema modification
o Propagation of schema information from one component of the
directory to other components of directory
Mansfield, et al Experimental [Page 2]
RFC 1804 Schema Publishing in X.500 Directory June 1995
In this document we concentrate on the aspect of schema
access/retrieval from the directory. Since schema objects are defined
and employed, the modification , addition and deletion of schema
objects can be carried out using existing directory mechanisms. But
the operational issue of synchronizing the schema with the DIB will
require further attention. Similarly the issue of schema propagation
requires further work and is outside the scope of this document. The
strategy proposed in this document has a very simple and workable
approach. No added DAP/DSP functionality is envisaged. At the same
time by using the directory's distributed framework scalability
problems are avoided. In essence, it allows the distributed storage
of schema objects and proposes a naming scheme which allows
algorithmic schema retrieval. Of course, on the down side, more than
one directory read operation may be required to retrieve the
information about an object and its attributes, as objects and
attributes are stored as separate entries in the directory.
As schema information of all objects in a naming context are stored
below the root entry of that naming context, the same DSA will be
able to supply the schema information stored in that DSA. Thus there
is no need to contact another DSA for resolving the schema of an
object stored in the local DSA.
3. Storage of Schema Information in the Directory
The schema information may be stored and distributed using mechanisms
external to the X.500 directory standard [5]. This document proposes
storing schema information in the directory. It has the following
advantages:
o The components of the directory can access the schema
information using the standard directory protocols.
o The nature of the directory naturally allows the schema
to be distributed. Schema used locally can be kept in the
local DSA itself whereas schema for general objects like
person, organization etc can be made available to all
components of the directory by publishing it.
In the operational model, the schema information in the directory is
expected to complement the schema information held in central
repositories.
Mansfield, et al Experimental [Page 3]
RFC 1804 Schema Publishing in X.500 Directory June 1995
3.1 Naming Scheme for the Schema
The schema information is stored in a distributed manner. We propose
a model in which each naming context stores the schema relevant to
it.
Root
\
\
+-------------\----------------------+
| C=IN DSA-1 |
| / \ |
| / \ |
| / \ |
| / \ |
| / cn=subschema |
| / / / | \ \ \ |
| / / / | \ \ \ |
| / oid= oid= |
+--/---------------------------------+
/
+----------------------/----------------------+
| o=IIT, Madras DSA-2 |
| / \ |
| / \ |
| / \ |
| / \ |
| ou=CSE cn=subschema |
| / \ / /| \ \ \ |
| / \ / / | \ \ \ |
|ipni=spark cn=Rajeev oid=ipni oid= |
+---------------------------------------------+
Figure 1: DIT with schema objects
To store the schema information, an object called subschema object is
defined. This object can come anywhere in the Directory Information
Tree (DIT). The subschema is defined as a subclass of Top. The
subschema entry is stored below the root entry of a naming context.
The root entry of a naming context must contain a subschema subentry,
named {CN= Subschema}. This standard naming methodology is necessary
so that the components of the directory can easily and
algorithmically locate the schema entries. All schema information
relevant to that naming context is stored below the subschema entry.
Children of the subschema entry store information about objects,
attribute types, attribute syntaxes or matching rules. The DIT
Mansfield, et al Experimental [Page 4]
RFC 1804 Schema Publishing in X.500 Directory June 1995
structure for storing schema information is shown in Figure 1.
Schema for these objects are given in section 5.
4. Retrieval of Schema from the Directory
When an unknown object is encountered by any component of directory
during a directory operation, it proceeds the following way to
resolve the schema.
The RDN component at the leaf-end of the name of the object whose
schema is to be resolved is replaced by the RDNs "oid=
RFC, FYI, BCP