Re: preamble

"Harald T. Alvestrand" <Harald.T.Alvestrand@uninett.no> Wed, 27 April 1994 11:03 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02297; 27 Apr 94 7:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02293; 27 Apr 94 7:03 EDT
Received: from survis.surfnet.nl by CNRI.Reston.VA.US id aa04296; 27 Apr 94 7:03 EDT
Received: from domen.uninett.no by survis.surfnet.nl with SMTP (PP) id <14947-0@survis.surfnet.nl>; Wed, 27 Apr 1994 12:50:12 +0200
Received: from localhost by domen.uninett.no with SMTP (PP) id <29369-0@domen.uninett.no>; Wed, 27 Apr 1994 12:49:50 +0200
To: Justin Ziegler <Justin.Ziegler@inria.fr>
cc: mime-mhs@surfnet.nl
Subject: Re: preamble
In-reply-to: Your message of "Wed, 27 Apr 1994 11:20:50 +0200." <199404270920.AA02859@chandon.inria.fr>
Content-type: Text/plain; charset="ISO-8859-1"
Content-transfer-encoding: 8bit
Date: Wed, 27 Apr 1994 12:49:47 +0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Harald T. Alvestrand" <Harald.T.Alvestrand@uninett.no>
Message-ID: <"survis.sur.961:27.03.94.10.50.22"@surfnet.nl>

On preamble area destination: It is /dev/null.

That should be more clearly identified in RFC 1495.
Note the following section in RFC 1521 (MIME):

   There appears to be room for additional information prior to the
   first encapsulation boundary and following the final boundary.  These
   areas should generally be left blank, and implementations must ignore
   anything that appears before the first boundary or after the last
   one.

      NOTE: These "preamble" and "epilogue" areas are generally not used
      because of the lack of proper typing of these parts and the lack
      of clear semantics for handling these areas at gateways,
      particularly X.400 gateways.  However, rather than leaving the
      preamble area blank, many MIME implementations have found this to
      be a convenient place to insert an explanatory note for recipients
      who read the message with pre-MIME software, since such notes will
      be ignored by MIME-compliant software.

Also destined for /dev/null is the "epilogue" area and (more worrisome)
any extra headers like Content-ID on parts inside a multipart message
that are *not* converted using the "fallback" mechanism.

                          Harald T. Alvestrand