At 13.47 +0100 00-11-24, Harald Alvestrand wrote:
See RFC 1766. Again, the problem is that it is not implemented; I
was not able to find a single implementation, let alone 2, when
checking if this could go to Draft Standard.
The problem with multipart/alternative is not that it is not
implemented, but that it is implemented partially.
Most mailers understand that they should only display one
of the alternatives in a multipart/alternative. But they
make their choice of which alternative to display, in
unsatisfactory ways. The result is disastrous - the user
is shown a random choice of the alternatives, not the
one in the language the user would have preferred.
Note that it would have been much better if the existing
implementations had downgraded multipart/alternative to
multipart/mixed. Then the users would be given a list of
the translations, and be able to make their own choices.
We have to accept that for a very long time in the future,
many mailers will not correctly handle the combination of
multipart/alternative with Content-Lanugage. This means
that we have to choose a solution which will gracefully
downgrade to existing mailers. And a combination ofh
multipart/alternative with Content-Lanugage downgrades
terribly bad to existing mailers.
However, a new content-type "multipart/translations" will
work much better, because it will, with existing mailers,
downgrade to multipart/mixed, which is a good solution
for mailers which have no support for language-choice.
I suggest that RFC 1766 is revised to use multipart/translations
instead of multipart/alternative. The obvious solution is
not always the best solution! Since there is no existing
implementation to my knowledge, which implements
multipart/alternative combined with Content-Language in
a suitable way, such a change to RFC 1766 would not cause
any interoperability problems with existing mailers,
it would instead give much better interoperability with
existing mailers than the present solution gives.
--
Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/