Re: multipart/alternative extension

At 15.12 -0700 01-05-06, <> wrote:
>>None of the systems I tested did better than
>>multipart/mixed. And none of the systems seemed to
>>recognize the "differences" attribute to
>The problem with building something completely new is that there's a very real
>chance that essentially nobody will implement it. So suppose this turns into a
>choice between rapid uptake of an enhancement to alternative in several key
>clients versus new facility that remains unimplemented for the forseeable
>future. What then?

Suppose someone sets up a server which will take an incoming
e-mail and resend it in multiple machine-translated versions.
We hope to be able to get money to develop such a server.
I am just now working on an application for funding of this.

If IETF says that multipart/alternative should be used, such
a server will still not use it, since using multipart/alternative
will cause many recipients to only get one of the translations,
not adapted to their language capabilities. So in this case,
we will implement this as either multipart/mixed or
unstandardized multipart/choices, since MUAs treat
multipart/unknown as multipart/mixed. Other implementors
of such an email translation service will also for the
same reason not choose multipart/alternative.

If the translation servers do not send multiple translations
in the multipart/alternative format, MUA implementors will
have no incentive to implement handling of this format
in the multiple-language case.

If, on the other hand, IETF says that multipart/choices
should be used, we will of course use it. If our and other
similar services become popular, many people will get
messages in multiple languages which their mailers will
treat as multipart/mixed. If many people get such sets
of translations, this may stimulate MUA implementors to
support it better. If not, the users will still at least
be given all the different translations and be able to
select which of them to read.
Jacob Palme <> (Stockholm University and KTH)
for more info see URL:

Received on Monday, 7 May 2001 07:27:08 UTC