idnits 2.17.1 draft-ietf-slim-multilangcontent-12.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 (August 9, 2017) is 2452 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-13 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: February 10, 2018 August 9, 2017 7 Multiple Language Content Type 8 draft-ietf-slim-multilangcontent-12 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 February 10, 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 charset is used for this message part. See RFC 3629 [RFC3629] 138 for details of UTF-8. 140 Whilst this section of the message is useful for backward 141 compatibility, it will normally only be shown when rendered by a non- 142 conforming email client, because conforming email clients SHOULD only 143 show the single language message part identified by the user's 144 preferred language and the language message part's Content-Language. 146 For the correct display of the multilingual preface in a non- 147 conforming email client, the sender MAY use the Content-Disposition 148 field with a value of 'inline' in conformance with RFC 2183 [RFC2183] 149 (which defines the Content-Disposition field). If provided, this 150 SHOULD be placed at the multipart/multilingual level and in the 151 multilingual preface. This makes it clear to a non-conforming email 152 client that the multilingual preface should be displayed immediately 153 to the recipient, followed by any subsequent parts marked as 154 'inline'. 156 For an example of a multilingual preface, see the examples in 157 Section 8. 159 3.2. The Language Message Parts 161 The language message parts are typically translations of the same 162 message content. These message parts SHOULD be ordered so that the 163 first part after the multilingual preface is in the language believed 164 to be the most likely to be recognised by the recipient as this will 165 constitute the default part when language negotiation fails and there 166 is no Language Independent part. All of the language message parts 167 MUST have a Content-Language field and a Content-Type field and MAY 168 have a Translation-Type 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. See RFC 6532 174 [RFC6532] for details of message/global. Each language message part 175 SHOULD have a Subject field in the appropriate language for that 176 language part. If there is a From field present, its value MUST 177 include the same email address as the top-level From header although 178 the display name MAY be a localised version. 180 3.3. The Language Independent Message Part 182 If there is language independent content intended for the recipient 183 to see if they have a preferred language other than one of those 184 specified in the language message parts and the default language 185 message part is unlikely to be understood, another part MAY be 186 provided. This could typically include a language independent 187 graphic. When this part is present, it MUST be the last part and 188 MUST have a Content-Language field with a value of "zxx" (as 189 described in BCP 47/RFC 5646 [RFC5646]). The part SHOULD have a 190 Content-Type of message/rfc822 or message/global (to match the 191 language message 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 will treat the message as if it was multipart/ 200 mixed and render message parts accordingly (in accordance with 201 sections 5.1.3 and 5.1.7 of RFC 2046 [RFC2046]). 203 If the email client does understand multipart/multilingual then it 204 SHOULD ignore the multilingual preface and select the best match for 205 the user's preferred language from the language message parts 206 available. Also, the user may prefer to see the original message 207 content in their second language over a machine translation in their 208 first language. The Translation-Type field value can be used for 209 further selection based on this preference. The selection of 210 language part may be implemented in a variety of ways, although the 211 matching schemes detailed in RFC 4647 [RFC4647] are RECOMMENDED as a 212 starting point for an implementation. The goal is to render the most 213 appropriate translation for the user. 215 If there is no match for the user's preferred language (or there is 216 no preferred language information available) the email client SHOULD 217 select the language independent part (if one exists) or the first 218 language part (directly after the multilingual preface) if a language 219 independent part does not exist. 221 If there is no translation type preference information available, the 222 values of the Translation-Type field may be ignored. 224 Additionally, interactive implementations MAY offer the user a choice 225 from among the available languages. 227 5. The Content-Language Field 229 The Content-Language field in the individual language message parts 230 is used to identify the language in which the message part is 231 written. Based on the value of this field, a conforming email client 232 can determine which message part to display (given the user's 233 language settings). 235 The Content-Language MUST comply with RFC 3282 [RFC3282] (which 236 defines the Content-Language field) and BCP 47/RFC 5646 [RFC5646] 237 (which defines the structure and semantics for the language code 238 values). 240 Examples of this field for English, German and an instruction manual 241 in Spanish and French, could look like the following: 243 Content-Language: en 245 Content-Language: de 247 Content-Language: es, fr 249 6. The Translation-Type Field 251 The Translation-Type field can be used in the individual language 252 message parts to identify the type of translation. Based on the 253 value of this parameter and the user's preferences, a conforming 254 email client can determine which message part to display. 256 This field can have one of three possible values: 'original', 'human' 257 or 'automated' although other values may be added in the future. A 258 value of 'original' is given in the language message part that is in 259 the original language. A value of 'human' is used when a language 260 message part is translated by a human translator or a human has 261 checked and corrected an automated translation. A value of 262 'automated' is used when a language message part has been translated 263 by an electronic agent without proofreading or subsequent correction. 265 Examples of this field include: 267 Translation-Type: original 269 Translation-Type: human 271 The syntax of the Translation-Type field in ABNF RFC 5234 [RFC5234] 272 is: 274 Translation-Type = [FWS] translationtype 276 FWS = 277 translationtype = "original" / "human" / "automated" / translTypeExt 278 translTypeExt = 1*atext 279 atext = 281 This references RFC 5322 [RFC5322] for the pre-defined rules FWS and 282 atext. 284 7. The Subject Field in the Language Message parts 286 On receipt of the message, conforming email clients will need to 287 render the subject in the correct language for the recipient. To 288 enable this the Subject field SHOULD be provided in each language 289 message part. The value for this field should be a translation of 290 the email subject. 292 US-ASCII and 'encoded-word' examples of this field include: 294 Subject: A really simple email subject 296 Subject: =?UTF-8?Q?Un_asunto_de_correo_electr=C3=b3nico_ 297 realmente_sencillo?= 299 See RFC 2047 [RFC2047] for the specification of 'encoded-word'. 301 The subject to be presented to the recipient should be selected from 302 the message part identified during the message part selection stage. 303 If no Subject field is found the top-level Subject header field value 304 should be used. 306 8. Examples 308 8.1. An Example of a Simple Multiple language email message 310 Below is a minimal example of a multiple language email message. It 311 has the multilingual preface and two language message parts. 313 From: Nik@example.com 314 To: Nathaniel@example.com 315 Subject: Example of a message in Spanish and English 316 Date: Thu, 7 Apr 2017 21:28:00 +0100 317 MIME-Version: 1.0 318 Content-Type: multipart/multilingual; 319 boundary="01189998819991197253" 321 --01189998819991197253 322 Content-Type: text/plain; charset="UTF-8" 323 Content-Disposition: inline 324 Content-Transfer-Encoding: quoted-printable 326 This is a message in multiple languages. It says the 327 same thing in each language. If you can read it in one language, 328 you can ignore the other translations. The other translations may be 329 presented as attachments or grouped together. 331 Este es un mensaje en varios idiomas. Dice lo mismo en 332 cada idioma. Si puede leerlo en un idioma, puede ignorar las otras 333 traducciones. Las otras traducciones pueden presentarse como archivos 334 adjuntos o agrupados. 336 --01189998819991197253 337 Content-Type: message/rfc822 338 Content-Language: en 339 Translation-Type: original 340 Content-Disposition: inline 342 Subject: Example of a message in Spanish and English 343 Content-Type: text/plain; charset="US-ASCII" 344 Content-Transfer-Encoding: 7bit 345 MIME-Version: 1.0 347 Hello, this message content is provided in your language. 349 --01189998819991197253 350 Content-Type: message/rfc822 351 Content-Language: es 352 Translation-Type: human 353 Content-Disposition: inline 355 Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?= 356 =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?= 357 Content-Type: text/plain; charset="US-ASCII" 358 Content-Transfer-Encoding: 7bit 359 MIME-Version: 1.0 361 Hola, el contenido de este mensaje esta disponible en su idioma. 363 --01189998819991197253-- 365 8.2. An Example of a Multiple language email message with language 366 independent part 368 Below is an example of a multiple language email message that has the 369 multilingual preface followed by two language message parts and then 370 a language independent png image. 372 From: Nik@example.com 373 To: Nathaniel@example.com 374 Subject: Example of a message in Spanish and English 375 Date: Thu, 7 Apr 2017 21:08:00 +0100 376 MIME-Version: 1.0 377 Content-Type: multipart/multilingual; 378 boundary="01189998819991197253" 380 --01189998819991197253 381 Content-Type: text/plain; charset="UTF-8" 382 Content-Disposition: inline 383 Content-Transfer-Encoding: quoted-printable 385 This is a message in multiple languages. It says the 386 same thing in each language. If you can read it in one language, 387 you can ignore the other translations. The other translations may be 388 presented as attachments or grouped together. 390 Este es un mensaje en varios idiomas. Dice lo mismo en 391 cada idioma. Si puede leerlo en un idioma, puede ignorar las otras 392 traducciones. Las otras traducciones pueden presentarse como archivos 393 adjuntos o agrupados. 395 --01189998819991197253 396 Content-Type: message/rfc822 397 Content-Language: en 398 Translation-Type: original 399 Content-Disposition: inline 401 Subject: Example of a message in Spanish and English 402 Content-Type: text/plain; charset="US-ASCII" 403 Content-Transfer-Encoding: 7bit 404 MIME-Version: 1.0 406 Hello, this message content is provided in your language. 408 --01189998819991197253 409 Content-Type: message/rfc822 410 Content-Language: es 411 Translation-Type: human 412 Content-Disposition: inline 414 Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?= 415 =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?= 416 Content-Type: text/plain; charset="US-ASCII" 417 Content-Transfer-Encoding: 7bit 418 MIME-Version: 1.0 420 Hola, el contenido de este mensaje esta disponible en su idioma. 422 --01189998819991197253 423 Content-Type: message/rfc822; name="Icon" 424 Content-Language: zxx 425 Content-Disposition: inline 427 Content-Type: image/png; name="icon.png" 428 Content-Transfer-Encoding: base64 430 iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZQAA 431 SA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr 432 997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII= 434 --01189998819991197253-- 436 8.3. An Example of a complex Multiple language email message with 437 language independent part 439 Below is an example of a more complex multiple language email 440 message. It has the multilingual preface and two language message 441 parts and then a language independent png image. The language 442 message parts have multipart/alternative contents and would therefore 443 require further processing to determine the content to display. 445 From: Nik@example.com 446 To: Nathaniel@example.com 447 Subject: Example of a message in Spanish and English 448 Date: Thu, 7 Apr 2017 20:55:00 +0100 449 MIME-Version: 1.0 450 Content-Type: multipart/multilingual; 451 boundary="01189998819991197253" 453 --01189998819991197253 454 Content-Type: text/plain; charset="UTF-8" 455 Content-Disposition: inline 456 Content-Transfer-Encoding: quoted-printable 458 This is a message in multiple languages. It says the 459 same thing in each language. If you can read it in one language, 460 you can ignore the other translations. The other translations may be 461 presented as attachments or grouped together. 463 Este es un mensaje en varios idiomas. Dice lo mismo en 464 cada idioma. Si puede leerlo en un idioma, puede ignorar las otras 465 traducciones. Las otras traducciones pueden presentarse como archivos 466 adjuntos o agrupados. 468 --01189998819991197253 469 Content-Type: message/rfc822 470 Content-Language: en 471 Translation-Type: original 472 Content-Disposition: inline 474 Subject: Example of a message in Spanish and English 475 Content-Type: multipart/alternative; 476 boundary="72530118999911999881"; charset="US-ASCII" 477 Content-Transfer-Encoding: 7bit 478 MIME-Version: 1.0 480 --72530118999911999881 481 Content-Type: text/plain; charset="US-ASCII" 482 Content-Transfer-Encoding: 7bit 484 Hello, this message content is provided in your language. 486 --72530118999911999881 487 Content-Type: text/html; charset="US-ASCII" 488 Content-Transfer-Encoding: 7bit 490 Hello, this message content is provided in 491 your language. 493 --72530118999911999881-- 494 --01189998819991197253 495 Content-Type: message/rfc822 496 Content-Language: es 497 Translation-Type: human 498 Content-Disposition: inline 500 Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?= 501 =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?= 502 Content-Type: multipart/alternative; 503 boundary="53011899989991197281"; charset="US-ASCII" 504 Content-Transfer-Encoding: 7bit 505 MIME-Version: 1.0 507 --53011899989991197281 508 Content-Type: text/plain; charset="US-ASCII" 509 Content-Transfer-Encoding: 7bit 511 Hola, el contenido de este mensaje esta disponible en su idioma. 513 --53011899989991197281 514 Content-Type: text/html; charset="US-ASCII" 515 Content-Transfer-Encoding: 7bit 517 Hola, el contenido de este mensaje esta 518 disponible en su idioma. 520 --53011899989991197281-- 521 --01189998819991197253 522 Content-Type: message/rfc822; name="Icon" 523 Content-Language: zxx 524 Content-Disposition: inline 526 Content-Type: multipart/mixed; 527 boundary="99911972530118999881"; charset="US-ASCII" 528 Content-Transfer-Encoding: 7bit 529 MIME-Version: 1.0 531 --99911972530118999881 532 Content-Type: image/png; name="icon.png" 533 Content-Disposition: inline 534 Content-Transfer-Encoding: base64 536 iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZQAA 537 SA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr 538 997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII= 540 --99911972530118999881-- 541 --01189998819991197253-- 543 9. Acknowledgements 545 The authors are grateful for the helpful input received from many 546 people but would especially like to acknowledge the help of Harald 547 Alvestrand, Stephane Bortzmeyer, Eric Burger, Mark Davis, Doug Ewell, 548 Randall Gellens, Gunnar Hellstrom, Barry Leiba, Sean Leonard, John 549 Levine, Alexey Melnikov, Addison Phillips, Julian Reschke, Pete 550 Resnick, Brian Rosen, Fiona Tomkinson, Simon Tyler and Daniel Vargha. 552 The authors would also like to thank Fernando Alvaro and Luis de 553 Pablo for their work on the Spanish translations. 555 10. IANA Considerations 557 10.1. The multipart/multilingual MIME type 559 The multipart/multilingual MIME type will be registered with IANA 560 including a reference to this document. This is the registration 561 template: 563 Media Type name: multipart 565 Media subtype name: multilingual 567 Required parameters: boundary (defined in RFC2046) 569 Optional parameters: N/A 571 Encoding considerations: There are no encoding considerations for 572 this multipart other than that of the embedded body parts. 573 The embedded body parts (typically one text/plain plus one or 574 more message/*) may contain 7-bit, 8-bit or binary encodings. 576 Security considerations: See the Security Considerations section 577 in RFC XXXX 579 Interoperability considerations: 580 Existing systems that do not treat unknown multipart subtypes 581 as multipart/mixed may not correctly render a 582 multipart/multilingual type. These systems would also be non- 583 compliant with MIME. 585 Author/Change controller: IETF 587 Published specification: RFC XXXX 589 Applications that use this media type: 590 Mail Transfer Agents, Mail User Agents, spam detection, 591 virus detection modules and message authentication modules. 593 Additional information: 594 Deprecated alias names for this type: N/A 595 Magic number(s): N/A 596 File extension(s): N/A 597 Macintosh file type code(s): N/A 599 Person & email address to contact for further information: 600 Nik Tomkinson 601 rfc.nik.tomkinson@gmail.com 603 Nathaniel Borenstein 604 nsb@mimecast.com 606 Intended usage: Common 608 10.2. The Translation-Type Field 610 The Translation-Type field will be added to the IANA "Permanent 611 Message Header Field Names" registry. That entry will reference this 612 document. This is the registration template: 614 Header field name: Translation-Type 616 Applicable protocol: mime 618 Status: Standard 620 Author/Change controller: IETF 622 Specification document(s): RFC XXXX 624 Related information: none 626 10.3. The Translation-Type Field Values 628 IANA is requested to create a new registry for Translation-Type 629 Header Field values. New values must be registered using 630 "Specification Required" IANA registration procedure. Registrations 631 must include translation type value, short description and a URI of 632 the specification. 634 This document also registers 3 initial values specified in Section 6. 636 11. Security Considerations 638 Whilst it is intended that each language message part is a direct 639 translation of the original message, this may not always be the case 640 and these parts could contain undesirable content. Therefore there 641 is a possible risk that undesirable text or images could be shown to 642 the recipient if the message is passed through a spam filter that 643 does not check all of the message parts. The risk should be minimal 644 due to the fact that an unknown multipart subtype should be treated 645 as multipart/mixed and so each message part should be subsequently 646 scanned. 648 Because the language message parts have a Content-Type of message/ 649 rfc822 or message/global, they might contain From fields which could 650 have different values to that of the top-level From field and may not 651 reflect the actual sender. The inconsistent From field values might 652 get shown to the recipient in a non-conforming email client and may 653 mislead the recipient into thinking that the email came from someone 654 other than the real sender. 656 12. Changes from Previous Versions 658 12.1. Changes from draft-tomkinson-multilangcontent-01 to draft- 659 tomkinson-slim-multilangcontent-00 661 o File name and version number changed to reflect the proposed WG 662 name SLIM (Selection of Language for Internet Media). 664 o Replaced the Subject-Translation field in the language message 665 parts with Subject and provided US-ASCII and non-US-ASCII 666 examples. 668 o Introduced the language-independent message part. 670 o Many wording improvements and clarifications throughout the 671 document. 673 12.2. Changes from draft-tomkinson-slim-multilangcontent-00 to draft- 674 tomkinson-slim-multilangcontent-01 676 o Added Translation-Type in each language message part to identify 677 the source of the translation (original/human/automated). 679 12.3. Changes from draft-tomkinson-slim-multilangcontent-01 to draft- 680 tomkinson-slim-multilangcontent-02 682 o Changed Translation-Type to be a parameter for the Content- 683 Language field rather than a new separate field. 685 o Added a paragraph about using Content-Disposition field to help 686 non-conforming mail clients correctly render the multilingual 687 preface. 689 o Recommended using a Name parameter on the language part Content- 690 Type to help the recipient identify the translations in non- 691 conforming mail clients. 693 o Many wording improvements and clarifications throughout the 694 document. 696 12.4. Changes from draft-tomkinson-slim-multilangcontent-02 to draft- 697 ietf-slim-multilangcontent-00 699 o Name change to reflect the draft being accepted into SLIM as a 700 working group document. 702 o Updated examples to use UTF-8 encoding where required. 704 o Removed references to 'locale' for identifying language 705 preference. 707 o Recommended language matching schemes from RFC 4647 [RFC4647]. 709 o Renamed the unmatched part to language independent part to 710 reinforce its intended purpose. 712 o Added requirement for using Content-Language: zxx in the language 713 independent part. 715 o Many wording improvements and clarifications throughout the 716 document. 718 12.5. Changes from draft-ietf-slim-multilangcontent-00 to draft-ietf- 719 slim-multilangcontent-01 721 o Changed the inner content type to require message/rfc822 or 722 message/global. 724 o Updated the examples to reflect the new inner content types. 726 o Added to the security considerations to highlight the risk from 727 insufficient spam filters. 729 12.6. Changes from draft-ietf-slim-multilangcontent-01 to draft-ietf- 730 slim-multilangcontent-02 732 o Restricted the use of a From field in the language message parts 733 and the language independent part. 735 o Updated the security considerations to highlight the risk of an 736 unmatched sender addresses that could be set in the language 737 message parts. 739 12.7. Changes from draft-ietf-slim-multilangcontent-02 to draft-ietf- 740 slim-multilangcontent-03 742 o Relaxed the restriction on the use of the From field in the 743 language message parts to allow a localised version of the 744 sender's display name. 746 12.8. Changes from draft-ietf-slim-multilangcontent-03 to draft-ietf- 747 slim-multilangcontent-04 749 o Updated the wording of the security considerations section to 750 reflect the relaxation of the use of the From field in the 751 language message parts. 753 12.9. Changes from draft-ietf-slim-multilangcontent-04 to draft-ietf- 754 slim-multilangcontent-05 756 o Referenced the RFC for message/global in Language Message Parts 757 section. 759 o Removed RFC 2119 keyword in the Message Part Selection section. 761 o Included full email addresses in all examples. 763 o Updated reference name of real-time companion document in the 764 Introduction. 766 o Removed paragraph warning of over use of language sub-tags. 768 o Changed 'exponential' to 'significantly' in Introduction. 770 12.10. Changes from draft-ietf-slim-multilangcontent-05 to draft-ietf- 771 slim-multilangcontent-06 773 o Changed parameter Translation-Type back to a new field to reduce 774 the risk of breaking existing implementations that don't expect 775 any parameters on Content-Language. 777 o Improved the IANA Considerations section to include the full 778 registration template for the multipart/multilingual type and the 779 new Translation-Type field. 781 12.11. Changes from draft-ietf-slim-multilangcontent-06 to draft-ietf- 782 slim-multilangcontent-07 784 o Updated the Encoding Considerations in the IANA Registration 785 Template. 787 12.12. Changes from draft-ietf-slim-multilangcontent-07 to draft-ietf- 788 slim-multilangcontent-08 790 o Reordered the sections to make the Security Considerations easier 791 to find. 793 o Shortened a line in one of the examples that was longer than 72 794 characters. 796 o Updated the link to the real-time companion document to the latest 797 version. 799 12.13. Changes from draft-ietf-slim-multilangcontent-08 to draft-ietf- 800 slim-multilangcontent-09 802 o Removed the phrase "and SHOULD NOT have a Subject field and SHOULD 803 NOT have a From field" in section 3.3 because the language 804 independent part would be message/rfc822 or message/global so it 805 is likely to have From and Subject fields. 807 o For the same reason as above, the phrase "(for example if the 808 language independent part is selected)" was removed from section 809 7. 811 o Phrase in part 3.3 was reworded from "This could typically be a 812 language independent graphic" to "This could typically include a 813 language independent graphic". 815 12.14. Changes from draft-ietf-slim-multilangcontent-09 to draft-ietf- 816 slim-multilangcontent-10 818 o Added Normative Reference to RFC 3629 for details of UTF-8 in the 819 Multilingual Preface section. 821 o Added ABNF for Translation-Type field. 823 o Updated example 2 to contain a image/png language independent 824 image directly rather than it being nested inside multipart/mixed 825 content. 827 o Inserted Change Controller into IANA template for multipart/ 828 multilingual. 830 o Replaced references to "This document" with RFC XXXX in the IANA 831 considerations. 833 12.15. Changes from draft-ietf-slim-multilangcontent-10 to draft-ietf- 834 slim-multilangcontent-11 836 o Updated the applicable protocol for the Translation-Type field in 837 the IANA registration template to be 'mime' rather than 'mail'. 839 o Added that updated specification documents would be the source of 840 new values for the Translation-Type field. 842 12.16. Changes from draft-ietf-slim-multilangcontent-11 to draft-ietf- 843 slim-multilangcontent-12 845 o Updated the ABNF for Translation-Type to allow for future values. 847 o Added section 10.3 to explain about the Translation-Type values 848 and providing new values. 850 13. References 852 13.1. Normative References 854 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 855 Extensions (MIME) Part Two: Media Types", RFC 2046, 856 DOI 10.17487/RFC2046, November 1996, 857 . 859 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 860 Part Three: Message Header Extensions for Non-ASCII Text", 861 RFC 2047, DOI 10.17487/RFC2047, November 1996, 862 . 864 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 865 Requirement Levels", BCP 14, RFC 2119, 866 DOI 10.17487/RFC2119, March 1997, 867 . 869 [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating 870 Presentation Information in Internet Messages: The 871 Content-Disposition Header Field", RFC 2183, 872 DOI 10.17487/RFC2183, August 1997, 873 . 875 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 876 DOI 10.17487/RFC3282, May 2002, 877 . 879 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 880 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 881 2003, . 883 [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", 884 BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006, 885 . 887 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 888 Specifications: ABNF", STD 68, RFC 5234, 889 DOI 10.17487/RFC5234, January 2008, 890 . 892 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 893 DOI 10.17487/RFC5322, October 2008, 894 . 896 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 897 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 898 September 2009, . 900 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 901 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 902 2012, . 904 13.2. Informational References 906 [I-D.ietf-slim-negotiating-human-language] 907 Gellens, R., "Negotiating Human Language in Real-Time 908 Communications", draft-ietf-slim-negotiating-human- 909 language-13 (work in progress), July 2017. 911 Authors' Addresses 913 Nik Tomkinson 914 Mimecast Ltd 915 CityPoint, One Ropemaker Street 916 London EC2Y 9AW 917 United Kingdom 919 Email: rfc.nik.tomkinson@gmail.com 921 Nathaniel Borenstein 922 Mimecast Ltd 923 480 Pleasant Street 924 Watertown MA 02472 925 North America 927 Email: nsb@mimecast.com