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.

In practice this means that no sensible person will
ever send different language versions using
multipart/alternative. What is the meaning of sending
a message in more than one language, if the recepient
may get the message in a language which the recipient
cannot read.

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.

At 17.16 -0400 01-05-02, Keith Moore wrote:
>It's difficult to
>imagine how to write a user agent that can effectively make choices
>between alternatives based on attributes whose syntax and semantics
>are not yet defined.

Exactly. That is why it was a mistake, that the MIME standard
allowed use of multipart/alternative with other differences
between the alternatives than Content-Type, and without aiding
the receiver (in the original MIME text) to select the right
part to display to the user. That is exactly the kind of
intelligence which standards should not require software to
have.

It might have worked, if the MIME standard from the beginning
had included the "difference" attribute to multipart/alternative,
and had very strongly said that a mailer which cannot handle
the value of the "difference" attribute, should treat the
multipart/alternative as multipart/mixed.

The "difference" attribute should either have been mandatory, or the
standard should say that its absence defaults to "Content-Type".

Addition of a mandatory "difference" parameter will reduce
the intelligence required of the receiving process to
a much more reasonable level.

Now, however, I believe it is too late. It will not be possible
to get mailers to change their implementation to support
a feature (different content-types in different languages)
which no one ever uses (for reasons described above).

Some possible choices today are:

(a) A new kind of Content-Type: multipart/choices.
     (Which in practice is almost the same as using
     multipart/mixed).

(b) Send multi-language messages as multipart/mixed.

(c) Send multi-language messages in HTML format as
     multipart/related. The first page the user sees
     would then show a list of languages, the user
     clicks on the preferred language.

(d) As (c) but all languages in the same HTML document,
     with a language-choice bar at the top which links
     locally within the HTML document.

When we start implementing this, I will have to test
how major existing mailers can handle these alternatives.

We will *not* implement something which is theoretically
right according to the standards, but which will work
diastrously poor for the users receiving messages in
more than one language.
-- 
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Received on Thursday, 3 May 2001 14:11:12 UTC