view Side-By-Side changes
Date: Tue, 09 Apr 2002 05:05:22 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 09 Dec 1992 04:39:00 GMT ETag: "3ddddf-2a46-2b257864" Accept-Ranges: bytes Content-Length: 10822 Connection: close Content-Type: text/plain Network WorkingS.E. Hardcastle-KilleGroup S. Kille Request for Comments: 1838 ISODE ConsortiumINTERNET-DRAFT November 1992 Expires: June 1993Category: Experimental August 1995 Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses Status of this Memo Thisdocument ismemo defines anInternet Draft. Internet Drafts are working documents ofExperimental Protocol for the InternetEngineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts.community. This memo does not specify an InternetDrafts are draft documents valid for a maximumstandard ofsix months. Internet Drafts may be updated, replaced, or obsoleted by other documents atanytime. 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 statuskind. Discussion and suggestions for improvement are requested. Distribution of thisor any other Internet Draft.memo is unlimited. 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[2]. 1. X.400/RFC 822 Mappings RFC 1327 defines an algorithm for maintaining a global mapping between X.400 and RFC 822 addresses directory [2]. RFC 1327 also defines a table based mechanism for maintaining this mapping. There is substantial benefit to maintaining this mapping within the directory. In particular, this willbe submittedlead to an approach for managing theRFC editor as a protocol standard. Distributionmapping which is both distributed and scalable. Mechanisms for representing O/R Address and Domain hierarchies within the DIT are defined in [1, 5]. These techniques are used to define two independent subtrees in the DIT, which contain the mapping information. The benefits of thismemoapproach are: 1. The mapping information isunlimited. Please send commentskept in a clearly defined area which can be widely replicated in an efficient manner. The tree is constrained to hold only information needed to support theauthor ormapping. This is important as gateways need good access to thediscussion group <mhs-ds@mercury.udev.cdc.com>. INTERNET--DRAFTentire mapping. 2. It facilitates migration from the currently deployed table-based approach. 3. It handles the issues of "missing components" in a natural manner. Kille Experimental [Page 1] RFC 1838 RFC 822/X.400 Mapping by X.500November 1992 1 RFC 1327 Mappings ItAugust 1995 An alternative approach which is not taken isimportant to be abletorepresent RFC 1327 mappings in the directory [Kil92]. The three RFC 1327 mappings are represented withinlocate theO/R Address and Domain hierarchies withininformation in theDIT [HK91, HK92b].routing subtrees. The benefits ofusing the existing O/R address and domain trees are:this would be: o It is the``natural''"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.oThisefficiency can be increased by representing mappings which can be derived from the basic mappings,is not done, asdefine in [HK92a]. An alternativethe benefits of the approach proposed are greater. There are three mappings, whichis not taken is to locateare represented by two subtrees located under: OU=X.400/RFC 822 Mapping, O=Internet These subtree roots are of object class subtree, and use theinformation in separate subtrees, as defined in [HK92b]. Bymechanism for representingthe informationsubtrees defined inseparate subtrees,[4]. X.400 to RFC 822 This table gives the equivalence mappinginformation would be kept in a clearly defined area which can be widely replicated infrom X.400 to RFC 822. There is anefficient manner. ThisO/R Address tree under this. An example entry is: PRMD=UK.AC, ADMD=Gold 400, C=GB, CN=X.400 to RFC 822, OU=X.400/RFC 822 Mapping, O=Internet RFC 822 to X.400 There isnot done, asa domain tree under this. This table holds thebenefits ofequivalence mapping from RFC 822 to X.400, and theapproach proposed are greater.gateway mapping defined in RFC 1327. An example entry is: DomainComponent=ISODE, DomainComponent=COM, CN=RFC 822 to X.400, OU=X.400/RFC 822 Mapping, O=Internet The values of the table mapping are defined by use of two new object classes, as specified in Figure 1.2The objects give pointers to the mapped components. Kille Experimental [Page 2] RFC 1838 RFC 822/X.400 Mapping by X.500 August 1995 2. Omitted Components In RFC 1327, it is possible to have omitted components in O/R Addresses on either side of the mapping. A mechanism to represent such omitted components is defined in Figure 2. The attribute at-or-address-component-type is set to the X.500 attribute type associated with the omitted component (e.g., at-prmd- name). This mechanism is for use only within the X.400 to RFC 822 subtree and for the at-associated-or-address attribute. ----------------------------------------------------------------------- rFC822ToX400Mapping OBJECT-CLASS ::= { SUBCLASS OF {domain-component} MAY CONTAIN { associatedORAddress| associatedX400Gateway} ID oc-rfc822-to-x400-mapping} x400ToRFC822Mapping OBJECT-CLASS ::= { SUBCLASS OF {top} MAY CONTAIN { 10 associatedDomain} ID oc-x400-to-rfc822-mapping} associatedORAddress ATTRIBUTE ::= { SUBTYPE OF distinguishedName SINGLE VALUE ID at-associated-or-address} 20 associatedX400Gateway ATTRIBUTE ::= { SUBTYPE OF mhs-or-addresses MULTI VALUE ID at-associated-x400-gateway} associatedDomain ATTRIBUTE ::= { SUBTYPE OF name WITH SYNTAX caseIgnoreIA5String SINGLE VALUE ID at-associated-domain} 30 Figure 1: ObjectClasses for RFC 1327 mappings Kille Experimental [Page 3] RFC 1838 RFC 822/X.400 Mapping by X.500 August 1995 ----------------------------------------------------------------------- omittedORAddressComponent OBJECT-CLASS ::= SUBCLASS OF {top} MUST Contain { oRAddressComponentType } ID oc-omitted-or-address-component} oRAddressComponentType ATTRIBUTE ::= { SUBTYPE OF objectIdentifier 10 SINGLE VALUE ID at-or-address-component-type} Figure 2: Omitted O/R Address Component 3. Mapping from X.400 to RFC 822 As an example, consider the mapping from the O/R Address:PRMD=UK.AC; ADMD=GoldP=UK.AC; A=Gold 400; C=GB This would be keyed by the directory entry: PRMD=UK.AC, ADMD=Gold 400,C=GBC=GB, CN=X.400 to RFC 822, OU=X.400/RFC 822 Mapping, O=Internet and return the mapping from the associatedDomain attribute, which gives the domain which this O/R address maps to. This attribute isHardcastle-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 1992used to define authoritative mappings, which are placed in the open community tree. The manager of an RFC 1327 mappingshouldshall 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 ina convenient routing tree. For authoritative information,theopen tree must be used, but for performance reasons, another tree will Hardcastle-Kille Expires: June 1993 Page 3 INTERNET--DRAFTin the X.400 to RFC822/X.400 Mapping by X.500 November 1992 usually822 subtree. This lookup will either succeed, or it will fail and indicate the longest possible match, which can then beused 1.looked up. 3. Check for an associatedDomainor 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,attribute in the matched entry. Kille Experimental [Page 4] RFC 1838 RFC 822/X.400 Mapping by X.500 August 1995 The mapping can always be achieved with two lookups.3Because 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. 4. 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, CN=RFC 822 to X.400, OU=X.400/RFC 822 Mapping, O=Internet This has associated with it the attributeassociatedORAddress,associatedORAddress encoded as a distinguished name with a value:PRMD=UK.AC;PRMD=UK.AC, ADMD=Gold400;400, C=GBThere is an optimisation analogous to the reverse mapping provided by the nonAuthoritativeORAddress attribute.The``table 3''"table 3" mapping defined in RFC 1327 [2] is provided by the associatedX400Gateway attribute. This value maybe 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 1992identify 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. Because of the nature of the mapping a domain will map to either a gateway or a domain, but not both. Thus, there shall never be both an associatedX400Gateway and associatedORAddress attribute present in the same entry. Functionally, mapping takes place exactly according to RFC 1327. The longest match is found by the following algorithm. 1.DerivedDerive a directory name from the domain part of the RFC 822 address. 2. Look up this name in the RFC 822 to X.400 subtree to find the mapped value(associatedORAddress(either associatedORAddress ornonAuthoritativeAssociatedORAddress oassociatedX400Gateway.).oIf the lookup fails, the error will indicate the longest match, which can then be looked up. If associatedORAddress is found, this will define the mappedvalueO/R Address. The mapping can always be achieved with two lookups. If an associatedX400Gateway is present,stop. o If not, strip one component ofthename, and repeat.address in question will be encoded as a domain defined attribute, relative to the O/R Address defined by this attribute. If multiple associatedX400Gateway Kille Experimental [Page 5] RFC 1838 RFC 822/X.400 Mapping by X.500 August 1995 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. 5. Acknowledgements Acknowledgements for work on this document are given in [3]. References[HK91] S.E. Hardcastle-Kille. X.500[1] Kille, S. "X.500 anddomains. Request for CommentsDomains", 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[2] Kille, S., "Mapping betweenX.400(1988) / ISOX.400(1988)/ISO 10021 and RFC822. Request for Comments822", RFC 1327, Department of Computer Science, University College London, May 1992.Hardcastle-Kille Expires:[3] Kille, S., "MHS Use of the X.500 Directory to Support MHS Routing", RFC 1801, ISODE Consortium, June1993 Page 5 INTERNET--DRAFT1995. [4] Kille, S., "Representing Tables and Subtrees in the X.500 Directory", RFC822/X.400 Mapping by1837, ISODE Consortium, August 1995. [5] Kille, S., "Representing the O/R Address Hierarchy in the X.500November 1992 4Directory Information Tree", RFC 1836, ISODE Consortium, August 1995. 6. Security Considerations Securityconsiderationsissues are not discussed in thisINTERNET--DRAFT . 5memo. Kille Experimental [Page 6] RFC 1838 RFC 822/X.400 Mapping by X.500 August 1995 7. Author's Address SteveHardcastle-KilleKille ISODE ConsortiumPO Box 505 London SW11 1DXThe Dome The Square Richmond TW9 1DT England Phone:+44-71-223-4062+44-81-332-9091 Internet EMail: S.Kille@ISODE.COMDN: CN=Steve Hardcastle-Kille,X.400: I=S; S=Kille; O=ISODEConsortium, C=GBConsortium; P=ISODE; A=Mailnet; C=FI; UFN: S.Hardcastle-Kille,Kille, ISODE Consortium, GBHardcastle-Kille Expires: June 1993 Page 6 INTERNET--DRAFTKille Experimental [Page 7] RFC 1838 RFC 822/X.400 Mapping by X.500November 1992August 1995 A Object Identifier Assignment_______________________________________________________________________----------------------------------------------------------------------- mhs-dsOBJECT-IDENTIFIEROBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) isode-consortium (453) mhs-ds(3)}(7)} 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} 10oc-x400-to-x400-mappingoc-x400-to-rfc822-mapping OBJECT IDENTIFIER ::= {oc 2} oc-omitted-or-address-component OBJECT IDENTIFIER ::= {oc 3} at-associated-or-address OBJECT IDENTIFIER ::= {at1} at-non-authoriatative-associated-or-address6} at-associated-x400-gateway OBJECT IDENTIFIER ::= {at2}3} at-associated-domain OBJECT IDENTIFIER ::= {at 4}at-non-authoritative-associated-domainat-or-address-component-type OBJECT IDENTIFIER ::= {at5} _______________Figure_2:__Object_Identifier_Assignment_________________ Hardcastle-Kille Expires: June 1993 Page 77} Figure 3: Object Identifier Assignment Kille Experimental [Page 8] ----