Network Working Group                                     Jacob Palme
Internet Draft                               Stockholm University/KTH
draft-palme-e-mail-translation-01.txt                          Sweden
Category-to-be: Proposed standard                 Date: November 2000
                                                     Expires: May 2001

                    Support for Language Translation
                        in E-Mail and Netnews

                         Status of this Memo


This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time.  It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Copyright (C) The Internet Society 1999, 2000. All Rights
Reserved.

1.1   Abstract

This memo specifies extensions to e-mail and netnews standards, to
allow for the submission of translation of messages, not only at
initial submission time, but also at later time, and made by other
translators than the original author of the message. three new e-
mail/netnews header fields are proposed, "Content-Translation-Of,
"Content-Translator" and "Translation-Request" and a new content-type
"Multipart/translations" is specified.

This memo does not specify any change to the already existing
proposed standard for the Content-Language header (RFC 1766).


1.2   Mailing list

Further discussion of this memo can take place in the mailing list WG-
I18N@TERENA.NL.

Mailing List Information

To write contributions

  Further discussion on this document should be done through the
  mailing list WG-I18N@TERENA.NL.

  Comments on less important details may also be sent to the editor,
  Jacob Palme <jpalme@dsv.su.se>.

To subscribe

  To subscribe to this mailing list, send a message to
  LISTSERV@TERENA.NL
  which contains the text
  SUB[SCRIBE] WG-I18N <your name (not your email address)>

To unsubscribe

  To unsubscribe from this list, send a message to
  LISTSERV@TERENA.NL
  which contains the text
  UNS[UBSCRIBE] WG-I18N

To access mailing list archives

  The archives are available for browsing from
  http://www.terena.nl/working-groups/wg-i18n/hypermail/

The archives are also available by email. Send a message to
  LISTSERV@TERENA.NL with the text "INDEX WG-I18N" to get a list
  of the archive files, and then a new message "GET <file name>" to
  retrieve archive files.


Table of Contents

      1.1  Abstract                                                    1
      1.2  Mailing list                                                2
2    Language Support in Existing Standards                            3
3    Multi-Language Scenario                                           4
4    The Content-Translation-Of Header Field                           4
5    The Content-Translator Header Field                               5
6    The Multipart/Translations MIME Content Type                      5
7    The Translation-Request Header                                    6
8    Examples                                                          7
      8.1  Separate Original and Translated Messages                   7
      8.2  Sending a Message to a Translator for Translation           8
      8.3  Resending of the Message in 8.2 After Translation           8
9    For Further Study                                                 9
10   Security Considerations                                           10
11   Copyright and Disclaimer                                          10
12   Acknowledgments                                                   11
13   References                                                        11
14   Author's Address                                                  12
Appendix 1: An Investigation of Handling of
Multipart/Alternative in some Common Mailers in November 2000          12



2     Language Support in Existing Standards

The "Content-Language:" e-mail content header specified in RFC 1766 [6]
can be used to specify one or a list of natural languages used in that
message body.

The "Content-Type: Multipart/alternative" defined in MIME [4] might be
used to send the same text in more than one language. Each part would
then be marked with the "Content-Language:" header to indicate its
language, and the recipient might choose the body part according to his
or her language preferences. The combination of Multipart/alternative
with Content-Language is however not commonly supported and gives
disastrous results with most mailers (November 2000), so this solution
is not recommended in this specification.

In HTTP [7], a request operation can indicate a list of preferred
languages, and the server can then deliver the resource in the
preferred language. The request operation can also indicate how good
each language is for a particular user, in the format:

           Accept-Content-Language: da, en-gb;q=0.8, en;q=0.7

HTTP also has facilities for the server to tell the client which
alternatives are available in different languages, letting the client
choose between them. It is also possible, with HTTP, to deliver a
resource in the "Multipart/alternative" format, if the recipient wants
to store the resource in all available language versions. These HTTP
features are however not commonly supported (November 2000).

All of these methods of transmitting information is based on the
assumption that all language versions are ready and available when a
message is sent.


3     Multi-Language Scenario

John Smith writes a message in English and submits it to a mailing list
or to a Usenet newsgroup. The mailing list expander sends this message
to an automatic translation agent which translates it into other
languages and returns the translations to the mailing list expander.
The mailing list expander might then either forward all translations to
each member of the list, or forward to each member only the translation
preferred by this member. Ernst Drrenmatt has requested the mailing
list to send him all language versions, but reads this message in
English, because he has indicated that he prefers English original
documents to automatic German translations. Hilda Schmidt reads the
message in both English and German, decides that the automatic German
translation is not very good, and cleans it up, submitting a new better
translation to German. Ernst Drrenmatt checks this translation, makes
some corrections, and submits a final corrected version of the German
translation of the original message.


4     The Content-Translation-Of Header Field

The "Content-Translation-Of" header field is used when submitting a
translation to a message, which earlier has been sent in another
language. The syntax for this header field is similar to the syntax for
the "In-Reply-To" header, but only one value is allowed, since every
translation can only be the translation of one previous message. The
value contains the Message-ID of the original message before
translation. If a message is available in more than one language,
"Content-Translation-Of" should always reference the original message,
even if the translation was actually based on a translated version. If
the original message is available in more than one version, with
"Supersedes" or "Replaces" references between the versions, then the
"Content-Translation-Of" should reference the version which was the
basis of this translation.

Translation is applied to the body content, and to the content of the
"Subject:" header, but not to any other header contents. When a
"Subject:" is translated, the language code enclosed in parenthesis"
can be added to the beginning of the "Subject".

If more than one translation is available of the same original message,
the "Supersedes" or "Replaces" header field should not be used between
them. "Supersedes" or "Replaces" are only to be used when the original
message is revised.


5     The Content-Translator Header Field

The "Content-Translator" header field indicates who made the
translation. When a translation is submitted, the "From" header field
should still indicate the original author, but the "Content-Translator"
header field can indicate who made the translation.

The syntax of the "Content-Translator" header field is:

Content-Translator           = "Content-Translator:" ( CFWS mailbox-
list / Phrase )
                        *(";" translator-parameter) CFWS CRLF

translator-parameter = art / fluency / future-extension

art                  = "Human" / "Machine" / "Original"

fluency              = "Expert" / "Native" / "Other"

The meaning of these parameters are:

Human    = Translation was made or revised/approved by a human
            translator.

Machine  = Translation was entirely automatic, with no human checking
            of the translation. In this case, the "Auto-Submitted" [8]
            header should also be added to the message heading.

Original = This is the original before translation. Absence of a
            "Content-Translator" also indicates that the message is not
            translated, but "Content-Translator: None; Original" can be
            used to explicitly specify that this is not translated.

Expert   = Translation was made by an expert translator.

Native   = Translation was made by a native speaker of the target
            language.


Other    = Translation was made by someone who is not an expert nor
            a native speaker of the target language.


6     The Multipart/Translations MIME Content Type

It might seem natural to use the Multipart/alternative content type
[5], with different language versions in the different bodies. This
should, however be avoided, because it downgrades disastrously to older
mailers. Instead, a new content-type Multipart/translations is to be
used. This will according to the Mime standard downgrade to
Multipart/mixed, which downgrades much better for older mailers than
Multipart/alternative does.

The Multipart/translations header is to be used when the different body
parts contain the same information translated to different human
languages. Each body part of Multipart/translations must contain a
Content-Language header. Even if the body part itself is a multipart,
such as a Multipart/mixed or Multipart/related. Content-Language is
required both in the embedded multipart heading and in textual body
parts within the embedded multipart.

If translation is desired also of the "Subject" header, then the
translated body parts has to be of content-type Message/rfc822, since
only that content-type allows different subject in different body
parts.

It is recommended to add information about translation at the top of
each body part (example, see section 8.3 below), because some mailers
display multiple body parts in sequence inline with no indication of
the Differences between them. This recommendation may be lifted at some
future time when most mailers have support for Multipart/translations.

It is also recommended to add a blank line at the end of each
translation, since this will show up neater on some old mailers, which
display all body parts in sequence to the recipient.


7     The Translation-Request Header

The Translation-Request header is used when sending a message for
translation to a human or machine translator. Its value is a list of
the languages to which translation is requested. The languages are
specified according to [6]. The language of the original can be
included in the Translation-Request header, this tells the translator
to include the original of the message when it is forwarded after
translation, together with the translations to other languages.

When the Translation-Request header is used, the content-type should
always be "Message/rfc822" [5] and the content should be the message to
be translated. When the translation is ready, the translator is
instructed to send the translation to the recipients in the "To:",
"Cc:" and "Bcc:" headers and to leave non-translated headers of the
message/rfc822 body as they were before the translation. When the
translator resends the translation, Resent-From" is added with the name
of the translator, and "Resent-Date" with the date of the translation.
If translation to multiple languages is requested, the result is sent
using the content-type multipart/translations.

Syntax: "Translation-Request:" CFWS language 1*(, CFWS language)
         CFWS CRLF


8     Examples

8.1   Separate Original and Translated Messages

     Message-ID: A@foo.bar.net
     From: John Smith <jsmit@foo.bar.net>
     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
     Content-Translator: None; Original
     Content-Language: en

     Message-ID: B@foo.bar.net
     From: John Smith <jsmit@foo.bar.net>
     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
     Content-Translation-Of: A
     Content-Translator: Erika Ernst <eernst@foo.bar.de>; human; native
     Content-Language: de

     Message-ID: C@foo.bar.net
     From: John Smith <jsmit@foo.bar.net>
     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
     Content-Translation-Of: A
     Content-Translator: Tomas Drrenmatt <tdurrenmatt@foo.bar.de>;
     expert
     Content-Language: de

     Message-ID: D@foo.bar.net
     From: John Smith <jsmit@foo.bar.net>
     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
     Content-Language: en
     Supersedes: A

     Message-ID: E@foo.bar.net
     From: John Smith <jsmit@foo.bar.net>
     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
     Content-Translation-Of: D
     Content-Translator: Supertrans Translation Engine
     <supertrans@foo.bar>; machine
     Auto-Submitted: Auto-generated
     Content-Language: de
     Supersedes: A


8.2   Sending a Message to a Translator for Translation

     Message-ID: Z@foo.bar.net
     From: John Smith <jsmit@foo.bar.net>
     Translation-Request: en, fr, de
     Content-Type: Message/rfc822

     Message-ID: A@foo.bar.net
     From: John Smith <jsmit@foo.bar.net>
     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
     Content-Translator: None; Original
     Content-Language: en
     Subject: Orchids

     Orchids are beautiful.


8.3   Resending of the Message in 8.2 After Translation

     Resent-From: Supertrans Translation Engine <supertrans@foo.bar>
     Message-ID: Z@foo.bar.net
     From: John Smith <jsmit@foo.bar.net>
     Content-Type: Multipart/translations; boundary="boundary 1"
     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
     Subject: (en) Orchids

     --boundary 1
     Message-ID: Y@foo.bar.net
     From: John Smith <jsmit@foo.bar.net>
     Translation-Request: en, fr, de
     Content-Type: Message/rfc822

     Message-ID: A@foo.bar.net
     From: John Smith <jsmit@foo.bar.net>
     To: Tropical Flowers Mailing List <tropflow@foo.bar.net>
     Content-Translator: None; Original
     Content-Language: en
     Subject: (en) Orchids

     Original English Text
     ---------------------

     Orchids are beautiful.

     --boundary 1
     Content-Type: Message/rfc822

     Message-ID: B@foo.bar.net
     From: John Smith <jsmit@foo.bar.net>
     Content-Translation-Of: A
     Content-Translator: Supertrans Translation
                         Engine <supertrans@foo.bar>; machine
     Content-Language: de
     Subject: (de) Orchideen

     Deutsche bersetzung
     --------------------

     Orchideen sind schn.

     --boundary 1
     Content-Type: Message/rfc822

     Message-ID: C@foo.bar.net
     Content-Translation-Of: A
     Content-Translator: Supertrans Translation Engine
                         <supertrans@foo.bar>; machine
     Content-Language: fr
     Subject: (fr) Orchide

     Traduction franais
     -------------------

     Orchide sont beau.

     --boundary 1--


9     For Further Study

The following is not yet resolved in this draft:

-  How a user can register its language preferences with a mail
    server or a mailing list expander.

-  Whether POP/IMAP should be extended with commands to request
    messages in only a certain language.

-  How to handle translation in Usenet News. One might for example
    have a set of co-ordinated newsgroups, with the same articles in
    different languages. A newsgroup "alt.cultures.multiple" might be
    provided with English in "alt.cultures.multiple.en", German in
    "alt.cultures.multiple.de", etc., with automatic or manual
    translation of the messages between these newsgroups.

-  Handling of signatures and seals.


10    Security Considerations

Translations made by other people than the original author of
a message will of course entail the risk of intentional or
unintentional incorrectness of the translation. But this is a
risk we must accept if we want to have translations, and if
everyone is not fluent in every language.

Some people claim that machine translation technology is so
bad, that it should not be used at all. I do not agree,
machine translation will often give a good understanding of
the intent of the original text even if the translation is not
perfect. And if the recipient has a choice of either not
understanding a message at all, or getting a machine
translation, the recipient may still prefer the automatic
translation. Based on this, the recipient might decide whether
the message is of enough interest to be willing to pay for a
human to make a better translation.

The risk can be reduced, if the receiving user agent clearly
shows that a message is a translator, who made the
translation, and allows the user to check the original text
and compare it with the translation.

A translation will invalidate any digital signatures or seals,
but the translator might add its own signature and seals to
ensure that the translation is not corrupted when sent from
translator to readers. These signatures and seals will not
promise any correspondence with the original text, except the
promise which a translator might give of the correctness of
its translations.


11    Copyright and Disclaimer

The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which
any license under such rights might or might not be available;
neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's procedures
with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims
of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of
such proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat."

The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may
be required to practice this standard. Please address the
information to the IETF Executive Director.

Copyright (C) The Internet Society (2000). All Rights
Reserved.

This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.


12    Acknowledgments

Suggestions during the development of this memo has been given by
Harald Alvestrand, Bill Jansson, Larry Masinter, Keith Moore and Henry
Spencer.

13    References

Ref.    Author, title                                    IETF status
                                                          (July 1996)
-----   ---------------------------------------------    -----------
[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
         STD 10, RFC 821, August 1982.                    Recommended

[2]     D. Crocker: "Standard for the format of ARPA     Standard,
         Internet text messages." STD 11, RFC 822,        Recommended
         August 1982.

[3]     M.R. Horton, R. Adams: "Standard for             Not an
         interchange of USENET messages", RFC 1036,       official
         December 1987.                                   IETF
                                                          standard,
                                                          but in
                                                          reality a de-
                                                          facto
                                                          standard for
                                                          Usenet News

[4]     N. Freed & N. Borenstein: "Multipurpose          Draft
         Internet Mail Extensions (MIME) Part One:        Standard,
         Format of Internet Message Bodies." RFC 2045.    elective
         November 1996.

[5]     N. Freed & N. Borenstein: "Multipurpose          Draft
         Internet Mail Extensions (MIME) Part Two:        Standard,
         Media Types." RFC 2046. November 1996.           elective

[6]     H. Alvestrand: "Tags for the Identification      Proposed
         of Languages", RFC 1766, February 1995.          standard,
                                                          elective

[7]     R. Fielding, J. Gettys, J. Mogul, H. Frystyk,    Draft
         T. Berners-Lee: Hypertext Transfer Protocol -    standard
         - HTTP/1.1, RFC 2616, June 1999.

[8]     J. Palme: The Auto-Submitted, Supersedes and     Work in
         Expires Headers in E-mail and Netnews, draft-    progress
         ietf-mailext-new-fields-14.txt, November
         1998.


14    Author's Address

Jacob Palme                     Phone: +46-8-16 16 67
Stockholm University/KTH        Fax: +46-8-783 08 29
Skeppargatan 73                 E-mail: jpalme@dsv.su.se
S-115 30 Stockholm, Sweden


Appendix 1: An Investigation of Handling of Multipart/Alternative in
some Common Mailers in November 2000

As a basis for possible work on developing standards for language-
translation in e-mail, I tested how some common mailers handled
multipart/alternative with different Content-Language in the body parts
in November 2000.

I used the following test messages:

Test message 1: First part English, second part German

Test message 2: Same as test message 1, but first part German, second
part English

Test message 3: Same as test message 2, but multipart/mixed instead of
multipart/alternative.

Test message 4: Same as test message 3, but with Content-Disposition:
Attachment on all but the first body part.

Test message 5: Multipart/mixed on an outer level, with the first part
a directory of attachments, and the second part a multipart/alternative
with the German and English parts as the two alternatives.

Test message 6: Multipart/alternative with the first part containing
all the translations in one body part, and the second part a
multipart/alternative with one translation in each alternative.

I tested this with the following mailers:
Eudora 5 Macintosh, Pine 4.21 on Unix, Netscape 4.7 Macintosh, Outlook
Express 5 Macintosh, First Class 5.611 Macintosh, KOM 2000 (our own
system), and Hotmail.

Result: None of the mailers seemed to test on the Content-Language
value, and make a selection based on this.

Eudora, Outlook Express, KOM 2000 and Hotmail only showed the first
body part. Netscape only showed the second body part. Pine only showed
the second body part, but provided a user command to see also the first
body part. First Class displayed both body parts in sequence, i.e. i
treated multipart/alternative as identical to multipart/mixed.

The conclusion of this is that if IETF makes a standard, specifying
that different translations of the same message should be sent with
multipart/alternative with different Content-Language on the different
body parts, then most mailers will not show a user the version in the
preferred language of that user.

Since backwards compatibility with existing mailers is very important,
this seems to indicate that an IETF standard for handling of language
translation in e-mail has to use some other format than
multipart/alternative to indicate translations.

I also tested some more complex messages. In test message 4, I used
multipart/mixed with three body parts, the first a list of the rest of
the body parts, which contained the message in different languages.
This format was not ideal either with the existing mailers. Most of
them showed all three body parts in sequence inline (even though all
except the first were marked as Content-Disposition: Attachment) and
some of them without any visible marker between the body parts.

In test message 5, on the top level is a multipart/mixed with two body
parts, the first a list of the body parts, the second a
multipart/alternative with the different language parts. This had the
same problem as all the other multipart/alternative test examples: Many
of the mailers arbitrarily chooses one of the multipart/alternatives
and only shows this, some mailers choose the first alternative, some
the second.

In test message 6, I had on the top level a multipart/alternative where
the first body part was a text/plain with all the language versions in
one text. The second body part was another multipart/alternative with
the different language parts as body parts. A mailer which cannot
discriminate between languages, should for this message only display
body part 1. Only Outlook Express and KOM 2000 did this. Pine, Netscape
and Hotmail arbitrarily showed only one language version.

In test message 7, I tested the format proposed in this ietf-draft, as
shown in section 8.3 above.


Test message 1:
---------------

       Message-ID: <language-test-1@dsv.su.se>
       Date: Wed, 12 Nov 2000 18:12:00 +0100
       From: Jacob Palme <jpalme@dsv.su.se>
       MIME-Version: 1.0
       To: jpalme@dsv.su.se, jptest@dsv.su.se
       Subject: Language test message no. 1 v1
       Content-Type: multipart/alternative; boundary="==boundary-2"

       Text displayed only to non-MIME-compliant mailers

       --==boundary-2
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit
       Content-Language: en

       Message in English.

       --==boundary-2
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit
       Content-Language: de

       Nachricht auf deutsch.
       --==boundary-2--


Test message 2:
---------------

       Message-ID: <language-test-2@dsv.su.se>
       Date: Wed, 12 Nov 2000 18:12:00 +0100
       From: Jacob Palme <jpalme@dsv.su.se>
       MIME-Version: 1.0
       To: jpalme@dsv.su.se, jptest@dsv.su.se
       Subject: Language test message no. 1 v1
       Content-Type: multipart/alternative; boundary="==boundary-2"

       Text displayed only to non-MIME-compliant mailers

       --==boundary-2
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit
       Content-Language: de

       Nachricht auf deutsch.
       --==boundary-2
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit
       Content-Language: en

       Message in English.
       --==boundary-2--


Test message 3:
---------------

       Message-ID: <language-test-3@dsv.su.se>
       Date: Wed, 12 Nov 2000 18:12:00 +0100
       From: Jacob Palme <jpalme@dsv.su.se>
       MIME-Version: 1.0
       To: jpalme@dsv.su.se,jptest@dsv.su.se
       Subject: Language test message no. 3 v1
       Content-Type: multipart/mixed; boundary="==boundary-2"

       Text displayed only to non-MIME-compliant mailers

       --==boundary-2
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit
       Content-Language: de

       Nachricht auf deutsch.
       --==boundary-2
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit
       Content-Language: en

       Message in English.
       --==boundary-2--


Test message 4:
---------------

       Message-ID: <language-test-4@dsv.su.se>
       Date: Wed, 12 Nov 2000 18:12:00 +0100
       From: Jacob Palme <jpalme@dsv.su.se>
       MIME-Version: 1.0
       To: jpalme@dsv.su.se,jptest@dsv.su.se
       Subject: Language test message no. 4 v1
       Content-Type: multipart/mixed; boundary="==boundary-2"

       Text displayed only to non-MIME-compliant mailers

       --==boundary-2
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit

       Attachment 1: Deutsch
       Attachment 2: English

       Nachricht auf deutsch.
       --==boundary-2
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit
       Content-Disposition: Attachment
       Content-Language: de

       Nachricht auf deutsch.
       --==boundary-2
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit
       Content-Disposition: Attachment
       Content-Language: en

       Message in English.
       --==boundary-2--


Test message 5:
---------------

       Message-ID: <language-test-5@dsv.su.se>
       Date: Mon, 13 Nov 2000 12:12:00 +0100
       From: Jacob Palme <jpalme@dsv.su.se>
       MIME-Version: 1.0
       To: jpalme@dsv.su.se,jptest@dsv.su.se
       Subject: Language test message no. 5 v1
       Content-Type: multipart/mixed; boundary="==boundary-2"

       Text displayed only to non-MIME-compliant mailers

       --==boundary-2
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit

       Attachment 1: Deutsch
       Attachment 2: English

       --==boundary-2
       Content-Type: Multipart/alternative; boundary="==boundary-1"

       --==boundary-1
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit
       Content-Language: de

       Nachricht auf deutsch.
       --==boundary-1
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit
       Content-Language: en

       Message in English.
       --==boundary-1--
       --==boundary-2--


Test message 6:
---------------

       Message-ID: <language-test-6@dsv.su.se>
       Date: Wed, 12 Nov 2000 18:12:00 +0100
       From: Jacob Palme <jpalme@dsv.su.se>
       MIME-Version: 1.0
       To: jpalme@dsv.su.se,jptest@dsv.su.se
       Subject: Language test message no. 6 v1
       Content-Type: multipart/alternative; boundary="==boundary-1"

       Text displayed only to non-MIME-compliant mailers

       --==boundary-1
       Content-Type: text/plain; charset=iso-8859-1

       **** This message in English ***

       Message in English.

       **** Diese Nachricht auf deutsch

       Nachricht auf deutsch.
       --==boundary-1
       Content-Type: multipart/alternative; boundary="==boundary-2"

       --==boundary-2
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit
       Content-Language: en

       Message in English.

       --==boundary-2
       Content-Type: text/plain; charset=iso-8859-1
       Content-Transfer-Encoding: 8bit
       Content-Language: de

       Nachricht auf deutsch.
       --==boundary-2--
       --==boundary-1--

Test message 7:
--------------

Same as in section 8.3 above.

Mailer          Test message 1&2        Test message 3
------          -----------------       ---------------

Eudora 5        Only displayed the      Both shown in
Macintosh       first alternative,      sequence, Content-
version         did not even indicate   headers shown, but
                 that there was any      not Content-Language!
                 other alternative.      No indication that
                                         the different
                                         language of the two
                                         body parts.

Pine 4.21 on a  Only the second         Both versions are
Unix platform   alternative is shown    listed in sequence
                 directly, but the       with a divider
                 user can ask to see     indication in-
                 the first alternative   between, no
                 with the VIEW           indication that the
                 command. Nothing is     different language of
                 said to indicate that   the two body parts.
                 the two alternatives
                 contain the same text
                 in two languages.

Netscape 4.7    Only the second         Both versions are
on a Macintosh  alternative is shown,   listed in sequence
                 did not even indicate   with a horizontal
                 that there was any      rule in-between, no
                 other alternative.      indication that the
                                         different language of
                                         the two body parts.

Outlook         Only displayed the      Both shown in
Express 5,      first alternative,      sequence, no divider
Macintosh       did not even indicate   and no indication
edition         that there was any      that the different
                 other alternative.      language of the two
                                         body parts.

First Class     Both versions are       Both versions are
5.611,          listed in sequence      listed in sequence
Macintosh       with no divider in-     with no divider in-
client          between, no             between, no
                 indication that the     indication that the
                 different language of   different language of
                 the two body parts.     the two body parts.

KOM 2000        Only displayed the      Both versions are
                 first alternative,      listed in sequence
                 did not even indicate   with a blank line in-
                 that there was any      between, no
                 other alternative.      indication that the
                                         different language of
                                         the two body parts.

Hotmail         Only displayed the      Both shown in
                 first alternative,      sequence, blank line
                 did not even indicate   in-between.
                 that there was any
                 other alternative.


Mailer          Test message 4          Test message 5
------          ---------------         ---------------

Eudora 5        All three body parts    First and second body
Macintosh       in sequence.            part shown inline.
version

Pine 4.21 on a  First message shown     First message shown
Unix platform   inline, the rest        inline, the rest
                 available by commands   available by commands
                 to retrieve             to retrieve
                 attachments.            attachments.

Netscape 4.7    All three body parts    Only first and third
on a Macintosh  in sequence with a      body part shown in
                 horizontal rule in-     sequence with two
                 between.                horizontal rules in-
                                         between.

Outlook         All three body parts    First and third body
Express 5,      in sequence.            parts in sequence.
Macintosh
edition

First Class     All three body parts
5.611,          listed in sequence.
Macintosh
client

KOM 2000        All three body parts    First and third body
                 in sequence,            part in sequence,
                 horizontal rule in      horizontal rule in
                 between.                between.

Hotmail         All three body parts    First and third body
                 in sequence.            part in sequence.


Mailer          Test message 6          Test message 7
------          ---------------         --------------

Eudora 5        The first and the       All translations
Macintosh       second, but not the     inline in sequence
version         third body part is      with all headers,
                 shown.                  including translation-
                                         headers shown on each
                                         body part.

Pine 4.21 on a  Last body part (the     All translations
Unix platform   German variant) shown   listed as
                 inline, the other       attachments.
                 body parts available
                 as attachments.

Netscape 4.7    Only the last body      All translations
on a Macintosh  part (the German        inline with some
                 variant shown,          headers shown on each
                 nothing indicates to    body parts.
                 the reader that
                 anything more is
                 available.)

Outlook         Only the first body     All translations
Express 5,      part shown, with both   inline with some
Macintosh       language text within    headers shown on each
edition         a single body part!     body parts.

First Class                             All translations
5.611,                                  inline in sequence
Macintosh                               with all headers,
client                                  including translation-
                                         headers shown on each
                                         body part.

KOM 2000        Only the first body     All translations
                 part is shown,          inline with some
                 containing both         headers shown on each
                 language versions in    body parts.
                 one body part.

Hotmail         Only the second body    All translations
                 part is shown, no       inline with some
                 indication that any     headers shown on each
                 more text is            body parts.
                 available.
