W3C home > Mailing lists > Public > ietf-discuss@w3.org > January 2002

Re: I-D ACTION:draft-palme-e-mail-translation-03.txt

From: <ned.freed@mrochek.com>
Date: Thu, 17 Jan 2002 07:07:33 -0800 (PST)
To: Jacob Palme <jpalme@dsv.su.se>
Cc: discuss@apps.ietf.org, langtrans@salut.nu
Message-id: <01KD64V9GVI4003WI0@mauve.mrochek.com>
> I do not agree. Quoted-printable was not a complete failure,
> and my proposed solution for multi-lingual messages does
> not have the problem which quoted-printable has. Messages
> will be quite readable, with the format I propose, for
> old mail clients. The only disadvantage is that the UA
> will not automatically select the language preferred by
> the user.

Not a complete failure, perhaps, but a partial failure nevertheless. And your
assertion that what you propose is "quite readable" is following the exact same
line of reasoning that led to quoted-printable, which makes me very nervous. 

> All the more reason to define multi-lingual messaging
> in a way which works nicely with existing mailers.
> In that way, multi-lingual messaging can come gradually,
> first some senders implementing the new format, then,
> if this becomes more common, some receiving UA software
> will maybe also handle the new format.

That's a fine goal if you can come up with a proposal that achieves it. I don't
think you have done so thus far. And this is basically my point: I think you're
setting your sights on something that isn't achievable. And that's why you're
flailing around.

Unfortunately, the whole space MIME operates in is filled with compromises,
some of which are quite painful. You need to be prepared to make very painful

> I have suggested two alternative solutions:

> (a) multipart/choices.

As I've said before, I suspect you're going to find that this works even less
well with existing mailers than multipart/alternative.

> (b) multipart/alternative, with an additional first and
>      last body part containing a concatenation of all the
>      translations.

This is the same sort of solution as quoted-printable, and while you may not be
willing to admit it, experience has shown that there's a real downside to this

Please note that I'm not saying that you should avoid this approach. What I'm
saying is that you shouldn't look at quoted-printable as justification
for using this approach. Instead you should look at quoted-printable
and try to learn  what can go wrong from that experience.

> (c) A third alternative, possibly the intention of existing
>      standards, would be just multipart/alternative with one
>      body part in each language. This third alternative will
>      only work if all recipients are using a mailer which
>      supports the new format.

> (d) A fourth alternative, a variant of (a), is to use
>      multipart/mixed.

> If I do get the money, should I then implement (a), (b),
> (c) or (d). I am not very happy with (c), because it
> downgrades so badly with existing mailers. (d) is a
> possibility, but what is its advantages compared to (c).
> Since the MIME standard says that un-known subtypes to
> multipart should be handled as multipart/mixed, (c) has
> advantages but no disadvantages compared to (d).

One other point to consider is that software that supports (b) will support (c)
trivially. As such, it may make sense to try (b) but plan to cut over to (c) if
the need arises.

I strongly recommend that you stay away from (a).

> >(2) Work the problem from the other end. Efforts are under way to develop
> >    and deploy facilities for determining the recipient characteristics and
> >    sending messages that match those characteristics. I don't know if these
> >    efforts are going to be successful, but if they are and language
> >    selection is included in the initial rollout you might get something
> >    deployed, albeit vicariously.

> Maybe. E-mail already has a facility for sending a message
> in different formats to different recipients. This is the
> "Bcc" header.

You're a bit confused here. The bcc field has nothing to do with sending
messages in different formats. The bcc facility in some UAs may end up sending
slightly different messages to different recipients, but that's an effect of
the UA's interpretation of bcc semantics, nothing more.

> But most existing mailers, I believe, does
> not implement this by actually sending different messages
> to different recipients. Instead, they only send a single
> message, with no Bcc content to any of the recipients.
> (Which is allowed by the standards, but still not a full
> implementation of Bcc.)

I haven't done any sort of survey of clients, but I get a lot of bcc's, and
most of them are separate messages with slightly different content.

> Another disadvantage with sending only one language version
> to each recipient is that some recipients may want a
> message in more than one translation. They may, for
> example, want to check if the translation was OK, and, if
> not, maybe want to submit their own translation. Especially
> if the original translation was made by a machine, this
> might be a reasonable need. Of course, a registry system
> could allow such people to register that they want a
> message in more than one language. This will however only
> work if such people have a mailer supporting the combination
> of multipart/alternative with content-language.

Sounds to me like you're now optimizing for the very uncommon case. This is
the sort of thing you really need to avoid.

Received on Thursday, 17 January 2002 10:47:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:08:13 UTC