Browse Prior Art Database

Representing Tables and Subtrees in the X.500 Directory (RFC2293) Disclosure Number: IPCOM000002856D
Original Publication Date: 1998-Mar-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 9 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Kille: AUTHOR


This document defines techniques for representing two types of information mapping in the OSI Directory [1].

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 26% of the total text.

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 Notice

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].

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

[2], 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

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.