doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc1405.txt b/doc/rfc/rfc1405.txt
new file mode 100644
index 0000000..286803b
--- /dev/null
+++ b/doc/rfc/rfc1405.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                       C. Allocchio
+Request for Comments: 1405                              I.N.F.N. - Italy
+                                                            January 1993
+
+
+       Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  Discussion and suggestions for improvement are requested.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" for the standardization state and status of this protocol.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes a set of mappings which will enable inter
+   working between systems operating the CCITT X.400 ( 1984 / 1988 )
+   Recommendations on Message Handling Systems, and systems running the
+   Mail-11 (also known as DECnet mail) protocol. The specifications are
+   valid within DECnet Phase IV addressing and routing scheme.
+
+   The complete scenario of X.400 / RFC822 / Mail-11 is also considered,
+   in order to cover the possible complex cases arising in multiple
+   gateway translations.
+
+   This document covers mainly the O/R address to DECnet from/to address
+   mapping (and vice versa); other mappings are based on RFC 1327 and
+   its eventual future updates.
+
+   This is a combined effort of COSINE S2.2, the RARE MSG Working Group,
+   and the IETF X.400 Ops Working Group.
+
+Chapter 1 - Introduction
+
+1.1. X.400
+
+   The standard referred shortly into this document as "X.400" relates
+   to the CCITT 1984 and 1988 X.400 Series Recommendations covering the
+   Message Oriented Text Interchange Service (MOTIS). This document
+   covers the Inter Personal Messaging System (IPMS) only.
+
+1.2. Mail-11
+
+   Mail-11, also known as DECnet mail and often improperly referred as
+   VMSmail, is the proprietary protocol implemented by Digital Equipment
+   Corporation (DEC) to establish a real-time text messaging system
+
+
+
+Allocchio                                                       [Page 1]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+   among systems implementing the DECnet Phase IV networking protocols.
+
+1.3. RFC822
+
+   RFC822 was defined as a standard for personal messaging systems
+   within the DARPA Internet and is now diffused on top of many
+   different message transfer protocols, like SMTP, UUCP, BITNET, JNT
+   Grey Book, CSnet. Its mapping with X.400 is fully described in
+   RFC1327. In this document we will try to consider its relations with
+   Mail-11, too.
+
+1.4. The user community
+
+   The community using X.400 messaging system is currently growing in
+   the whole world, but there is still a number of very large
+   communities using Mail-11 based messaging systems willing to
+   communicate easily with X.400 based Message Handling Systems. Among
+   these large DECnet based networks we can include the High Energy
+   Physics network (HEPnet) and the Space Physics Analysis Network
+   (SPAN).
+
+   These DECnet communities will in the future possibly migrate to
+   DECnet Phase V (DECnet-OSI) protocols, converting thus their
+   messaging systems to OSI specifications, i.e., merging into the X.400
+   MHS; however the transition period could be long, and there could
+   always be some DECnet Phase IV communities around.
+
+   For these reasons a set of mapping rules covering conversion between
+   Mail-11 and X.400 is described in this document.
+
+   This document also covers the case of Mail-11 systems implementing
+   the "foreign mail protocol" allowing Mail-11 to interface other mail
+   systems, including RFC822 based system.
+
+Chapter 2 - Message Elements
+
+2.1. Service Elements
+
+   Mail-11 protocol offers a very restricted set of elements composing a
+   Inter Personal Message (IPM), whereas X.400 specifications support a
+   complex and large amount of service elements. Considering the case
+   where a message is relayed between two X.400 MHS via a DECnet network
+   this could result in a nearly complete loss of information. To
+   minimise this inconvenience most of X.400 service elements will be
+   mapped into Mail-11 text body parts. To consider also the case when a
+   message originates from a network implementing RFC822 protocols and
+   is relayed via Mail-11 to and X.400 MHS, the applied mapping from
+   X.400 service elements into Mail-11 text body part the rules
+
+
+
+Allocchio                                                       [Page 2]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+   specified in RFC1327 and their updates will be used, producing an
+   RFC822-like header.
+
+2.2. Mail-11 service elements
+
+   All envelope (P1) and header (P2) Mail-11 service elements are
+   supported in the conversion to X.400. Note that Mail-11 P1 is solely
+   composed by P1.From and P1.To, and any other Mail-11 element belongs
+   to Mail-11 P2:
+
+        - P1.From
+                maps to P1.Originator
+
+        - P1.To
+                maps to P1.Primary Recipient
+
+        - P2.From
+                maps to P2.Originator
+
+        - P2.To
+                maps to P2.Primary Recipient
+
+        - Cc
+                maps to P2.Copy Recipient
+
+        - Date
+                maps to Submission Time Stamp
+
+        - Subj
+                maps to Subject
+
+   Any eventual RFC822-like text header in Mail-11 body part will be
+   interpreted as specified into RFC1327 and its updates.
+
+2.3. X.400 service elements
+
+   The following X.400 service elements are supported directly into
+   Mail-11 conversion:
+
+        - P1.Originator
+                maps to P1.'From'
+
+        - P1.Primary Recipients
+                maps to P1.'To'
+
+        - P2.Originator
+                maps to P2.'From'
+
+
+
+
+Allocchio                                                       [Page 3]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+        - P2.Primary Recipients
+                maps to P2.'To'
+
+        - Copy Recipients
+                maps to 'Cc'
+
+        - Submission Time Stamp
+                maps to 'date'
+
+        - Subject
+                maps to 'Subj'
+
+   The following X.400 service element is partially supported into
+   Mail-11 conversion:
+
+        - Blind Copy Recipient
+                to ensure the required privacy, when a message contains
+                a BCC address, the following actions occurs:
+                - a new message is created, containing the body parts;
+                - a new envelope is added to the new message, containing
+                  the originator and the BCC recipient addresses only;
+                - a note is added to the message informing the BCC
+                  recipient about the fact that the message was a BCC;
+                - the new message is delivered separately;
+                - a note is added to the message delivered to TO and CC
+                  recipients informing them about the fact that there
+                  were some BCC recipients, too.
+
+   Any other X.400 service element support is done accordingly to
+   RFC1327 including the mapped element into the RFC822-like header into
+   Mail-11 body part.
+
+Chapter 3 - Basic Mappings
+
+   The basic mappings indicated in RFC1327 and its updates should be
+   fully used.
+
+Chapter 4 - Addressing
+
+4.1. Mail-11 addressing
+
+   Mail-11 addressing can vary from a very simple case up to complex
+   ones, if there are other Mail-11 to "something-else" gateways
+   involved. In any case a Mail-11 address is an ASCII string composed
+   of different elements.
+
+
+
+
+
+
+Allocchio                                                       [Page 4]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+4.2. X.400 addressing
+
+   On the other hand, An X.400 O/R address is a collection of
+   attributes, which can anyway be presented as an IA5 textual
+   representation as defined in chapter 4 of RFC1327.
+
+4.3. Mail-11 address components
+
+   Let us start defining the different parts composing a Mail-11
+   address. We can consider any Mail-11 address as composed by 3 parts:
+
+        [[route]::] [[node]::] local-part
+
+   where 'route' and 'node' are optional and only 'local-part' is
+   compulsory.
+
+   Here comes a strict definition of these elements
+
+     node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT
+
+     route = *(node "::")
+
+     local-part = username / nickname / for-protocol
+
+     username = *(ALPHA/DIGIT)
+
+     nickname = <printablestring - <" " and HTAB>>
+
+     for-protocol = (f-pref f-sep <">f-address<">)
+
+     f-pref = *(ALPHA/DIGIT)
+
+     f-sep = "%" / "::"
+
+     f-address = printablestring / RFC822-address / X400-text-address
+
+     X400-text-address = <textual representation of an X.400 O/R addr>
+
+   Please note that in x-text-address both the ";" notation and the "/"
+   notation are equivalent and allowed (see examples in different sect.)
+
+
+
+
+
+
+
+
+
+
+
+Allocchio                                                       [Page 5]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+   Some examples:
+
+      route           node    local-part
+      -----------------------------------------------------------
+                              USER47
+                      MYNODE::BETTY
+      BOSTON::CLUS02::GOOFY1::MARY34
+                              IN%"M.P.Tracy@Dicdum.cc.edu"
+              UCLA13::MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB"
+                      MIAMI2::George.Rosenthal
+              CCUBVX::VS3100::Jnet%"IAB3425@IBAX23L"
+                              MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
+                      MAINVX::IN%"path1!path2!user%dom"
+                      GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;"
+                      GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee"
+                              smtp%"postmast@nodeb.bitnet"
+              MICKEY::PRFGAT::profs%"NANCY@IBMB"
+                              edu%"HU427BD%CSUNIB@abc.acme.edu"
+
+Chapter 5 - Mapping
+
+5.1. Mapping scheme
+
+   DECnet address field is somehow a 'flat land' with some obliged
+   routes to reach some hidden areas. Thus a truly hierarchical mapping
+   scheme using mapping tables as suitable for RFC822 is not the
+   appropriate solution. A fixed set of rules using DDAs support is
+   defined in order to define the mapping.
+
+   Another important aspect of the problem is the coexistence of many
+   disjoint DECnet networks, using the same DECnet address space, i.e.,
+   common X.400 and/or RFC822 mailing system acting as glue to connect
+   different isolated Mail-11 islands. Thus, to identify uniquely each
+   DECnet network we must also introduce the concept of 'DECnet network
+   name', which we will refer shortly as 'net' from now onwards. We
+   define as 'net' a unique ASCII string identifying the DECnet network
+   we are connected to. To be more specific, the 'net' element will
+   identify the DECnet community being served, i.e., it could also
+   differ from the actual official network name. Aliases are allowed for
+   the
+
+       net = 'HEPnet'       the High Energy Physics DECnet network
+       net = 'SPAN'         the Space Physics Analysis Network
+       net = 'Enet'         the Digital Equipment Corporate Network
+
+   The need of labelling each DECnet network with its name comes also
+   from the requirement to implement the 'intelligent' gateway, i.e.,
+   the gateway which is able to understand its ability to connect
+
+
+
+Allocchio                                                       [Page 6]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+   directly to the specified DECnet network, even if the O/R address
+   specify a path to a different gateway. A more detailed discussion of
+   the problem is in 5.3 and 5.5.
+
+   A registry of 'net' attributes and their correspondent gateways must
+   also be implemented to insure uniqueness of names. A simple table
+   coupling 'net' and the gateway address is used, in a syntax similar
+   to the 'gate' table used in RFC1327. An example:
+
+        HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
+        SPAN#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
+        SPAN#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#
+
+   Ambiguous left entries are allowed. Gateway implementations could
+   simply choose among one of them, or try them all in cyclic order to
+   obtain better performances.
+
+   In order to keep the mapping rules very simple, avoiding the need to
+   analyse Mail-11 addresses to distinguish the 'route', 'node' and
+   needed to cover the mapping problem.
+
+5.2. Mail-11 --> X.400
+
+    We define the following Domain Defined Attributes to map a Mail-11
+   address:
+
+        DD.Dnet
+        DD.Mail-11
+
+   We thus define the mapping rule
+
+        route::node::localpart
+
+   maps into
+
+        C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
+        DD.Mail-11=route::node::localpart;
+
+   with
+
+        xx  = country code of the gateway performing the conversion
+        yyy = Admd of the gateway performing the conversion
+        zzz = Prmd of the gateway performing the conversion
+        ooo = Organisation of the gateway performing the conversion
+        uuu = Org. Unit(s) of the gateway performing the conversion
+        net = name of the DECnet network (e.g., HEPnet, SPAN,...)
+
+   ('zzz','ooo','uuu' being used or dropped appropriately in order to
+
+
+
+Allocchio                                                       [Page 7]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+   identify uniquely within the X.400 MHS the gateway performing the
+   conversion).
+
+   The following defaults also apply:
+
+   if 'node' is missing and we are mapping the Mail-11 originator (From)
+   then 'node' defaults to the DECnet node name of the gateway (gwnode);
+
+   if 'node' is missing and we are mapping the Mail-11 recipient (To,
+   Cc) then 'node' defaults to the DECnet node name of the 'From'
+   address.
+
+   if 'DD.Dnet=net' is missing, then it defaults to a value defined
+   locally by the gateway: if the gateway is connected to one DECnet
+   network only, then 'net' will be the name of this unique network; if
+   the gateway is connected to more than one DECnet network, then the
+   gateway will establish a 'first choice' DECnet network, and 'net'
+   will default to this value.
+
+   In case 'local-part' contains 'x400-text-address' see also section
+   6.4.3;
+
+   In case 'local-part' contains 'RFC822-address' see also section
+   6.4.4.
+
+5.2.1. Examples
+
+   Let us suppose that:
+
+     the DECnet network name (net) is 'HEP';
+     the DECnet node name of the gateway (gwnode) is 'X4TDEC';
+     the Country Code of the gateway is 'IT' and its ADMD is 'garr'
+     (and these two fields are enough to identify uniquely the gateway
+     within the X.400 MHS).
+
+    USER47
+     C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=X4TDEC::USER47;
+
+    MYNODE::BETTY
+     C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MYNODE::BETTY;
+
+    BOSTON::CLUS02::GOOFY1::MARY34
+     C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=BOSTON::GOOFY1::MARY34;
+
+    UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB"
+     C=it; ADMD=garr; DD.Dnet=HEP;
+     DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q)
+
+
+
+
+Allocchio                                                       [Page 8]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+    MIAMI2::George.Rosenthal
+     C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MIAMI2::George.Rosenthal;
+
+    MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
+     C=it; ADMD=garr; DD.Dnet=HEP;
+     DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q)
+
+    MAINVX::In%"path1!path2!user%dom"
+     C=it; ADMD=garr; DD.Dnet=HEP;
+     DD.Mail-11=MAINVX::In(p)(q)path1(b)path2(b)user(p)dom(q)
+
+5.3. X.400 encoding of Mail-11 --> Mail-11
+
+   In order to assure path reversibility in case of multiple Mail-
+   11/X.400 gateway crossing we must distinguish two cases:
+
+   - DD.Dnet=net is known to the gateway as one of the DECnet networks
+     it is connected to. In this case the mapping is trivial:
+
+        C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
+        DD.Mail-11=route::node::localpart;
+
+   (see sect. 5.2 for explication of 'xx','yyy','zzz','ooo','uuu','net')
+
+   maps into
+
+        route::node::localpart
+
+   - DD.Dnet=net is NOT known to the gateway as one of the DECnet
+     networks it is connected to. In this case the mapping rule
+     described into section 5.4 apply:
+
+        C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net;
+        DD.Mail-11=route::node::localpart;
+
+   maps into
+
+        gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net;
+        DD.Mail-11=route::node::localpart;"
+
+5.3.1. Examples
+
+   Let us suppose that:
+
+     the DECnet network name (net) is 'HEP';
+     the DECnet node name of the gateway (gwnode) is 'X4TDEC';
+     the Country Code of the gateway is 'IT' and its ADMD is 'garr';
+     (and these two fields are enough to identify uniquely the gateway
+
+
+
+Allocchio                                                       [Page 9]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+     within the X.400 MHS).
+
+     C=it; ADMD=garr; DD.Dnet=HEP;
+     DD.Mail-11=X4TDEC::MRGATE::(q)C=ab::A=dsa::P=qwty::OU=mie::S=Cly(q)
+       MRGATE::"C=ab::A=dsa::P=qwty::OU=mie::S=Cly"
+
+     C=it; ADMD=garr; DD.Dnet=EASYNET; DD.Mail-11=ROM01::CARLO;
+       X4TDEC::gw%"C=it;ADMD=garr;DD.Dnet=EASYNET;
+       DD.Mail-11=ROM01::CARLO;"
+
+   (in the above example 'EASYNET' is supposed to be not connected to
+   our gateway located on X4TDEC DECnet node).
+
+5.4. X.400 --> Mail-11
+
+   The mapping of an X.400 O/R address into Mail-11 is done encoding the
+   various attributes into the X400-text-address as defined in chapter 4
+   of RFC1327, and including this as 'f-address'. A 'f-pref' and a the
+   DECnet node name of the gateway.
+
+   Thus
+
+      x400-text-address
+
+   will be encoded like
+
+      gwnode::gw%"x400-text-address"
+
+   having spaces dividing attributes as optional.
+
+5.4.1. Example
+
+   Let us suppose that:
+
+     the DECnet node name of the gateway (gwnode) is 'X4TDEC';
+
+   Thus
+
+      C=gb; ADMD=Gold 400; PRMD=AC.UK; O=ucl; OU=cs; G=Jim; S=Clay;
+
+   will be encoded like
+
+    X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=ucl/OU=cs/G=Jim/S=Clay"
+
+   or its equivalent with the ";" notation
+
+    X4TDEC::gw%"C=gb;ADMD=Gold 400;PRMD=AC.UK;O=ucl;OU=cs;G=Jim;S=Clay;"
+
+
+
+
+Allocchio                                                      [Page 10]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+5.5. Mail-11 encoding of X.400 --> X.400
+
+   It can happened that Mail-11 is used to relay messages between X.400
+   systems; this will mean multiple X.400/Mail-11 gateway crossing and
+   we will encounter Mail-11 addresses containing embedded X.400
+   informations. In order to assure path reversibility we must then
+   distinguish two cases:
+
+   - the embedded X.400 address belongs to a domain whose naming and
+     routing rules are known to the global X.400 MHS.  In this case the
+     mapping is trivial:
+
+       route::gwnode::gw%"x400-text-address"
+
+   maps into
+
+       x400-text-address
+
+      'route' and 'gwnode' are mapped into X.400 Trace service elements.
+
+   - the encoded X.400 domain does not belong to the global X.400 name
+     space. In this case the mapping rule described into section 5.2
+     apply:
+
+       route::gwnode::gw%"x400-text-address"
+
+   maps into
+
+       C=xx; ADMD=yyy; DD.Dnet=net;
+       DD.Mail-11=route::gwnode::gw(p)(q)x400-text-address(q);
+
+   The latter case  is deprecated and must be regarded as a possible
+   temporary solution only, while waiting to include into the global
+   X.400 MHS also this domain.
+
+5.5.1. Examples
+
+   Let us suppose that:
+
+     the DECnet network name (net) is 'HEP';
+     the DECnet node name of the gateway (gwnode) is 'X4TDEC';
+     the Country Code of the gateway is 'IT' and its ADMD is 'garr';
+     (and these two fields are enough to identify uniquely the gateway
+     within the X.400 MHS).
+
+     X4TDEC::gw%"C=fr;ADMD=atlas;PRMD=ifip;O=poly;S=Moreau;"
+       C=fr; ADMD=atlas; PRMD=ifip; O=poly; S=Moreau;
+
+
+
+
+Allocchio                                                      [Page 11]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+     X4TDEC::gw%"C=zz;ADMD= ;PRMD=Botwa;O=Miner;S=Chiuaw;"
+       C=it; ADMD=garr; DD.Dnet=HEP;
+       DD.Mail-11=X4TDEC::gw(p)(q)C=zz;ADMD= ;
+       PRMD=Botwa;O=Miner;S=Chiuaw;(q)
+
+   (in the above example  C=zz is unknown to the global X.400 MHS)
+
+Chapter 6 - Complex mapping
+
+6.1. The protocol triangle
+
+   The bilateral mappings described in chapter 5 must be extended in
+   order to cover also the case in which also RFC822 addressing is
+   involved, and the following triangular situation occurs:
+
+                                   x.400
+                                   /  \
+                                  /    \
+                                 /      \
+                             Mail-11----RFC822
+
+   The X.400 - RFC822 side is fully covered by RFC1327, and the previous
+   chapters in this document cover the Mail-11 - X.400 side.
+
+   Currently a number of implementations also perform the mapping along
+   the Mail-11 - RFC822 side. The most important among these de facto
+   standards are discussed in Appendix A, jointly with a Mail-11 -
+   RFC822 mapping scheme which covers this side of the triangle.
+
+6.2. RFC822 mapped in Mail-11
+
+   The 'RFC822-address' is usually included in 'local-part' as
+
+        route::gwnode::gw%"rfc822-address"
+
+   an example
+
+        NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu"
+
+6.3. Mail-11 mapped in RFC822
+
+   There are different styles in mapping a Mail-11 address in RFC822;
+   let's have a short summary.
+
+   - Mail-11 address encoded in "Left Hand Side" (LHS) of RFC822
+     address, using "%" syntax or "::" syntax;
+
+        route::node::localpart
+
+
+
+Allocchio                                                      [Page 12]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+   maps to
+
+        localpart%node%route@gw-domains
+
+   or
+
+        "route::node::localpart"@gw-domains
+
+   where 'gw-domains' identify uniquely the Mail-11 / RFC822 gateway.
+
+   - Mail-11 address maps partly to LHS and partly to 'domain' part of
+     RFC822 address:
+
+        node::localpart
+
+   maps to
+
+        localpart@node.gw-domains
+
+   - Mail-11 address is completely hidden by a mapping table / directory
+     and the resultant RFC822 address contains no trace at all of the
+     original address.
+
+   As you could notice, in any of the quoted cases the resultant RFC822
+   address is not distinguishable from a genuine RFC822 address.
+
+6.4. Multiple conversions
+
+   Let us now examine briefly the possible situations which involve
+   multiple conversions, having one protocol as a relay between the
+   other two. This summary suggest some possible enhanced solutions to
+   avoid heavy and unduly mappings, but the 'step by step' approach,
+   considering blindly one conversion as disjointed to the other, as
+   described in the previous sections, can always be used.
+
+6.4.1. X.400 --> RFC822 --> Mail-11
+
+   We apply the RFC1327 rules to the first step, obtaining an RFC822
+   address which can be mapped in Mail-11 using the 'f-address' field,
+   as described in section 6.2.
+
+   an example:
+
+      C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
+
+   maps accordingly to RFC1327 to
+
+      Jim.Clay@cs.UCL.AC.UK
+
+
+
+Allocchio                                                      [Page 13]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+   and finally becomes
+
+      SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"
+
+   where 'SMTPGW' is the DECnet node name of the machine running the
+   RFC822 to Mail-11 gateway.
+
+6.4.2. Mail-11 --> RFC822 --> X.400
+
+   Some of the possible mapping described in section 6.3 apply to the
+   Mail-11 address, hiding completely its origin. The RFC1327 apply on
+   the last step.
+
+   an example:
+
+      RELAY::MYNODE::BETTY
+
+   could map into RFC822 as
+
+      BETTY%MYNODE@RELAY.dnet.gw1.it
+
+   and accordingly to RFC1327
+
+      C=it; A=garr; P=dom1; O=gw1; OU=RELAY; S=BETTY(p)MYNODE;
+
+   where 'dnet.gw1.it' is the domain of the machine running the Mail-11
+   to RFC822 gateway.
+
+6.4.3. X.400 --> Mail-11 --> RFC822
+
+   The X.400 address is stored into Mail-11 'f-address' element as
+   described in sections 5.3 and 5.4; then if the Mail-11 to RFC822
+   gateway is able to understand the presence of a 'x400-text-address'
+   into the Mail-11 address, then it applies RFC1327 to it, and encodes
+   header. Otherwise it applies the rules described in 6.3
+
+   an example:
+
+     C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
+
+   will be encoded like
+
+     X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"
+
+   If the Mail-11 to RFC822 gateway recognise the x400-text-address,
+   then the address becomes, accordingly to RFC1327
+
+     Jim.Clay@cs.UCL.AC.UK
+
+
+
+Allocchio                                                      [Page 14]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+   and the following RFC822 header line is added
+
+     Received: from X4TDEC with DECnet (Mail-11) on xx-xxx-xxxx.
+
+   Otherwise one of the dumb rules could produce
+
+    gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"@X4TDEC.doms
+
+6.4.4. RFC822 --> Mail-11 --> X.400
+
+   The RFC822 address is encoded in Mail-11 f-address element as
+   described in sect. 6.2; then if the Mail-11 to X.400 gateway is able
+   to understand the presence of an 'RFC822-address' into the Mail-11
+   address, then it applies RFC1327 to it, and encodes 'route' and
+   applies the rules described in 5.2 and 5.5.
+
+   an example:
+
+      Jim.Clay@cs.UCL.AC.UK
+
+   will be encoded like
+
+      SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"
+
+   If the Mail-11 to X.400 gateway recognise the RFC822-address, then
+   the address becomes, accordingly to RFC1327
+
+      C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
+
+   and a 'trace' record is added into the X.400 P1 data, stating that a
+   node named SMTPGW was crossed.
+
+   Otherwise dumb rule produces
+
+      C=it; ADMD=garr; DD.Dnet=HEP;
+      DD.Mail-11=SMTPGW::In(p)(q)Jim.Clay(a)cs.UCL.AC.UK(q)
+
+6.4.5. RFC822 --> X.400 --> Mail-11
+
+   We apply RFC1327 to the first conversion, obtaining an X.400 address.
+   Then the rules described in sections 5.3 and 5.4 are used to store
+   the X.400 address as 'x400-text-address' into the Mail-11
+
+   an example:
+
+      Jim.Clay@cs.UCL.AC.UK
+
+   maps accordingly to RFC1327 to
+
+
+
+Allocchio                                                      [Page 15]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+      C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
+
+   and finally becomes
+
+      SMTPGW::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"
+
+   where 'SMTPGW' is the DECnet node name of the machine running the
+   X.400 to Mail-11 gateway.
+
+6.4.6. Mail-11 --> X.400 --> RFC822
+
+   The Mail-11 address is encoded as specified in sections 5.2 and 5.5;
+   then RFC1327 is used to convert the address in RFC822.
+
+   an example:
+
+      RELAY::MYNODE::BETTY
+
+   maps into X.400 as
+
+      C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=RELAY::MYNODE::BETTY;
+
+   and accordingly to RFC1327
+
+      "/C=it/A=garr/DD.Dnet=HEP/DD.Mail-11=RELAY::MYNODE::BETTY"@gw2.it
+
+   where 'gw2.it' is the domain of the machine running the RFC1327
+   gateway.
+
+Appendix A Mail-11 - RFC822 mapping
+
+A.1 Introduction
+
+   The implementation of a Mail-11 - RFC822 gateway was faced by many
+   software developers independently, and was included in many mail
+   products which were running on both VAX/VMS and UNIX systems. As
+   there was not a unique standard mapping way, the implementations
+   resulted into a number of possible variant methods to map a Mail-11
+   address into an RFC822 one. Some of these products became then
+   largely widespread, starting to create a number of de facto mapping
+   methods.
+
+   In this small appendix some sort of standardisation of the mapping
+   problem is considered, trying to be compatible with the existing
+   installed software. We must also remind that, in some cases, only
+   simple Mail-11 addresses could be mapped into RFC822, having complex
+   ones producing all sort of quite strange results.
+
+
+
+
+Allocchio                                                      [Page 16]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+   On the other hand, the mapping of an RFC822 address in Mail-11 was
+   quite straightforward, resulting in a common definition which uses
+   "Mail-11 foreign mail protocol" to design an RFC822 address:
+
+      [[node::][node::]...]prot%"rfc-822-address"
+
+   or
+
+      [node::][node::]...]::"rfc-822-address"
+
+A.2 De facto implementations
+
+   A considerable number of de-facto implementations of Mail-11/RFC822
+   gateways is existing. As said in the introduction, the mapping of
+   RFC822 addresses in Mail-11 is accomplished using the foreign mail
+   protocol syntax and is thus unique.
+
+   On the other hand, Mail-11 addresses are encoded in RFC822 syntax in
+   various ways. Here are the most common ones:
+
+        a) "node::user"@gateway-address
+        b) user%node@gateway-address
+        c) user@node.decnet.domains
+        d) user%node.dnet@gateway-address
+
+   Let's have a quick look to these different choices.
+
+   a - This form simply encloses as quoted Left Hand Side string the
+       original Mail-11 address into the RFC822 address of the
+       Mail-11/RFC822 gateway. This method is fully conformant with
+       RFC822 syntax, and the Mail-11 address is left untouched; thus
+       no encoding rules need to applied to it.
+
+   b - As one will immediately notice, this form has nothing in it
+       indicating the address is a Mail-11 one; this makes the encoding
+       indistinguishable from a similar encoding of RSCS (BITnet)
+       addresses used by some IBM VM Mailer systems. It should thus be
+       deprecated.
+
+   c - In this case a sort of 'reserved word' (decnet)  embedded into
+       the address itself identifies the presence of a Mail-11 original
+       address preceding it. The decoding is possible, dropping
+       'domains' and extracting 'user' and 'node' parts. However complex
+       Mail-11 addresses cannot be mapped properly in this syntax, and
+       there is no specific rule for adding the 'domains' part of the
+       address.
+
+
+
+
+
+Allocchio                                                      [Page 17]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+   d - In this case again there is a 'reserved word' (dnet)  which make
+       possible the identification of the original Mail-11 address;
+       'gateway-address' points to the Mail-11/RFC822 gateway and 'node'
+       and 'user' information can be easily drawn from the address.
+       However complex Mail-11 addresses cannot be embedded easily into
+       this syntax.
+
+A.3 Recommended mappings
+
+   From the examples seen in the previous paragraphs we can derive a
+   canonical form for representing the mapping between Mail-11 and
+   RFC822.
+
+A3.1 RFC822 mapped in Mail-11
+
+   The mapping of an RFC822 address in Mail-11 is straightforward, using
+   the "Mail-11 foreign mail protocol" syntax. The two possible variants
+   are:
+
+      [[node::][node::]...]prot%"rfc-822-address"
+
+   or
+
+      [node::][node::]...]::"rfc-822-address"
+
+A3.2 Mail-11 mapped in RFC822
+
+   RFC822 foresee a canonical form for representing non-RFC822
+   addresses: put the foreign address in local part (Left Hand Side,
+   LHS) is a form as similar as possible to its original syntax. Thus
+   the suggested mapping is:
+
+      "Mail-11-address"@gateway-address
+
+   This format assures also the return path via the appropriate gateway.
+
+A.4 Conclusions
+
+   A standard way of mapping Mail-11 addresses into RFC822 and vice
+   versa is feasible. A suggestion is thus made to unify all existing
+   and future implementations. It should be noted, however, that there
+   is no way to specify in these mappings the name of the decnet
+   community owning the encoded address, as it was done for X.400, thus
+   the implementation of the 'intelligent' gateway in this case is
+   impossible.
+
+
+
+
+
+
+Allocchio                                                      [Page 18]
+
+RFC 1405                    Mail-11 Mapping                 January 1993
+
+
+Acknowledgements
+
+   I wish to thank all those people who read the first draft and
+   contributed a lot with their useful suggestions to the revision of
+   this document, in particular RARE WG1 and IETF X.400 ops group
+   members and S. Hardcastle-Kille.
+
+References
+
+   [1]  CCITT, "CCITT Recommendations X.400-X.430", Message Handling
+        Systems: Red Book, October 1984.
+
+   [2]  CCITT, "CCITT Recommendations X.400-X.420", Message Handling
+        Systems: Blue Book, November 1988.
+
+   [3]  Crocker, D., "Standard of the Format of ARPA Internet Text
+        Messages", STD 11, RFC 822, UDel, August 1982.
+
+   [4]  Kille, S., "Mapping Between X.400 and RFC 822", UK Academic
+        Community Report (MG.19) / RFC 987, June 1986.
+
+   [5]  Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
+        822", RFC 1327, March 1992.
+
+   [6]  Digital Equipment Corp.;, "VAX/VMS Mail Utility".
+
+   [7]  Joiner Associates Inc., "Jnet User's Manual".
+
+   [8]  PMDF User's Guide.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   Claudio Allocchio
+   Cosine S2.2
+   Sincrotrone Trieste
+   Area di Ricerca
+   Padriciano 99
+   I 34012 Trieste
+   Italy
+
+   Phone:   +39 40 3758523
+   Fax:     +39 40 226338
+   EMail:  Claudio.Allocchio@elettra.Trieste.it
+           C=it; A=garr; P=Trieste; O=Elettra; S=Allocchio; G=Claudio;
+
+
+
+Allocchio                                                      [Page 19]
+
\ No newline at end of file