doc: Add RFC documents

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]
+