Re: multipart/alternative extension

At 13.59 +0200 01-05-04, Harald Tveit Alvestrand wrote:
>given the vehemence of this debate, would there be interest in 
>pursuing an idea of making a more complete multipart/alternative 
>specification (including the RFC 1766 stuff, discussion of various 
>scenarios including our by-now long experience with Outlook's use of 
>the feature) and pushing it onto the standards track as an update to 
>MIME?

Sounds like a good idea. However, I think the type should be given
a new name, for example multipart/choices, because so many existing
mailers treat multipart/alternative so badly that no one will ever
dare using it except in accordance with its original spec in
the first MIME version.

In general, if an existing feature is implemented badly, IETF
prefers to use a new name for the new feature, in order to
avoid clashes with old implementations. Examples of this is
Errors-To:,
Return-Receipt-To:,
Read-Receipt-To:,
X-Confirm-reading-to:,
Return-Receipt-Requested,
Register-Mail-Reply-Requested-By:

or Encoding: specified in RFC 1154 and RFC 1505, which was
replaced by Content-Transfer-Encoding in MIME.

-- 
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Received on Sunday, 6 May 2001 05:35:13 UTC