Network Working Group                                     Jacob Palme
Internet Draft                               Stockholm University/KTH
draft-palme-e-mail-translation-00.txt                          Sweden
Category-to-be: Proposed standard                    Date: April 1999
                                                Expires: October 1999


                  Support for Language Translation of E-Mail

                        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 1998. All Rights Reserved.


1.1.1.                            Abstract

This memo proposes 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. Two new e-mail/netnews header
fields are proposed, "Translation-Of" and "Translator".

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

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.   Introduction
2.   Multi-Language Scenario
3.   The Translation-Of Header Field
4.   The Translator Header Field
5.   Examples
6.   Security considerations
7.   Copyright and disclaimer
8.   Acknowledgments
9.   References
10.  Author's address


1.    Introduction

The "Language:" e-mail content header specified in RFC 1766 [5] 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] can be
used to send the same text in more than one language. Each part is
marked with the "Language:" header to indicate its language, and the
recipient can choose the body part according to his or her language
preferences.

In HTTP [6], a GET operation can indicate a list of preferred
languages, and the server can then deliver the resource in the
preferred language. 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.

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.


2.    Multi-Language Scenario

John Smith writes a message in English and submits it to a mailing list
or to a Usenet newsgroup. An automatic translation agent gets this
message and translates it into German. The German translation is
submitted to the same mailing list or newsgroup. Ernst Dürrenmatt 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.


3.    The Translation-Of Header Field

The "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, "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 "Translation-Of" should reference the
version which was the basis of this translation.

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" is only to be used when the original
message is revised. Example:


4.    The Translator Header Field

The "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 "Translator" header field can
indicate who made the translation.

The syntax of the "Translator" header field is:

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

translator-parameter = art / fluency / future-extension

art                  = "Human" / "Machine"

fluency              = "Expert" / "Native"

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" [7]
          header should also be added to the message heading.

Expert  = Translation was made by an expert translator.

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


5.    Examples

Message-ID: A
From: John Smith <jsmit@foo.bar.net>
To: Tropical Flowers Mailing list
Language: en

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

Message-ID: C
From: John Smith <jsmit@foo.bar.net>
To: Tropical Flowers Mailing list
Translation-Of: A
Translator: Tomas Dürrenmatt <tdurrenmatt@foo.bar.de>; expert
Language: de

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

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


6.    Security considerations

Translations made by other people than the original author of
a message will of ourse 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, if the
recipient has a choice of either not understanding a message
at all, or getting a bad 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.


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


8.    Acknowledgments

Suggestions during the development of this memo has been given by Henry
Spencer and Larry Masinter.


9.    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 offi-
        interchange of USENET messages", RFC 1036,       cial IETF
        December 1987.                                   standard,
                                                         but in
                                                         reality a de-
                                                         facto
                                                         standard for
                                                         Usenet News

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

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

[6]     R. Fielding, J. Gettys, J. Mogul, H. Frystyk,    Proposed
        T. Berners-Lee: Hypertext Transfer Protocol -    standard
        - HTTP/1.1, RFC 2068, January 1997.

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


10.   Author's address

Jacob Palme                     Phone: +46-8-16 16 67
Stockholm University/KTH        Fax: +46-8-783 08 29
Electrum 230                    E-mail: jpalme@dsv.su.se
S-164 40 Kista, Sweden

