Re: Intelligence in standards-based software

At 14.50 -0400 01-05-03, Scott Lawrence wrote:
>To your original point - why shouldn't the MUA provide an indication 
>that alternatives are available, a display of the Content-* values 
>for each alternative, and allow manual override of the selection? 
>Your problem disappears, and so does the problem of dealing with 
>difference attributes that were not anticipated when the program was 
>writtten.

No problem with me. That is good way for a MUA to handle this.
However, none of the mailers I tested works like this. And I
think it will be very difficult to get MUA implementors to
change their implementations in order to better receive
messages in a format which no one sends any message in.

At 16.17 -0400 01-05-03, Keith Moore wrote:
>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.

The normal IETF practice is to specify new features so that they
downgrade gracefully to older mailers.

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

Treating it as multipart/mixed and showing all the body parts
is *much* better than showing only one body part in the wrong
language, and not telling the user that there are other body
parts in other languages.

At 16.17 -0400 01-05-03, Keith Moore wrote:
>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.

That will only work when sender and recipient both use the
same, enhanced software. But when sender and recipient both
use the same software, no standards are needed. Standards are
for cases where the sender and recipient uses different
software.

At 16.17 -0400 01-05-03, Keith Moore wrote:
>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.

That is a solution which will work for recipients who get messages
in languages they cannot read. It would help for me in the case
I describe above. But it will not help when I send answers,
unless I make my own MUA so intelligent that it send, to each
recipient of the answer, its translation to the language of
that user. And that is not a good choice either, many recipients
can understand more than one language, and may for example
prefer to see a message in its original English, rather than
in bad machine-translated French.

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

Multipart/choices (or Multipart/mixed) is much better than
Multipart/alternative when sending a message in more than
one language, or when an agent between the sender and the
recipient translates the message to multiple languages.

--- --- ---

This discussion seems to have changed tack to the issue
of where translation should best be done. Should it be done
by the sender (using multipart with different languages
in different parts, or some other standards construct),
by an agent close to the sender (similar to by the sender),
or by the recipient or an agent close to the recipient.

If translation is to be done by the recipient or by an
agent close to a recipient, multipart/alternative might
be used since the recipient will in this case have some
enhanced MUA which can handle multipart(/alternative.

I want, however, to be able to correspond with people
in France and Spain without having to force the to switch
to a different mailer than they currently use. It is
only in very special circumstances you can force someone
to swith to a new MUA just to be able to communicate
with you. In my case, this is definitely out of the
question.

At 16.16 -0700 01-05-03, <ned.freed@mrochek.com> wrote:
>  > 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.
>
>Exactly. We defined something in a standard that hasn't been implemented by
>user agents to your satisfaction, and now you hope to solve this problem by
>defining something that's essentially the same but labelled differently. I'm
>sorry, but I fail to see any reason why multipart/choices will work out any
>better in this regard. Standards can only do so much.

"Multipart/choices" will work like "Multipart/mixed" in
existing mailers. And giving the recipient all the language
versions is *much* much better than giving the recipient only
one language version, which is the wrong language for this
recipient, and not even telling the recipient that there are
other language versions available.

-- 
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Received on Friday, 4 May 2001 03:14:19 UTC