summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8255.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8255.txt')
-rw-r--r--doc/rfc/rfc8255.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc8255.txt b/doc/rfc/rfc8255.txt
new file mode 100644
index 0000000..230da10
--- /dev/null
+++ b/doc/rfc/rfc8255.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) N. Tomkinson
+Request for Comments: 8255 N. Borenstein
+Category: Standards Track Mimecast, Ltd.
+ISSN: 2070-1721 October 2017
+
+
+ Multiple Language Content Type
+
+Abstract
+
+ This document defines the 'multipart/multilingual' content type,
+ which is an addition to the Multipurpose Internet Mail Extensions
+ (MIME) standard. This content type makes it possible to send one
+ message that contains multiple language versions of the same
+ information. The translations would be identified by a language tag
+ and selected by the email client based on a user's language settings.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8255.
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 1]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
+ 2. The Content-Type Header Field . . . . . . . . . . . . . . . . 3
+ 3. The Message Parts . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. The Multilingual Preface . . . . . . . . . . . . . . . . 4
+ 3.2. The Language Message Parts . . . . . . . . . . . . . . . 5
+ 3.3. The Language-Independent Message Part . . . . . . . . . . 5
+ 4. Message Part Selection . . . . . . . . . . . . . . . . . . . 6
+ 5. The Content-Language Field . . . . . . . . . . . . . . . . . 6
+ 6. The Content-Translation-Type Field . . . . . . . . . . . . . 7
+ 7. The Subject Field in the Language Message Parts . . . . . . . 8
+ 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 8.1. An Example of a Simple Multiple-Language Email Message . 8
+ 8.2. An Example of a Multiple-Language Email Message with a
+ Language-Independent Part . . . . . . . . . . . . . . . . 9
+ 8.3. An Example of a Complex Multiple-Language Email Message
+ with a Language-Independent Part . . . . . . . . . . . . 11
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
+ 9.1. The 'multipart/multilingual' Media Type . . . . . . . . . 13
+ 9.2. The Content-Translation-Type Field . . . . . . . . . . . 15
+ 9.3. The Content-Translation-Type Header Field Values . . . . 15
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 18
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
+
+1. Introduction
+
+ Since the invention of email and the rapid spread of the Internet,
+ more and more people have been able to communicate in more and more
+ countries and in more and more languages. But during this time of
+ technological evolution, email has remained a single-language
+ communication tool, whether it is English to English, Spanish to
+ Spanish, or Japanese to Japanese.
+
+ Also during this time, many corporations have established their
+ offices in multicultural cities and have formed departments and teams
+ that span continents, cultures, and languages. Thus, the need to
+ communicate efficiently with little margin for miscommunication has
+ grown significantly.
+
+ This document defines the 'multipart/multilingual' content type,
+ which is an addition to the Multipurpose Internet Mail Extensions
+ (MIME) standard specified in [RFC2045], [RFC2046], [RFC2047],
+
+
+
+Tomkinson & Borenstein Standards Track [Page 2]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+ [RFC4289], and [RFC6838]. This content type makes it possible to
+ send a single message to a group of people in such a way that all of
+ the recipients can read the email in their preferred language. The
+ methods of translation of the message content are beyond the scope of
+ this document, but the structure of the email itself is defined
+ herein.
+
+ This document depends on the identification of language in message
+ parts for non-real-time communication. [HUMAN-LANG] is concerned
+ with a similar problem for real-time communication.
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in BCP
+ 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+2. The Content-Type Header Field
+
+ The 'multipart/multilingual' Media Subtype allows the sending of a
+ message in a number of different languages with the different
+ language versions embedded in the same message. This Media Subtype
+ helps the receiving email client make sense of the message structure.
+
+ The multipart subtype 'multipart/multilingual' has similar semantics
+ to 'multipart/alternative' (as discussed in RFC 2046 [RFC2046]) in
+ that each of the message parts is an alternative version of the same
+ information. The primary difference between 'multipart/multilingual'
+ and 'multipart/alternative' is that when using 'multipart/
+ multilingual', the message part to select for rendering is chosen
+ based on the values of the Content-Language field and optionally the
+ Content-Translation-Type field instead of the ordering of the parts
+ and the Content-Types.
+
+ The syntax for this multipart subtype conforms to the common syntax
+ for subtypes of multipart given in Section 5.1.1. of RFC 2046
+ [RFC2046]. An example 'multipart/multilingual' Content-Type header
+ field would look like this:
+
+ Content-Type: multipart/multilingual; boundary=01189998819991197253
+
+
+
+
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 3]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+3. The Message Parts
+
+ A 'multipart/multilingual' message will have a number of message
+ parts: exactly one multilingual preface, one or more language message
+ parts, and zero or one language-independent message part. The
+ details of these are described below.
+
+3.1. The Multilingual Preface
+
+ In order for the message to be received and displayed in non-
+ conforming email clients, the message SHOULD contain an explanatory
+ message part that MUST NOT be marked with a Content-Language field
+ and MUST be the first of the message parts. For maximum support in
+ the most basic of non-conforming email clients, it SHOULD have a
+ Content-Type of 'text/plain'. Because non-conforming email clients
+ are expected to treat a message with an unknown multipart type as
+ 'multipart/mixed' (in accordance with Sections 5.1.3 and 5.1.7 of RFC
+ 2046 [RFC2046]), they may show all of the message parts sequentially
+ or as attachments. Including and showing this explanatory part will
+ help the message recipient understand the message structure.
+
+ This initial message part SHOULD briefly explain to the recipient
+ that the message contains multiple languages, and the parts may be
+ rendered sequentially or as attachments. This SHOULD be presented in
+ the same languages that are provided in the subsequent language
+ message parts.
+
+ As this explanatory section is likely to contain languages using
+ scripts that require non-US-ASCII characters, it is RECOMMENDED that
+ a UTF-8 charset be used for this message part. See RFC 3629
+ [RFC3629] for details of UTF-8.
+
+ Whilst this section of the message is useful for backward
+ compatibility, it will normally only be shown when rendered by a non-
+ conforming email client. This is because conforming email clients
+ SHOULD only show the single language message part identified by the
+ user's preferred language and the language message part's Content-
+ Language.
+
+ For the correct display of the multilingual preface in a non-
+ conforming email client, the sender MAY use the Content-Disposition
+ field with a value of 'inline' in conformance with RFC 2183 [RFC2183]
+ (which defines the Content-Disposition field). If provided, this
+ SHOULD be placed at the 'multipart/multilingual' level and in the
+ multilingual preface. This makes it clear to a non-conforming email
+ client that the multilingual preface should be displayed immediately
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 4]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+ to the recipient, followed by any subsequent parts marked as
+ 'inline'.
+
+ For examples of a multilingual preface, see Section 8.
+
+3.2. The Language Message Parts
+
+ The language message parts are typically translations of the same
+ message content. These message parts SHOULD be ordered so that the
+ first part after the multilingual preface is in the language believed
+ to be the most likely to be recognized by the recipient; this will
+ constitute the default part when language negotiation fails and there
+ is no language-independent part. All of the language message parts
+ MUST have a Content-Language field and a Content-Type field; they MAY
+ have a Content-Translation-Type field.
+
+ The Content-Type for each individual language message part SHOULD be
+ 'message/rfc822' to provide good support with non-conforming email
+ clients. However, an implementation MAY use 'message/global' as
+ support for 'message/global' becomes more commonplace. (See RFC 6532
+ [RFC6532] for details of 'message/global'.) Each language message
+ part should have a Subject field in the appropriate language for that
+ language part. If there is a From field present, its value MUST
+ include the same email address as the top-level From header field,
+ although the display name MAY be a localized version. If there is a
+ mismatch of sender email address, the top-level From header field
+ value SHOULD be used to show to the recipient.
+
+3.3. The Language-Independent Message Part
+
+ If there is language-independent content for the recipient to see if
+ they have a preferred language other than one of those specified in
+ the language message parts, and the default language message part is
+ unlikely to be understood, another part MAY be provided. This part
+ could typically include one or more language-independent graphics.
+ When this part is present, it MUST be the last part and MUST have a
+ Content-Language field with a value of "zxx" (as described in BCP 47
+ [RFC5646]). The part SHOULD have a Content-Type of 'message/rfc822'
+ or 'message/global' (to match the language message parts).
+
+
+
+
+
+
+
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 5]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+4. Message Part Selection
+
+ The logic for selecting the message part to render and present to the
+ recipient is summarized in the next few paragraphs.
+
+ If the email client does not understand 'multipart/multilingual',
+ then it will treat the message as if it was 'multipart/mixed' and
+ render message parts accordingly (in accordance with Sections 5.1.3
+ and 5.1.7 of RFC 2046 [RFC2046]).
+
+ If the email client does understand 'multipart/multilingual', then it
+ SHOULD ignore the multilingual preface and select the best match for
+ the user's preferred language from the language message parts
+ available. Also, the user may prefer to see the original message
+ content in their second language over a machine translation in their
+ first language. The Content-Translation-Type field value can be used
+ for further selection based on this preference. The selection of the
+ language part may be implemented in a variety of ways, although the
+ matching schemes detailed in RFC 4647 [RFC4647] are RECOMMENDED as a
+ starting point for an implementation. The goal is to render the most
+ appropriate translation for the user.
+
+ If there is no match for the user's preferred language or there is no
+ preferred language information available, the email client SHOULD
+ select the language-independent part (if one exists) or the first
+ language part directly after the multilingual preface if a language-
+ independent part does not exist.
+
+ If there is no translation type preference information available, the
+ values of the Content-Translation-Type field may be ignored.
+
+ Additionally, interactive implementations MAY offer the user a choice
+ from among the available languages or the option to see them all.
+
+5. The Content-Language Field
+
+ The Content-Language field in the individual language message parts
+ is used to identify the language in which the message part is
+ written. Based on the value of this field, a conforming email client
+ can determine which message part to display (given the user's
+ language settings).
+
+ The Content-Language MUST comply with RFC 3282 [RFC3282] (which
+ defines the Content-Language field) and BCP 47 [RFC5646] (which
+ defines the structure and semantics for the language tag values).
+
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 6]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+ Examples of this field could look like the following:
+
+ Content-Language: en-GB
+
+ Content-Language: de
+
+ Content-Language: es-MX, fr
+
+ Content-Language: sr-Cyrl
+
+6. The Content-Translation-Type Field
+
+ The Content-Translation-Type field can be used in the individual
+ language message parts to identify the type of translation. Based on
+ the value of this field and the user's preferences, a conforming
+ email client can determine which message part to display.
+
+ This field can have one of three possible values: 'original',
+ 'human', or 'automated' (although other values may be added in the
+ future). A value of 'original' is given in the language message part
+ that is in the original language. A value of 'human' is used when a
+ language message part is translated by a human translator or a human
+ has checked and corrected an automated translation. A value of
+ 'automated' is used when a language message part has been translated
+ by an electronic agent without proofreading or subsequent correction.
+ New values of the Content-Translation-Type header field
+ ("translTypeExt" in the ABNF) are added according to the procedure
+ specified in Section 9.3.
+
+ Examples of this field include:
+
+ Content-Translation-Type: original
+
+ Content-Translation-Type: human
+
+ The syntax of the Content-Translation-Type field in ABNF [RFC5234]
+ is:
+
+ Content-Translation-Type = [FWS] translationtype
+
+ FWS = <Defined in RFC 5322>
+ translationtype = "original" / "human" / "automated" /
+ translTypeExt
+ translTypeExt = 1*atext
+ atext = <Defined in RFC 5322>
+
+ This references RFC 5322 [RFC5322] for the predefined rules 'folding
+ white space (FWS)' and 'atext'.
+
+
+
+Tomkinson & Borenstein Standards Track [Page 7]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+7. The Subject Field in the Language Message Parts
+
+ On receipt of the message, conforming email clients will need to
+ render the subject in the correct language for the recipient. To
+ enable this, the Subject field SHOULD be provided in each language
+ message part. The value for this field should be a translation of
+ the email subject.
+
+ US-ASCII and 'encoded-word' examples of this field include:
+
+ Subject: A really simple email subject
+
+ Subject: =?UTF-8?Q?Un_asunto_de_correo_electr=C3=b3nico_
+ realmente_sencillo?=
+
+ See RFC 2047 [RFC2047] for the specification of 'encoded-word'.
+
+ The subject to be presented to the recipient SHOULD be selected from
+ the message part identified during the message part selection stage.
+ If no Subject field is found, the top-level Subject header field
+ value should be used.
+
+8. Examples
+
+8.1. An Example of a Simple Multiple-Language Email Message
+
+ Below is a minimal example of a multiple-language email message. It
+ has the multilingual preface and two language message parts.
+
+ From: Nik@example.com
+ To: Nathaniel@example.com
+ Subject: Example of a message in Spanish and English
+ Date: Thu, 7 Apr 2017 21:28:00 +0100
+ MIME-Version: 1.0
+ Content-Type: multipart/multilingual;
+ boundary="01189998819991197253"
+
+ --01189998819991197253
+ Content-Type: text/plain; charset="UTF-8"
+ Content-Disposition: inline
+ Content-Transfer-Encoding: quoted-printable
+
+ This is a message in multiple languages. It says the
+ same thing in each language. If you can read it in one language,
+ you can ignore the other translations. The other translations may be
+ presented as attachments or grouped together.
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 8]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+ Este es un mensaje en varios idiomas. Dice lo mismo en
+ cada idioma. Si puede leerlo en un idioma, puede ignorar las otras
+ traducciones. Las otras traducciones pueden presentarse como archivos
+ adjuntos o agrupados.
+
+ --01189998819991197253
+ Content-Type: message/rfc822
+ Content-Language: en-GB
+ Content-Translation-Type: original
+ Content-Disposition: inline
+
+ Subject: Example of a message in Spanish and English
+ Content-Type: text/plain; charset="US-ASCII"
+ Content-Transfer-Encoding: 7bit
+ MIME-Version: 1.0
+
+ Hello, this message content is provided in your language.
+
+ --01189998819991197253
+ Content-Type: message/rfc822
+ Content-Language: es
+ Content-Translation-Type: human
+ Content-Disposition: inline
+
+ Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?=
+ =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?=
+ Content-Type: text/plain; charset="US-ASCII"
+ Content-Transfer-Encoding: 7bit
+ MIME-Version: 1.0
+
+ Hola, el contenido de este mensaje esta disponible en su idioma.
+
+ --01189998819991197253--
+
+8.2. An Example of a Multiple-Language Email Message with a Language-
+ Independent Part
+
+ Below is an example of a multiple-language email message that has the
+ multilingual preface followed by two language message parts and then
+ a language-independent png image.
+
+ From: Nik@example.com
+ To: Nathaniel@example.com
+ Subject: Example of a message in Spanish and English
+ Date: Thu, 7 Apr 2017 21:08:00 +0100
+ MIME-Version: 1.0
+ Content-Type: multipart/multilingual;
+ boundary="01189998819991197253"
+
+
+
+Tomkinson & Borenstein Standards Track [Page 9]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+ --01189998819991197253
+ Content-Type: text/plain; charset="UTF-8"
+ Content-Disposition: inline
+ Content-Transfer-Encoding: quoted-printable
+
+ This is a message in multiple languages. It says the
+ same thing in each language. If you can read it in one language,
+ you can ignore the other translations. The other translations may
+ be presented as attachments or grouped together.
+
+ Este es un mensaje en varios idiomas. Dice lo mismo en
+ cada idioma. Si puede leerlo en un idioma, puede ignorar las otras
+ traducciones. Las otras traducciones pueden presentarse como
+ archivos adjuntos o agrupados.
+
+ --01189998819991197253
+ Content-Type: message/rfc822
+ Content-Language: en
+ Content-Translation-Type: original
+ Content-Disposition: inline
+
+ Subject: Example of a message in Spanish and English
+ Content-Type: text/plain; charset="US-ASCII"
+ Content-Transfer-Encoding: 7bit
+ MIME-Version: 1.0
+
+ Hello, this message content is provided in your language.
+
+ --01189998819991197253
+ Content-Type: message/rfc822
+ Content-Language: es-ES
+ Content-Translation-Type: human
+ Content-Disposition: inline
+
+ Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?=
+ =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?=
+ Content-Type: text/plain; charset="US-ASCII"
+ Content-Transfer-Encoding: 7bit
+ MIME-Version: 1.0
+
+ Hola, el contenido de este mensaje esta disponible en su idioma.
+
+
+
+
+
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 10]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+ --01189998819991197253
+ Content-Type: message/rfc822; name="Icon"
+ Content-Language: zxx
+ Content-Disposition: inline
+
+ Content-Type: image/png; name="icon.png"
+ Content-Transfer-Encoding: base64
+
+ iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZ
+ QAASA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr
+ 997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII=
+
+ --01189998819991197253--
+
+8.3. An Example of a Complex Multiple-Language Email Message with a
+ Language-Independent Part
+
+ Below is an example of a more complex multiple-language email
+ message. It has the multilingual preface and two language message
+ parts and then a language-independent png image. The language
+ message parts have 'multipart/alternative' contents and would
+ therefore require further processing to determine the content to
+ display.
+
+ From: Nik@example.com
+ To: Nathaniel@example.com
+ Subject: Example of a message in Spanish and English
+ Date: Thu, 7 Apr 2017 20:55:00 +0100
+ MIME-Version: 1.0
+ Content-Type: multipart/multilingual;
+ boundary="01189998819991197253"
+
+ --01189998819991197253
+ Content-Type: text/plain; charset="UTF-8"
+ Content-Disposition: inline
+ Content-Transfer-Encoding: quoted-printable
+
+ This is a message in multiple languages. It says the
+ same thing in each language. If you can read it in one language,
+ you can ignore the other translations. The other translations may
+ be presented as attachments or grouped together.
+
+ Este es un mensaje en varios idiomas. Dice lo mismo en
+ cada idioma. Si puede leerlo en un idioma, puede ignorar las otras
+ traducciones. Las otras traducciones pueden presentarse como
+ archivos adjuntos o agrupados.
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 11]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+ --01189998819991197253
+ Content-Type: message/rfc822
+ Content-Language: en
+ Content-Translation-Type: original
+ Content-Disposition: inline
+
+ Subject: Example of a message in Spanish and English
+ Content-Type: multipart/alternative;
+ boundary="72530118999911999881"; charset="US-ASCII"
+ Content-Transfer-Encoding: 7bit
+ MIME-Version: 1.0
+
+ --72530118999911999881
+ Content-Type: text/plain; charset="US-ASCII"
+ Content-Transfer-Encoding: 7bit
+
+ Hello, this message content is provided in your language.
+
+ --72530118999911999881
+ Content-Type: text/html; charset="US-ASCII"
+ Content-Transfer-Encoding: 7bit
+
+ <html><body>Hello, this message content is <b>provided</b> in
+ <i>your</i> language.</body></html>
+
+ --72530118999911999881--
+ --01189998819991197253
+ Content-Type: message/rfc822
+ Content-Language: es
+ Content-Translation-Type: human
+ Content-Disposition: inline
+
+ Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?=
+ =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?=
+ Content-Type: multipart/alternative;
+ boundary="53011899989991197281"; charset="US-ASCII"
+ Content-Transfer-Encoding: 7bit
+ MIME-Version: 1.0
+
+ --53011899989991197281
+ Content-Type: text/plain; charset="US-ASCII"
+ Content-Transfer-Encoding: 7bit
+
+ Hola, el contenido de este mensaje esta disponible en su idioma.
+
+
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 12]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+ --53011899989991197281
+ Content-Type: text/html; charset="US-ASCII"
+ Content-Transfer-Encoding: 7bit
+
+ <html><body>Hola, el contenido de este <b>mensaje</b> <i>esta</i>
+ disponible en su idioma.</body></html>
+
+ --53011899989991197281--
+ --01189998819991197253
+ Content-Type: message/rfc822; name="Icon"
+ Content-Language: zxx
+ Content-Disposition: inline
+
+ Content-Type: multipart/mixed;
+ boundary="99911972530118999881"; charset="US-ASCII"
+ Content-Transfer-Encoding: 7bit
+ MIME-Version: 1.0
+
+ --99911972530118999881
+
+ Content-Type: image/png; name="icon.png"
+ Content-Disposition: inline
+ Content-Transfer-Encoding: base64
+
+ iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZ
+ QAASA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr
+ 997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII=
+
+ --99911972530118999881--
+ --01189998819991197253--
+
+9. IANA Considerations
+
+9.1. The 'multipart/multilingual' Media Type
+
+ The 'multipart/multilingual' Media Type has been registered with
+ IANA. This is the registration template based on the template
+ specified in [RFC6838]:
+
+ Media Type name: multipart
+
+ Media subtype name: multilingual
+
+ Required parameters: boundary (defined in RFC 2046)
+
+ Optional parameters: N/A
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 13]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+ Encoding considerations:
+ There are no encoding considerations for this multipart other
+ than that of the embedded body parts. The embedded body parts
+ (typically one 'text/plain' plus one or more 'message/*') may
+ contain 7-bit, 8-bit, or binary encodings.
+
+ Security considerations:
+ See the Security Considerations section in RFC 8255
+
+ Interoperability considerations:
+ Existing systems that do not treat unknown multipart subtypes
+ as 'multipart/mixed' may not correctly render a
+ 'multipart/multilingual' type. These systems would also be non-
+ compliant with MIME.
+
+ Published specification: RFC 8255
+
+ Applications that use this media type:
+ Mail Transfer Agents, Mail User Agents, spam detection,
+ virus detection modules, and message authentication modules.
+
+ Fragment identifier considerations: N/A
+
+ Additional information:
+ Deprecated alias names for this type: N/A
+ Magic number(s): N/A
+ File extension(s): N/A
+ Macintosh file type code(s): N/A
+
+ Person & email address to contact for further information:
+ Nik Tomkinson
+ rfc.nik.tomkinson@gmail.com
+
+ Nathaniel Borenstein
+ nsb@mimecast.com
+
+ Intended usage: COMMON
+
+ Restrictions on usage: N/A
+
+ Author/Change controller: IETF
+
+
+
+
+
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 14]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+9.2. The Content-Translation-Type Field
+
+ The Content-Translation-Type field has been added to the IANA
+ "Permanent Message Header Field Names" registry. That entry
+ references this document. This registration template is below:
+
+ Header field name: Content-Translation-Type
+
+ Applicable protocol: MIME
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+ Specification document(s): RFC 8255
+
+ Related information: none
+
+9.3. The Content-Translation-Type Header Field Values
+
+ IANA has created a new registry titled "Content-Translation-Type
+ Header Field Values". New values must be registered using the
+ "Specification Required" [RFC8126] IANA registration procedure.
+ Registrations must include a translation type value, a short
+ description, and a reference to the specification.
+
+ This document also registers three initial values specified below.
+
+ Value: original
+ Description:
+ Content in the original language
+ Reference: RFC 8255
+
+ Value: human
+ Description:
+ Content that has been translated by a human translator
+ or a human has checked and corrected an automated translation
+ Reference: RFC 8255
+
+ Value: automated
+ Description:
+ Content that has been translated by an electronic agent
+ without proofreading or subsequent correction
+ Reference: RFC 8255
+
+
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 15]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+10. Security Considerations
+
+ Whilst it is intended that each language message part is a direct
+ translation of the original message, this may not always be the case;
+ these parts could contain undesirable content. Therefore, there is a
+ possible risk that undesirable text or images could be shown to the
+ recipient if the message is passed through a spam filter that does
+ not check all of the message parts. The risk should be minimal due
+ to the fact that an unknown multipart subtype should be treated as
+ 'multipart/mixed'; thus, each message part should be subsequently
+ scanned.
+
+ If the email contains undesirable content in a language that the
+ recipient cannot understand and this unknown content is assumed to be
+ a direct translation of the content that the recipient can
+ understand, the recipient may unintentionally forward undesirable
+ content to a recipient that can understand it. To mitigate this
+ risk, an interactive implementation may allow the recipient to see
+ all of the translations for comparison.
+
+ Because the language message parts have a Content-Type of 'message/
+ rfc822' or 'message/global', they might contain From fields that
+ could have different values from that of the top-level From field,
+ and they may not reflect the actual sender. The inconsistent From
+ field values might get shown to the recipient in a non-conforming
+ email client and may mislead the recipient into thinking that the
+ email came from someone other than the real sender.
+
+11. References
+
+11.1. Normative References
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
+ <https://www.rfc-editor.org/info/rfc2045>.
+
+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046,
+ DOI 10.17487/RFC2046, November 1996,
+ <https://www.rfc-editor.org/info/rfc2046>.
+
+ [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
+ Part Three: Message Header Extensions for Non-ASCII Text",
+ RFC 2047, DOI 10.17487/RFC2047, November 1996,
+ <https://www.rfc-editor.org/info/rfc2047>.
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 16]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
+ Presentation Information in Internet Messages: The
+ Content-Disposition Header Field", RFC 2183,
+ DOI 10.17487/RFC2183, August 1997,
+ <https://www.rfc-editor.org/info/rfc2183>.
+
+ [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
+ DOI 10.17487/RFC3282, May 2002,
+ <https://www.rfc-editor.org/info/rfc3282>.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
+ 2003, <https://www.rfc-editor.org/info/rfc3629>.
+
+ [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
+ Extensions (MIME) Part Four: Registration Procedures",
+ BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005,
+ <https://www.rfc-editor.org/info/rfc4289>.
+
+ [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags",
+ BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006,
+ <https://www.rfc-editor.org/info/rfc4647>.
+
+ [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234,
+ DOI 10.17487/RFC5234, January 2008,
+ <https://www.rfc-editor.org/info/rfc5234>.
+
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ DOI 10.17487/RFC5322, October 2008,
+ <https://www.rfc-editor.org/info/rfc5322>.
+
+ [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
+ Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
+ September 2009, <https://www.rfc-editor.org/info/rfc5646>.
+
+ [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
+ Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
+ 2012, <https://www.rfc-editor.org/info/rfc6532>.
+
+
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 17]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+ [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
+ Specifications and Registration Procedures", BCP 13,
+ RFC 6838, DOI 10.17487/RFC6838, January 2013,
+ <https://www.rfc-editor.org/info/rfc6838>.
+
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+11.2. Informative References
+
+ [HUMAN-LANG]
+ Gellens, R., "Negotiating Human Language in Real-Time
+ Communications", Work in Progress, draft-ietf-slim-
+ negotiating-human-language-13, July 2017.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 18]
+
+RFC 8255 Multiple Language Content Type October 2017
+
+
+Acknowledgements
+
+ The authors are grateful for the helpful input received from many
+ people but would especially like to acknowledge the help of Harald
+ Alvestrand, Stephane Bortzmeyer, Eric Burger, Ben Campbell, Mark
+ Davis, Doug Ewell, Ned Freed, Randall Gellens, Gunnar Hellstrom,
+ Mirja Kuehlewind, Barry Leiba, Sean Leonard, John Levine, Alexey
+ Melnikov, Addison Phillips, Julian Reschke, Pete Resnick, Adam Roach,
+ Brian Rosen, Fiona Tomkinson, Simon Tyler, and Daniel Vargha.
+
+ The authors would also like to thank Fernando Alvaro and Luis de
+ Pablo for their work on the Spanish translations.
+
+Authors' Addresses
+
+ Nik Tomkinson
+ Mimecast, Ltd.
+ CityPoint, One Ropemaker Street
+ London EC2Y 9AW
+ United Kingdom
+
+ Email: rfc.nik.tomkinson@gmail.com
+
+
+ Nathaniel Borenstein
+ Mimecast, Ltd.
+ 480 Pleasant Street
+ Watertown, MA 02472
+ United States of America
+
+ Email: nsb@mimecast.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tomkinson & Borenstein Standards Track [Page 19]
+