RFC 2293 (rfc2293) - Page 2 of 8
Representing Tables and Subtrees in the X
Alternative Format: Original Text Document
RFC 2293 Table and Subtrees in the X.500 March 1998
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 entry
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 optimization, so that the block of information may be
widely replicated.
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 organization, it will be located under the organization.
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:
Kille Standards Track