1 2 3 4 5 6 7Network Working Group S. Kille 8Request for Comments: 2293 Isode Ltd. 9Obsoletes: 1837 March 1998 10Category: Standards Track 11 12 13 Representing Tables and Subtrees in the X.500 Directory 14 15Status 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 23Copyright Notice 24 25 Copyright (C) The Internet Society (1998). All Rights Reserved. 26 27Abstract 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 58Kille Standards Track [Page 1] 59 60RFC 2293 Table and Subtrees in the X.500 March 1998 61 62 631 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 114Kille Standards Track [Page 2] 115 116RFC 2293 Table and Subtrees in the X.500 March 1998 117 118 119table OBJECT-CLASS ::= { 120 SUBCLASS OF {top} 121 MUST CONTAIN {commonName} 122 MAY CONTAIN {manager} 123 ID oc-table} 124 125 126tableEntry OBJECT-CLASS ::= { 127 SUBCLASS OF {top} 128 MAY CONTAIN {description} 10 129 ID oc-table-entry} 130 131textTableEntry OBJECT-CLASS ::= { 132 SUBCLASS OF {tableEntry} 133 MUST CONTAIN {textTableKey} 134 MAY CONTAIN {textTableValue} 135 ID oc-text-table-entry} 136 137textTableKey ATTRIBUTE ::= { 138 SUBTYPE OF name 20 139 WITH SYNTAX DirectoryString {ub-name} 140 ID at-text-table-key} 141 142textTableValue ATTRIBUTE ::= { 143 SUBTYPE OF name 144 WITH SYNTAX DirectoryString {ub-description} 145 ID at-text-table-value} 146 147distinguishedNameTableEntry OBJECT-CLASS ::= { 148 SUBCLASS OF {tableEntry} 30 149 MUST CONTAIN {distinguishedNameTableKey} 150 ID oc-distinguished-name-table-entry} 151 152distinguishedNameTableKey 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 170Kille Standards Track [Page 3] 171 172RFC 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 226Kille Standards Track [Page 4] 227 228RFC 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 2462 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 282Kille Standards Track [Page 5] 283 284RFC 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 3013 Acknowledgments 302 303 Acknowledgments for work on this document are given in [2]. 304 305References 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 3134 Security Considerations 314 315 Security considerations are not discussed in this memo. 316 3175 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 338Kille Standards Track [Page 6] 339 340RFC 2293 Table and Subtrees in the X.500 March 1998 341 342 343A Object Identifier Assignment 344 345 346mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) 347 private(4) enterprises(1) isode-consortium (453) mhs-ds (7)} 348 349tables OBJECT IDENTIFIER ::= {mhs-ds 1} 350 351oc OBJECT IDENTIFIER ::= {tables 1} 352at OBJECT IDENTIFIER ::= {tables 2} 353 354oc-subtree OBJECT IDENTIFIER ::= {oc 1} 355oc-table OBJECT IDENTIFIER ::= {oc 2} 10 356oc-table-entry OBJECT IDENTIFIER ::= {oc 3} 357oc-text-table-entry OBJECT IDENTIFIER ::= {oc 4} 358oc-distinguished-name-table-entry OBJECT IDENTIFIER ::= {oc 5} 359 360at-text-table-key OBJECT IDENTIFIER ::= {at 1} 361at-text-table-value OBJECT IDENTIFIER ::= {at 2} 362at-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 394Kille Standards Track [Page 7] 395 396RFC 2293 Table and Subtrees in the X.500 March 1998 397 398 399Full 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 450Kille Standards Track [Page 8] 451 452