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
- preamble Justin Ziegler
- Re: preamble John Haxby
- Re: preamble Harald T. Alvestrand