rfc1405.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,067 行 · 第 1/3 页

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%"[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]"

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