draft-ietf-mhsds-subtrees-02.txt   rfc1837.txt 
Network Working S.E. Hardcastle-Kille Network Working Group S. Kille
Group ISODE Consortium Request for Comments: 1837 ISODE Consortium
INTERNET-DRAFT November 1992 Category: Experimental August 1995
Expires: June 1993
Representing Tables and Subtrees in the Directory Representing Tables and Subtrees in the X.500 Directory
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a "working draft"
or "work in progress."
Please check the I-D abstract listing contained in each Internet Draft This memo defines an Experimental Protocol for the Internet
directory to learn the current status of this or any other Internet community. This memo does not specify an Internet standard of any
Draft. kind. Discussion and suggestions for improvement are requested.
Abstract Distribution of this memo is unlimited.
This document defines techniques for representing two types of
information mapping in the OSI Directory [CCI88].
1. Mapping from a key to a value (or set of values), as might be done Abstract
in a table lookup.
2. Mapping from a distinguished name to an associated value (or This document defines techniques for representing two types of
values), where the values are not defined by the owner of the information mapping in the OSI Directory [1].
entry. This is achieved by use of a directory subtree.
This techniques were developed for supporting MHS use of Directory 1. Mapping from a key to a value (or set of values), as might be
[HK92], but are specified separately as they have more general done in a table lookup.
applicability.
This draft document will be submitted to the RFC editor as a protocol 2. Mapping from a distinguished name to an associated value (or
standard. Distribution of this memo is unlimited. Please send values), where the values are not defined by the owner of the
comments to the author or to the discussion group entry. This is achieved by use of a directory subtree.
<mhs-ds@mercury.udev.cdc.com>.
INTERNET--DRAFT Representing Subtrees November 1992 These techniques were developed for supporting MHS use of Directory
[2], but are specified separately as they have more general
applicability.
1 Representing Flat Tables 1. Representing Flat Tables
Before considering specific function, a general purpose technique for Before considering specific function, a general purpose technique for
representing tables in the directory is introduced. The schema for representing tables in the directory is introduced. The schema for
this is given in Figure 1. 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. 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:
2. The object can only be named effectively in the context of being a 1. The object does not have a natural global name.
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 2. The object can only be named effectively in the context of being
associate parameters with this object, in cases where they cannot a key to a binding. In this case, the object will be given a
be placed in the objects global entry. Reasons why they might not natural global name by the table.
be so placed include:
o The object does not have a directory entry 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 There is no authority to place the parameters in the global o The object does not have a directory entry
entry
o The parameters are not global --- they only make sense in the o There is no authority to place the parameters in the global
context of the table. entry
4. It is desirable to group information together as a performance o The parameters are not global --- they only make sense in the
optimisation, so that the block of information may be widely context of the table.
replicated.
A table is represented as a single level subtree. The root of the 4. It is desirable to group information together as a performance
subtree is an entry of object class Table. This is named with a optimisation, so that the block of information may be widely
common name descriptive of the table. The table will be located replicated.
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 A table is represented as a single level subtree. The root of the
will be subclassed, and the subclass will define the naming attribute. subtree is an entry of object class Table. This is named with a
Two subclasses are defined: 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.
INTERNET--DRAFT Representing Subtrees November 1992 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 table OBJECT-CLASS ::= {
SUBCLASS OF top SUBCLASS OF {top}
MUST CONTAIN {commonName} MUST CONTAIN {commonName}
MAY CONTAIN {manager} MAY CONTAIN {manager}
::= oc-table ID oc-table}
tableEntry OBJECT-CLASS tableEntry OBJECT-CLASS ::= {
SUBCLASS OF top SUBCLASS OF {top}
MAY CONTAIN {description} 10 MAY CONTAIN {description} 10
::= oc-table-entry ID oc-table-entry}
textTableEntry OBJECT-CLASS textTableEntry OBJECT-CLASS ::= {
SUBCLASS OF tableEntry SUBCLASS OF {tableEntry}
MUST CONTAIN {textTableKey} MUST CONTAIN {textTableKey}
MAY CONTAIN {textTableValue} MAY CONTAIN {textTableValue}
::= oc-text-table-entry ID oc-text-table-entry}
textTableKey ATTRIBUTE textTableKey ATTRIBUTE ::= {
WITH ATTRIBUTE-SYNTAX 20 SUBTYPE OF name 20
caseIgnoreStringSyntax WITH SYNTAX DirectoryString {ub-name}
::= at-text-table-key ID at-text-table-key}
textTableValue ATTRIBUTE textTableValue ATTRIBUTE ::= {
WITH ATTRIBUTE-SYNTAX SUBTYPE OF name
caseIgnoreStringSyntax WITH SYNTAX DirectoryString {ub-description}
::= at-text-table-value ID at-text-table-value}
distinguishedNameTableEntry OBJECT-CLASS distinguishedNameTableEntry OBJECT-CLASS ::= {
SUBCLASS OF tableEntry 30 SUBCLASS OF {tableEntry} 30
MUST CONTAIN {distinguishedNameTableKey} MUST CONTAIN {distinguishedNameTableKey}
::= oc-distinguished-name-table-entry ID oc-distinguished-name-table-entry}
distinguishedNameTableKey ATTRIBUTE distinguishedNameTableKey ATTRIBUTE ::= {
WITH ATTRIBUTE-SYNTAX SUBTYPE OF distinguishedName
distinguishedNameSyntax ID at-distinguished-name-table-key}
::= at-distinguished-name-table-key
____________________Figure_1:__Representing_Tables_____________________ Figure 1: Representing Tables
INTERNET--DRAFT Representing Subtrees November 1992
1. TextEntry, which define table entries with text keys, which may 1. TextEntry, which define table entries with text keys, which may
have single or multiple values of any type. An attribute is have single or multiple values of any type. An attribute is
defined to allow a text value, to support the frequent text key to defined to allow a text value, to support the frequent text key to
text value mapping. Additional values may be defined. text value mapping. Additional values may be defined.
2. DistinguishedNameEntry. This is used for associating information 2. DistinguishedNameEntry. This is used for associating information
with globally defined objects. This approach should be used where with globally defined objects. This approach should be used where
the number of objects in the table is small or very sparsely the number of objects in the table is small or very sparsely
spread over the DIT. In other cases where there are many objects spread over the DIT. In other cases where there are many objects
skipping to change at page 3, line 32 skipping to change at page 4, line 4
CN=Bells, OU=Computer Science, CN=Bells, OU=Computer Science,
O=University College London, C=GB O=University College London, C=GB
Suppose that the MTA needs a table mapping from private keys to fully Suppose that the MTA needs a table mapping from private keys to fully
qualified domain names (this example is fictitious). The table might qualified domain names (this example is fictitious). The table might
be named as: be named as:
CN=domain-nicknames, CN=domain-nicknames,
CN=Bells, OU=Computer Science, CN=Bells, OU=Computer Science,
O=University College London, C=GB O=University College London, C=GB
To represent a mapping in this table from "euclid" to
To represent a mapping in this table from ``euclid'' to "bloomsbury.ac.uk", the entry:
``bloomsbury.ac.uk'', the entry:
CN=euclid, CN=domain-nicknames, CN=euclid, CN=domain-nicknames,
CN=Bells, OU=Computer Science, CN=Bells, OU=Computer Science,
O=University College London, C=GB O=University College London, C=GB
will contain the attribute: will contain the attribute:
TextValue=bloomsbury.ac.uk TextTableValue=bloomsbury.ac.uk
A second example, showing the use of DistinguishedNameEntry is now A second example, showing the use of DistinguishedNameEntry is now
given. Consider again the MTA: given. Consider again the MTA:
INTERNET--DRAFT Representing Subtrees November 1992
_______________________________________________________________________
subtree OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {commonName}
MAY CONTAIN {manager}
::= oc-subtree
___________________Figure_2:__Representing_Subtrees____________________
CN=Bells, OU=Computer Science, CN=Bells, OU=Computer Science,
O=University College London, C=GB O=University College London, C=GB
Suppose that the MTA needs a table mapping from MTA Name to bilateral Suppose that the MTA needs a table mapping from MTA Name to bilateral
agreement information of that MTA. The table might be named as: agreement information of that MTA. The table might be named as:
CN=MTA Bilateral Agreements, CN=MTA Bilateral Agreements,
CN=Bells, OU=Computer Science, CN=Bells, OU=Computer Science,
O=University College London, C=GB O=University College London, C=GB
To represent information on the MTA: To represent information on the MTA which has the Distinguished Name:
CN=Q3T21, ADMD=Gold 400, C=GB CN=Q3T21, ADMD=Gold 400, C=GB
There would be an entry in this table with the Relative Distinguished There would be an entry in this table with the Relative Distinguished
Name of the table entry being the Distinguished Name of the MTA being Name of the table entry being the Distinguished Name of the MTA being
referred to. The MTA Bilateral information would be an attribute in referred to. The MTA Bilateral information would be an attribute in
this entry. this entry. Using a non-standard notation, the Distinguished Name of
the table entry is:
2 Representing Subtrees DistinguishedNameTableValue=<CN=Q3T21, ADMD=Gold 400, C=GB>,
CN=MTA Bilateral Agreements,
CN=Bells, OU=Computer Science,
O=University College London, C=GB
A subtree is similar to a table, except that the keys are constructed 2. Representing Subtrees
a distinguished name hierarchy relative to the location of the subtree
in the DIT. The subtree effectively starts a private ``root'', and has
distinguished names relative to this root. Typically, this approach
is used to associate local information with global objects. The
schema used is defined in Figure 2. Functionally, this is equivalent
to a table with distinguished name keys. The table approach is best
when the tree is very sparse. This approach is better for subtrees
which are more populated.
INTERNET--DRAFT Representing Subtrees November 1992 A subtree is similar to a table, except that the keys are constructed
as a distinguished name hierarchy relative to the location of the
subtree in the DIT. The subtree effectively starts a private "root",
and has distinguished names relative to this root. Typically, this
approach is used to associate local information with global objects.
The schema used is defined in Figure 2. Functionally, this is
equivalent to a table with distinguished name keys. The table
approach is best when the tree is very sparse. This approach is
better for subtrees which are more populated.
The subtree object class defines the root for a subtree in an The subtree object class defines the root for a subtree in an
analogous means to the table. Information within the subtree will analogous means to the table. Information within the subtree will
generally be defined in the same way as for the global object, and so generally be defined in the same way as for the global object, and so
no specific object classes for subtree entries are needed.
For example consider University College London.
O=University College London, C=GB ---------------------------------------------------------------------
subtree OBJECT-CLASS ::= {
SUBCLASS OF {top}
MUST CONTAIN {commonName}
MAY CONTAIN {manager}
ID oc-subtree}
Suppose that the UCL needs a private subtree, with interesting Figure 2: Representing Subtrees
information about directory objects. The table might be named as:
CN=private subtree, no specific object classes for subtree entries are needed.
O=University College London, C=GB
UCL specific information on Inria might be stored in the entry: For example consider University College London.
O=Inria, C=FR, O=University College London, C=GB
CN=private subtree,
O=University College London, C=GB
Practical examples of this mapping are given in [HK92]. Suppose that the UCL needs a private subtree, with interesting
information about directory objects. The table might be named as:
References CN=private subtree,
O=University College London, C=GB
[CCI88] The Directory --- overview of concepts, models and services, UCL specific information on Inria might be stored in the entry:
December 1988. CCITT X.500 Series Recommendations.
[HK92] S.E. Hardcastle-Kille. MHS use of the directory to support O=Inria, C=FR,
MHS routing, April 1992. Internet Draft. CN=private subtree,
O=University College London, C=GB
3 Security Considerations Practical examples of this mapping are given in [2].
Security considerations are not discussed in this INTERNET--DRAFT . 3. Acknowledgements
4 Author's Address Acknowledgements for work on this document are given in [2].
Steve Hardcastle-Kille References
INTERNET--DRAFT Representing Subtrees November 1992 [1] The Directory --- overview of concepts, models and services,
1993. CCITT X.500 Series Recommendations.
ISODE Consortium [2] Kille, S., "MHS use of the X.500 Directory to Support MHS
PO Box 505 Routing", RFC 1801, ISODE Consortium, June 1995.
London
SW11 1DX
England
Phone: +44-71-223-4062 4. Security Considerations
EMail: S.Kille@ISODE.COM Security issues are not discussed in this memo.
DN: CN=Steve Hardcastle-Kille, 5. Author's Address
O=ISODE Consortium, C=GB
UFN: S. Hardcastle-Kille, ISODE Consortium, GB Steve Kille
ISODE Consortium
The Dome
The Square
Richmond
TW9 1DT
England
INTERNET--DRAFT Representing Subtrees November 1992 Phone: +44-81-332-9091
Internet EMail: S.Kille@ISODE.COM
X.400: I=S; S=Kille; O=ISODE Consortium; P=ISODE;
A=Mailnet; C=FI;
DN: CN=Steve Kille,
O=ISODE Consortium, C=GB
UFN: S. Kille, ISODE Consortium, GB
A Object Identifier Assignment A. Object Identifier Assignment
_______________________________________________________________________ -----------------------------------------------------------------------
mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4) mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
enterprises(1) isode-consortium (453) mhs-ds (3)} private(4) enterprises(1) isode-consortium (453) mhs-ds (7)}
tables OBJECT IDENTIFIER ::= {mhs-ds 1} tables OBJECT IDENTIFIER ::= {mhs-ds 1}
oc OBJECT IDENTIFIER ::= {tables 1} oc OBJECT IDENTIFIER ::= {tables 1}
at OBJECT IDENTIFIER ::= {tables 2} at OBJECT IDENTIFIER ::= {tables 2}
oc-subtree OBJECT IDENTIFIER ::= {oc 1} oc-subtree OBJECT IDENTIFIER ::= {oc 1}
oc-table OBJECT IDENTIFIER ::= {oc 2} 10 oc-table OBJECT IDENTIFIER ::= {oc 2} 10
oc-table-entry OBJECT IDENTIFIER ::= {oc 3} oc-table-entry OBJECT IDENTIFIER ::= {oc 3}
oc-text-table-entry OBJECT IDENTIFIER ::= {oc 4} oc-text-table-entry OBJECT IDENTIFIER ::= {oc 4}
oc-distinguished-name-table-entry OBJECT IDENTIFIER ::= {oc 5} oc-distinguished-name-table-entry OBJECT IDENTIFIER ::= {oc 5}
at-text-table-key OBJECT IDENTIFIER ::= {at 1} at-text-table-key OBJECT IDENTIFIER ::= {at 1}
at-text-table-value OBJECT IDENTIFIER ::= {at 2} at-text-table-value OBJECT IDENTIFIER ::= {at 2}
at-distinguished-name-table-key OBJECT IDENTIFIER ::= {at 3} at-distinguished-name-table-key OBJECT IDENTIFIER ::= {at 3}
_______________Figure_3:__Object_Identifier_Assignment_________________ Figure 3: Object Identifier Assignment
 End of changes. 65 change blocks. 
164 lines changed or deleted 149 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/