summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1838.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1838.txt')
-rw-r--r--doc/rfc/rfc1838.txt451
1 files changed, 451 insertions, 0 deletions
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]
+