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: Fri, 18 Jan 2002 12:25:07 +0100
Message-Id: <p05100301b86db4dee195@[]>
To: Keith Moore <moore@cs.utk.edu>
Cc: discuss@apps.ietf.org, langtrans@salut.nu
At 13.42 -0500 02-01-17, Keith Moore wrote:
>I think there are two separate problems here that should not be combined:
>1. If you are trying to send out multi-lingual text to today's user agents,
>naturally you need to choose whatever format you think is most compatible
>with the user agents used by the recipients of those messages. 
>2. If we want to standardize a MIME format for sending out multi-lingual
>text, then we would need to pick a format that met the criteria for
>standards-track documents: no known technical omissions, etc.  As a
>practical matter, we would also want reason to believe that at least
>some UA vendors (whether commercial or not) were likely to implement
>that format.
>It's quite reasonable to ask which representation of the messages would
>work best for purpose #1.  That doesn't mean, however, that such a
>representation would meet the quality for standards-track documents
>or that vendors would implement it.

I believe that the first implementations will be a few
vendors who provide *sending* of messages in multiple
languages. For example, SYSTRAN might develop and market a
translation agent, which a company can install, and which
will, at the request of their users, forward a message with
machine translations to different target languages. Or
SYSTRAN might set up such a service on their own servers,
which will receive mail in one language and forward it in
multiple languages.

If the above service becomes successful and much used,
then as a second step one might expect existing vendors
of receiving mailers to be able to select the right
body part dependent on the user's preferences.

Because I expect that senders will implement the new
standard before recipients, it is very important that the
standard works well for receiving mail UAs which do not yet
support the standard.

A good standard should of course support both your choices
#1 and #2. Using multipart/alternative has the advantage,
that in some far future, when all receiving UAs will
support this, one can omit the extra body part at the start
and end of the messages, and thus get the neat solution
which one would prefer in a standard.
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/
Received on Friday, 18 January 2002 06:46:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:01 UTC