W3C home > Mailing lists > Public > ietf-discuss@w3.org > May 2001

Re: multipart/alternative extension

From: Jacob Palme <jpalme@dsv.su.se>
Date: Sun, 6 May 2001 21:26:37 +0200
Message-Id: <p0501041cb71b508aad7d@[130.237.150.141]>
To: discuss@apps.ietf.org
At 09.28 -0700 01-05-06, <ned.freed@mrochek.com> wrote:
>>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.

I did not mean "badly" from the implementors view. However, if
a message is sent in English, German and French, and shown
to a person who cannot read French only in the French version,
then that implementation is obviously bad from the user's
viewpoint.

At 09.28 -0700 01-05-06, <ned.freed@mrochek.com> wrote:
>  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 faster.

Its is not reasonable to expect that a new definition of this
will be rapidly implemented. It is reasonable to expect that
many mailers will for a long time follow the original MIME
specification of multipart/alternative. Note that there are
still many implementations which treat multipart/alternative
as multipart/mixed (which actually happens to be better
than the most common present implementation of
multipart/alternative in the case of multiple languages).

Is there an established base of support for alternative,
which is better than multipart/mixed for multi-language
messages? None of the systems I tested did better than
multipart/mixed. And none of the systems seemed to
recognize the "differences" attribute to
multipart/alternative.

-- 
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 15:27:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 March 2006 20:11:28 GMT