Representing Tables and Subtrees in the X.500 Directory (RFC1837)
Original Publication Date: 1995-Aug-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
This document defines techniques for representing two types of information mapping in the OSI Directory .
Network Working Group S. Kille
Request for Comments: 1837 ISODE Consortium
Category: Experimental August 1995
Representing Tables and Subtrees in the 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.
This document defines techniques for representing two types of
information mapping in the OSI Directory .
1. Mapping from a key to a value (or set of values), as might be
done in a table lookup.
2. Mapping from a distinguished name to an associated value (or
values), where the values are not defined by the owner of the
entry. This is achieved by use of a directory subtree.
These techniques were developed for supporting MHS use of Directory
, but are specified separately as they have more general
1. Representing Flat Tables
Before considering specific function, a general purpose technique for
representing tables in the directory is introduced. The schema for
this is given in Figure 1.
A table can be considered as an unordered set of key to (single or
multiple) value mappings, where the key cannot be represented as a
global name. There are four reasons why this may occur:
1. The object does not have a natural global name.
2. The object can only be named effectively in the context of being
a key to a binding. In this case, the object will be given a
natural global name by the table.
3. The object has a global name, and the table is being used to
associate parameters with this object, in cases where they cannot
be placed in the objects global entry. Reasons why they might
not be so placed include:
o The object does not have a directory entry
o There is no authority to place the parameters in the global
o The parameters are not global --- they only make sense in the
context of the table.
4. It is desirable to group information together as a performance
optimisation, so that the block of information may be widely
A table is represented as a single level subtree. The root of the
subtree is an entry of object class Table. This is named with a
common name descriptive of the table. The table will be located
somewhere appropriate to its function. If a table is private to an
MTA, it will be below the MTA's entry. If it is shared by MTA's in
an organisation, it will be located under the organisation.
The generic table entry contains only a description. All instances
will be subclassed, and the subclass will define the naming
attribute. Two subclasses are defined: