idnits 2.17.1 draft-tomkinson-multilangcontent-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Apr 16, 2014) is 3655 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF N. Tomkinson 3 Internet-Draft N. Borenstein 4 Intended status: Standards Track Mimecast Ltd 5 Expires: October 18, 2014 Apr 16, 2014 7 Multiple Language Content Type 8 draft-tomkinson-multilangcontent-01 10 Abstract 12 This document defines an addition to the Multipurpose Internet Mail 13 Extensions (MIME) standard to make it possible to send one message 14 that contains multiple language versions of the same information. 15 The translations would be identified by a language code and selected 16 by the email client based on a user's language settings or locale. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 18, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 Since the invention of email and the rapid spread of the internet, 53 more and more people have been able to communicate in more and more 54 countries and in more and more languages. But during this time of 55 technological evolution, email has remained a single language 56 communication tool, whether it is English to English, Spanish to 57 Spanish or Japanese to Japanese. 59 Also during this time, many corporations have established their 60 offices in multi-cultural cities and formed departments and teams 61 that span continents, cultures and languages so the need to 62 communicate efficiently with little margin for miscommunication has 63 grown exponentially. 65 The objective of this document is to define an addition to the widely 66 used Multipurpose Internet Mail Extensions (MIME) standard, to make 67 it possible to send a single message to a group of people in such a 68 way that all of the recipients can read the email in their own first 69 language. The methods of translation of the message content are 70 beyond the scope of this document, but the structure of the email 71 itself is presented herein. 73 1.1. Requirements Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 2. The Content-Type Header 81 When there is a requirement to send a message in a number of 82 different languages and the translations are to be embedded in the 83 same message, the multipart subtype "multipart/multilingual" SHOULD 84 be used to help the receiving email client make sense of the message 85 structure. 87 The suggested multipart subtype "multipart/multilingual" has the same 88 semantics as "multipart/alternative" (as discussed in RFC 2046 89 [RFC2046]) in that each of the body parts is an alternative version 90 of the same information. The primary difference between "multipart/ 91 multilingual" and "multipart/alternative" is that when using 92 "multipart/multilingual", the message part to select for rendering is 93 chosen based on the value of the Content-Language header instead of 94 the ordering of the parts and the Content-Types. 96 The syntax for this multipart subtype conforms to the common syntax 97 for subtypes of multipart given in section 5.1.1. of RFC 2046 98 [RFC2046], therefore, an example "multipart/multilingual" Content- 99 Type header field would look like this: 101 Content-type: multipart/multilingual; boundary=01189998819991197253 103 3. The Multilingual Preface -- the first message part 105 In order for the message to be received and displayed in non- 106 conforming email clients, the message MUST contain an explanatory 107 message part which MUST-NOT be marked with a Content-Language header 108 but MUST be the first of the message parts. Because non-conforming 109 email clients are expected to treat the message as multipart/mixed 110 (in accordance with sections 5.1.3 and 5.1.7 of RFC 2046 [RFC2046]) 111 they may show all of the message parts sequentially or as 112 attachments. Including and showing this explanatory part will help 113 the message recipient understand the message structure. 115 This initial message part SHOULD explain briefly to the message 116 recipient that the message contains multiple languages and the parts 117 may be rendered sequentially or as attachments. This SHOULD be 118 presented in the same languages that are provided in the subsequent 119 message parts. 121 Whilst this section of the message is useful for backward 122 compatibility, it SHOULD only be shown when rendered by a non- 123 conforming email client because conforming email client SHOULD only 124 show the single message part identified by the user's preferred 125 language (or locale) and the message part's Content-Language. 127 4. The Subsequent Message Parts 129 The subsequent message parts are translations of the same message 130 content. These body parts MAY be ordered so that the first part 131 after the multilingual preface is in the language believed to be the 132 most likely to be recognised by recipients using software that does 133 not implement multipart/multilingual. 135 The Content-Type for each individual language part MAY be any MIME 136 type (including multipart subtypes such as multipart/alternative). 137 However, it is recommended that the Content-Type of the language 138 parts is kept as simple as possible for interoperability with 139 existing email clients. The language parts are not required to have 140 matching Content-Types or multipart structures. For example, there 141 might be an English part of type "text/html" followed by a Spanish 142 part of type "application/pdf" followed by a Chinese part of type 143 "image/jpeg". Whatever the content-type, the contents SHOULD be 144 composed for optimal viewing in the specified language. 146 5. The Content-Language Header 148 The Content-Language header in the individual multipart message parts 149 is used to identify the language in which the message part is 150 written. Based on the value of this header, a conforming email 151 client can determine which message part to display (given the user's 152 language settings or locale). 154 The Content-Language MUST comply with RFC 3282 [RFC3282] (which 155 defines the Content-Language header) and BCP 47/RFC 5646 [RFC5646] 156 (which defines the structure and semantics for the language code 157 values). Examples of this header for English, English as used in the 158 United States and Latin American Spanish, could look like the 159 following: 161 Content-Language: en 163 Content-Language: en-US 165 Content-Language: es-419 167 6. The Subject-Translation Header 169 On receipt of the message, conforming email clients will need to 170 select the correct multipart message content and replace the subject 171 that is shown to the message recipient with the translated subject. 172 To enable this the Subject-Translation header SHOULD be provided in 173 each message part that contains a Content-Language header. 175 The value for this header should be a simple translated version of 176 the original email subject. An example of this header may look like 177 this: 179 Subject-Translation: Mensaje de ejemplo para varios idiomas 181 7. Examples 183 7.1. An Example of a Simple Multiple language email message 185 Below is an example of a simple multiple language email message 186 formatted using the method detailed in this document. 188 From: Nik 189 To: Nathaniel 190 Subject: Simple example multiple language message 191 Content-type: multipart/multilingual; boundary=01189998819991197253 193 --01189998819991197253 195 This is a message in two languages: English and Spanish. It says the 196 same thing in each language. If you read it in the first language, 197 you can ignore the other translations. The other translations may be 198 presented as attachments or grouped together. 200 Este es un mensaje en dos idiomas: Ingles y Espanol. Dice lo mismo en 201 cada idioma. Si lo necesita en el primer idioma, puede ignorar el 202 otras traducciones. Las otras traducciones se pueden presentar como 203 archivos adjuntos o agrupados. 205 --01189998819991197253 206 Content-Language: en 207 Content-Type: text/plain 208 Subject-Translation: Simple example multiple language message 210 Hello, this message content is provided in your language. 212 --01189998819991197253 213 Content-Language: es 214 Content-Type: text/plain 215 Subject-Translation: Ejemplo simple mensaje en varios idiomas 217 Hola, el contenido de este mensaje esta disponible en su idioma. 219 --01189998819991197253-- 221 7.2. An Example of a Complex Multiple language email message 223 Below is an example of a more complex multiple language email message 224 formatted using the method detailed in this document. Note that the 225 language parts have multipart contents and would therefore require 226 further processing to determine the content to display. 228 From: Nik 229 To: Nathaniel 230 Subject: Complex example multiple language message 231 Content-type: multipart/multilingual; boundary=01189998819991197253 233 --01189998819991197253 234 This is a message in two languages: English and Spanish. It says the 235 same thing in each language. If you read it in the first language, 236 you can ignore the other translations. The other translations may be 237 presented as attachments or grouped together. 239 Este es un mensaje en dos idiomas: Ingles y Espanol. Dice lo mismo en 240 cada idioma. Si lo necesita en el primer idioma, puede ignorar el 241 otras traducciones. Las otras traducciones se pueden presentar como 242 archivos adjuntos o agrupados. 244 --01189998819991197253 245 Content-Language: en 246 Content-Type: multipart/alternative; boundary=multipartaltboundary 247 Subject-Translation: Complex example multiple language message 249 --multipartaltboundary 250 Content-Type: text/plain 252 Hello, this message content is provided in your language. 254 --multipartaltboundary 255 Content-Type: text/html 257

Hello, this message content is provided in your 258 language.

260 --multipartaltboundary-- 262 --01189998819991197253 263 Content-Language: es 264 Content-Type: multipart/mixed; boundary=multipartmixboundary 265 Subject-Translation: Ejemplo complejo mensaje en varios idiomas 267 --multipartmixboundary 268 Content-Type:application/pdf 270 ..PDF file in Spanish here.. 272 --multipartmixboundary 273 Content-Type:image/jpeg 275 ..JPEG image showing Spanish content here.. 277 --multipartmixboundary-- 279 --01189998819991197253-- 281 8. Acknowledgements 283 The authors are grateful for the helpful input received from many 284 people but would especially like to acknowledge the help of Harald 285 Alvestrand, Mark Davis, Doug Ewell, Fiona Tomkinson and Simon Tyler. 287 9. IANA Considerations 289 The multipart/multilingual MIME type will be registered with IANA. 291 10. Security Considerations 293 This document has no additional security considerations beyond those 294 that apply to the standards and procedures on which it is built. 296 11. Normative References 298 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 299 Extensions (MIME) Part Two: Media Types", RFC 2046, 300 November 1996. 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, March 1997. 305 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 306 May 2002. 308 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 309 Languages", BCP 47, RFC 5646, September 2009. 311 Authors' Addresses 313 Nik Tomkinson 314 Mimecast Ltd 315 CityPoint, One Ropemaker Street 316 London, EC2Y 9AW 317 United Kingdom 319 Email: rfc.nik.tomkinson@gmail.com 320 Nathaniel Borenstein 321 Mimecast Ltd 322 480 Pleasant Street 323 Watertown, MA 02472 324 North America 326 Email: nsb@mimecast.com