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

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

From: Jacob Palme <jpalme@dsv.su.se>
Date: Thu, 17 Jan 2002 11:21:38 +0100
Message-Id: <p05100304b86c51a3daaa@[130.237.150.141]>
To: discuss@apps.ietf.org, langtrans@salut.nu
At 08.36 -0800 02-01-16, <ned.freed@mrochek.com> wrote:
>See above -- the comparison isn't as apt as you seem to think, and even if it
>were apt you're basically saying we should repeat something that didn't work
>the first time.

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.

>An additional point. The pent up demand for MIME in the 
>early 90s was enormous.
>A standardized message format for internationalized text and material other
>than text was urgently needed. This more than anything else drove the
>deployment of MIME support, and even then deployment was pretty slow. By
>contrast, the demand for language translation support in email is minimal at
>best. I know it is something you want very badly, but how many other people
>want it? Uptake of other MIME enhancements or extensions that require
>substantial UA changes has been sporadic at best, and seems largely related to
>the perceived needs of the vendors themselves, not a desire for full standards
>compliance.

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.

Using only multipart/alternative combined with
content-language will not co-work nicely with existing
receiving UA software, and thus has much less chance
of ever being used by anyone.

>There are, however, two alternate approaches that immediately come to mind
>that might work better:
>
>(1) Do some coding work yourself. There are plenty of open source UAs in use
>    today and several other UAs provide hooks for extensibility. Have you
>    tried coding honest to goodness alternative language support for these?
>    Doing so and proving the value of such capabilities might help your cause.
>    (Several MIME compliant mail systems were released at the same time the
>    MIME RFCs came out. This helped enormously in getting MIME started.)

I intend to do this if I can get the necessary funding.
I am trying to apply for funding money, have not got
it yet. However, if I do get funding, it would be better
if I implement something which is acceptable to the
standards-making community as a new standard. That is
why I am discussing this issue in this mailing list
at this time - to find out which solution is acceptable.

I have suggested two alternative solutions:

(a) multipart/choices.

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

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

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

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.

-- 
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/
Received on Thursday, 17 January 2002 09:12:02 GMT

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