RFC 1496 (rfc1496) - Page 2 of 5

Rules for downgrading messages from X

RFC 1496                        HARPOON                      August 1993


   It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is NOT
   obsoleted.

   NOTE: A desireable side-effect of HARPOON is that a standardized
   method for the identification and transmission of multimedia and
   binary data (like spreadsheets) between X.400/84 UAs is achieved.

   While this method is not compatible with current proprietary
   approaches, we believe that it requires less invasive changes to
   current UAs than other possible methods.

   This memo updates RFC 1328.  HARPOON is a pure name, and has no
   meaning.  Please send comments to the MIME-MHS mailing list
   [email protected]>.

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

   Of course, for X.400/88 body parts that are already defined in
   X.400/84, no downgrading should be done. In particular, multi-body
   messages should remain multi-body messages, IA5 messages including
   IA5 messages encoded as Extended Body Parts) should remain IA5
   messages, and G3Fax messages should remain G3Fax messages.









Alvestrand, Romaguera & Jordan