Re: Intelligence in standards-based software

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


Received on Thursday, 3 May 2001 16:18:49 UTC