idnits 2.17.1 draft-ietf-slim-multilangcontent-09.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. 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 (July 24, 2017) is 2466 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (-24) exists of draft-ietf-slim-negotiating-human-language-10 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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 25, 2018 July 24, 2017 7 Multiple Language Content Type 8 draft-ietf-slim-multilangcontent-09 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 25, 2018. 35 Copyright Notice 37 Copyright (c) 2017 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 significantly. 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.ietf-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 field instead of the ordering of the parts and the 99 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 field. 169 The Content-Type for each individual language message part SHOULD be 170 message/rfc822 to provide good support with non-conforming email 171 clients. However, an implementation MAY use message/global as 172 support for message/global becomes more commonplace. See RFC 6532 173 [RFC6532] for details of message/global. Each language message part 174 SHOULD have a Subject field in the appropriate language for that 175 language part. If there is a From field present, its value MUST 176 include the same email address as the top-level From header although 177 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 include a language independent 186 graphic. When this part is present, it MUST be the last part and 187 MUST have a Content-Language field with a value of "zxx" (as 188 described in BCP 47/RFC 5646 [RFC5646]). The part SHOULD have a 189 Content-Type of message/rfc822 or message/global (to match the 190 language message parts). 192 4. Message Part Selection 194 The logic for selecting the message part to render and present to the 195 recipient is summarised in the next few paragraphs. 197 Firstly, if the email client does not understand multipart/ 198 multilingual then it should treat the message as if it was multipart/ 199 mixed and render message parts accordingly. 201 If the email client does understand multipart/multilingual then it 202 SHOULD ignore the multilingual preface and select the best match for 203 the user's preferred language from the language message parts 204 available. Also, the user may prefer to see the original message 205 content in their second language over a machine translation in their 206 first language. The Translation-Type field value can be used for 207 further selection based on this preference. The selection of 208 language part may be implemented in a variety of ways, although the 209 matching schemes detailed in RFC 4647 [RFC4647] are RECOMMENDED as a 210 starting point for an implementation. The goal is to render the most 211 appropriate translation for the user. 213 If there is no match for the user's preferred language (or there is 214 no preferred language information available) the email client SHOULD 215 select the language independent part (if one exists) or the first 216 language part (directly after the multilingual preface) if a language 217 independent part does not exist. 219 If there is no translation type preference information available, the 220 values of the Translation-Type field may be ignored. 222 Additionally, interactive implementations MAY offer the user a choice 223 from among the available languages. 225 5. The Content-Language Field 227 The Content-Language field in the individual language message parts 228 is used to identify the language in which the message part is 229 written. Based on the value of this field, a conforming email client 230 can determine which message part to display (given the user's 231 language settings). 233 The Content-Language MUST comply with RFC 3282 [RFC3282] (which 234 defines the Content-Language field) and BCP 47/RFC 5646 [RFC5646] 235 (which defines the structure and semantics for the language code 236 values). 238 Examples of this field for English, German and an instruction manual 239 in Spanish and French, could look like the following: 241 Content-Language: en 243 Content-Language: de 245 Content-Language: es, fr 247 6. The Translation-Type Field 249 The Translation-Type field can be used in the individual language 250 message parts to identify the type of translation. Based on the 251 value of this parameter and the user's preferences, a conforming 252 email client can determine which message part to display. 254 This field can have one of three possible values: 'original', 'human' 255 or 'automated' although other values may be added in the future. A 256 value of 'original' is given in the language message part that is in 257 the original language. A value of 'human' is used when a language 258 message part is translated by a human translator or a human has 259 checked and corrected an automated translation. A value of 260 'automated' is used when a language message part has been translated 261 by an electronic agent without proofreading or subsequent correction. 263 Examples of this field include: 265 Translation-Type: original 267 Translation-Type: human 269 7. The Subject Field in the Language Message parts 271 On receipt of the message, conforming email clients will need to 272 render the subject in the correct language for the recipient. To 273 enable this the Subject field SHOULD be provided in each language 274 message part. The value for this field should be a translation of 275 the email subject. 277 US-ASCII and 'encoded-word' examples of this field include: 279 Subject: A really simple email subject 281 Subject: =?UTF-8?Q?Un_asunto_de_correo_electr=C3=b3nico_ 282 realmente_sencillo?= 284 See RFC 2047 [RFC2047] for the specification of 'encoded-word'. 286 The subject to be presented to the recipient should be selected from 287 the message part identified during the message part selection stage. 289 If no Subject field is found the top-level Subject header field value 290 should be used. 292 8. Examples 294 8.1. An Example of a Simple Multiple language email message 296 Below is a minimal example of a multiple language email message. It 297 has the multilingual preface and two language message parts. 299 From: Nik@example.com 300 To: Nathaniel@example.com 301 Subject: Example of a message in Spanish and English 302 Date: Thu, 7 Apr 2017 21:28:00 +0100 303 MIME-Version: 1.0 304 Content-Type: multipart/multilingual; 305 boundary="01189998819991197253" 307 --01189998819991197253 308 Content-Type: text/plain; charset="UTF-8" 309 Content-Disposition: inline 310 Content-Transfer-Encoding: quoted-printable 312 This is a message in multiple languages. It says the 313 same thing in each language. If you can read it in one language, 314 you can ignore the other translations. The other translations may be 315 presented as attachments or grouped together. 317 Este es un mensaje en varios idiomas. Dice lo mismo en 318 cada idioma. Si puede leerlo en un idioma, puede ignorar las otras 319 traducciones. Las otras traducciones pueden presentarse como archivos 320 adjuntos o agrupados. 322 --01189998819991197253 323 Content-Type: message/rfc822 324 Content-Language: en 325 Translation-Type: original 326 Content-Disposition: inline 328 Subject: Example of a message in Spanish and English 329 Content-Type: text/plain; charset="US-ASCII" 330 Content-Transfer-Encoding: 7bit 331 MIME-Version: 1.0 333 Hello, this message content is provided in your language. 335 --01189998819991197253 336 Content-Type: message/rfc822 337 Content-Language: es 338 Translation-Type: human 339 Content-Disposition: inline 341 Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?= 342 =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?= 343 Content-Type: text/plain; charset="US-ASCII" 344 Content-Transfer-Encoding: 7bit 345 MIME-Version: 1.0 347 Hola, el contenido de este mensaje esta disponible en su idioma. 349 --01189998819991197253-- 351 8.2. An Example of a Multiple language email message with language 352 independent part 354 Below is an example of a multiple language email message that has the 355 multilingual preface followed by two language message parts and then 356 a language independent png image. 358 From: Nik@example.com 359 To: Nathaniel@example.com 360 Subject: Example of a message in Spanish and English 361 Date: Thu, 7 Apr 2017 21:08:00 +0100 362 MIME-Version: 1.0 363 Content-Type: multipart/multilingual; 364 boundary="01189998819991197253" 366 --01189998819991197253 367 Content-Type: text/plain; charset="UTF-8" 368 Content-Disposition: inline 369 Content-Transfer-Encoding: quoted-printable 371 This is a message in multiple languages. It says the 372 same thing in each language. If you can read it in one language, 373 you can ignore the other translations. The other translations may be 374 presented as attachments or grouped together. 376 Este es un mensaje en varios idiomas. Dice lo mismo en 377 cada idioma. Si puede leerlo en un idioma, puede ignorar las otras 378 traducciones. Las otras traducciones pueden presentarse como archivos 379 adjuntos o agrupados. 381 --01189998819991197253 382 Content-Type: message/rfc822 383 Content-Language: en 384 Translation-Type: original 385 Content-Disposition: inline 387 Subject: Example of a message in Spanish and English 388 Content-Type: text/plain; charset="US-ASCII" 389 Content-Transfer-Encoding: 7bit 390 MIME-Version: 1.0 392 Hello, this message content is provided in your language. 394 --01189998819991197253 395 Content-Type: message/rfc822 396 Content-Language: es 397 Translation-Type: human 398 Content-Disposition: inline 400 Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?= 401 =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?= 402 Content-Type: text/plain; charset="US-ASCII" 403 Content-Transfer-Encoding: 7bit 404 MIME-Version: 1.0 406 Hola, el contenido de este mensaje esta disponible en su idioma. 408 --01189998819991197253 409 Content-Type: message/rfc822; name="Icon" 410 Content-Language: zxx 411 Content-Disposition: inline 413 Content-Type: multipart/mixed; 414 boundary="99911972530118999881"; charset="US-ASCII" 415 Content-Transfer-Encoding: 7bit 416 MIME-Version: 1.0 418 --99911972530118999881 419 Content-Type: image/png; name="icon.png" 420 Content-Disposition: inline 421 Content-Transfer-Encoding: base64 423 iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZQAA 424 SA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr 425 997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII= 427 --99911972530118999881-- 428 --01189998819991197253-- 429 8.3. An Example of a complex Multiple language email message with 430 language independent part 432 Below is an example of a more complex multiple language email 433 message. It has the multilingual preface and two language message 434 parts and then a language independent png image. The language 435 message parts have multipart/alternative contents and would therefore 436 require further processing to determine the content to display. 438 From: Nik@example.com 439 To: Nathaniel@example.com 440 Subject: Example of a message in Spanish and English 441 Date: Thu, 7 Apr 2017 20:55:00 +0100 442 MIME-Version: 1.0 443 Content-Type: multipart/multilingual; 444 boundary="01189998819991197253" 446 --01189998819991197253 447 Content-Type: text/plain; charset="UTF-8" 448 Content-Disposition: inline 449 Content-Transfer-Encoding: quoted-printable 451 This is a message in multiple languages. It says the 452 same thing in each language. If you can read it in one language, 453 you can ignore the other translations. The other translations may be 454 presented as attachments or grouped together. 456 Este es un mensaje en varios idiomas. Dice lo mismo en 457 cada idioma. Si puede leerlo en un idioma, puede ignorar las otras 458 traducciones. Las otras traducciones pueden presentarse como archivos 459 adjuntos o agrupados. 461 --01189998819991197253 462 Content-Type: message/rfc822 463 Content-Language: en 464 Translation-Type: original 465 Content-Disposition: inline 467 Subject: Example of a message in Spanish and English 468 Content-Type: multipart/alternative; 469 boundary="72530118999911999881"; charset="US-ASCII" 470 Content-Transfer-Encoding: 7bit 471 MIME-Version: 1.0 473 --72530118999911999881 474 Content-Type: text/plain; charset="US-ASCII" 475 Content-Transfer-Encoding: 7bit 476 Hello, this message content is provided in your language. 478 --72530118999911999881 479 Content-Type: text/html; charset="US-ASCII" 480 Content-Transfer-Encoding: 7bit 482 Hello, this message content is provided in 483 your language. 485 --72530118999911999881-- 486 --01189998819991197253 487 Content-Type: message/rfc822 488 Content-Language: es 489 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 528 iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZQAA 529 SA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr 530 997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII= 532 --99911972530118999881-- 533 --01189998819991197253-- 535 9. Acknowledgements 537 The authors are grateful for the helpful input received from many 538 people but would especially like to acknowledge the help of Harald 539 Alvestrand, Stephane Bortzmeyer, Eric Burger, Mark Davis, Doug Ewell, 540 Randall Gellens, Gunnar Hellstrom, Barry Leiba, Sean Leonard, John 541 Levine, Alexey Melnikov, Addison Phillips, Julian Reschke, Pete 542 Resnick, Brian Rosen, Fiona Tomkinson, Simon Tyler and Daniel Vargha. 544 The authors would also like to thank Fernando Alvaro and Luis de 545 Pablo for their work on the Spanish translations. 547 10. IANA Considerations 549 10.1. The multipart/multilingual MIME type 551 The multipart/multilingual MIME type will be registered with IANA 552 including a reference to this document. This is the registration 553 template: 555 Media Type name: multipart 557 Media subtype name: multilingual 559 Required parameters: boundary (defined in RFC2046) 561 Optional parameters: N/A 563 Encoding considerations: There are no encoding considerations for 564 this multipart other than that of the embedded body parts. 565 The embedded body parts (typically one text/plain plus one or 566 more message/*) may contain 7-bit, 8-bit or binary encodings. 568 Security considerations: See the Security Considerations section 569 in this document 571 Interoperability considerations: 572 Existing systems that do not treat unknown multipart subtypes 573 as multipart/mixed may not correctly render a 574 multipart/multilingual type. 576 Published specification: This document 578 Applications that use this media type: 579 Mail Transfer Agents, Mail User Agents, spam detection, 580 virus detection modules and message authentication modules. 582 Additional information: 583 Deprecated alias names for this type: N/A 584 Magic number(s): N/A 585 File extension(s): N/A 586 Macintosh file type code(s): N/A 588 Person & email address to contact for further information: 589 Nik Tomkinson 590 rfc.nik.tomkinson@gmail.com 592 Nathaniel Borenstein 593 nsb@mimecast.com 595 Intended usage: Common 597 10.2. The Translation-Type field 599 The Translation-Type field will be added to the IANA "Permanent 600 Message Header Field Names" registry. That entry will reference this 601 document. This is the registration template: 603 Header field name: Translation-Type 605 Applicable protocol: mail 607 Status: Standard 609 Author/Change controller: IETF 611 Specification document(s): this document 613 Related information: none 615 11. Security Considerations 617 Whilst it is intended that each language message part is a direct 618 translation of the original message, this may not always be the case 619 and these parts could contain undesirable content. Therefore there 620 is a possible risk that undesirable text or images could be shown to 621 the recipient if the message is passed through a spam filter that 622 does not check all of the message parts. The risk should be minimal 623 due to the fact that an unknown multipart subtype should be treated 624 as multipart/mixed and so each message part should be subsequently 625 scanned. 627 Because the language message parts have a Content-Type of message/ 628 rfc822 or message/global, they might contain From fields which could 629 have different values to that of the top-level From field and may not 630 reflect the actual sender. The inconsistent From field values might 631 get shown to the recipient in a non-conforming email client and may 632 mislead the recipient into thinking that the email came from someone 633 other than the real sender. 635 12. Changes from Previous Versions 637 12.1. Changes from draft-tomkinson-multilangcontent-01 to draft- 638 tomkinson-slim-multilangcontent-00 640 o File name and version number changed to reflect the proposed WG 641 name SLIM (Selection of Language for Internet Media). 643 o Replaced the Subject-Translation field in the language message 644 parts with Subject and provided US-ASCII and non-US-ASCII 645 examples. 647 o Introduced the language-independent message part. 649 o Many wording improvements and clarifications throughout the 650 document. 652 12.2. Changes from draft-tomkinson-slim-multilangcontent-00 to draft- 653 tomkinson-slim-multilangcontent-01 655 o Added Translation-Type in each language message part to identify 656 the source of the translation (original/human/automated). 658 12.3. Changes from draft-tomkinson-slim-multilangcontent-01 to draft- 659 tomkinson-slim-multilangcontent-02 661 o Changed Translation-Type to be a parameter for the Content- 662 Language field rather than a new separate field. 664 o Added a paragraph about using Content-Disposition field to help 665 non-conforming mail clients correctly render the multilingual 666 preface. 668 o Recommended using a Name parameter on the language part Content- 669 Type to help the recipient identify the translations in non- 670 conforming mail clients. 672 o Many wording improvements and clarifications throughout the 673 document. 675 12.4. Changes from draft-tomkinson-slim-multilangcontent-02 to draft- 676 ietf-slim-multilangcontent-00 678 o Name change to reflect the draft being accepted into SLIM as a 679 working group document. 681 o Updated examples to use UTF-8 encoding where required. 683 o Removed references to 'locale' for identifying language 684 preference. 686 o Recommended language matching schemes from RFC 4647 [RFC4647]. 688 o Renamed the unmatched part to language independent part to 689 reinforce its intended purpose. 691 o Added requirement for using Content-Language: zxx in the language 692 independent part. 694 o Many wording improvements and clarifications throughout the 695 document. 697 12.5. Changes from draft-ietf-slim-multilangcontent-00 to draft-ietf- 698 slim-multilangcontent-01 700 o Changed the inner content type to require message/rfc822 or 701 message/global. 703 o Updated the examples to reflect the new inner content types. 705 o Added to the security considerations to highlight the risk from 706 insufficient spam filters. 708 12.6. Changes from draft-ietf-slim-multilangcontent-01 to draft-ietf- 709 slim-multilangcontent-02 711 o Restricted the use of a From field in the language message parts 712 and the language independent part. 714 o Updated the security considerations to highlight the risk of an 715 unmatched sender addresses that could be set in the language 716 message parts. 718 12.7. Changes from draft-ietf-slim-multilangcontent-02 to draft-ietf- 719 slim-multilangcontent-03 721 o Relaxed the restriction on the use of the From field in the 722 language message parts to allow a localised version of the 723 sender's display name. 725 12.8. Changes from draft-ietf-slim-multilangcontent-03 to draft-ietf- 726 slim-multilangcontent-04 728 o Updated the wording of the security considerations section to 729 reflect the relaxation of the use of the From field in the 730 language message parts. 732 12.9. Changes from draft-ietf-slim-multilangcontent-04 to draft-ietf- 733 slim-multilangcontent-05 735 o Referenced the RFC for message/global in Language Message Parts 736 section. 738 o Removed RFC 2119 keyword in the Message Part Selection section. 740 o Included full email addresses in all examples. 742 o Updated reference name of real-time companion document in the 743 Introduction. 745 o Removed paragraph warning of over use of language sub-tags. 747 o Changed 'exponential' to 'significantly' in Introduction. 749 12.10. Changes from draft-ietf-slim-multilangcontent-05 to draft-ietf- 750 slim-multilangcontent-06 752 o Changed parameter Translation-Type back to a new field to reduce 753 the risk of breaking existing implementations that don't expect 754 any parameters on Content-Language. 756 o Improved the IANA Considerations section to include the full 757 registration template for the multipart/multilingual type and the 758 new Translation-Type field. 760 12.11. Changes from draft-ietf-slim-multilangcontent-06 to draft-ietf- 761 slim-multilangcontent-07 763 o Updated the Encoding Considerations in the IANA Registration 764 Template. 766 12.12. Changes from draft-ietf-slim-multilangcontent-07 to draft-ietf- 767 slim-multilangcontent-08 769 o Reordered the sections to make the Security Considerations easier 770 to find. 772 o Shortened a line in one of the examples that was longer than 72 773 characters. 775 o Updated the link to the real-time companion document to the latest 776 version. 778 13. References 780 13.1. Normative References 782 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 783 Extensions (MIME) Part Two: Media Types", RFC 2046, 784 DOI 10.17487/RFC2046, November 1996, 785 . 787 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 788 Part Three: Message Header Extensions for Non-ASCII Text", 789 RFC 2047, DOI 10.17487/RFC2047, November 1996, 790 . 792 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 793 Requirement Levels", BCP 14, RFC 2119, 794 DOI 10.17487/RFC2119, March 1997, 795 . 797 [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating 798 Presentation Information in Internet Messages: The 799 Content-Disposition Header Field", RFC 2183, 800 DOI 10.17487/RFC2183, August 1997, 801 . 803 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 804 DOI 10.17487/RFC3282, May 2002, 805 . 807 [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", 808 BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006, 809 . 811 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 812 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 813 September 2009, . 815 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 816 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 817 2012, . 819 13.2. Informational References 821 [I-D.ietf-slim-negotiating-human-language] 822 Gellens, R., "Negotiating Human Language in Real-Time 823 Communications", draft-ietf-slim-negotiating-human- 824 language-10 (work in progress), May 2017. 826 Authors' Addresses 828 Nik Tomkinson 829 Mimecast Ltd 830 CityPoint, One Ropemaker Street 831 London EC2Y 9AW 832 United Kingdom 834 Email: rfc.nik.tomkinson@gmail.com 835 Nathaniel Borenstein 836 Mimecast Ltd 837 480 Pleasant Street 838 Watertown MA 02472 839 North America 841 Email: nsb@mimecast.com