1 files changed, 234 insertions, 0 deletions
diff --git a/doc/rfc/rfc1026.txt b/doc/rfc/rfc1026.txt
new file mode 100644
index 0000000..91e143f
--- /dev/null
+++ b/doc/rfc/rfc1026.txt
@@ -0,0 +1,234 @@
+
+Network Working Group                                          S.E. Kille
+Request for Comments 1026                       University College London
+                                                           September 1987
+
+                         Addendum to RFC 987
+
+                 (Mapping between X.400 and RFC-822)
+
+
+
+
+
+Status of this Memo
+
+   This RFC suggest a proposed protocol for the Internet community, and
+   requests discussion and suggestions for improvements.  Distribution
+   of this memo is unlimited.
+
+   This document specifies a number of additions and corrections to
+   RFC-987, aka Mailgroup Note 19.
+
+   The addendum carries equal weight to the original specification,
+   which must be used when this mapping is performed on the Internet or
+   in the UK Academic Community.  This mapping may also be used within
+   the RARE community in Europe.  This specification may be modified in
+   the light of implementation experience, but no substantial changes
+   are expected.
+
+1.  Errata
+
+   -    In section 4.6.4, replace ".." with ".".
+
+   -    In section 4.2.4, replace three references to 4.3.1 by
+        4.2.1, and one reference to 4.2.2 by 4.1.2.
+
+   -    In section 5.2, replace "1  mailbox" with "1#mailbox",
+        "1 msg-id" with "1#msg-id" and "1 encoded-type" with
+        "1#encoded-type".
+
+2.  Component Ordering
+
+   In most cases, ordering of O/R name components is not significant for
+   the mappings specified by this document.  However, Organisational
+   Units and Domain Defined Attributes are specified as SEQUENCE, in
+   P1.ORName, and so their order may be significant.  This specification
+   needs to take account of this in two ways:
+
+   1)   To allow consistent mapping into the domain hierarchy
+
+   2)   To ensure preservation of order over multiple mappings.
+
+
+
+
+Kille                                                           [Page 1]
+
+RFC 1026                                                  September 1987
+
+
+There are three places where an order must be specified:
+
+   1)   On the text encoding (std-orname) of P1.ORName as used in the
+        local-part of an RFC-822 address, the most significant component
+        must be on the RHS.  This applies only to those components which
+        may have multiple values (Organisational Unit, and Domain
+        Defined Attributes).  Other attributes may be presented in any
+        order. Note that in dmn-orname specified in Appendix F, this
+        ordering is already implied by the current ordering
+        requirements.
+
+   2)   For the Organisational Units (OU) in P1.ORName, the first OU in
+        the SEQUENCE is the most signicicant.  This follows the
+        "natural" hierarchy of the specification of P1.ORName, where the
+        most significant components are defined first.
+
+   3)   For the Domain Defined Attributes in P1.ORName, the First Domain
+        Defined Attribute in the SEQUENCE is the most significant.
+
+   Note that although the ordering defined in 2) and 3) is mandatory for
+   this mapping, there are NO implications on ordering significance
+   within X.400.
+
+   3.  Extensions To Deal with Omitted Components
+
+   Implementation of RFC-987 has proved to be a little inflexible for
+   some naming strategies.  In particular, there are some difficulties
+   where Organisation or PRMD is omitted:
+
+   The following sentence of RFC-987 should be removed: 4.2.1 (Page 27):
+   "If one of the hierarchical components is omitted ....  tuple).".
+
+   The strategy proposed is to introduce the concept of explicit missing
+   components to the symmetrical mapping described in 4.2.1.
+   Essentially, a domain may be associated with an omitted attribute in
+   conjuction with several present ones.  When performing the
+   algorithmic insertion of components lower in the hierarchy, the
+   omitted value should be skipped.  For example, if "GMD.DFN" is
+   associated with "C=DE", "ADMD=DBP", "PRMD=GMD", and omitted
+   organisation, then "ZI.GMD.DFN" is mapped with "C=DE", "ADMD=DBP",
+   "PRMD=GMD", "OU=ZI".  It should be noted that attributes may have
+   null values, and that this is treated separately from omitted
+   attributes (whilst it would be bad practice to treat these two cases
+   differently, they must be allowed for in practice).
+
+
+
+
+
+
+
+
+
+
+Kille                                                           [Page 2]
+
+RFC 1026                                                  September 1987
+
+
+   To allow the mapping of null organisations to be represented in the
+   specification of Appendix F, the dmn-orname syntax is extended, so
+   that values may be given the symbol "@" (not a printable string
+   character). This corresponds to an omitted attribute. The new
+   definition is:
+
+           dmn-orname      = dmn-part *( "." dmn-part )
+           dmn-part        = attribute "$" value
+           attribute       = standard-type
+                           / "~" dmn-printablestring
+           value           = dmn-printablestring
+                           / "@"
+           dmn-printablestring
+                           = *( dmn-char / dmn-pair )
+           dmn-char        = <ps-delim, and any ps-char except ".">
+           dmn-pair        = "."
+
+   Appendix F - Format of address mapping tables
+
+   A new Appendix F is defined as follows:
+
+   There is a need to specify the association between the domain and
+   X.400 namespaces described in 4.2.1.  This is defined as a table
+   syntax, but the syntax is defined in a manner which makes it suitable
+   for use with domain nameservices (such as the Internet Domain
+   nameservers or the UK NRS).  The mapping is not symmetric, and so a
+   separate table is specified for each direction.  If multiple matches
+   are possible, the longest possible match should be used.
+
+   Various restrictions are placed on the usage of dmn-orname:
+
+   1)   Only C, ADMD, PRMD, O, and OU may be used.
+
+   2)   There must be a strict ordering of all components, with the most
+        significant components on the RHS.
+
+   3)   No components may be omitted from the hierarchy, although the
+        hierarchy may terminate at any level.  If the mapping is to an
+        omitted component, the "@" syntax is used.
+
+   For domain -> X.400:
+
+           domain-syntax "#" dmn-orname "#"
+
+   Note that the trailing "#" is used for clarity, as the dmn-orname
+   syntax can lead to values with trailing blanks.
+
+           For example:
+
+           AC.UK#PRMD$DES.ADMD$BT.C$UK#
+           XEROX.COM#O$Xerox.ADMD$ATT.C$US#
+
+
+
+Kille                                                           [Page 3]
+
+RFC 1026                                                  September 1987
+
+
+           HMI.DBP.DFN#O$@.PRMD$HMI.ADMD.DBP.C$DE#
+
+   For X.400 -> domain:
+
+           dmn-orname "#" domain-syntax "#"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille                                                           [Page 4]
+