7 Network Working Group S. Kille
8 Request for Comments: 2294 Isode Ltd.
9 Obsoletes: 1836 March 1998
10 Category: Standards Track
13 Representing the O/R Address hierarchy in the
14 X.500 Directory Information Tree
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 Copyright (C) The Internet Society (1998). All Rights Reserved.
30 This document defines a representation of the O/R Address hierarchy
31 in the Directory Information Tree [6, 1]. This is useful for a range
32 of purposes, including:
34 o Support for MHS Routing [4].
36 o Support for X.400/RFC 822 address mappings [2, 5].
38 Please send comments to the author or to the discussion group <mhs-
39 ds@mercury.udev.cdc.com>.
58 Kille Standards Track [Page 1]
60 RFC 2294 Directory Information Tree March 1998
63 Object Class Mandatory
64 ------------ ---------
69 mHSNumericUserIdentifier O
71 mHSOrganizationalUnit O
75 mHSDomainDefinedAttribute O
77 Table 1: Order of O/R Address Directory Components
79 1 The O/R Address Hierarchy
81 An O/R Address hierarchy is represented in the X.500 directory by
82 associating directory name components with O/R Address components.
83 An example of this is given in Figure 1. The object classes and
84 attributes required to support this representation are defined in
85 Figure 2. The schema, which defines the hierarchy in which these
86 objects are represented in the directory information tree is
87 specified in Table 1. A given object class defined in the table will
88 always be higher in the DIT than an object class defined lower down
89 the table. Valid combinations of O/R Address components are defined
114 Kille Standards Track [Page 2]
116 RFC 2294 Directory Information Tree March 1998
121 C=GB / \ Numeric-C=234
125 +------------+<----------------+----+
127 +------------+ +----+
132 ADMD=" " / \ ADMD=Gold 400
133 +-------------+ +------------+
135 +-------------+ +------------+
138 \ PRMD=UK.AC \ PRMD=UK.AC
141 | PRMD |< -----------| |
160 Figure 1: Example O/R Address Tree
170 Kille Standards Track [Page 3]
172 RFC 2294 Directory Information Tree March 1998
176 ub-domain-name-length, ub-organization-name-length,
177 ub-organizational-unit-name-length, ub-common-name-length,
178 ub-x121-address-length, ub-domain-defined-attribute-type-length,
179 ub-domain-defined-attribute-value-length, ub-terminal-id-length,
180 ub-numeric-user-id-length, ub-country-name-numeric-length,
181 ub-surname-length, ub-given-name-length, ub-initials-length,
182 ub-generation-qualifier-length
184 FROM MTSUpperBounds {joint-iso-ccitt mhs-motis(6) mts(3) 10
185 modules(0) upper-bounds(3) };
187 mHSCountry OBJECT-CLASS ::= {
188 SUBCLASS OF {country}
189 MAY CONTAIN {mHSNumericCountryName}
192 mHSNumericCountryName ATTRIBUTE ::= {
193 WITH SYNTAX NumericString (SIZE (1..ub-country-name-numeric-length))
195 ID at-mhs-numeric-country-name}
197 aDMD OBJECT-CLASS ::= {
199 MUST CONTAIN {aDMDName}
202 aDMDName ATTRIBUTE ::= {
204 WITH SYNTAX DirectoryString {ub-domain-name-length} 30
207 pRMD OBJECT-CLASS ::= {
209 MUST CONTAIN {pRMDName}
212 pRMDName ATTRIBUTE ::= {
214 WITH SYNTAX DirectoryString {ub-domain-name-length} 40
217 mHSOrganization OBJECT-CLASS ::= {
219 MUST CONTAIN {mHSOrganizationName }
220 ID oc-mhs-organization}
226 Kille Standards Track [Page 4]
228 RFC 2294 Directory Information Tree March 1998
231 mHSOrganizationName ATTRIBUTE ::= {
232 SUBTYPE OF organizationName
233 WITH SYNTAX DirectoryString {ub-organization-name-length} 50
234 ID at-mhs-organization-name}
236 mHSOrganizationalUnit OBJECT-CLASS ::= {
238 MUST CONTAIN {mHSOrganizationalUnitName}
239 ID oc-mhs-organizational-unit}
241 mHSOrganizationalUnitName ATTRIBUTE ::= {
242 SUBTYPE OF organizationalUnitName 60
243 WITH SYNTAX DirectoryString {ub-organizational-unit-name-length}
244 ID at-mhs-organizational-unit-name}
246 mHSPerson OBJECT-CLASS ::= {
248 MUST CONTAIN {mHSSurname}
249 MAY CONTAIN {mHSGivenName|
251 mHSGenerationalQualifier}
254 mHSSurname ATTRIBUTE ::= {
256 WITH SYNTAX DirectoryString {ub-surname-length}
259 mHSGivenName ATTRIBUTE ::= {
261 WITH SYNTAX DirectoryString {ub-given-name-length}
262 ID at-mhs-given-name} 80
264 mHSInitials ATTRIBUTE ::= {
266 WITH SYNTAX DirectoryString {ub-initials-length}
269 mHSGenerationQualifier ATTRIBUTE ::= {
270 SUBTYPE OF generationQualifier
271 WITH SYNTAX DirectoryString {ub-generation-qualifier-length}
272 ID at-mhs-generation-qualifier} 90
274 mHSNamedObject OBJECT-CLASS ::= {
276 MUST CONTAIN {mHSCommonName}
277 ID oc-mhs-named-object}
282 Kille Standards Track [Page 5]
284 RFC 2294 Directory Information Tree March 1998
287 mHSCommonName ATTRIBUTE ::= {
288 SUBTYPE OF commonName
289 WITH SYNTAX DirectoryString {ub-common-name-length}
290 ID at-mhs-common-name} 100
292 mHSX121 OBJECT-CLASS ::= {
294 MUST CONTAIN {mHSX121Address}
297 mHSX121Address ATTRIBUTE ::= {
299 WITH SYNTAX DirectoryString {ub-x121-address-length}
300 ID at-x121-address} 110
302 mHSDomainDefinedAttribute OBJECT-CLASS ::= {
305 mHSDomainDefinedAttributeType|
306 mHSDomainDefinedAttributeValue}
307 ID oc-mhs-domain-defined-attribute}
309 mHSDomainDefinedAttributeType ATTRIBUTE ::= {
311 WITH SYNTAX DirectoryString {ub-domain-defined-attribute-type-length}
313 ID at-mhs-domain-defined-attribute-type}
315 mHSDomainDefinedAttributeValue ATTRIBUTE ::= {
317 WITH SYNTAX DirectoryString {ub-domain-defined-attribute-value-length}
319 ID at-mhs-domain-defined-attribute-value}
322 mHSTerminalID OBJECT-CLASS ::= {
324 MUST CONTAIN {mHSTerminalIDName}
325 ID oc-mhs-terminal-id}
327 mHSTerminalIDName ATTRIBUTE ::= {
329 WITH SYNTAX DirectoryString {ub-terminal-id-length}
330 ID at-mhs-terminal-id-name} 140
338 Kille Standards Track [Page 6]
340 RFC 2294 Directory Information Tree March 1998
343 mHSNumericUserIdentifier OBJECT-CLASS ::= {
345 MUST CONTAIN {mHSNumericUserIdentifierName}
346 ID oc-mhs-numeric-user-id}
348 mHSNumericeUserIdentifierName ATTRIBUTE ::= {
350 WITH SYNTAX DirectoryString {ub-numeric-user-id-length} 150
351 ID at-mhs-numeric-user-id-name}
353 Figure 2: O/R Address Hierarchy
355 The hierarchy is defined so that:
357 1. The representation is defined so that it is straightforward to
358 make a mechanical transformation in either direction. This
359 requires that each node is named by an attribute whose type can
360 determine the mapping.
362 2. Where there are multiple domain defined attributes, the first
363 in the sequence is the most significant.
365 3. Physical Delivery (postal) addresses are not represented in
366 this hierarchy. This is primarily because physical delivery can
367 be handled by the Access Unit routing mechanisms defined in [4],
368 and there is no need for this representation.
370 4. Terminal and network forms of address are not handled, except
371 for X.121 form, which is useful for addressing faxes.
373 5. MHSCountry is defined as a subclass of Country, and so the
374 same entry will be used for MHS Routing as for the rest of the
377 6. The numeric country code will be an alias.
379 7. ADMD will always be present in the hierarchy. This is true
380 in the case of " " and of "0". This facilitates an easy
381 mechanical transformation between the two forms of address.
383 8. Each node is named by the relevant part of the O/R Address.
385 9. Aliases may be used in other parts of the tree, in order to
386 normalize alternate values. Where an alias is used, the value of
387 the alias should be present as an alternate value in the node
388 aliased to. Aliases may not be used for domain defined
394 Kille Standards Track [Page 7]
396 RFC 2294 Directory Information Tree March 1998
399 10. Domain Defined Attributes are named by a multi-valued RDN
400 (Relative Distinguished Name), consisting of the type and value.
401 This is done so that standard attribute syntaxes can be used.
403 11. Where an O/R Address has a valid Printable String and T.61 form,
404 both must be present, with one as an alias for the other. This
405 is so that direct lookup of the name will work, independent of
406 the variant used. When both are present in an O/R Address being
407 looked up, either may be used to construct the distinguished
410 12. Personal name is handled by use of the mHSPerson object class.
411 Each of the components of the personal name will be present in
412 the relative distinguished name, which will usually be multi-
415 The relationship between X.400 O/R Addresses and the X.400 Entries
416 (Attribute Type and Object Class) are given in Table 2. Where there
417 are multiple Organizational Units or Domain Defined Attributes, each
418 component is mapped onto a single X.500 entry.
420 Note: When an X.121 address is used for addressing fax transmission,
421 this may only be done relative to the PRMD or ADMD. This is in
422 line with the current X.400 standards position. This means that
423 it is not possible to use this form of addressing for an
424 organizational or departmental fax gateway service.
426 O/R Address Object Class Naming Attribute
427 ----------- ------------ ----------------
428 C mHSCountry countryName
430 mHSNumericCountryName
433 O mHSOrganization mHSOrganizationName
434 OU/OU1/OU2 mHSOrganizationalUnit mHSOrganizationalUnitName
436 PN mHSPerson personName
437 CN mHSNamedObject mHSCommonName
438 X121 mHSX121 mHSX121Address
439 T-ID mHSTerminalID mHSTerminalIDName
440 UA-ID mHSNumericUserIdentifier mHSNumericUserIdentifierName
441 DDA mHSDomainDefinedAttribute mHSDomainDefinedAttributeType
443 mHSDomainDefinedAttributeValue
446 Table 2: O/R Address relationship to Directory Name
450 Kille Standards Track [Page 8]
452 RFC 2294 Directory Information Tree March 1998
457 O/R Addresses are written in the standard X.400 Notation.
458 Distinguished Names use the string representation of distinguished
459 names defined in [3]. The keywords used for the attributes defined
460 in this specification are given in Table 3.
462 3 Example Representation
466 I=S; S=Kille; OU1=CS; O=UCL,
467 P=UK.AC; A=Gold 400; C=GB;
470 would be represented in the directory as:
472 MHS-I=S + MHS-S=Kille, MHS-OU=CS, MHS-O=UCL,
477 mHSNumericCountryName MHS-Numeric-Country
480 mHSOrganizationName MHS-O
481 mHSOrganizationalUnitName MHS-OU
485 mHSGenerationalQualifier MHS-GQ
487 mHSX121Address MHS-X121
488 mHSDomainDefinedAttributeType MHS-DDA-Type
489 mHSDomainDefinedAttributeValue MHS-DDA-Value
490 mHSTerminalIDName MHS-T-ID
491 mHSNumericeUserIdentifierName MHS-UA-ID
493 Table 3: Keywords for String DN Representation
496 PRMD=UK.AC, ADMD=Gold 400, C=GB
498 4 Mapping from O/R Address to Directory Name
500 The primary application of this mapping is to take an X.400 encoded
501 O/R Address and to generate an equivalent directory name. This
502 mapping is only used for selected types of O/R Address:
506 Kille Standards Track [Page 9]
508 RFC 2294 Directory Information Tree March 1998
515 o Terminal form, where country is present and X121 addressing
518 Other forms of O/R address are handled by Access Unit mechanisms.
519 The O/R Address is treated as an ordered list, with the order as
520 defined in Table 1. For each O/R Address attribute, generate the
521 equivalent directory naming attribute. In most cases, the mapping is
522 mechanical. Printable String or Teletex encodings are chosen as
523 appropriate. Where both forms are present in the O/R Address, either
524 form may be used to generate the distinguished name. Both will be
525 represented in the DIT. There are two special cases:
527 1. A DDA generates a multi-valued RDN
529 2. The Personal Name is mapped to a multi-valued RDN
531 In many cases, an O/R Address will be provided, and only the higher
532 components of the address will be represented in the DIT. In this
533 case, the "longest possible match" should be returned.
535 5 Mapping from Directory Name to O/R Address
537 The reverse mapping is also needed in some cases. All of the naming
538 attributes are unique, so the mapping is mechanically reversible.
542 Acknowledgments for work on this document are given in [4].
546 [1] The Directory --- overview of concepts, models and services,
547 1993. CCITT X.500 Series Recommendations.
549 [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
550 between X.400 and RFC 822/MIME", RFC 2156, January 1998.
552 [3] Kille, S., "A String Representation of Distinguished Names",
553 RFC 1779, March 1995.
555 [4] Kille, S., "Use of an X.500/LDAP directory to support MIXER address
556 mapping", RFC 2164, January 1998.
562 Kille Standards Track [Page 10]
564 RFC 2294 Directory Information Tree March 1998
567 [5] Kille, S., "X.400-MHS use of the X.500 directory to support
568 X.400-MHS routing", RFC 1801, June 1995.
570 [6] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
571 SG 5/VII / ISO/IEC JTC1, Message Handling: System and Service
574 7 Security Considerations
576 This protocol introduces no known security risks.
588 Phone: +44-181-332-9091
589 EMail: S.Kille@ISODE.COM
591 X.400: I=S; S=Kille; P=ISODE; A=Mailnet; C=FI;
618 Kille Standards Track [Page 11]
620 RFC 2294 Directory Information Tree March 1998
623 A Object Identifier Assignment
625 mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
626 enterprises(1) isode-consortium (453) mhs-ds (7)}
629 tree OBJECT IDENTIFIER ::= {mhs-ds 2}
631 oc OBJECT IDENTIFIER ::= {tree 1}
632 at OBJECT IDENTIFIER ::= {tree 2}
634 oc-admd OBJECT IDENTIFIER ::= {oc 1} 10
635 oc-mhs-country OBJECT IDENTIFIER ::= {oc 2}
636 oc-mhs-domain-defined-attribute OBJECT IDENTIFIER ::= {oc 3}
637 oc-mhs-named-object OBJECT IDENTIFIER ::= {oc 4}
638 oc-mhs-organization OBJECT IDENTIFIER ::= {oc 5}
639 oc-mhs-organizational-unit OBJECT IDENTIFIER ::= {oc 6}
640 oc-mhs-person OBJECT IDENTIFIER ::= {oc 7}
641 oc-mhs-x121 OBJECT IDENTIFIER ::= {oc 8}
642 oc-prmd OBJECT IDENTIFIER ::= {oc 9}
643 oc-mhs-terminal-id OBJECT IDENTIFIER ::= {oc 10}
644 oc-mhs-numeric-user-id OBJECT IDENTIFIER ::= {oc 11} 20
646 at-admd-name OBJECT IDENTIFIER ::= {at 1}
647 at-mhs-common-name OBJECT IDENTIFIER ::= {at 2}
648 at-mhs-domain-defined-attribute-type OBJECT IDENTIFIER ::= {at 3}
649 at-mhs-domain-defined-attribute-value OBJECT IDENTIFIER ::= {at 4}
650 at-mhs-numeric-country-name OBJECT IDENTIFIER ::= {at 5}
651 at-mhs-organization-name OBJECT IDENTIFIER ::= {at 6}
652 at-mhs-organizational-unit-name OBJECT IDENTIFIER ::= {at 7}
653 at-prmd-name OBJECT IDENTIFIER ::= {at 10}
654 at-x121-address OBJECT IDENTIFIER ::= {at 12} 30
655 at-mhs-terminal-id-name OBJECT IDENTIFIER ::= {at 13}
656 at-mhs-numeric-user-id-name OBJECT IDENTIFIER ::= {at 14}
657 at-mhs-surname OBJECT IDENTIFIER ::= {at 15}
658 at-mhs-given-name OBJECT IDENTIFIER ::= {at 16}
659 at-mhs-initials OBJECT IDENTIFIER ::= {at 17}
660 at-mhs-generation-qualifier OBJECT IDENTIFIER ::= {at 18}
662 Figure 3: Object Identifier Assignment
674 Kille Standards Track [Page 12]
676 RFC 2294 Directory Information Tree March 1998
679 Full Copyright Statement
681 Copyright (C) The Internet Society (1998). All Rights Reserved.
683 This document and translations of it may be copied and furnished to
684 others, and derivative works that comment on or otherwise explain it
685 or assist in its implementation may be prepared, copied, published
686 and distributed, in whole or in part, without restriction of any
687 kind, provided that the above copyright notice and this paragraph are
688 included on all such copies and derivative works. However, this
689 document itself may not be modified in any way, such as by removing
690 the copyright notice or references to the Internet Society or other
691 Internet organizations, except as needed for the purpose of
692 developing Internet standards in which case the procedures for
693 copyrights defined in the Internet Standards process must be
694 followed, or as required to translate it into languages other than
697 The limited permissions granted above are perpetual and will not be
698 revoked by the Internet Society or its successors or assigns.
700 This document and the information contained herein is provided on an
701 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
702 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
703 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
704 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
705 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
730 Kille Standards Track [Page 13]