external/bsd/openldap/dist/doc/rfc/rfc2293.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                            S. Kille
   8 Request for Comments: 2293                                     Isode Ltd.
   9 Obsoletes: 1837                                                March 1998
  10 Category: Standards Track
  11
  12
  13         Representing Tables and Subtrees in the X.500 Directory
  14
  15 Status of this Memo
  16
  17    This document specifies an Internet standards track protocol for the
  18    Internet community, and requests discussion and suggestions for
  19    improvements.  Please refer to the current edition of the "Internet
  20    Official Protocol Standards" (STD 1) for the standardization state
  21    and status of this protocol.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  26
  27 Abstract
  28
  29    This document defines techniques for representing two types of
  30    information mapping in the OSI Directory [1].
  31
  32    1.  Mapping from a key to a value (or set of values), as might
  33        be done in a table lookup.
  34
  35    2.  Mapping from a distinguished name to an associated
  36        value (or values), where the values are not defined by the owner
  37        of the entry.  This is achieved by use of a directory subtree.
  38
  39    These techniques were developed for supporting MHS use of Directory
  40    [2], but are specified separately as they have more general
  41    applicability.
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Kille                       Standards Track                     [Page 1]
  59 \f
  60 RFC 2293            Table and Subtrees in the X.500           March 1998
  61
  62
  63 1  Representing Flat Tables
  64
  65    Before considering specific function, a general purpose technique for
  66    representing tables in the directory is introduced.  The schema for
  67    this is given in Figure 1.  A table can be considered as an unordered
  68    set of key to (single or multiple) value mappings, where the key
  69    cannot be represented as a global name.  There are four reasons why
  70    this may occur:
  71
  72    1.  The object does not have a natural global name.
  73
  74    2.  The object can only be named effectively in the context of
  75        being a key to a binding.  In this case, the object will be given
  76        a natural global name by the table.
  77
  78    3.  The object has a global name, and the table is being used
  79        to associate parameters with this object, in cases where they
  80        cannot be placed in the objects global entry.  Reasons why they
  81        might not be so placed include:
  82
  83         o  The object does not have a directory entry
  84
  85         o  There is no authority to place the parameters in the
  86            global entry
  87
  88         o  The parameters are not global --- they only make sense
  89            in the  context of the table.
  90
  91    4.  It is desirable to group information together as a
  92        performance optimization, so that the block of information may be
  93        widely replicated.
  94
  95    A table is represented as a single level subtree.  The root of the
  96    subtree is an entry of object class Table.  This is named with a
  97    common name descriptive of the table.  The table will be located
  98    somewhere appropriate to its function.  If a table is private to an
  99    MTA, it will be below the MTA's entry.  If it is shared by MTA's in
 100    an organization, it will be located under the organization.
 101
 102    The generic table entry contains only a description.  All instances
 103    will be subclassed, and the subclass will define the naming
 104    attribute.  Two subclasses are defined:
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Kille                       Standards Track                     [Page 2]
 115 \f
 116 RFC 2293            Table and Subtrees in the X.500           March 1998
 117
 118
 119 table OBJECT-CLASS ::= {
 120     SUBCLASS OF {top}
 121     MUST CONTAIN {commonName}
 122     MAY CONTAIN {manager}
 123     ID oc-table}
 124
 125
 126 tableEntry OBJECT-CLASS ::= {
 127     SUBCLASS OF {top}
 128     MAY CONTAIN {description}                                       10
 129     ID oc-table-entry}
 130
 131 textTableEntry OBJECT-CLASS ::= {
 132     SUBCLASS OF {tableEntry}
 133     MUST CONTAIN {textTableKey}
 134     MAY CONTAIN {textTableValue}
 135     ID oc-text-table-entry}
 136
 137 textTableKey ATTRIBUTE ::= {
 138     SUBTYPE OF name                                                 20
 139     WITH SYNTAX DirectoryString {ub-name}
 140     ID at-text-table-key}
 141
 142 textTableValue ATTRIBUTE ::= {
 143     SUBTYPE OF name
 144     WITH SYNTAX  DirectoryString {ub-description}
 145     ID at-text-table-value}
 146
 147 distinguishedNameTableEntry OBJECT-CLASS ::= {
 148     SUBCLASS OF {tableEntry}                                        30
 149     MUST CONTAIN {distinguishedNameTableKey}
 150     ID oc-distinguished-name-table-entry}
 151
 152 distinguishedNameTableKey ATTRIBUTE ::= {
 153     SUBTYPE OF distinguishedName
 154     ID at-distinguished-name-table-key}
 155
 156                      Figure 1:  Representing Tables
 157
 158
 159    1.  TextEntry, which define table entries with text keys,
 160        which may have single or multiple values of any type.  An
 161        attribute is defined to allow a text value, to support the
 162        frequent text key to text value mapping.  Additional values may
 163        be defined.
 164
 165
 166
 167
 168
 169
 170 Kille                       Standards Track                     [Page 3]
 171 \f
 172 RFC 2293            Table and Subtrees in the X.500           March 1998
 173
 174
 175    2.  DistinguishedNameEntry.  This is used for associating
 176        information with globally defined objects.  This approach should
 177        be used where the number of objects in the table is small or very
 178        sparsely spread over the DIT. In other cases where there are many
 179        objects or the objects are tightly clustered in the DIT, the
 180        subtree approach defined in Section 2 will be preferable.  No
 181        value attributes are defined for this type of entry.  An
 182        application of this will make appropriate subtyping to define the
 183        needed values.
 184
 185    This is best illustrated by example.  Consider the MTA:
 186
 187    CN=Bells, OU=Computer Science,
 188    O=University College London, C=GB
 189
 190    Suppose that the MTA needs a table mapping from private keys to fully
 191    qualified domain names (this example is fictitious).  The table might
 192    be named as:
 193
 194    CN=domain-nicknames,
 195    CN=Bells, OU=Computer Science,
 196    O=University College London, C=GB
 197
 198    To represent a mapping in this table from "euclid" to
 199    "bloomsbury.ac.uk", the entry:
 200
 201    TextTableKey=euclid, CN=domain-nicknames,
 202    CN=Bells, OU=Computer Science,
 203    O=University College London, C=GB
 204
 205    will contain the attribute:
 206
 207    TextTableValue=bloomsbury.ac.uk
 208
 209    A second example, showing the use of DistinguishedNameEntry is now
 210    given.  Consider again the MTA:
 211
 212    CN=Bells, OU=Computer Science,
 213    O=University College London, C=GB
 214
 215    Suppose that the MTA needs a table mapping from MTA Name to bilateral
 216    agreement information of that MTA. The table might be named as:
 217
 218    CN=MTA Bilateral Agreements,
 219    CN=Bells, OU=Computer Science,
 220    O=University College London, C=GB
 221
 222
 223
 224
 225
 226 Kille                       Standards Track                     [Page 4]
 227 \f
 228 RFC 2293            Table and Subtrees in the X.500           March 1998
 229
 230
 231    To represent information on the MTA which has the Distinguished Name:
 232
 233    CN=Q3T21, ADMD=Gold 400, C=GB
 234
 235    There would be an entry in this table with the Relative Distinguished
 236    Name of the table entry being the Distinguished Name of the MTA being
 237    referred to.  The MTA Bilateral information would be an attribute in
 238    this entry.  Using a non-standard notation, the Distinguished Name of
 239    the table entry is:
 240
 241    DistinguishedNameTableKey=<CN=Q3T21, ADMD=Gold 400, C=GB>,
 242    CN=MTA Bilateral Agreements,
 243    CN=Bells, OU=Computer Science,
 244    O=University College London, C=GB
 245
 246 2  Representing Subtrees
 247
 248    A subtree is similar to a table, except that the keys are constructed
 249    as a distinguished name hierarchy relative to the location of the
 250    subtree in the DIT. The subtree effectively starts a private "root",
 251    and has distinguished names relative to this root.  Typically, this
 252    approach is used to associate local information with global objects.
 253    The schema used is defined in Figure 2.  Functionally, this is
 254    equivalent to a table with distinguished name keys.  The table
 255    approach is best when the tree is very sparse.  This approach is
 256    better for subtrees which are more populated.
 257
 258    The subtree object class defines the root for a subtree in an
 259    analogous means to the table.  Information within the subtree will
 260    generally be defined in the same way as for the global object, and so
 261
 262    subtree OBJECT-CLASS ::= {
 263        SUBCLASS OF {top}
 264        MUST CONTAIN {commonName}
 265        MAY CONTAIN {manager}
 266        ID oc-subtree}
 267
 268                      Figure 2:  Representing Subtrees
 269
 270
 271    no specific object classes for subtree entries are needed.
 272
 273    For example consider University College London.
 274
 275    O=University College London, C=GB
 276
 277
 278
 279
 280
 281
 282 Kille                       Standards Track                     [Page 5]
 283 \f
 284 RFC 2293            Table and Subtrees in the X.500           March 1998
 285
 286
 287    Suppose that the UCL needs a private subtree, with interesting
 288    information about directory objects.  The table might be named as:
 289
 290    CN=private subtree,
 291    O=University College London, C=GB
 292
 293    UCL specific information on Inria might be stored in the entry:
 294
 295    O=Inria, C=FR,
 296    CN=private subtree,
 297    O=University College London, C=GB
 298
 299    Practical examples of this mapping are given in [2].
 300
 301 3  Acknowledgments
 302
 303    Acknowledgments for work on this document are given in [2].
 304
 305 References
 306
 307    [1] The Directory --- overview of concepts, models and services,
 308        1993. CCITT X.500 Series Recommendations.
 309
 310    [2] Kille, S.E., "X.400-MHS use of the X.500 directory to support
 311        X.400-MHS routing," RFC 1801, June 1995.
 312
 313 4  Security Considerations
 314
 315    Security considerations are not discussed in this memo.
 316
 317 5  Author's Address
 318
 319    Steve Kille
 320    Isode Ltd
 321    The Dome
 322    The Square
 323    Richmond
 324    TW9 1DT
 325    England
 326
 327    Phone:  +44-181-332-9091
 328    EMail:  S.Kille@ISODE.COM
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Kille                       Standards Track                     [Page 6]
 339 \f
 340 RFC 2293            Table and Subtrees in the X.500           March 1998
 341
 342
 343 A  Object Identifier Assignment
 344
 345
 346 mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
 347           private(4) enterprises(1) isode-consortium (453) mhs-ds (7)}
 348
 349 tables OBJECT IDENTIFIER ::= {mhs-ds 1}
 350
 351 oc OBJECT IDENTIFIER ::= {tables 1}
 352 at OBJECT IDENTIFIER ::= {tables 2}
 353
 354 oc-subtree OBJECT IDENTIFIER ::= {oc 1}
 355 oc-table OBJECT IDENTIFIER ::= {oc 2}                               10
 356 oc-table-entry OBJECT IDENTIFIER ::= {oc 3}
 357 oc-text-table-entry OBJECT IDENTIFIER ::= {oc 4}
 358 oc-distinguished-name-table-entry  OBJECT IDENTIFIER ::= {oc 5}
 359
 360 at-text-table-key OBJECT IDENTIFIER ::= {at 1}
 361 at-text-table-value OBJECT IDENTIFIER ::= {at 2}
 362 at-distinguished-name-table-key OBJECT IDENTIFIER ::= {at 3}
 363
 364                 Figure 3:  Object Identifier Assignment
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Kille                       Standards Track                     [Page 7]
 395 \f
 396 RFC 2293            Table and Subtrees in the X.500           March 1998
 397
 398
 399 Full Copyright Statement
 400
 401    Copyright (C) The Internet Society (1998).  All Rights Reserved.
 402
 403    This document and translations of it may be copied and furnished to
 404    others, and derivative works that comment on or otherwise explain it
 405    or assist in its implementation may be prepared, copied, published
 406    and distributed, in whole or in part, without restriction of any
 407    kind, provided that the above copyright notice and this paragraph are
 408    included on all such copies and derivative works.  However, this
 409    document itself may not be modified in any way, such as by removing
 410    the copyright notice or references to the Internet Society or other
 411    Internet organizations, except as needed for the purpose of
 412    developing Internet standards in which case the procedures for
 413    copyrights defined in the Internet Standards process must be
 414    followed, or as required to translate it into languages other than
 415    English.
 416
 417    The limited permissions granted above are perpetual and will not be
 418    revoked by the Internet Society or its successors or assigns.
 419
 420    This document and the information contained herein is provided on an
 421    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 422    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 423    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 424    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 425    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Kille                       Standards Track                     [Page 8]
 451 \f