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