As per Relevance of the word represent, we have this rfc below:
Network Working Group S.
Request for Comments: 1837 ISODE
Category: Experimental August 1995
Representing Tables and Subtrees in the X.500
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
This document defines techniques for representing two types
information mapping in the OSI Directory [1].
1. Mapping from a key to a value (or set of values), as might
done in a table lookup
2. Mapping from a distinguished name to an associated value (
values), where the values are not defined by the owner of
entry. This is achieved by use of a directory subtree
These techniques were developed for supporting MHS use of
[2], but are specified separately as they have more
applicability
1. Representing Flat
Before considering specific function, a general purpose technique
representing tables in the directory is introduced. The schema
this is given in Figure 1.
A table can be considered as an unordered set of key to (single
multiple) value mappings, where the key cannot be represented as
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
a key to a binding. In this case, the object will be given
natural global name by the table
Kille Experimental [Page 1]
RFC 1837 Representing Subtrees August 1995
3. The object has a global name, and the table is being used
associate parameters with this object, in cases where they
be placed in the objects global entry. Reasons why they
not be so placed include
o The object does not have a directory
o There is no authority to place the parameters in the
o The parameters are not global --- they only make sense in
context of the table
4. It is desirable to group information together as a
optimisation, so that the block of information may be
replicated
A table is represented as a single level subtree. The root of
subtree is an entry of object class Table. This is named with
common name descriptive of the table. The table will be
somewhere appropriate to its function. If a table is private to
MTA, it will be below the MTA's entry. If it is shared by MTA's
an organisation, it will be located under the organisation
The generic table entry contains only a description. All
will be subclassed, and the subclass will define the
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 [Page 2]
RFC 1837 Representing Subtrees August 1995
SUBTYPE OF name 20
WITH SYNTAX DirectoryString {ub-name
ID at-text-table-key
textTableValue ATTRIBUTE ::= {
SUBTYPE OF
WITH SYNTAX DirectoryString {ub-description
ID at-text-table-value
distinguishedNameTableEntry OBJECT-CLASS ::= {
SUBCLASS OF {tableEntry} 30
MUST CONTAIN {distinguishedNameTableKey
ID oc-distinguished-name-table-entry
distinguishedNameTableKey ATTRIBUTE ::= {
SUBTYPE OF
ID at-distinguished-name-table-key
Figure 1: Representing
1. TextEntry, which define table entries with text keys, which
have single or multiple values of any type. An attribute
defined to allow a text value, to support the frequent text key
text value mapping. Additional values may be defined
2. DistinguishedNameEntry. This is used for associating
with globally defined objects. This approach should be used
the number of objects in the table is small or very
spread over the DIT. In other cases where there are many
or the objects are tightly clustered in the DIT, the
approach defined in Section 2 will be preferable. No
attributes are defined for this type of entry. An application
this will make appropriate subtyping to define the needed values
This is best illustrated by example. Consider the MTA
CN=Bells, OU=Computer Science
O=University College London, C=
Suppose that the MTA needs a table mapping from private keys to
qualified domain names (this example is fictitious). The table
be named as
CN=domain-nicknames
CN=Bells, OU=Computer Science
O=University College London, C=
Kille Experimental [Page 3]
RFC 1837 Representing Subtrees August 1995
To represent a mapping in this table from "euclid"
"bloomsbury.ac.uk", the entry
CN=euclid, CN=domain-nicknames
CN=Bells, OU=Computer Science
O=University College London, C=
will contain the attribute
TextTableValue=bloomsbury.ac.
A second example, showing the use of DistinguishedNameEntry is
given. Consider again the MTA
CN=Bells, OU=Computer Science
O=University College London, C=
Suppose that the MTA needs a table mapping from MTA Name to
agreement information of that MTA. The table might be named as
CN=MTA Bilateral Agreements
CN=Bells, OU=Computer Science
O=University College London, C=
To represent information on the MTA which has the Distinguished Name
CN=Q3T21, ADMD=Gold 400, C=
There would be an entry in this table with the Relative
Name of the table entry being the Distinguished Name of the MTA
referred to. The MTA Bilateral information would be an attribute
this entry. Using a non-standard notation, the Distinguished Name
the table entry is
DistinguishedNameTableValue=,
CN=MTA Bilateral Agreements
CN=Bells, OU=Computer Science
O=University College London, C=
Kille Experimental [Page 4]
RFC 1837 Representing Subtrees August 1995
2. Representing
A subtree is similar to a table, except that the keys are
as a distinguished name hierarchy relative to the location of
subtree in the DIT. The subtree effectively starts a private "root",
and has distinguished names relative to this root. Typically,
approach is used to associate local information with global objects
The schema used is defined in Figure 2. Functionally, this
equivalent to a table with distinguished name keys. The
approach is best when the tree is very sparse. This approach
better for subtrees which are more populated
The subtree object class defines the root for a subtree in
analogous means to the table. Information within the subtree
generally be defined in the same way as for the global object, and
---------------------------------------------------------------------
subtree OBJECT-CLASS ::= {
SUBCLASS OF {top
MUST CONTAIN {commonName
MAY CONTAIN {manager
ID oc-subtree
Figure 2: Representing
no specific object classes for subtree entries are needed
For example consider University College London
O=University College London, C=
Suppose that the UCL needs a private subtree, with
information about directory objects. The table might be named as
CN=private subtree
O=University College London, C=
UCL specific information on Inria might be stored in the entry
O=Inria, C=FR
CN=private subtree
O=University College London, C=
Practical examples of this mapping are given in [2].
Kille Experimental [Page 5]
RFC 1837 Representing Subtrees August 1995
3.
Acknowledgements for work on this document are given in [2].
[1] The Directory --- overview of concepts, models and services
1993. CCITT X.500 Series Recommendations
[2] Kille, S., "MHS use of the X.500 Directory to Support
Routing", RFC 1801, ISODE Consortium, June 1995.
4. Security
Security issues are not discussed in this memo
5. Author's
Steve
ISODE
The
The
TW9 1
Phone: +44-81-332-9091
Internet EMail: S.Kille@ISODE.
X.400: I=S; S=Kille; O=ISODE Consortium; P=ISODE
A=Mailnet; C=FI
DN: CN=Steve Kille
O=ISODE Consortium, C=
UFN: S. Kille, ISODE Consortium,
Kille Experimental [Page 6]
RFC 1837 Representing Subtrees August 1995
A. Object Identifier
-----------------------------------------------------------------------
mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) mhs-ds (7)}
tables OBJECT IDENTIFIER ::= {mhs-ds 1}
oc OBJECT IDENTIFIER ::= {tables 1}
at OBJECT IDENTIFIER ::= {tables 2}
oc-subtree OBJECT IDENTIFIER ::= {oc 1}
oc-table OBJECT IDENTIFIER ::= {oc 2} 10
oc-table-entry OBJECT IDENTIFIER ::= {oc 3}
oc-text-table-entry OBJECT IDENTIFIER ::= {oc 4}
oc-distinguished-name-table-entry OBJECT IDENTIFIER ::= {oc 5}
at-text-table-key OBJECT IDENTIFIER ::= {at 1}
at-text-table-value OBJECT IDENTIFIER ::= {at 2}
at-distinguished-name-table-key OBJECT IDENTIFIER ::= {at 3}
Figure 3: Object Identifier
Kille Experimental [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
