Representing Tables and Subtrees in the X.500 Directory (RFC2293)
Original Publication Date: 1998-Mar-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: 2293 Isode Ltd.
Obsoletes: 1837 March 1998
Category: Standards Track
Representing Tables and Subtrees in the X.500 Directory
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (1998). All Rights Reserved.
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
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
A table is represented as a single leve...