rfc2162.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

     Message-Id: <[e-mail]>

   The described method, although violating canonical conversion
   principles, assures the maximum functionality to the users, and
   provides consistency in case of multiple conversions for a single
   message.

Chapter 3 - Basic Mappings

   The basic mappings indicated in MIXER and its updates should be fully
   used.

   A special consideration must be used for encoding RFC822 addresses
   containing quotes '"' into Mail-11. In fact Mail-11 addresses cannot
   contain that special character, as it is reserved to delimit "quoted
   strings" themselves, as when using the Mail-11 foreign mail protocol.
   An example:

      "John Poe"@Mixergw.local.ca.us    (RFC822)

   cannot be included in a Mail-11 foreign mail protocol address 'as
   is', due to the quotes in the LHS section. Quotes must thus be
   encoded.  MIXER specifies exactly how to encode quotes and other
   characters when translating RFC822 addresses into X.400. Mail-11
   addresses are not limited to printablestring, as for X.400, but a



Allocchio                     Experimental                      [Page 9]

RFC 2162                        MaXIM-11                    January 1998


   subset of the MIXER encoding can be used for the quotes character,
   and, as a direct consequence, for open and closed round brackets '('
   and ')':

      smtp%"(q)John Poe(q)@Mixergw.local.ca.us"

Chapter 4 - Addressing - Mail-11 / X.400

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 RFC1685 and CCITT F.401, Annex B.

4.3. Mail-11 address components

   Let us start defining the different parts composing a Mail-11
   address. Mail-11 addresses syntax is slightly different between Phase
   IV and DECnet/OSI cases:

   - Phase IV:  we consider a Mail-11 address as composed by 3 parts:

        [route] [node::] local-part

   where 'route' and 'node' are optional and only 'local-part' is
   compulsory.

   - DECnet/OSI: we consider a Mail-11 address as composed by 3 parts:

        [net:] [node-clns::] local-part

   where 'net and 'node-clns' are optional and only 'local-part' is
   compulsory.

   Here comes a formal definition of these elements

     node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT

     route = *(node "::")

     subdomain = *(ALPHA/DIGIT)



Allocchio                     Experimental                     [Page 10]

RFC 2162                        MaXIM-11                    January 1998


     node-clns = *("." subdomain)

     net = *(ALPHA/DIGIT)

     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 x400-text-address both the ";" notation and the
     "/" notation are equivalent and allowed (see examples in different
     sect.)

        Some examples (Phase IV):

           route           node    local-part
           -----------------------------------------------------------
                                   USER47
                           MYNODE::BETTY
           BOSTON::CLUS02::GOOFY1::MARY34
                                   IN%"[e-mail]"
                   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%"[e-mail]"
                   MICKEY::PRFGAT::profs%"NANCY@IBMB"
                                   edu%"[e-mail]"









Allocchio                     Experimental                     [Page 11]

RFC 2162                        MaXIM-11                    January 1998


   Some examples (DECnet/OSI):

      net  node              local-part
      -----------------------------------------------------------
                              USER47
           .IT.MYDOM1.MYNODE::BETTY
      OMNI:.US.GOV.LB.GOOFY1::MARY34
                              IN%"[e-mail]"
      NET1:.SALES.ADM.MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB"
             .FR.LYON.MIAMI2::George.Rosenthal
           .AU.ABXY2W.VS3100::Jnet%"IAB3425@IBAX23L"
                              MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
       INT:.GB.3LABV56.MAINV::IN%"path1!path2!user%dom"
                      GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;"
                              smtp%"[e-mail]"
      OMNI:.DE.TEST.V1.GWY32::GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee"

   Note that also in DECnet/OSI there can be Phase IV like node names,
   the so called "Phase IV compatibility node names", but no 'route'
   term is allowed in front of them. In case the address consists of a
   DECnet/OSI 'net' and/or 'node' specification, plus an old Phase IV
   node address (like the last one in above examples) we consider the
   old Phese IV node name (GX409A) as 'local-part'.

Chapter 5 - Mapping - Mail-11 / X.400

5.1. Mapping scheme

   DECnet phase IV address field is somehow a 'flat land' with some
   obliged routes to reach some hidden areas. Thus a truly hierarchical
   mapping scheme using mapping rules as suitable for RFC822 is not the
   appropriate solution. A fixed set of encoding rules using DDAs
   support is defined in order to define the mapping.

   DECnet/OSI address field is, on the other hand, hyerarchical,
   implementing a real domain style organization, resembling very
   closely the RFC822 domain addresses. However also in DECnet/OSI
   networks the old Phase IV flat addresing schema remains valid,
   expecially for the so called 'Phase IV short aliases'. For this
   reason, and to keep mapping as simple as possible, the same set of
   fixed rules usind DDAs encoding will be used both for Phase IV and
   DECnet/OSI addresses.









Allocchio                     Experimental                     [Page 12]

RFC 2162                        MaXIM-11                    January 1998


   Another important aspect of the problem is the coexistence in DECnet
   phase IV of many disjoint 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. In DECnet/OSI this
   aspect is more canonically approached, introducing the concept of
   'net', a unique name identifying the single internally fully
   interconnected DECnet network sharing the same DECnet/OSI name space.

   To identify uniquely each DECnet Phase IV network we will thus extend
   the concept of DECnet/OSI 'net' also to this case. We define as 'net'
   in Phase IV a unique ASCII string identifying the DECnet network we
   are connected to. If the Phase IV network is already migrating and
   thus interconnected to DECnet/OSI areas, the 'net' identifier already
   used in the DECnet/OSI areas is automatically extended to the whole
   DECnet community.

   If the network still uses Phase IV protocols only, a 'net' identifier
   must be chosen. In this case the 'net' element will identify the
   DECnet community being served, but it could also differ from the
   actual official network name. It is reccommended that the same 'net'
   identifier will be adopted unmodified when the eventual migration to
   DECnet/OSI will take place within that DECnet community.

   Aliases are allowed for the 'net' identifier. Some well known
   identifiers and aliases:

       net = 'OMNI'         the High Energy Physics & Space Physics
                            DECnet network;

   aliases:

       net = 'HEPnet'       alias for 'OMNI'
       net = 'SPAN'         alias for 'OMNI'

   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.











Allocchio                     Experimental                     [Page 13]

RFC 2162                        MaXIM-11                    January 1998


   A registry of 'net' attributes to insure uniqueness of names must be
   established: this registry is the same one created for migration to
   DECnet/OSI. A simple table coupling 'net' and the gateway address is
   also used, in a syntax similar to the 'gate1' and 'gate2' tables used
   in MIXER. An example:

        OMNI#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
        OMNI#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#
        HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
        HEPnet#O$ESRIN1.PRMD$esa.ADMD$Master400.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 the specified gateways, or try them all in
   cyclic order to obtain better performances.

   Note that aliases are established using this gate table, too: simply
   add equivalent entries into the table, like the 'HEPnet' and 'SPAN'
   entries. Aliases, however, must be used only to enable users to use
   commonly used names, but any  gateway implementing this specification
   must generate addresses with official 'net' names, only ('OMNI' for
   the above table).

   The Mail-11 gateways table, however, just constitutes the list of the
   the appropriate MIXER address translation) RFC822 world. Any other
   gateway implementing this specification (and the related ones) should
   use its local name as first choice for the Mail-11 'net' it can
   reach, and use the official Mail-11 gateway table to reach only the
   non connected ones. This list of Mail-11 gateway entries is supposed
   to contain the list of 'net' tags and their aliases; as this list is
   usually small, currently we do not take into account distribution
   mechanisms for this information different from a static table.

   In order to keep the mapping rules very simple, avoiding the need to
   analyse Mail-11 addresses to distinguish the 'route', 'node', and
   Attributes (DDAs) 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






Allocchio                     Experimental                     [Page 14]

RFC 2162                        MaXIM-11                    January 1998


   We thus define the Mail-11 Phase IV 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;

   Meanwhile we define the mapping rule for Mail-11 DECnet/OSI:

        net:node-clns::localpart

      maps into

        C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
        DD.Mail-11=node-clns::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., OMNI, 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' (or 'node-clns') is missing and we are mapping the Mail-11
   originator (From) then 'node' (or 'node-clns') defaults to the DECnet
   node name of the gateway (gwnode);

   if 'node' (or 'node-clns') is missing and we are mapping the Mail-11
   recipient (To, Cc) then 'node' (or 'node-clns') defaults to the
   DECnet node name of the 'From' address.

   if '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.




Allocchio                     Experimental                     [Page 15]

RFC 2162                        MaXIM-11                    January 1998


   The 'node' syntax (DECnet/OSI or Phase IV) depends on the DECnet
   protocol implemented and on the value of a system parameter (usually
   the MAIL$SYSTEM_FLAGS one) on the gateway host.

   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 'OMNI';
     - the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC'
       alias 'X4TDEC' in Phase IV;
     - 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=OMNI; DD.Mail-11=.IT.DM.X4TDEC::USER47;

    MYNODE::BETTY
     C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=MYNODE::BETTY;

    BOSTON::GOOFY1::MARY34
     C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=BOSTON::GOOFY1::MARY34;

    .DE.UNI-BN.PHYS.NODE18::MARY34
     C=it; ADMD=garr; DD.Dnet=OMNI;
     DD.Mail-11=.DE.UNI-BN.PHYS.NODE18::MARY34;

    UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB"
     C=it; ADMD=garr; DD.Dnet=OMNI;
     DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q)

    ENET:.US.CENTRAL.MIAMI2::George.Rosenthal
     C=it; ADMD=garr; DD.Dnet=ENET;
     DD.Mail-11=.US.CENTRAL.MIAMI2::George.Rosenthal;

    MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
     C=it; ADMD=garr; DD.Dnet=OMNI;
     DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q)






Allocchio                     Experimental                     [Page 16]

RFC 2162                        MaXIM-11                    January 1998


    MAINVX::In%"path1!path2!user%dom"
     C=it; ADMD=garr; DD.Dnet=OMNI;
     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

   and for DECnet/OSI addresses

        C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
        DD.Mail-11=node-clns::localpart;

   maps into

        net:node-clns::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;"










Allocchio                     Experimental                     [Page 17]