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.

While I somewhat agree with your conclusion the reasoning leading up to it is
bogus. This discussion has shwn that by some measures the implementations of
multipart/alternative you're complaining about are correct. They are not
"implemented badly".

What happened was implementors followed the original MIME specification and
then for whatever reason didn't implement on the subsequent extension to
alternative implied by RFC 1766. You cannot blame folks for implementing what
the MIME specification told them to implement; you can only blame them for not
picking up on the additional stuff they needed to do.

Whether or not a new subtype makes sense is dependent why the extension in RFC
1766 wasn't widely implemented. If the reason is that multipart/alternative got
implemented in a particular way before RFC 1766 came out and people didn't want
to revise that, then a new type is the right way to go. But if the reason is
that people simply didn't understand what needed to be done and are willing to
do the right thing once they understand it, then building off of the
established base of support for alternative will get you a lot further a lot

It may also be the case that the reasons for the lack of uptake of
multipart/alternative vary from vendor to vendor, which makes assessing whether
or not a new subtype is a good idea practically impossible to assess.

All in all I'm inclined to go with multipart/choices, but first I'd like to at
least hear from the client implementors on this list about how they think we
should proceed. IMO their opinion is the best direction we're going to get.

> 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.

Again, your premise here has been shown to be false. Reread Pete Resnick's
messages if you don't believe this.

 Examples of this is

> Errors-To:,
> Return-Receipt-To:,
> Read-Receipt-To:,
> X-Confirm-reading-to:,
> Return-Receipt-Requested,
> Register-Mail-Reply-Requested-By:

Sigh. There are plenty of examples of features that were badly implemented in
various protocols, but you haven't hit on any of them here. The problem with
all of these header fields is that the design behind them is fatally flawed.
That makes it impossible to implement any of them "well". And the reason we
standardized on different fields for DSNs and MDNs is that we needed a
fundamentally different underlying design.

And getting back to multipart/alternative, it isn't clear that the underlying
design in RFC 1766 is fundamentally different.

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

Here you've finally hit on one where things were indeed badly implemented. (For
those of you who don't know, some implementations of Encoding: assume units of
bytes and others assume units of lines. The specification clearly says lines,
so there is a problems with how this was implemented.) However, bad
implementations weren't the reason a different field was chosen in MIME.  That
happened after the MIME specification was complete. There were several reasons
why we abandoned Encoding: in MIME, bu the big one was that experience with
this mechanism showed that such counts just weren't reliable.

Anyway, if you want valid examples of features that were abandoned because of
poor handling by various implementations, I suggest you look at RFC 2822. The
obsolete syntax contains many examples of such features.


Received on Sunday, 6 May 2001 12:57:31 UTC