draft                          HARPOON                          May 92


                                 HARPOON
      Rules for downgrading messages from X.400/88 to X.400/84 when
              MIME content-types are present in the messages

                     Sun Aug 30 23:40:19 MET DST 1992


                         Harald Tveit Alvestrand
                               SINTEF DELAB
                   Harald.T.Alvestrand@delab.sintef.no


                              Jim Romaguera
                              NetConsult AG
                      Romaguera@cosine-mhs.switch.ch


                               Kevin Jordan
                        Control Data Systems, Inc.
                         kej@mercury.udev.cdc.com






    Status of this Memo

         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.

         If consensus is reached in the IETF MIME-MHS Interworking
         Working Group, it will be submitted to the IESG asking that





Alvestrand et al        Expires March 28 1993                 [Page 1]


draft                          HARPOON                          May 92


         it be recommended to the IAB as a Proposed Standard protocol
         specification.

         HARPOON stands for Holistic Approach to Reliable Provision of
         Open Networking, and is used solely to catch the eye of
         readers.

         Please send comments to the MIME-MHS mailing list
         <mime-mhs@surfnet.nl>











































Alvestrand et al        Expires March 28 1993                 [Page 2]


draft                          HARPOON                          May 92


    1.  Introduction

    Interworking between X.400(88) and MIME is achieved by [MAPPING],
    which modifies RFC-1327 [RFC 1327], which specifies the
    interworking between X.400(88) and RFC-822 based mail.

    Interworking between X.400(88) and X.400 (84) is achieved by RFC-
    1328 [RFC 1328]. That document does not describe what to do in the
    case where body parts arrive at the gateway that cannot be
    adequately represented in the X.400(84) system.

    This document describes how RFC-1328 must be modified in order to
    provide adequate support for the scenarios:

    SMTP(MIME) -> X.400(84)

    X.400(84) -> SMTP(MIME)


    2.  Basic approach

    The approach is to imagine that the connection X.400(84) <->
    SMTP(MIME) never happens. This, of course, is an illusion, but can
    be a very useful illusion.

    All mail will therefore go on one of the paths

    X.400(84) -> X.400(88) -> SMTP(MIME)

    SMTP(MIME) -> X.400(88) -> X.400(84)

    when it goes between a MIME user and an X.400(84) user.

    The approach at the interface between X.400(88) and X.400(84) is:


    o    Convert what you can

    o    Encapsulate what you have to

    o    Never drop a message

    3.  Basic fallback format

    For any body part that cannot be used directly in X.400(84), the
    following body part is made:






Alvestrand et al        Expires March 28 1993                 [Page 3]


draft                          HARPOON                          May 92


    -    Tag = 14 (Bilaterally defined)

    -    Content = Octet string

    -    First bytes of content: (in USASCII, with C escape sequences
         used to represent control characters):

         MIME-version: <version>\r\n
         Content-type: <the proper MIME content type>\r\n
         Content-transfer-encoding: <encoding>\r\n
         <Possibly other Content headings here, terminated by\r\n>
         \r\n
         <Here follows the bytes of the content, as per [MAPPING]>


    The preferred encoding is BINARY, because X.400 does not have any
    limitations to what octets it can pass in an Octet String, but
    this RFC does not require use of the BINARY encoding.

    All implementations MUST place the MIME-version: header first in
    the body part. Headers that are placed by [RFC-1327] and [MAPPING]
    into other parts of the message MUST NOT be placed in the MIME
    body part.

    Since all X.400(88) body parts can be represented in MIME by using
    the x400-bp MIME content-type, this conversion will never fail.

    In the reverse direction, any body part that starts with the token
    "MIME-Version:" will be subjected to conversion according to
    [MAPPING] before including the body part into an X.400(88)
    message.


    4.  Implications

    The implications are several:


    -    People with X.400(84) readers who have the ability to save
         Bodypart 14 messages to file will now be able to save MIME
         multimedia messages

    -    People who can use features like the "Mailcaps" file to
         identify what to do about a bodypart 14 can now grab MetaMail
         or MHN and achieve at least some multimedia functionality







Alvestrand et al        Expires March 28 1993                 [Page 4]


draft                          HARPOON                          May 92


    -    People with E-mail systems that drop into BP 14 when an 8-bit
         character comes along can now include the magic tokens by
         hand at the beginning of the message, and get their
         characters received properly by MIME users

    5.  Security considerations

    The security considerations in [MIME] and [MAPPING] (beware of
    trojans that can hit you if your UA automagically starts programs
    for you) are now relevant also for X.400(84) systems.


    6.  Authors' address

    Harald Tveit Alvestrand
    SINTEF DELAB
    N-7034 Trondheim
    NORWAY
    Harald.T.Alvestrand@delab.sintef.no

    Kevin E. Jordan, ARH215
    Control Data Systems, Inc.
    4201 Lexington Avenue N
    Arden Hills, MN  55126
    USA
    Kevin.E.Jordan@mercury.oss.arh.cpg.cdc.com

    James A. Romaguera
    NetConsult AG
    Mettlendwaldweg 20a
    3037 Herrenschwanden
    Switzerland
    Romaguera@cosine-mhs.switch.ch


    7.  References

    [MIME]
         N. Borenstein, N. Freed, MIME: Mechanisms for Specifying and
         Describing the Format of Internet Message Bodies.  Internet-
         Draft, (January, 1992).

    [RFC-1327]
         S.E. Hardcastle-Kille, Mapping between X.400(1988) / ISO
         10021 and RFC-822.







Alvestrand et al        Expires March 28 1993                 [Page 5]


draft                          HARPOON                          May 92


    [RFC-1328]
         S.E. Hardcastle-Kille, X.400 1988 to 1984 downgrading.

    [MAPPING]
         H.T. Alvestrand, R.S. Miles, M.T. Rose, S.J. Thompson,
         Mapping between X.400 and RFC-822 Message Bodies Internet-
         Draft, (June, 1992).













































Alvestrand et al        Expires March 28 1993                 [Page 6]


draft                          HARPOON                          May 92


    Table of Contents


     Status of this Memo ........................................    1
    1 Introduction ..............................................    3
    2 Basic approach ............................................    3
    3 Basic fallback format .....................................    3
    4 Implications ..............................................    4
    5 Security considerations ...................................    5
    6 Authors' address ..........................................    5
    7 References ................................................    5









































Alvestrand et al        Expires March 28 1993                 [Page 7]

------------------------------ End of body part 2