idnits 2.17.1 draft-ietf-slim-multilangcontent-04.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 25 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 25, 2016) is 2825 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) == Outdated reference: A later version (-03) exists of draft-gellens-slim-negotiating-human-language-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: January 26, 2017 July 25, 2016 7 Multiple Language Content Type 8 draft-ietf-slim-multilangcontent-04 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 tag and selected 16 by the email client based on a user's language settings. 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 January 26, 2017. 35 Copyright Notice 37 Copyright (c) 2016 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 66 Multipurpose Internet Mail Extensions (MIME) standard, to make it 67 possible to send a single message to a group of people in such a way 68 that all of the recipients can read the email in their preferred 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 defined herein. 73 Whilst this document depends on identification of language in message 74 parts for non-real-time communication, there is a companion document 75 that is concerned with a similar problem for real-time communication: 76 [I-D.gellens-slim-negotiating-human-language] 78 1.1. Requirements Language 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 2. The Content-Type Header Field 86 The "multipart/multilingual" MIME subtype allows the sending of a 87 message in a number of different languages with the translations 88 embedded in the same message. This MIME subtype helps the receiving 89 email client make sense of the message structure. 91 The multipart subtype "multipart/multilingual" has similar semantics 92 to "multipart/alternative" (as discussed in RFC 2046 [RFC2046]) in 93 that each of the message parts is an alternative version of the same 94 information. The primary difference between "multipart/multilingual" 95 and "multipart/alternative" is that when using "multipart/ 96 multilingual", the message part to select for rendering is chosen 97 based on the values of the Content-Language field and optionally the 98 Translation-Type parameter of the Content-Language field instead of 99 the ordering of the parts and the Content-Types. 101 The syntax for this multipart subtype conforms to the common syntax 102 for subtypes of multipart given in section 5.1.1. of RFC 2046 103 [RFC2046]. An example "multipart/multilingual" Content-Type header 104 field would look like this: 106 Content-Type: multipart/multilingual; boundary=01189998819991197253 108 3. The Message Parts 110 A multipart/multilingual message will have a number of message parts: 111 exactly one multilingual preface, one or more language message parts 112 and zero or one language independent message part. The details of 113 these are described below. 115 3.1. The Multilingual Preface 117 In order for the message to be received and displayed in non- 118 conforming email clients, the message SHOULD contain an explanatory 119 message part which MUST NOT be marked with a Content-Language field 120 and MUST be the first of the message parts. For maximum support in 121 the most basic of non-conforming email clients, it SHOULD have a 122 Content-Type of text/plain. Because non-conforming email clients are 123 expected to treat a message with an unknown multipart type as 124 multipart/mixed (in accordance with sections 5.1.3 and 5.1.7 of RFC 125 2046 [RFC2046]) they may show all of the message parts sequentially 126 or as attachments. Including and showing this explanatory part will 127 help the message recipient understand the message structure. 129 This initial message part SHOULD explain briefly to the recipient 130 that the message contains multiple languages and the parts may be 131 rendered sequentially or as attachments. This SHOULD be presented in 132 the same languages that are provided in the subsequent language 133 message parts. 135 As this explanatory section is likely to contain languages using 136 scripts that require non-US-ASCII characters, it is RECOMMENDED that 137 UTF-8 encoding is used for this message part. 139 Whilst this section of the message is useful for backward 140 compatibility, it will normally only be shown when rendered by a non- 141 conforming email client, because conforming email clients SHOULD only 142 show the single language message part identified by the user's 143 preferred language and the language message part's Content-Language. 145 For the correct display of the multilingual preface in a non- 146 conforming email client, the sender MAY use the Content-Disposition 147 field with a value of 'inline' in conformance with RFC 2183 [RFC2183] 148 (which defines the Content-Disposition field). If provided, this 149 SHOULD be placed at the multipart/multilingual level and in the 150 multilingual preface. This makes it clear to a non-conforming email 151 client that the multilingual preface should be displayed immediately 152 to the recipient, followed by any subsequent parts marked as 153 'inline'. 155 For an example of a multilingual preface, see the examples in 156 Section 8. 158 3.2. The Language Message Parts 160 The language message parts are typically translations of the same 161 message content. These message parts SHOULD be ordered so that the 162 first part after the multilingual preface is in the language believed 163 to be the most likely to be recognised by the recipient as this will 164 constitute the default part when language negotiation fails and there 165 is no Language Independent part. All of the language message parts 166 MUST have a Content-Language field and a Content-Type field and MAY 167 have a Translation-Type parameter applied to the Content-Language 168 field. 170 The Content-Type for each individual language message part SHOULD be 171 message/rfc822 to provide good support with non-conforming email 172 clients. However, an implementation MAY use message/global as 173 support for message/global becomes more commonplace. Each language 174 message part SHOULD have a Subject field in the appropriate language 175 for that language part. If there is a From field present, its value 176 MUST include the same email address as the top-level From header 177 although the display name MAY be a localised version. 179 3.3. The Language Independent Message Part 181 If there is language independent content intended for the recipient 182 to see if they have a preferred language other than one of those 183 specified in the language message parts and the default language 184 message part is unlikely to be understood, another part MAY be 185 provided. This could typically be a language independent graphic. 186 When this part is present, it MUST be the last part, MUST have a 187 Content-Language field with a value of "zxx" (as described in BCP 47/ 188 RFC 5646 [RFC5646]) and SHOULD NOT have a Subject field and SHOULD 189 NOT have a From field. The part SHOULD have a Content-Type of 190 message/rfc822 or message/global (to match the language message 191 parts). 193 4. Message Part Selection 195 The logic for selecting the message part to render and present to the 196 recipient is summarised in the next few paragraphs. 198 Firstly, if the email client does not understand multipart/ 199 multilingual then it SHOULD treat the message as if it was multipart/ 200 mixed and render message parts accordingly. 202 If the email client does understand multipart/multilingual then it 203 SHOULD ignore the multilingual preface and select the best match for 204 the user's preferred language from the language message parts 205 available. Also, the user may prefer to see the original message 206 content in their second language over a machine translation in their 207 first language. The Translation-Type parameter of the Content- 208 Language field value can be used for further selection based on this 209 preference. The selection of language part may be implemented in a 210 variety of ways, although the matching schemes detailed in RFC 4647 211 [RFC4647] are RECOMMENDED as a starting point for an implementation. 212 The goal is to render the most appropriate translation for the user. 214 If there is no match for the user's preferred language (or there is 215 no preferred language information available) the email client SHOULD 216 select the language independent part (if one exists) or the first 217 language part (directly after the multilingual preface) if a language 218 independent part does not exist. 220 If there is no translation type preference information available, the 221 values of the Translation-Type parameter may be ignored. 223 Additionally, interactive implementations MAY offer the user a choice 224 from among the available languages. 226 5. The Content-Language Field 228 The Content-Language field in the individual language message parts 229 is used to identify the language in which the message part is 230 written. Based on the value of this field, a conforming email client 231 can determine which message part to display (given the user's 232 language settings). 234 The Content-Language MUST comply with RFC 3282 [RFC3282] (which 235 defines the Content-Language field) and BCP 47/RFC 5646 [RFC5646] 236 (which defines the structure and semantics for the language code 237 values). While RFC 5646 provides a mechanism accommodating 238 increasingly fine-grained distinctions, in the interest of maximum 239 interoperability, each Content-Language value SHOULD be restricted to 240 the largest granularity of language tags; in other words, it is 241 RECOMMENDED to specify only a Primary-subtag and NOT to include 242 subtags (e.g., for region or dialect) unless the languages might be 243 mutually incomprehensible without them. Examples of this field for 244 English, German and an instruction manual in Spanish and French, 245 could look like the following: 247 Content-Language: en 249 Content-Language: de 251 Content-Language: es, fr 253 6. The Translation-Type Parameter 255 The Translation-Type parameter can be applied to the Content-Language 256 field in the individual language message parts and is used to 257 identify the type of translation. Based on the value of this 258 parameter and the user's preferences, a conforming email client can 259 determine which message part to display. 261 This parameter can have one of three possible values: 'original', 262 'human' or 'automated' although other values may be added in the 263 future. A value of 'original' is given in the language message part 264 that is in the original language. A value of 'human' is used when a 265 language message part is translated by a human translator or a human 266 has checked and corrected an automated translation. A value of 267 'automated' is used when a language message part has been translated 268 by an electronic agent without proofreading or subsequent correction. 270 Examples of this parameter include: 272 Content-Language: en; translation-type=original 274 Content-Language: fr; translation-type=human 276 7. The Subject Field in the Language Message parts 278 On receipt of the message, conforming email clients will need to 279 render the subject in the correct language for the recipient. To 280 enable this the Subject field SHOULD be provided in each language 281 message part. The value for this field should be a translation of 282 the email subject. 284 US-ASCII and 'encoded-word' examples of this field include: 286 Subject: A really simple email subject 287 Subject: =?UTF-8?Q?Un_asunto_de_correo_electr=C3=b3nico_ 288 realmente_sencillo?= 290 See RFC 2047 [RFC2047] for the specification of 'encoded-word'. 292 The subject to be presented to the recipient should be selected from 293 the message part identified during the message part selection stage. 294 If no Subject field is found (for example if the language independent 295 part is selected) the top-level Subject header field value should be 296 used. 298 8. Examples 300 8.1. An Example of a Simple Multiple language email message 302 Below is a minimal example of a multiple language email message. It 303 has the multilingual preface and two language message parts. 305 From: Nik 306 To: Nathaniel 307 Subject: Example of a message in Spanish and English 308 Date: Thu, 7 Jul 2016 21:28:00 +0100 309 MIME-Version: 1.0 310 Content-Type: multipart/multilingual; 311 boundary="01189998819991197253" 313 --01189998819991197253 314 Content-Type: text/plain; charset="UTF-8" 315 Content-Disposition: inline 316 Content-Transfer-Encoding: quoted-printable 318 This is a message in multiple languages. It says the 319 same thing in each language. If you can read it in one language, 320 you can ignore the other translations. The other translations may be 321 presented as attachments or grouped together. 323 Este es un mensaje en varios idiomas. Dice lo mismo en 324 cada idioma. Si puede leerlo en un idioma, puede ignorar las otras 325 traducciones. Las otras traducciones pueden presentarse como archivos 326 adjuntos o agrupados. 328 --01189998819991197253 329 Content-Type: message/rfc822 330 Content-Language: en; translation-type=original 331 Content-Disposition: inline 333 Subject: Example of a message in Spanish and English 334 Content-Type: text/plain; charset="US-ASCII" 335 Content-Transfer-Encoding: 7bit 336 MIME-Version: 1.0 338 Hello, this message content is provided in your language. 340 --01189998819991197253 341 Content-Type: message/rfc822 342 Content-Language: es; translation-type=human 343 Content-Disposition: inline 345 Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?= 346 =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?= 347 Content-Type: text/plain; charset="US-ASCII" 348 Content-Transfer-Encoding: 7bit 349 MIME-Version: 1.0 351 Hola, el contenido de este mensaje esta disponible en su idioma. 353 --01189998819991197253-- 355 8.2. An Example of a Multiple language email message with language 356 independent part 358 Below is an example of a multiple language email message that has the 359 multilingual preface followed by two language message parts and then 360 a language independent png image. 362 From: Nik 363 To: Nathaniel 364 Subject: Example of a message in Spanish and English 365 Date: Thu, 7 Jul 2016 21:08:00 +0100 366 MIME-Version: 1.0 367 Content-Type: multipart/multilingual; 368 boundary="01189998819991197253" 370 --01189998819991197253 371 Content-Type: text/plain; charset="UTF-8" 372 Content-Disposition: inline 373 Content-Transfer-Encoding: quoted-printable 375 This is a message in multiple languages. It says the 376 same thing in each language. If you can read it in one language, 377 you can ignore the other translations. The other translations may be 378 presented as attachments or grouped together. 380 Este es un mensaje en varios idiomas. Dice lo mismo en 381 cada idioma. Si puede leerlo en un idioma, puede ignorar las otras 382 traducciones. Las otras traducciones pueden presentarse como archivos 383 adjuntos o agrupados. 385 --01189998819991197253 386 Content-Type: message/rfc822 387 Content-Language: en; translation-type=original 388 Content-Disposition: inline 390 Subject: Example of a message in Spanish and English 391 Content-Type: text/plain; charset="US-ASCII" 392 Content-Transfer-Encoding: 7bit 393 MIME-Version: 1.0 395 Hello, this message content is provided in your language. 397 --01189998819991197253 398 Content-Type: message/rfc822 399 Content-Language: es; translation-type=human 400 Content-Disposition: inline 402 Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?= 403 =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?= 404 Content-Type: text/plain; charset="US-ASCII" 405 Content-Transfer-Encoding: 7bit 406 MIME-Version: 1.0 408 Hola, el contenido de este mensaje esta disponible en su idioma. 410 --01189998819991197253 411 Content-Type: message/rfc822; name="Icon" 412 Content-Language: zxx 413 Content-Disposition: inline 415 Content-Type: multipart/mixed; 416 boundary="99911972530118999881"; charset="US-ASCII" 417 Content-Transfer-Encoding: 7bit 418 MIME-Version: 1.0 420 --99911972530118999881 421 Content-Type: image/png; name="icon.png" 422 Content-Disposition: inline 423 Content-Transfer-Encoding: base64 425 iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZQAA 426 SA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr 427 997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII= 429 --99911972530118999881-- 430 --01189998819991197253-- 431 8.3. An Example of a complex Multiple language email message with 432 language independent part 434 Below is an example of a more complex multiple language email 435 message. It has the multilingual preface and two language message 436 parts and then a language independent png image. The language 437 message parts have multipart/alternative contents and would therefore 438 require further processing to determine the content to display. 440 From: Nik 441 To: Nathaniel 442 Subject: Example of a message in Spanish and English 443 Date: Thu, 7 Jul 2016 20:55:00 +0100 444 MIME-Version: 1.0 445 Content-Type: multipart/multilingual; 446 boundary="01189998819991197253" 448 --01189998819991197253 449 Content-Type: text/plain; charset="UTF-8" 450 Content-Disposition: inline 451 Content-Transfer-Encoding: quoted-printable 453 This is a message in multiple languages. It says the 454 same thing in each language. If you can read it in one language, 455 you can ignore the other translations. The other translations may be 456 presented as attachments or grouped together. 458 Este es un mensaje en varios idiomas. Dice lo mismo en 459 cada idioma. Si puede leerlo en un idioma, puede ignorar las otras 460 traducciones. Las otras traducciones pueden presentarse como archivos 461 adjuntos o agrupados. 463 --01189998819991197253 464 Content-Type: message/rfc822 465 Content-Language: en; translation-type=original 466 Content-Disposition: inline 468 Subject: Example of a message in Spanish and English 469 Content-Type: multipart/alternative; 470 boundary="72530118999911999881"; charset="US-ASCII" 471 Content-Transfer-Encoding: 7bit 472 MIME-Version: 1.0 474 --72530118999911999881 475 Content-Type: text/plain; charset="US-ASCII" 476 Content-Transfer-Encoding: 7bit 478 Hello, this message content is provided in your language. 480 --72530118999911999881 481 Content-Type: text/html; charset="US-ASCII" 482 Content-Transfer-Encoding: 7bit 484 Hello, this message content is provided in your language. 486 --72530118999911999881-- 487 --01189998819991197253 488 Content-Type: message/rfc822 489 Content-Language: es; translation-type=human 490 Content-Disposition: inline 492 Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?= 493 =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?= 494 Content-Type: multipart/alternative; 495 boundary="53011899989991197281"; charset="US-ASCII" 496 Content-Transfer-Encoding: 7bit 497 MIME-Version: 1.0 499 --53011899989991197281 500 Content-Type: text/plain; charset="US-ASCII" 501 Content-Transfer-Encoding: 7bit 503 Hola, el contenido de este mensaje esta disponible en su idioma. 505 --53011899989991197281 506 Content-Type: text/html; charset="US-ASCII" 507 Content-Transfer-Encoding: 7bit 509 Hola, el contenido de este mensaje esta 510 disponible en su idioma. 512 --53011899989991197281-- 513 --01189998819991197253 514 Content-Type: message/rfc822; name="Icon" 515 Content-Language: zxx 516 Content-Disposition: inline 518 Content-Type: multipart/mixed; 519 boundary="99911972530118999881"; charset="US-ASCII" 520 Content-Transfer-Encoding: 7bit 521 MIME-Version: 1.0 523 --99911972530118999881 524 Content-Type: image/png; name="icon.png" 525 Content-Disposition: inline 526 Content-Transfer-Encoding: base64 527 iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZQAA 528 SA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr 529 997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII= 531 --99911972530118999881-- 532 --01189998819991197253-- 534 9. Changes from Previous Versions 536 9.1. Changes from draft-tomkinson-multilangcontent-01 to draft- 537 tomkinson-slim-multilangcontent-00 539 o File name and version number changed to reflect the proposed WG 540 name SLIM (Selection of Language for Internet Media). 542 o Replaced the Subject-Translation field in the language message 543 parts with Subject and provided US-ASCII and non-US-ASCII 544 examples. 546 o Introduced the language-independent message part. 548 o Many wording improvements and clarifications throughout the 549 document. 551 9.2. Changes from draft-tomkinson-slim-multilangcontent-00 to draft- 552 tomkinson-slim-multilangcontent-01 554 o Added Translation-Type in each language message part to identify 555 the source of the translation (original/human/automated). 557 9.3. Changes from draft-tomkinson-slim-multilangcontent-01 to draft- 558 tomkinson-slim-multilangcontent-02 560 o Changed Translation-Type to be a parameter for the Content- 561 Language field rather than a new separate field. 563 o Added a paragraph about using Content-Disposition field to help 564 non-conforming mail clients correctly render the multilingual 565 preface. 567 o Recommended using a Name parameter on the language part Content- 568 Type to help the recipient identify the translations in non- 569 conforming mail clients. 571 o Many wording improvements and clarifications throughout the 572 document. 574 9.4. Changes from draft-tomkinson-slim-multilangcontent-02 to draft- 575 ietf-slim-multilangcontent-00 577 o Name change to reflect the draft being accepted into SLIM as a 578 working group document. 580 o Updated examples to use UTF-8 encoding where required. 582 o Removed references to 'locale' for identifying language 583 preference. 585 o Recommended language matching schemes from RFC 4647 [RFC4647]. 587 o Renamed the unmatched part to language independent part to 588 reinforce its intended purpose. 590 o Added requirement for using Content-Language: zxx in the language 591 independent part. 593 o Many wording improvements and clarifications throughout the 594 document. 596 9.5. Changes from draft-ietf-slim-multilangcontent-00 to draft-ietf- 597 slim-multilangcontent-01 599 o Changed the inner content type to require message/rfc822 or 600 message/global. 602 o Updated the examples to reflect the new inner content types. 604 o Added to the security considerations to highlight the risk from 605 insufficient spam filters. 607 9.6. Changes from draft-ietf-slim-multilangcontent-01 to draft-ietf- 608 slim-multilangcontent-02 610 o Restricted the use of a From field in the language message parts 611 and the language independent part. 613 o Updated the security considerations to highlight the risk of an 614 unmatched sender addresses that could be set in the language 615 message parts. 617 9.7. Changes from draft-ietf-slim-multilangcontent-02 to draft-ietf- 618 slim-multilangcontent-03 620 o Relaxed the restriction on the use of the From field in the 621 language message parts to allow a localised version of the 622 sender's display name. 624 9.8. Changes from draft-ietf-slim-multilangcontent-03 to draft-ietf- 625 slim-multilangcontent-04 627 o Updated the wording of the security considerations section to 628 reflect the relaxation of the use of the From field in the 629 language message parts. 631 10. Acknowledgements 633 The authors are grateful for the helpful input received from many 634 people but would especially like to acknowledge the help of Harald 635 Alvestrand, Stephane Bortzmeyer, Eric Burger, Mark Davis, Doug Ewell, 636 Randall Gellens, Gunnar Hellstrom, Sean Leonard, John Levine, Alexey 637 Melnikov, Addison Phillips, Pete Resnick, Brian Rosen, Fiona 638 Tomkinson, Simon Tyler and Daniel Vargha. 640 The authors would also like to thank Fernando Alvaro and Luis de 641 Pablo for their work on the Spanish translations. 643 11. IANA Considerations 645 The multipart/multilingual MIME type will be registered with IANA. 647 12. Security Considerations 649 Whilst it is intended that each language message part is a direct 650 translation of the original message, this may not always be the case 651 and these parts could contain undesirable content. Therefore there 652 is a possible risk that undesirable text or images could be shown to 653 the recipient if the message is passed through a spam filter that 654 does not check all of the message parts. The risk should be minimal 655 due to the fact that an unknown multipart subtype should be treated 656 as multipart/mixed and so each message part should be subsequently 657 scanned. 659 Because the language message parts have a Content-Type of message/ 660 rfc822 or message/global, they might contain From fields which could 661 have different values to that of the top-level From field and may not 662 reflect the actual sender. The inconsistent From field values might 663 get shown to the recipient in a non-conforming email client and may 664 mislead the recipient into thinking that the email came from someone 665 other than the real sender. 667 13. References 669 13.1. Normative References 671 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 672 Extensions (MIME) Part Two: Media Types", RFC 2046, 673 DOI 10.17487/RFC2046, November 1996, 674 . 676 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 677 Part Three: Message Header Extensions for Non-ASCII Text", 678 RFC 2047, DOI 10.17487/RFC2047, November 1996, 679 . 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, 683 DOI 10.17487/RFC2119, March 1997, 684 . 686 [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating 687 Presentation Information in Internet Messages: The 688 Content-Disposition Header Field", RFC 2183, 689 DOI 10.17487/RFC2183, August 1997, 690 . 692 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 693 DOI 10.17487/RFC3282, May 2002, 694 . 696 [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", 697 BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006, 698 . 700 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 701 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 702 September 2009, . 704 13.2. Informational References 706 [I-D.gellens-slim-negotiating-human-language] 707 Gellens, R., "Negotiating Human Language in Real-Time 708 Communications", draft-gellens-slim-negotiating-human- 709 language-02 (work in progress), July 2015. 711 Authors' Addresses 713 Nik Tomkinson 714 Mimecast Ltd 715 CityPoint, One Ropemaker Street 716 London EC2Y 9AW 717 United Kingdom 719 Email: rfc.nik.tomkinson@gmail.com 721 Nathaniel Borenstein 722 Mimecast Ltd 723 480 Pleasant Street 724 Watertown MA 02472 725 North America 727 Email: nsb@mimecast.com