RFC 1837 (rfc1837) - Page 2 of 7
Representing Tables and Subtrees in the X
Alternative Format: Original Text Document
RFC 1837 Representing Subtrees August 1995
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
optimisation, 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 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:
-----------------------------------------------------------------------
table OBJECT-CLASS ::= {
SUBCLASS OF {top}
MUST CONTAIN {commonName}
MAY CONTAIN {manager}
ID oc-table}
tableEntry OBJECT-CLASS ::= {
SUBCLASS OF {top}
MAY CONTAIN {description} 10
ID oc-table-entry}
textTableEntry OBJECT-CLASS ::= {
SUBCLASS OF {tableEntry}
MUST CONTAIN {textTableKey}
MAY CONTAIN {textTableValue}
ID oc-text-table-entry}
textTableKey ATTRIBUTE ::= {
Kille Experimental