Multiple Language Content Type
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|Authors||Nik Tomkinson , Dr. Nathaniel S. Borenstein|
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
IETF N. Tomkinson Internet-Draft N. Borenstein Intended status: Standards Track Mimecast Ltd Expires: April 23, 2014 Oct 20, 2013 Multiple Language Content Type draft-tomkinson-multilangcontent-00 Abstract This document defines an addition to the Multipurpose Internet Mail Extensions (MIME) standard to make it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language code and selected by the email client based on a user's language settings or locale. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 23, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Tomkinson & Borenstein Expires April 23, 2014 [Page 1] Internet-Draft Multiple Language Content Type Oct 2013 1. Introduction Since the invention of email and the rapid spread of the internet, more and more people have been able to communicate in more and more countries and in more and more languages. But during this time of technological evolution, email has remained a single language communication tool, whether it is English to English, Spanish to Spanish or Japanese to Japanese. Also during this time, many corporations have established their offices in multi-cultural cities and formed departments and teams that span continents, cultures and languages so the need to communicate efficiently with little margin for miscommunication has grown exponentially. The objective of this document is to define an addition to the widely used Multipurpose Internet Mail Extensions (MIME) standard, to make it possible to send a single message to a group of people in such a way that all of the recipients can read the email in their own first language. The methods of translation of the message content are beyond the scope of this document, but the structure of the email itself is presented herein. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Content-Type Header When there is a requirement to send a message in a number of different languages and the translations are to be embedded in the same message, the multipart subtype "multipart/multilingual" SHOULD be used to help the receiving email client make sense of the message structure. The suggested multipart subtype "multipart/multilingual" has the same semantics as "multipart/alternative" (as discussed in RFC 2046 [RFC2046]) in that each of the body parts is an alternative version of the same information. The primary difference between "multipart/ multilingual" and "multipart/alternative" is that when using "multipart/multilingual", the message part to select for rendering is chosen based on the value of the Content-Language header instead of the ordering of the parts and the Content-Types. The syntax for this multipart subtype conforms to the common syntax Tomkinson & Borenstein Expires April 23, 2014 [Page 2] Internet-Draft Multiple Language Content Type Oct 2013 for subtypes of multipart given in section 5.1.1. of RFC 2046 [RFC2046], therefore, an example "multipart/multilingual" Content- Type header field would look like this: Content-type: multipart/multilingual; boundary=01189998819991197253 3. The Multilingual Preface -- the first message part In order for the message to be received and displayed in non- conforming email clients, the message MUST contain an explanatory message part which MUST-NOT be marked with a Content-Language header but MUST be the first of the message parts. Because non-conforming email clients are expected to treat the message as multipart/mixed (in accordance with sections 5.1.3 and 5.1.7 of RFC 2046 [RFC2046]) they may show all of the message parts sequentially or as attachments. Including and showing this explanatory part will help the message recipient understand the message structure. This initial message part SHOULD explain briefly to the message recipient that the message contains multiple languages and the parts may be rendered sequentially or as attachments. This SHOULD be presented in the same languages that are provided in the subsequent message parts. Whilst this section of the message is useful for backward compatibility, it SHOULD only be shown when rendered by a non- conforming email client because conforming email client SHOULD only show the single message part identified by the user's preferred language (or locale) and the message part's Content-Language. 4. The Subsequent Message Parts The subsequent message parts are translations of the same message content. These body parts MAY be ordered so that the first part after the multilingual preface is in the language believed to be the most likely to be recognised by recipients using software that does not implement multipart/multilingual. The Content-Type for each individual language part MAY be any MIME type (including multipart subtypes such as multipart/alternative). However, it is recommended that the Content-Type of the language parts is kept as simple as possible for interoperability with existing email clients. The language parts are not required to have matching Content-Types or multipart structures. For example, there might be an English part of type "text/html" followed by a Spanish part of type "application/pdf" followed by a Chinese part of type Tomkinson & Borenstein Expires April 23, 2014 [Page 3] Internet-Draft Multiple Language Content Type Oct 2013 "image/jpeg". Whatever the content-type, the contents SHOULD be composed for optimal viewing in the specified language. 5. The Content-Language Header The Content-Language header in the individual multipart message parts is used to identify the language in which the message part is written. Based on the value of this header, a conforming email client can determine which message part to display (given the user's language settings or locale). The Content-Language MUST comply with RFC 3282 [RFC3282] which fully defines how the language is identified. This makes use of ISO 639 [ISO639] coding of languages. An example of this header could look like the following: Content-Language: en 6. The Subject-Translation Header On receipt of the message, conforming email clients will need to select the correct multipart message content and replace the subject that is shown to the message recipient with the translated subject. To enable this the Subject-Translation header SHOULD be provided in each message part that contains a Content-Language header. The value for this header should be a simple translated version of the original email subject. An example of this header may look like this: Subject-Translation: Mensaje de ejemplo para varios idiomas 7. Examples 7.1. An Example of a Simple Multiple language email message Below is an example of a simple multiple language email message formatted using the method detailed in this document. Tomkinson & Borenstein Expires April 23, 2014 [Page 4] Internet-Draft Multiple Language Content Type Oct 2013 From: Nik To: Nathaniel Subject: Simple example multiple language message Content-type: multipart/multilingual; boundary=01189998819991197253 --01189998819991197253 This is a message in two languages: English and Spanish. It says the same thing in each language. If you read it in the first language, you can ignore the other translations. The other translations may be presented as attachments or grouped together. Este es un mensaje en dos idiomas: Ingles y Espanol. Dice lo mismo en cada idioma. Si lo necesita en el primer idioma, puede ignorar el otras traducciones. Las otras traducciones se pueden presentar como archivos adjuntos o agrupados. --01189998819991197253 Content-Language: en Content-Type: text/plain Subject-Translation: Simple example multiple language message Hello, this message content is provided in your language. --01189998819991197253 Content-Language: es Content-Type: text/plain Subject-Translation: Ejemplo simple mensaje en varios idiomas Hola, el contenido de este mensaje esta disponible en su idioma. --01189998819991197253-- 7.2. An Example of a Complex Multiple language email message Below is an example of a more complex multiple language email message formatted using the method detailed in this document. From: Nik To: Nathaniel Subject: Complex example multiple language message Content-type: multipart/multilingual; boundary=01189998819991197253 --01189998819991197253 This is a message in two languages: English and Spanish. It says the same thing in each language. If you read it in the first language, Tomkinson & Borenstein Expires April 23, 2014 [Page 5] Internet-Draft Multiple Language Content Type Oct 2013 you can ignore the other translations. The other translations may be presented as attachments or grouped together. Este es un mensaje en dos idiomas: Ingles y Espanol. Dice lo mismo en cada idioma. Si lo necesita en el primer idioma, puede ignorar el otras traducciones. Las otras traducciones se pueden presentar como archivos adjuntos o agrupados. --01189998819991197253 Content-Language: en Content-Type: multipart/alternative; boundary=multipartaltboundary Subject-Translation: Complex example multiple language message --multipartaltboundary Content-Type: text/plain Hello, this message content is provided in your language. --multipartaltboundary Content-Type: text/html <html><body><p>Hello, this message content is provided in your language.<p></body></html> --multipartaltboundary-- --01189998819991197253 Content-Language: es Content-Type: multipart/mixed; boundary=multipartmixboundary Subject-Translation: Ejemplo complejo mensaje en varios idiomas --multipartmixboundary Content-Type:application/pdf ..PDF file in Spanish here.. --multipartmixboundary Content-Type:image/jpeg ..JPEG image showing Spanish content here.. --multipartmixboundary-- --01189998819991197253-- Tomkinson & Borenstein Expires April 23, 2014 [Page 6] Internet-Draft Multiple Language Content Type Oct 2013 8. Acknowledgements The authors are grateful for the helpful input received from many people but would especially like to acknowledge the help of Harald Alvestrand, Mark Davis, Fiona Tomkinson and Simon Tyler. 9. IANA Considerations The multipart/multilingual MIME type will be registered with IANA. 10. Security Considerations This document has no additional security considerations beyond those that apply to the standards and procedures on which it is built. 11. References 11.1. Normative References [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. 11.2. Informative References [ISO639] International Organization for Standardization, "ISO 639", 1967-2010, <http://www.iso.org/iso/home/standards/ language_codes.htm>. Tomkinson & Borenstein Expires April 23, 2014 [Page 7] Internet-Draft Multiple Language Content Type Oct 2013 Authors' Addresses Nik Tomkinson Mimecast Ltd CityPoint, One Ropemaker Street London, EC2Y 9AW United Kingdom Email: firstname.lastname@example.org Nathaniel Borenstein Mimecast Ltd 480 Pleasant Street Watertown, MA 02472 North America Email: email@example.com Tomkinson & Borenstein Expires April 23, 2014 [Page 8]