- From: Keith Moore <moore@cs.utk.edu>
- Date: Thu, 03 May 2001 16:17:55 -0400
- To: Jacob Palme <jpalme@dsv.su.se>
- cc: discuss@apps.ietf.org
> At 17.16 -0400 01-05-02, Keith Moore wrote: > > > I am beginning to understand that there is a need for > >> a new golden rule: > >> > >> (n) Do not specify standards which require any kind > >> of intelligence of the software using it. > > > >If that were a rule, very few of our protocols would pass muster. > > > >I think you are grossly overexaggerating the problems with multipart/ > >alternative. As far as I can tell, the biggest problem with > >multipart/alternative is that the set of attributes on which a > >choice between alternatives might be based is extensible - it includes > >not only content-type and its parameters, but also content-language, > >and perhaps other attributes not yet invented. > > The problem is that if I send a message in the format > "multipart/alternative" with different languages in the > different body parts, then most major mailers will > only show the recipient one of the body parts, not > selected based on the language preferences of the > recipient, and will not even tell the recipient that > there are other body parts. right. but this is a problem inherent in any new feature - you can hardly expect existing user agents to do something reasonable with a construct that has never been tried before. defining a new content-type doesn't help this problem much, if at all - either the recipient's mailer *still* refuses to show the text, or the mailer treats as multipart/mixed and displays all of the parts (which can be quite annoying). neither is satisfactory. > I regularly get e-mail in French, which I cannot read, and > I use http://www.systransoft.com/ to get them translated > to English. That is rather cumbersome for me. That is > why I want to develop software such that I will automatically > get the message in the languages I can read. And such software > cannot use multipart/alternative, the way it works today > in major mailers. there's nothing stopping new software from using multipart/alternative to distinguish between text in different languages and display the text in the user's preferred language. your complaint appears to be that old software will not do this. nor is there anything stopping you from writing a filter that will recognize French mail and translate it to English. you don't need multipart/choices to do this. Even if you wanted this filter to act at message presentation time rather than at say delivery time, having multipart/choices wouldn't help you create a hook for converting French mail to English. Keith
Received on Thursday, 3 May 2001 16:18:49 UTC