GENWiki

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"

1. -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.

1. -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.

1. -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.

1. -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

1. -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.

1. -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.

1. -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

1. -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=

1. -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"

1. -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

1. -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

1. -72530118999911999881

Content-Type: text/plain; charset="US-ASCII"

 Content-Transfer-Encoding: 7bit

 Hello, this message content is provided in your language.

1. -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>

1. -72530118999911999881–
2. -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

1. -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

1. -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>

1. -53011899989991197281–
2. -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

1. -99911972530118999881

 Content-Type: image/png; name="icon.png"
 Content-Disposition: inline
 Content-Transfer-Encoding: base64

 iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZ
 QAASA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr
 997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII=

1. -99911972530118999881–
2. -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]