[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 RFC 1405

     COSINE S2.2                           Claudio Allocchio
     Draft v2.3                            I.N.F.N. - Italy
                                           August 22, 1992
                                           Allocchio@elettra.trieste.it
     
     
        Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)
     
     
     Status of this Memo:
     
              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  cover mainly  the O/R  address  to DECnet  from/to
     address  mapping  (and vice versa);  other mappings  are  based on
     RFC1327 and its updates.
     
     This document  provides an  experimental standard  definition, and
     is expected to be revised after an initial test period.
     
     Distribution is unlimited.
     
     This document is an Internet Draft.  Internet Drafts  are  working
     documents of the Internet Engineering Task Force (IETF), its Areas,
     and its Working Groups. Note that other groups may also distribute
     working documents as Internet Drafts.
     
     Internet Drafts are draft documents  valid for  a  maximum  of six
     months. Internet Drafts  may be  updated, replaced,  or  obsoleted
     by other documents at any  time.   It  is  not appropriate  to use
     Internet Drafts  as reference material or to  cite them other than
     as a "working draft" or "work in progress."
     
     Please  check the I-D abstract  listing contained in each Internet
     Draft directory to learn the current  status  of this or any other
     Internet Draft.
     
     Document Expiration Date
     
     This  document  was  submitted  on  September 23rd, 1992  and  its
     validity will expire on March 23rd 1993.
     
     
     
     
     (c) notice:
     Mail-11,  DECnet, VMSmail,  VAX/VMS, DEC are trademarks of Digital
     Equipment Corporation; Jnet is a trademark of Joiner Inc.
     
     
     
     
     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 among  systems implementing  the DECnet Phase IV
     networking protocols.
     
     
     1.3. RFC 822
     
              RFC 822 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).
     
              The se 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 RFC 822 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 RFC 822 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 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'
     
              - 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.
                       - the new message is delivered separately.
     
              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.
     
     
     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.)
     
     
     some examples:
     
     route           node    local part
     ----------------------------------------------------------
                             USER47
                     MYNODE::BETTY
     BOSTON::CLUS02::GOOFY1::MARY34
                             IN%"M.T.Rose@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"
     
     
     
     
     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. 'area' and 'node' numbers. A possible
     case exists  when we have a common  X.400 and/or RFC 822 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' attribute. Some possible examples are:
     
            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  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 'local part',  we will  define only the
     minimum  set  of  DDAs strictly  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  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)
     
      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 within the x.400 MHS).
     
       C=it; ADMD=garr; DD.Dnet=HEP;
       DD.Mail-11=X4TDEC::MRGATE::(q)C=ab::A=dsa::P=qwerty::OU=mine::S=Clay(q)
         MRGATE::"C=ab::A=dsa::P=qwerty::OU=mine::S=Clay"
     
       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  'f-sep'  are  added completing
     'local part'.  'gwnode'  is  included as 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=Paul; S=Smith;
     
     will be encoded like
     
       X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=ucl/OU=cs/G=Paul/S=Smith"
     
     or its equivalent with the ";" notation
     
       X4TDEC::gw%"C=gb;ADMD=Gold 400;PRMD=AC.UK;O=ucl;OU=cs;G=Paul;S=Smith;"
     
     
     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 information's. 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;
     
       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 RFC 822
     addressing is involved,  and  the following triangular situation
     occurs:
     
               x.400
                /  \
               /    \
              /      \
         Mail-11----RFC822
     
     
              The  X.400 - RFC 822  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 - RFC 822 side.  The most important
     among these de facto  standards  are  discussed  in  Appendix A,
     jointly  with  a Mail-11 - RFC 822  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  'f-address' using  the  Mail-11 foreign mail protocol
     syntax:
     
          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 RFC 822; let's have a short summary.
     
     - Mail-11 address  encoded in  "Left Hand Side" (LHS) of RFC 822
       address, using "%" syntax or "::" syntax;
     
          route::node::localpart
     
       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
       or  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 --> RFC 822 --> Mail-11
     
              We apply the RFC1327 rules to the first step, obtaining
     an  RFC 822  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=Paul; S=Smith;
     
     maps accordingly to RFC1327 to
     
        Paul.Smith@cs.UCL.AC.UK
     
     and finally becomes
     
        SMTPGW::In%"Paul.Smith@cs.UCL.AC.UK"
     
     where 'SMTPGW'  is  the DECnet node  name of the machine running
     the RFC 822 to Mail-11 gateway.
     
     
     6.4.2. Mail-11 --> RFC 822 --> 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 RFC 822 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 RFC 822 gateway.
     
     
     6.4.3. X.400 --> Mail-11 --> RFC 822
     
              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 RFC 822 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  'route'  and  'node' as
     'Received:' elements into RFC 822 message 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=Paul; S=Smith;
     
     will be encoded like
     
      X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Paul/S=Smith"
     
     If the Mail-11 to RFC822 gateway recognise the x400-text-address,
     then the address becomes, accordingly to RFC1327
     
      Paul.Smith@cs.UCL.AC.UK
     
     and the following RFC 822 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=Paul/S=Smith"@X4TDEC.domains
     
     
     6.4.4. RFC 822 --> Mail-11 --> X.400
     
              The  RFC 822  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  'node'  as 'trace'
     elements of the message header.  Otherwise  it applies the rules
     described in 5.2 and 5.5.
     
     an example:
     
        Paul.Smith@cs.UCL.AC.UK
     
     will be encoded like
     
        SMTPGW::In%"Paul.Smith@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=Paul; S=Smith;
     
     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)Paul.Smith(a)cs.UCL.AC.UK(q)
     
     
     6.4.5. RFC 822 --> 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 'local part'.
     
     an example:
     
      Paul.Smith@cs.UCL.AC.UK
     
     maps accordingly to RFC1327 to
     
      C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Paul; S=Smith;
     
     and finally becomes
     
      SMTPGW::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Paul/S=Smith"
     
     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 --> RFC 822
     
              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 - RFC 822 mapping
     
     A.1 Introduction
     
              The  implementation of a  Mail-11 - RFC 822 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
     RFC 822  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
     RFC 822, having complex ones producing all sort of quite strange
     results.
     
              On the other hand, the mapping of an RFC 822 address in
     Mail-11  was   quite  straightforward,  resulting  in  a  common
     definition which  uses "Mail-11 foreign mail protocol" to design
     an RFC 822 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  RFC 822 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  RFC 822
     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  RFC 822 address  of the
     Mail-11 / RFC822  gateway.  This method is fully conformant with
     RFC 822 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.
     
     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  RFC 822  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
     RFC 822 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.
     
     Acknowledgements
     
              I wish  to  thank all those people which 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.
     
     Author's address
     
     Claudio Allocchio           Phone:  +39 40 3758523
     Cosine S2.2                 Fax:    +30 49 226338
     Sincrotrone Trieste         e-mail: allocchio@elettra.trieste.it
     c/o Area di Ricerca
     Padriciano 99
     I 34012 Trieste (TS)
     Italy
     
     References
     
       CCITT, "CCITT Recommendations X.400-X.430," Message Handling
       Systems: Red Book, October 1984
     
       CCITT, "CCITT Recommendations X.400-X.420," Message Handling
       Systems: Blue Book, November 1988
     
       D.H. Crocker, "Standard of the Format of ARPA Internet Text
       Messages," RFC 822, August 1982.
     
       S.E. Kille, "Mapping Between X.400 and RFC 822," UK Academic
       Community Report (MG.19) / RFC 987, June 1986.
     
       S.E. Kille, "Mapping Between X.400(1988) / ISO 10021 and RFC
       822," RFC 1327, March 1992.
     
       Digital Equipment Corp.;, "VAX/VMS Mail Utility"
     
       Joiner Associates Inc., "Jnet User's Manual"
     
       PMDF User's Guide.
     
     
     
     Document Expiration Date
     
     This  document  was  submitted  on  September 23rd, 1992  and  its
     validity will expire on March 23rd 1993.
     

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/