From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1838.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc1838.txt (limited to 'doc/rfc/rfc1838.txt') diff --git a/doc/rfc/rfc1838.txt b/doc/rfc/rfc1838.txt new file mode 100644 index 0000000..d0f3c6c --- /dev/null +++ b/doc/rfc/rfc1838.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group S. Kille +Request for Comments: 1838 ISODE Consortium +Category: Experimental August 1995 + + + Use of the X.500 Directory to support mapping between X.400 + and RFC 822 Addresses + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this 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 [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 will lead to an approach for managing + the mapping 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 this approach are: + + 1. The mapping information is kept 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 the + mapping. This is important as gateways need good access to the + entire 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.500 August 1995 + + + An alternative approach which is not taken is to locate the + information in the routing subtrees. The benefits of this + would be: + + 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. + + This is not done, as the benefits of the approach proposed + are greater. + + There are three mappings, which are represented by two subtrees + located under: + + OU=X.400/RFC 822 Mapping, O=Internet + + These subtree roots are of object class subtree, and use the + mechanism for representing subtrees defined in [4]. + + X.400 to RFC 822 This table gives the equivalence mapping from X.400 + to RFC 822. There is an O/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 is a domain tree under this. This table holds + the equivalence mapping from RFC 822 to X.400, and the 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. The 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: + + P=UK.AC; A=Gold 400; C=GB + + This would be keyed by the directory entry: + + PRMD=UK.AC, ADMD=Gold 400, C=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 is + used to define authoritative mappings, which are placed in the open + community tree. The manager of an RFC 1327 mapping shall make the + appropriate entry. + + 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 the in + the X.400 to RFC 822 subtree. This lookup will either succeed, + or it will fail and indicate the longest possible match, which + can then be looked up. + + 3. Check for an associatedDomain 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. + + 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. + +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 attribute associatedORAddress encoded + as a distinguished name with a value: + + PRMD=UK.AC, ADMD=Gold 400, C=GB + + The "table 3" mapping defined in RFC 1327 [2] is provided by the + associatedX400Gateway attribute. This value may 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. + 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. Derive 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 (either associatedORAddress or + associatedX400Gateway.). If the lookup fails, the error will + indicate the longest match, which can then be looked up. + + If associatedORAddress is found, this will define the mapped O/R + Address. The mapping can always be achieved with two lookups. If an + associatedX400Gateway is present, the 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. + + 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 + + [1] Kille, S. "X.500 and Domains", RFC 1279, + Department of Computer Science, University College London, + November 1991. + + [2] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC 822", + RFC 1327, Department of Computer Science, University College + London, May 1992. + + [3] Kille, S., "MHS Use of the X.500 Directory to Support MHS + Routing", RFC 1801, ISODE Consortium, June 1995. + + [4] Kille, S., "Representing Tables and Subtrees in the X.500 + Directory", RFC 1837, ISODE Consortium, August 1995. + + [5] Kille, S., "Representing the O/R Address Hierarchy in the X.500 + Directory Information Tree", RFC 1836, ISODE Consortium, August + 1995. + +6. Security Considerations + + Security issues are not discussed in this memo. + + + + + + + + + + + + + + + + + + +Kille Experimental [Page 6] + +RFC 1838 RFC 822/X.400 Mapping by X.500 August 1995 + + +7. Author's Address + + Steve Kille + ISODE Consortium + The Dome + The Square + Richmond + TW9 1DT + England + + Phone: +44-81-332-9091 + Internet EMail: S.Kille@ISODE.COM + + X.400: I=S; S=Kille; O=ISODE Consortium; P=ISODE; + A=Mailnet; C=FI; + + UFN: S. Kille, ISODE Consortium, GB + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille Experimental [Page 7] + +RFC 1838 RFC 822/X.400 Mapping by X.500 August 1995 + + +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 (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} 10 +oc-x400-to-rfc822-mapping OBJECT IDENTIFIER ::= {oc 2} +oc-omitted-or-address-component OBJECT IDENTIFIER ::= {oc 3} + +at-associated-or-address OBJECT IDENTIFIER ::= {at 6} +at-associated-x400-gateway OBJECT IDENTIFIER ::= {at 3} +at-associated-domain OBJECT IDENTIFIER ::= {at 4} +at-or-address-component-type OBJECT IDENTIFIER ::= {at 7} + +Figure 3: Object Identifier Assignment + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kille Experimental [Page 8] + -- cgit v1.2.3