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 . To subscribe To subscribe to this mailing list, send a message to LISTSERV@TERENA.NL which contains the text SUB[SCRIBE] WG-I18N 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 " 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 To: Tropical Flowers Mailing list Language: en Message-ID: B From: John Smith To: Tropical Flowers Mailing list Translation-Of: A Translator: Erika Ernst ; human; native Language: de Message-ID: C From: John Smith To: Tropical Flowers Mailing list Translation-Of: A Translator: Tomas Dürrenmatt ; expert Language: de Message-ID: D From: John Smith To: Tropical Flowers Mailing list Language: en Supersedes: A Message-ID: E From: John Smith To: Tropical Flowers Mailing list Translation-Of: D Translator: Supertrans Super Translation Engine 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