catch up latest / update

3 files changed, 1499 insertions, 257 deletions

diff --git a/Documentation/en/I-D/draft-ietf-drums-mail-followup-to-00.txt b/Documentation/en/I-D/draft-ietf-drums-mail-followup-to-00.txt
deleted file mode 100644
index a4c5ba46..00000000
--- a/Documentation/en/I-D/draft-ietf-drums-mail-followup-to-00.txt
+++ /dev/null
@@ -1,245 +0,0 @@
-Network Working Group                                       Jacob Palme
-Internet Draft                                 Stockholm University/KTH
-draft-ietf-drums-mail-followup-to-00.txt
-Expires: May 1998                                         November 1997
-
-
-The ''Mail-Followup-To'' header
-
-
-
-Status of this Document
-
-
-This document is an Internet-Draft. 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.''
-
-To learn the current status of any Internet-Draft, please check the
-``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
-Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-ftp.isi.edu (US West Coast).
-
-NOTE: This document is a proposal for text to be incorporated in the
-new message format standard or published as a separate RFC. It is
-written as input for discussions in the drums working group and does
-not yet reflect any consensus within that group.
-
-
-Abstract
-
-This proposal contains a proposed new e-mail header ''Mail-Followup-To'',
-which is intended to be used instead of the ''Reply-To'' header for
-suggesting where replies to the group who participates in a discussion
-should be sent.
-
-Temporary note
-
-This proposal does not represent any consensus opinion in the drums
-working group at this time (21 November 1997).
-
-
-Table of Contents
-
-1. Introduction
-2. The "Mail-Followup-To" Header
-   2.1 Syntax
-   2.2 Sender action
-   2.3 Mailing list action
-   2.4 Mail Client Action
-   2.5 Usenet News Client Action
-   2.6 A note about the "From:" header
-   2.7 Security Considerations
-3. The "Message-ID" Header
-   3.1 Relation of changes "Message-ID" and other headers and body
-   3.2 Security Considerations
-4. Copyright
-5. Acknowledgments
-6. References
-7. Contact Information
-   7.1 Author's Addresses
-   7.2 Working Group Chairman
-   7.3 Applications Area Director(s):
-   7.4 Area Advisor
-   7.5 Mailing lists:
-
-
-
-
-1.    Introduction
-
-The "Reply-To" e-mail header is known to be problematic because it is
-used for different purposes by different mailers and when the mailer
-inserting this header and the mailer using the header interpret it in
-different ways, unexpected results can happen. For example, a message
-intended for the author of a previous message only may by mistake be
-sent to a mailing list. One way to reduce this problem is to define a
-new header "Mail-Followup-To" which replaces "Reply-To" in recommending
-recipients for replies destined for the group of people discussing an
-issue.
-
-
-2.    The "Mail-Followup-To" Header
-
-2.1   Syntax
-
-"Mail-Followup-To"    =    "Mail-Followup-To" mailbox-list CRLF
-
-
-2.2   Sender action
-
-The "Mail-Followup-To" header can be inserted by the sender of a
-message to indicate suggestions on where replies, intended for the
-group of people who are discussing the issue of the previous message,
-are to be sent. Here are some ways of constructing this header:
-
-1. Merge the recipients in the "From:", "To:" and "Cc:" headers in
-   order to suggest that replies are to be sent to all except "Bcc:"
-   recipients of the previous message. Note that omitting any
-   "Mail-Followup-To:" header is not the same thing, it does not
-   give the protection described in point 4. below.
-
-2. When a message is sent to a mailing list, and the author is a member
-   of this list, and wants to get only one copy of replies, the author
-   can be omitted from the "Mail-Followup-To" header.
-
-3. When a message is sent to several mailing lists, but the author
-   suggests that further discussion should take place only in one of
-   them, the names of the other lists can be omitted from the header.
-   This is similar to the usage of the "Followup-To" header in Usenet
-   News.
-
-4. When a message is sent to a mailing list, which contains sublists,
-   there is a risk that the sublists will insert "Reply-To" or
-   "Mail-Follow-Up-To" headers referring to the sublist. If this
-   happens, replies might be sent to the sublist, and thus not
-   reaching the full set of readers of the primary mailing list.
-   Use of the "Mail-Followup-To" can be used by the author or the
-   primary mailing list to stop sublists inserting "Mail-Followup-To"
-   in the header.
-
-2.3   Mailing list action
-
-A mailing list expander may insert the "Mail-Followup-To" header, with
-a reference to the list, if there is no previous "Mail-Followup-To" in
-the message. A mailing list expander SHOULD NOT change an existing
-"Mail-Followup-To" header, since this may reduce the set of recipients
-suggested in the original message.
-
-If a message has a "Followup-To" header, indicating a suggestion for
-further discussion in a newsgroup, a mailing list expander SHOULD NOT
-insert "Mail-Followup-To" except to refer to a mailing list which is
-gatewayed to the newsgroup in the "Followup-To" header. A message
-should not contain both a "Followup-To" referring to a newsgroup and a
-"Mail-Followup-To" referring to a mailing list which is gatewayed to
-and from that newsgroup, so if such a "Mail-Followup-To" is inserted,
-the "Followup-To" SHOULD be removed.
-
-2.4   Mail Client Action
-
-The "Mail-Followup-To" contains a suggestion to the recipient of where
-to send group replies, but the recipient SHOULD be free to choose other
-recipients of a reply. If a mail client contains a command intended to
-write a reply to all recipients of a message, the value of the
-"Mail-Followup-To" SHOULD be used instead of the merge of the "From:",
-"To:" and "Cc:" fields in construction a default suggested set of
-recipients for such a reply.
-
-2.5   Usenet News Client Action
-
-If a message has a "Mail-Followup-To" header, and no "Followup-To"
-header, this is an indication that further discussion should take place
-only in e-mail, not in Usenet News, and thus a Usenet News client
-SHOULD NOT automatically assemble a proposed set of recipients which
-includes any Usenet News newsgroup. Instead, the "Mail-Followup-To"
-header should be used also by the Usenet News client in suggesting a
-default set of reply recipients to its users.
-
-2.6   A note about the "From:" header
-
-Whenever the text above specifies the "From:" header, its value SHOULD
-be replaced by the value of a "Reply-To" header, if there is such a
-header.
-
-2.7   Security Considerations
-
-There are no particular security risks with the "Mail-Followup-To" if
-implemented correctly. Instead, they will reduce the security risk of
-having personal messages inadvertently sent to more recipients than
-intended.
-
-
-3.    Copyright
-
-Copyright (C) The Internet Society (date). 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.
-
-This document and the information contained herein is provided on an
-"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
-NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
-NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
-FITNESS FOR A PARTICULAR PURPOSE.
-
-
-4.    Acknowledgments
-
-Chris Newman and several other people have helped me with preparing
-this document. I alone take responsibility for any errors which may
-still be in the document.
-
-
-5.    References
-
-Not ready
-
-6.    Contact Information
-
-6.1   Author's Addresses
-
-Jacob Palme                          Phone: +46-8-16 16 67
-Stockholm University and KTH         Fax: +46-8-783 08 29
-Electrum 230                         Email: jpalme@dsv.su.se
-S-164 40 Kista, Sweden
-
-6.2   Working Group Chairman
-
-Chris Newman <chris.newman@innosoft.com>
-
-6.3    Applications Area Director(s):
-
-Keith Moore  <moore+iesg@cs.utk.edu>
-Harald Alvestrand  <Harald.T.Alvestrand@uninett.no>
-
-6.4    Area Advisor
-
-Harald Alvestrand  <Harald.T.Alvestrand@uninett.no>
-
-6.5    Mailing lists:
-
-General Discussion:drums@cs.utk.edu
-To Subscribe:      drums-request@cs.utk.edu
-Archive:           ftp://cs.utk.edu/pub/drums/mail-archive/
-
diff --git a/Documentation/en/I-D/draft-ietf-drums-mail-followup-to-01.txt b/Documentation/en/I-D/draft-ietf-drums-mail-followup-to-01.txt
new file mode 100644
index 00000000..2cc38fc0
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-drums-mail-followup-to-01.txt
@@ -0,0 +1,19 @@
+

+This Internet-Draft has been deleted. Unrevised documents placed in the

+Internet-Drafts directories have a maximum life of six months. After

+that time, they are deleted. This Internet-Draft was not published as

+an RFC.

+

+Internet-Drafts are not an archival document series, and expired

+drafts, such as this one, are not available; please do not ask for

+copies... they are not available. The Secretariat does not have

+information as to future plans of the authors or working groups WRT the

+deleted Internet-Draft.

+

+For more information or a copy of the document, contact the author directly.

+

+Draft Author(s):

+

+J. Palme: jpalme@dsv.su.se                                                        

+

+

diff --git a/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt b/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt
index fa4ee0c2..71075584 100644
--- a/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt
+++ b/Documentation/en/I-D/draft-palme-e-mail-translation-03.txt
@@ -1,19 +1,1487 @@
+Network Working Group                          Jacob Palme
+Internet Draft                                   Stockholm
+draft-palme-e-mail-translation-03.txt       University/KTH
+                                                     Sweden
+Category-to-be: Proposed standard      Date: December 2001
+                                         Expires: June 2001
 
-This Internet-Draft has been deleted. Unrevised documents placed in the
-Internet-Drafts directories have a maximum life of six months. After
-that time, they are deleted. This Internet-Draft was not published as
-an RFC.
 
-Internet-Drafts are not an archival document series, and expired
-drafts, such as this one, are not available; please do not ask for
-copies... they are not available. The Secretariat does not have
-information as to future plans of the authors or working groups WRT the
-deleted Internet-Draft.
 
-For more information or a copy of the document, contact the author directly.
+                   Support for Language Translation
+                        in E-Mail and Netnews
 
-Draft Author(s):
+                         Status of this Memo
 
-J. Palme: jpalme@dsv.su.se                                                        
 
+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 2001, 2002. All
+Rights Reserved.
+
+
+1.1  Abstract
+
+This memo specifies extensions to e-mail and netnews
+standards, to allow for the submission of translations 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".
+
+
+1.2  Mailing list
+
+To write
+
+  Further discussion of this memo can take place in the
+mailing list
+  LANGTRANS@SU.SE.
+
+  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@SU.SE
+  which contains the text
+  SUB[SCRIBE] LANGTRANS <your name (not your email address)>
+
+To unsubscribe
+
+  To unsubscribe from this list, send a message to
+  LISTSERV@SU.SE
+  which contains the text
+  UNS[UBSCRIBE] LANGTRANS
+
+To access mailing list archives
+
+  The archives are available for browsing from
+  http://salut.nu/forum/uno/6/1/
+  Use the browsing command "All messages" to get everything
+written on a
+  single web page.
+
+
+Table of Contents
+     1.1 Abstract
+     1.2 Mailing list
+   Table of Contents
+2   Language Support in Existing Standards
+3   Multi-Language Scenario
+4   The Content-Translation-Of Header Field
+5   The Content-Translator Header Field
+6   USE of The Multipart/Choices MIME Content Type
+7   The Translation-Request Header
+8   Examples
+     8.1 Separate Original and Translated Messages
+     8.2 Sending a Message to a Translator for
+     Translation
+     8.3 Resending of the Message in 8.2 After
+     Translation
+9   For Further Study
+10  Security Considerations
+11  Copyright and Disclaimer
+12  Acknowledgments
+13  References
+14  Author's Address
+Appendix B: An Investigation of Handling of
+Multipart/Alternative in some Common Mailers in
+November 2000
+
+
+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, 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 D’rrenmatt 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
+D’rrenmatt 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 or of a body part containing the original text
+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". Example:
+
+Subject: (en) This is the English version
+
+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 should
+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 or
+            by an expert in the topic of the message, such as a
+            medical expert for a message on a medical topic.
+
+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    Use of The Multipart/Choices MIME Content Type
+
+When several translations of the same message are sent in
+the same message, the content-type multipart/choices, as
+defined in [9]. An alternative is to use
+mulitpart/alternative in the way described in Appendix A.4
+below.
+
+If translation is desired also of the "Subject" header,
+then the translated body parts have 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/choices.
+
+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/choices.
+
+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 D’rrenmatt
+     <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: Z-en@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@supertrans.bar.net
+     From: John Smith <jsmit@foo.bar.net>
+     Content-Type: Multipart/choices; boundary="boundary 1"
+     To: Tropical Flowers Mailing List
+     <tropflow@foo.bar.net>
+     Subject: (en) Orchids
+
+     --boundary 1
+     Message-ID: Z-@foo.bar.net
+     From: John Smith <jsmit@foo.bar.net>
+     Translation-Request: en, fr, de
+     Content-Type: Message/rfc822
+
+     Message-ID: Z-en@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: Z-de@supertrans.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 sch÷n.
+
+     --boundary 1
+     Content-Type: Message/rfc822
+
+     Message-ID: Z-fr@supertrans.bar.net
+     Content-Translation-Of: A
+     Content-Translator: Supertrans Translation Engine
+                         <supertrans@foo.bar>; machine
+     Content-Language: fr
+     Subject: (fr) Orchid‰e
+
+     Traduction fran‡ais
+     -------------------
+
+     Orchid‰e 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. However, 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
+----   -------------------------------------    --------
+
+[1]    J. Klensin: "Simple Mail Transfer        Proposed
+        Protocol", RFC 2821, April 2001.         Standard
+
+[2]    P. Resnick: "Internet Message Format"    Proposed
+        STD 11, RFC 2822, April 2001.            Standard
+
+[3]    M.R. Horton, R. Adams: "Standard for     Not an
+        interchange of USENET messages", RFC     official
+        1036, December 1987.                     IETF
+                                                 standard,
+                                                 but in
+                                                 reality a
+                                                 de-facto
+                                                 standard
+                                                 for Usenet
+                                                 News
+
+[4]    N. Freed & N. Borenstein:                Draft
+        "Multipurpose Internet Mail              Standard,
+        Extensions (MIME) Part One: Format of    elective
+        Internet Message Bodies." RFC 2045.
+        November 1996.
+
+[5]    N. Freed & N. Borenstein:                Draft
+        "Multipurpose Internet Mail              Standard,
+        Extensions (MIME) Part Two: Media        elective
+        Types." RFC 2046. November 1996.
+
+[6]    H. Alvestrand: "Tags for the             Proposed
+        Identification of Languages", RFC        standard,
+        1766, February 1995.                     elective
+
+[7]    R. Fielding, J. Gettys, J. Mogul, H.     Draft
+        Frystyk, T. Berners-Lee: Hypertext       standard
+        Transfer Protocol -- HTTP/1.1, RFC
+        2616, June 1999.
+
+[8]    J. Palme: The Auto-Submitted,            Work in
+        Supersedes and Expires Headers in        progress
+        E-mail and Netnews, draft-ietf-
+        mailext-new-fields-14.txt, November
+        1998.
+
+[9]    J. Palme: The multipart/choices          Work in
+        Content-Type. draft-palme-multipart-     progress
+        choices-00.txt, December 2000.
+
+[10]   R. Troost, S. Dorner, K. Moore:          Proposed
+        Communicating Presentation               standard
+        Information in Internet Messages: the
+        Content-Disposition Header field, RFC
+        2183, August 1997.
+
+
+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 A: A Discussion of Alternative Ways of Handling
+Translation in E-Mail
+
+
+A.1 Use Multipart/alternative
+
+The most natural solution might be to send a message in
+multiple languages as a multipart/alternative, with each
+body part in a different language.
+
+However, this solution downgrades disastrously bad with
+many existing mail clients, as is shown in Appendix B. Most
+existing mail clients will either show only the first or
+only the last body part in such a multipart/alternative.
+Thus, users will not have the option of getting the message
+in their preferred language, they will instead get the
+message in a language which they might not understand.
+
+
+A.2 Use Multipart/mixed
+
+Another solution would be to use multipart/mixed, and with
+a Content-Disposition file-name containing the language.
+Most mailers will then show the message as a list of
+attachments, listing their file names. The recipients can
+then click on the name of the attachment which contains
+their preferred languages.
+
+The disadvantage with this solution is that it does not
+support future mailers which really do support multiple
+languages and can select the language part according to the
+user's preferences.
+
+
+A.3 Use multipart/choices
+
+A third solution would be to use a new Content-Type
+"multipart/choices". Since the MIME standard says that a
+mailer should handle "multipart/xxx" where "xxx" is an
+unkown subtype, as multipart/mixed. So this solution has
+all the advantages but not the disadvantage of using
+multipart/mixed. If multipart/choices becomes a standard,
+mailers of the future can support it better than
+multipart/mixed.
+
+
+A.4 Use multipart/alternative with additional first
+     and last body part.
+
+A fourth solution would be to send the message as a
+multipart/alternative with the following contents:
+
+First body part: A plain text version of all the
+translations after each other.
+
+Last body part: A HTML version with all the translations
+after each other, and with a list of languages at the top.
+The user seeing this part can just click on one of the
+languages to get this message in that language.
+
+All the other body parts, between the first and the last,
+contains the text in each of the available languages.
+
+The advantage with this is that it will downgrade well with
+existing mailers, they will show either the first or the
+last part, which both contains the text in all the
+languages.
+
+At the same time, a mailer which understands the combinaton
+of multipart/alternative with Content-Language can let the
+user select a language or automatically select language
+based on user preferences.
+
+A third advantage is that no new subtype to Multipart have
+to be defined.
+
+The disadvantage is that the message will be longer, each
+translation is repeated three times, in the first body
+part, in one of the middle body part and in the last body
+part.
+
+
+Appendix B: An Investigation of Handling of
+Multipart/Alternative in some Common Mailers in November
+2000 and November 2001
+
+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. The
+tests on the Windows Explorer 5.0 were done in November
+2001.
+
+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 8 uses a first body part with all language
+versions in plain text, a last body part with all language
+versions in HTML, and in-between separate body parts for
+each translation. This seems to work very well with
+existing mailers.
+
+
+Test message 1:
+---------------
+
+      Message-ID: <language-test-1@dsv.su.se>
+      Date: Wed, 21 Nov 2001 09:55: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, 21 Nov 2001 09:55: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. 2
+      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, 21 Nov 2001 09:55: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
+      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, 21 Nov 2001 09:55: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
+      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 4b:
+---------------
+
+      Message-ID: <language-test-4@dsv.su.se>
+      Date: Wed, 21 Nov 2001 09:55: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
+      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: en
+
+      Message in English.
+      --==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--
+
+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, 21 Nov 2001 09:55: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.
+
+Test message 8:
+--------------
+
+     From: Jacob Palme <jpalme@dsv.su.se>
+     Content-Type: Multipart/alternative; boundary="boundary
+     1"
+     To: Tropical Flowers Mailing List
+     <tropflow@foo.bar.net>
+     Subject: Test message 8
+
+     --boundary 1
+
+     Message-ID: Z-en@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
+
+     --boundary 1
+     Content-Type: text/plain; charset=iso-8859-1
+     Content-Language: en, de, fr
+
+     This message will be shown in English, German and
+     French
+
+     **** This message in English ***
+
+     Orchids are beautiful.
+
+     **** Traduction fran‡ais ***
+
+     Orchids sind sch÷n.
+
+     *** This message in French ***
+
+     Orchid‰e sont beau.
+     --boundary 1
+     Content-Type: text/plain
+     Content-Language: fr
+
+     Orchid‰e sont beau.
+     --boundary 1
+     Content-Type: text/plain
+     Content-Language: en
+
+     Orchids are beautiful.
+
+     --boundary 1
+     Content-Type: text/plain
+     Content-Language: de
+
+     Orchids sind sch÷n.
+
+     --boundary 1
+     Content-Type: text/html
+     Content-Language: en, fr, de
+
+     <p>This message will be shown in <a
+     href="#en">English</a>,
+     <a href="#de">German</a>   and <a
+     href="#fr">French</a></p>
+     <p><a name="en"></a>**** This message in English ***
+     </p>
+     <p> Orchids are beautiful.
+     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
+     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
+     <p> <a name="fr"></a>**** Traduction fran&ccedil;ais
+     ***
+     <p> Orchid&eacute;e sont beau.
+     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
+     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
+     p> <a name="de"></a>*** Deutsche &Uuml;bersetzung: ***
+     <p> Orchids sind sch&ouml;n.
+     --boundary 1--
+
+Test message 8:
+--------------
+
+     From: Jacob Palme <jpalme@dsv.su.se>
+     Content-Type: Multipart/alternative; boundary="boundary
+     1"
+     To: Tropical Flowers Mailing List
+     <tropflow@foo.bar.net>
+     Subject: Test message 8
+
+     --boundary 1
+
+     Message-ID: Z-en@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
+
+     --boundary 1
+     Content-Type: text/plain; charset=iso-8859-1
+     Content-Language: en, de, fr
+
+     This message will be shown in English, German and
+     French
+
+     **** This message in English ***
+
+     Orchids are beautiful.
+
+     **** Traduction fran‡ais ***
+
+     Orchid‰e sont beau.
+
+     *** Deutsche ’bersetzung: ***
+
+     Orchids sind sch÷n.
+
+     --boundary 1
+     Content-Type: message/rfc822
+     Subject: Traduction fran‡ais
+     Content-Language: fr
+
+     Content-Type: text/plain
+     Content-Language: fr
+
+     Orchid‰e sont beau.
+     --boundary 1
+     Content-Type: message/rfc822
+     Subject: This message in English
+     Content-Language: en
+
+     Content-Type: text/plain
+     Content-Language: en
+
+     Orchids are beautiful.
+
+     --boundary 1
+     Content-Type: message/rfc822
+     Subject: Deutsche =?iso-8859-1?Q?=FCbersetzung=3A?=
+     Content-Transfer-Encoding: 8bit
+     Content-Language: de
+
+     Content-Type: text/plain
+     Content-Language: de
+
+     Orchids sind sch÷n.
+
+     --boundary 1
+     Content-Type: text/html
+     Content-Language: en, fr, de
+
+     <p>This message will be shown in <a
+     href="#en">English</a>,
+     <a href="#de">German</a>   and <a
+     href="#fr">French</a></p>
+     <p><a name="en"></a>**** This message in English ***
+     </p>
+     <p> Orchids are beautiful.
+     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
+     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
+     <p> <a name="fr"></a>**** Traduction fran&ccedil;ais
+     ***
+     <p> Orchid&eacute;e sont beau.
+     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
+     <p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;<p>&nbsp;
+     p> <a name="de"></a>*** Deutsche &Uuml;bersetzung: ***
+     <p> Orchids sind sch&ouml;n.
+     --boundary 1--
+
+
+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        headers shown, but
+              indicate that       not Content-
+              there was any       Language! No
+              other alternative.  indication that
+                                  the different
+                                  language of the
+                                  two body parts.
+
+Pine 4.21 on Only the second     Both versions are
+a Unix       alternative is      listed in sequence
+platform     shown directly,     with a divider
+              but the user can    indication in-
+              ask to see the      between, no
+              first alternative   indication that
+              with the VIEW       the different
+              command. Nothing    language of the
+              is said to          two body parts.
+              indicate that the
+              two alternatives
+              contain the same
+              text in two
+              languages.
+
+Netscape 4.7 Only the second     Both versions are
+on a         alternative is      listed in sequence
+Macintosh    shown, did not      with a horizontal
+              even indicate that  rule in-between,
+              there was any       no indication that
+              other alternative.  the different
+                                  language of the
+                                  two body parts.
+
+Outlook      Only displayed the  Both shown in
+Express 5,   first alternative,  sequence, on the
+Macintosh    did not even        Macintosh no
+and Windows  indicate that       divider and no
+98 edition   there was any       indication that
+              other alternative.  the different
+                                  language of the
+                                  two body parts, in
+                                  Windows a
+                                  horizontal divider
+                                  line between the
+                                  two 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     indication that
+              the different       the different
+              language of the     language of the
+              two body parts.     two body parts.
+
+KOM 2000     Only displayed the  Both versions are
+              first alternative,  listed in sequence
+              did not even        with a blank line
+              indicate that       in-between, no
+              there was any       indication that
+              other alternative.  the different
+                                  language of the
+                                  two body parts.
+
+Hotmail      Only displayed the  Both shown in
+              first alternative,  sequence, blank
+              did not even        line in-between.
+              indicate that
+              there was any
+              other alternative.
+
+
+Mailer       Test message 4      Test message 5
+------       ---------------     ---------------
+
+Eudora 5     All three body      First and second
+Macintosh    parts in sequence.  body part shown
+version                          inline.
+
+Pine 4.21 on First message       First message
+a Unix       shown inline, the   shown inline, the
+platform     rest available by   rest available by
+              commands to         commands to
+              retrieve            retrieve
+              attachments.        attachments.
+
+Netscape 4.7 All three body      Only first and
+on a         parts in sequence   third body part
+Macintosh    with a horizontal   shown in sequence
+              rule in-between.    with two
+                                  horizontal rules
+                                  in-between.
+
+Outlook      All three body      First and third
+Express 5,   parts in sequence   body parts in
+Macintosh    on the Macintosh.   sequence.
+and Windows  In Windows, only
+edition      first and third
+              body part shown in
+              sequence.
+              Reordering the
+              second and third
+              body parts with
+              the German version
+              last gave the same
+              result: first and
+              third (German)
+              part shown only.
+
+First Class  All three body
+5.611,       parts listed in
+Macintosh    sequence.
+client
+
+KOM 2000     All three body      First and third
+              parts in sequence,  body part in
+              horizontal rule in  sequence,
+              between.            horizontal rule in
+                                  between.
+
+Hotmail      All three body      First and third
+              parts in sequence.  body part in
+                                  sequence.
+
+
+Mailer       Test message 6      Test message 7
+------       --------------      --------------
+
+Eudora 5     The first and the   All translations
+Macintosh    second, but not     inline in sequence
+version      the third body      with all headers,
+              part is shown.      including
+                                  translation-
+                                  headers shown on
+                                  each body part.
+
+Pine 4.21 on Last body part      All translations
+a Unix       (the German         listed as
+platform     variant) shown      attachments.
+              inline, the other
+              body parts
+              available as
+              attachments.
+
+Netscape 4.7 Only the last body  All translations
+on a         part (the German    inline with some
+Macintosh    variant shown,      headers shown on
+              nothing indicates   each body parts.
+              to the reader that
+              anything more is
+              available.)
+
+Outlook      Only the first      All translations
+Express 5,   body part shown,    inline with some
+Macintosh    with both language  headers shown on
+and Windows  text within a       each body parts on
+version      single body part    the Macintosh. On
+              on the Macintosh!   Windows,
+              In Windows, only
+              the second body
+              part is shown.
+
+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      All translations
+              body part is        inline with some
+              shown, containing   headers shown on
+              both language       each body parts.
+              versions in one
+              body part.
+
+Hotmail      Only the second     All translations
+              body part is        inline with some
+              shown, no           headers shown on
+              indication that     each body parts.
+              any more text is
+              available.
+
+Mailer       Test message 8
+------       --------------
+
+Eudora 5     Only last part
+Macintosh    shown, user has to
+version      manually scroll
+              down to his
+              preferred
+              language, clicking
+              on the languages
+              in the first line
+              does not work.
+
+              Note: User can use
+              the Eudora-command
+              "Open in Browser"
+              and then clicking
+              on the language
+              links will work!
+
+Pine 4.40 on Last body part
+a Unix       shown in-line with
+platform     simulated clicking
+              to view each
+              language. The
+              other body parts
+              shown as
+              attachments.
+
+Netscape 4.7 Last body part
+on Windows   shown, clicking on
+98           links will get the
+              readers to the
+              language they
+              prefer.
+
+Outlook      Last body part
+Express 5,   shown, clicking on
+Macintosh    links will get the
+and Windows  readers to the
+version      language they
+              prefer.
+
+First Class  Only the first
+5.611,       body part is
+Macintosh    shown.
+client
+
+KOM 2000     Last body part
+              only shown,
+              clicking on links
+              to select language
+              works.
+
+Hotmail      Last body part
+              only shown,
+              clicking on links
+              to select language
+              works.