Network Working S.E. Hardcastle-Kille Group ISODE Consortium INTERNET-DRAFT November 1992 Expires: June 1993 Use of the Directory to support mapping between X.400 and RFC 822 Addresses 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 directory to learn the current status of this or any other Internet Draft. Abstract This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [Kil92]. This draft document will be submitted to the RFC editor as a protocol standard. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group . INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 November 1992 1 RFC 1327 Mappings It is important to be able to represent RFC 1327 mappings in the directory [Kil92]. The three RFC 1327 mappings are represented within the O/R Address and Domain hierarchies within the DIT [HK91, HK92b]. The benefits of using the existing O/R address and domain trees are: o It is the ``natural'' location, and will also help to ensure correct administrative authority for a mapping definition. o The tree will usually be accessed for routing, and so it will be efficient for addresses which are being routed. o This efficiency can be increased by representing mappings which can be derived from the basic mappings, as define in [HK92a]. An alternative approach which is not taken is to locate the information in separate subtrees, as defined in [HK92b]. By representing the information in separate subtrees, the mapping information would be kept in a clearly defined area which can be widely replicated in an efficient manner. This is not done, as the benefits of the approach proposed are greater. The values of the table mapping are defined by use of two new object classes, as specified in Figure 1. 2 Mapping from X.400 to RFC 822 As an example, consider the mapping from the O/R Address: PRMD=UK.AC; ADMD=Gold 400; C=GB This would be keyed by the directory entry: PRMD=UK.AC, ADMD=Gold 400, C=GB and return the mapping from the associatedDomain attribute, which gives the domain which this O/R address maps to. This attribute is Hardcastle-Kille Expires: June 1993 Page 1 INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 November 1992 _______________________________________________________________________ rFC822ToX400Mapping OBJECT-CLASS SUBCLASS OF domain-component MAY CONTAIN { associatedORAddress, nonAuthoritativeAssociatedORAddress, associatedX400Gateway} ::= oc-rfc822-to-x400-mapping x400ToRFC822Mapping OBJECT-CLASS SUBCLASS OF or-address-component 10 MAY CONTAIN { associatedDomain, nonAuthoritativeassociatedDomain} ::= oc-x400-to-x400-mapping associatedORAddress ATTRIBUTE SUBTYPE OF mhs-or-addresses SINGLE VALUE ::= at-associated-or-address 20 nonAuthoritativeAssociatedORAddress ATTRIBUTE SUBTYPE OF associatedORAddress SINGLE VALUE ::= at-non-authoriatative-associated-or-address associatedX400Gateway ATTRIBUTE SUBTYPE OF mhs-or-addresses SINGLE VALUE ::= at-associated-x400-gateway 30 nonAuthoritativeassociatedDomain ATTRIBUTE SUBTYPE OF associatedDomain SINGLE VALUE ::= at-non-authoritative-associated-domain ___________Figure_1:__Object_Classes_for_RFC_1327_mappings_____________ Hardcastle-Kille Expires: June 1993 Page 2 INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 November 1992 used to define authoritative mappings, which are placed in the open community tree. The manager of an RFC 1327 mapping should make the appropriate entry. To improve efficiency, the same information is made available in other places. There are two cases: 1. Representation of mapping information in routing trees other than the open community tree. 2. Representing a hierarchically derived mapping. For example, a mapping could be stored in the entry: MHS-O=Salford, PRMD=UK.AC, ADMD=Gold 400, C=GB This information could be derived from information in the entry: PRMD=UK.AC, ADMD=Gold 400, C=GB However, it would take an extra lookup to find this information. This information is stored by use of the nonAuthoritativeAssociatedDomain attributes. For example, the entry MHS-O=UCL, PRMD=UK.AC, ADMD=Gold 400, C=GB could have a nonAuthoritativeAssociatedDomain attribute of value ``UCL.AC.UK''. It is the responsibility of the manager of the entry to track changes in authoritative mappings. Functionally, mapping takes place exactly according to RFC 1327. The longest match is found by the following algorithm. 1. Take the O/R Address, and derive a directory name. This will be the O/R Address as far as the lowest OU. 2. Look up the entire name derived from the RFC 1327 key in a convenient routing tree. For authoritative information, the open tree must be used, but for performance reasons, another tree will Hardcastle-Kille Expires: June 1993 Page 3 INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 November 1992 usually be used 1. 3. Check for associatedDomain or nonAuthoritativeAssociatedDomain attributes. o If the mapped value is present, stop. o If not, strip one component of the name, and repeat. If the non-authoritative information is provided, the mapping can always be achieved with two lookups. 3 Mapping from RFC 822 to X.400 There is an analogous structure for mappings in the reverse direction. The domain hierarchy is represented in the DIT according to RFC 1279. The domain: AC.UK Is represented in the DIT as: DomainComponent=AC, DomainComponent=UK, O=Internet This has associated with it the attribute associatedORAddress, with a value: PRMD=UK.AC; ADMD=Gold 400; C=GB There is an optimisation analogous to the reverse mapping provided by the nonAuthoritativeORAddress attribute. The ``table 3'' mapping is provided by the associatedX400Gateway attribute. This value may be different in different routing trees, as this is not a globally unique mapping. It is also possible to ---------------------------- 1. It may be sensible to define an attribute which indicates the tree that an MTA uses for this purpose. Hardcastle-Kille Expires: June 1993 Page 4 INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 November 1992 identify multiple possible associated gateways. This information is looked up at the same time as mapped O/R addresses. In effect, this provides a fallback mapping, which is found if there is no equivalence mapping. Functionally, mapping takes place exactly according to RFC 1327. The longest match is found by the following algorithm. 1. Derived a directory name from the domain part of the RFC 822 address. 2. Look up this name to find the mapped value (associatedORAddress or nonAuthoritativeAssociatedORAddress o associatedX400Gateway.). o If the mapped value is present, stop. o If not, strip one component of the name, and repeat. If multiple associatedX400Gateway attributes are found, the MTA may select the one it chooses to use. If the non-authoritative information is provided, the mapping can always be achieved with two lookups. Because of the availability of aliases, some of the table mappings may be simplified. In addition, the directory can support mapping from addresses using the numeric country codes. References [HK91] S.E. Hardcastle-Kille. X.500 and domains. Request for Comments RFC 1279, Department of Computer Science, University College London, November 1991. [HK92a] S.E. Hardcastle-Kille. MHS use of the directory to support MHS routing, April 1992. Internet Draft. [HK92b] S.E. Hardcastle-Kille. Representing the O/R Address hierarchy in the directory information tree, April 1992. Internet Draft. [Kil92] S.E. Kille. Mapping between X.400(1988) / ISO 10021 and RFC 822. Request for Comments 1327, Department of Computer Science, University College London, May 1992. Hardcastle-Kille Expires: June 1993 Page 5 INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 November 1992 4 Security Considerations Security considerations are not discussed in this INTERNET--DRAFT . 5 Author's Address Steve Hardcastle-Kille ISODE Consortium PO Box 505 London SW11 1DX England Phone: +44-71-223-4062 EMail: S.Kille@ISODE.COM DN: CN=Steve Hardcastle-Kille, O=ISODE Consortium, C=GB UFN: S. Hardcastle-Kille, ISODE Consortium, GB Hardcastle-Kille Expires: June 1993 Page 6 INTERNET--DRAFT RFC 822/X.400 Mapping by X.500 November 1992 A Object Identifier Assignment _______________________________________________________________________ mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) isode-consortium (453) mhs-ds (3)} mapping OBJECT IDENTIFIER ::= {mhs-ds 4} oc OBJECT IDENTIFIER ::= {mapping 1} at OBJECT IDENTIFIER ::= {mapping 2} oc-rfc822-to-x400-mapping OBJECT IDENTIFIER ::= {oc 1} 10 oc-x400-to-x400-mapping OBJECT IDENTIFIER ::= {oc 2} at-associated-or-address OBJECT IDENTIFIER ::= {at 1} at-non-authoriatative-associated-or-address OBJECT IDENTIFIER ::= {at 2} at-associated-domain OBJECT IDENTIFIER ::= {at 4} at-non-authoritative-associated-domain OBJECT IDENTIFIER ::= {at 5} _______________Figure_2:__Object_Identifier_Assignment_________________ Hardcastle-Kille Expires: June 1993 Page 7