- From: Jacob Palme <jpalme@dsv.su.se>
- Date: Fri, 18 Jan 2002 12:25:07 +0100
- 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: >Jacob, > >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