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
