draft-ietf-slim-multilangcontent-14.txt   rfc8255.txt 
IETF N. Tomkinson Internet Engineering Task Force (IETF) N. Tomkinson
Internet-Draft N. Borenstein Request for Comments: 8255 N. Borenstein
Intended status: Standards Track Mimecast Ltd Category: Standards Track Mimecast, Ltd.
Expires: February 19, 2018 August 18, 2017 ISSN: 2070-1721 October 2017
Multiple Language Content Type Multiple Language Content Type
draft-ietf-slim-multilangcontent-14
Abstract Abstract
This document defines the multipart/multilingual content type, which This document defines the 'multipart/multilingual' content type,
is an addition to the Multipurpose Internet Mail Extensions (MIME) which is an addition to the Multipurpose Internet Mail Extensions
standard to make it possible to send one message that contains (MIME) standard. This content type makes it possible to send one
multiple language versions of the same information. The translations message that contains multiple language versions of the same
would be identified by a language tag and selected by the email information. The translations would be identified by a language tag
client based on a user's language settings. and selected by the email client based on a user's language settings.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 19, 2018. 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 Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. The Content-Type Header Field . . . . . . . . . . . . . . . . 3 2. The Content-Type Header Field . . . . . . . . . . . . . . . . 3
3. The Message Parts . . . . . . . . . . . . . . . . . . . . . . 3 3. The Message Parts . . . . . . . . . . . . . . . . . . . . . . 4
3.1. The Multilingual Preface . . . . . . . . . . . . . . . . 4 3.1. The Multilingual Preface . . . . . . . . . . . . . . . . 4
3.2. The Language Message Parts . . . . . . . . . . . . . . . 5 3.2. The Language Message Parts . . . . . . . . . . . . . . . 5
3.3. The Language Independent Message Part . . . . . . . . . . 5 3.3. The Language-Independent Message Part . . . . . . . . . . 5
4. Message Part Selection . . . . . . . . . . . . . . . . . . . 5 4. Message Part Selection . . . . . . . . . . . . . . . . . . . 6
5. The Content-Language Field . . . . . . . . . . . . . . . . . 6 5. The Content-Language Field . . . . . . . . . . . . . . . . . 6
6. The Content-Translation-Type Field . . . . . . . . . . . . . 7 6. The Content-Translation-Type Field . . . . . . . . . . . . . 7
7. The Subject Field in the Language Message parts . . . . . . . 7 7. The Subject Field in the Language Message Parts . . . . . . . 8
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. An Example of a Simple Multiple language email message . 8 8.1. An Example of a Simple Multiple-Language Email Message . 8
8.2. An Example of a Multiple language email message with 8.2. An Example of a Multiple-Language Email Message with a
language independent part . . . . . . . . . . . . . . . . 9 Language-Independent Part . . . . . . . . . . . . . . . . 9
8.3. An Example of a complex Multiple language email message 8.3. An Example of a Complex Multiple-Language Email Message
with language independent part . . . . . . . . . . . . . 11 with a Language-Independent Part . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9.1. The 'multipart/multilingual' Media Type . . . . . . . . . 13
10.1. The multipart/multilingual MIME type . . . . . . . . . . 13 9.2. The Content-Translation-Type Field . . . . . . . . . . . 15
10.2. The Content-Translation-Type Field . . . . . . . . . . . 15 9.3. The Content-Translation-Type Header Field Values . . . . 15
10.3. The Content-Translation-Type Field Values . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Changes from Previous Versions . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . 21 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
13.2. Informational References . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Since the invention of email and the rapid spread of the Internet, 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 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 countries and in more and more languages. But during this time of
technological evolution, email has remained a single-language technological evolution, email has remained a single-language
communication tool, whether it is English to English, Spanish to communication tool, whether it is English to English, Spanish to
Spanish or Japanese to Japanese. Spanish, or Japanese to Japanese.
Also during this time, many corporations have established their Also during this time, many corporations have established their
offices in multi-cultural cities and formed departments and teams offices in multicultural cities and have formed departments and teams
that span continents, cultures and languages, so the need to that span continents, cultures, and languages. Thus, the need to
communicate efficiently with little margin for miscommunication has communicate efficiently with little margin for miscommunication has
grown significantly. grown significantly.
This document defines the multipart/multilingual content type, which This document defines the 'multipart/multilingual' content type,
is an addition to the Multipurpose Internet Mail Extensions (MIME) which is an addition to the Multipurpose Internet Mail Extensions
standard, to make it possible to send a single message to a group of (MIME) standard specified in [RFC2045], [RFC2046], [RFC2047],
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.
Whilst this document depends on identification of language in message [RFC4289], and [RFC6838]. This content type makes it possible to
parts for non-real-time communication, there is a companion document send a single message to a group of people in such a way that all of
that is concerned with a similar problem for real-time communication: the recipients can read the email in their preferred language. The
[I-D.ietf-slim-negotiating-human-language] 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 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "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 2. The Content-Type Header Field
The "multipart/multilingual" MIME subtype allows the sending of a The 'multipart/multilingual' Media Subtype allows the sending of a
message in a number of different languages with the translations message in a number of different languages with the different
embedded in the same message. This MIME subtype helps the receiving language versions embedded in the same message. This Media Subtype
email client make sense of the message structure. helps the receiving email client make sense of the message structure.
The multipart subtype "multipart/multilingual" has similar semantics The multipart subtype 'multipart/multilingual' has similar semantics
to "multipart/alternative" (as discussed in RFC 2046 [RFC2046]) in to 'multipart/alternative' (as discussed in RFC 2046 [RFC2046]) in
that each of the message parts is an alternative version of the same that each of the message parts is an alternative version of the same
information. The primary difference between "multipart/multilingual" information. The primary difference between 'multipart/multilingual'
and "multipart/alternative" is that when using "multipart/ and 'multipart/alternative' is that when using 'multipart/
multilingual", the message part to select for rendering is chosen multilingual', the message part to select for rendering is chosen
based on the values of the Content-Language field and optionally the based on the values of the Content-Language field and optionally the
Content-Translation-Type field instead of the ordering of the parts Content-Translation-Type field instead of the ordering of the parts
and the Content-Types. and the Content-Types.
The syntax for this multipart subtype conforms to the common syntax The syntax for this multipart subtype conforms to the common syntax
for subtypes of multipart given in section 5.1.1. of RFC 2046 for subtypes of multipart given in Section 5.1.1. of RFC 2046
[RFC2046]. An example "multipart/multilingual" Content-Type header [RFC2046]. An example 'multipart/multilingual' Content-Type header
field would look like this: field would look like this:
Content-Type: multipart/multilingual; boundary=01189998819991197253 Content-Type: multipart/multilingual; boundary=01189998819991197253
3. The Message Parts 3. The Message Parts
A multipart/multilingual message will have a number of message parts: A 'multipart/multilingual' message will have a number of message
exactly one multilingual preface, one or more language message parts parts: exactly one multilingual preface, one or more language message
and zero or one language independent message part. The details of parts, and zero or one language-independent message part. The
these are described below. details of these are described below.
3.1. The Multilingual Preface 3.1. The Multilingual Preface
In order for the message to be received and displayed in non- In order for the message to be received and displayed in non-
conforming email clients, the message SHOULD contain an explanatory conforming email clients, the message SHOULD contain an explanatory
message part which MUST NOT be marked with a Content-Language field 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 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 the most basic of non-conforming email clients, it SHOULD have a
Content-Type of text/plain. Because non-conforming email clients are Content-Type of 'text/plain'. Because non-conforming email clients
expected to treat a message with an unknown multipart type as 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 '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 2046 [RFC2046]), they may show all of the message parts sequentially
or as attachments. Including and showing this explanatory part will or as attachments. Including and showing this explanatory part will
help the message recipient understand the message structure. help the message recipient understand the message structure.
This initial message part SHOULD explain briefly to the recipient This initial message part SHOULD briefly explain to the recipient
that the message contains multiple languages and the parts may be that the message contains multiple languages, and the parts may be
rendered sequentially or as attachments. This SHOULD be presented in rendered sequentially or as attachments. This SHOULD be presented in
the same languages that are provided in the subsequent language the same languages that are provided in the subsequent language
message parts. message parts.
As this explanatory section is likely to contain languages using As this explanatory section is likely to contain languages using
scripts that require non-US-ASCII characters, it is RECOMMENDED that scripts that require non-US-ASCII characters, it is RECOMMENDED that
UTF-8 charset is used for this message part. See RFC 3629 [RFC3629] a UTF-8 charset be used for this message part. See RFC 3629
for details of UTF-8. [RFC3629] for details of UTF-8.
Whilst this section of the message is useful for backward Whilst this section of the message is useful for backward
compatibility, it will normally only be shown when rendered by a non- compatibility, it will normally only be shown when rendered by a non-
conforming email client, because conforming email clients SHOULD only conforming email client. This is because conforming email clients
show the single language message part identified by the user's SHOULD only show the single language message part identified by the
preferred language and the language message part's Content-Language. user's preferred language and the language message part's Content-
Language.
For the correct display of the multilingual preface in a non- For the correct display of the multilingual preface in a non-
conforming email client, the sender MAY use the Content-Disposition conforming email client, the sender MAY use the Content-Disposition
field with a value of 'inline' in conformance with RFC 2183 [RFC2183] field with a value of 'inline' in conformance with RFC 2183 [RFC2183]
(which defines the Content-Disposition field). If provided, this (which defines the Content-Disposition field). If provided, this
SHOULD be placed at the multipart/multilingual level and in the SHOULD be placed at the 'multipart/multilingual' level and in the
multilingual preface. This makes it clear to a non-conforming email multilingual preface. This makes it clear to a non-conforming email
client that the multilingual preface should be displayed immediately client that the multilingual preface should be displayed immediately
to the recipient, followed by any subsequent parts marked as to the recipient, followed by any subsequent parts marked as
'inline'. 'inline'.
For an example of a multilingual preface, see the examples in For examples of a multilingual preface, see Section 8.
Section 8.
3.2. The Language Message Parts 3.2. The Language Message Parts
The language message parts are typically translations of the same The language message parts are typically translations of the same
message content. These message parts SHOULD be ordered so that the message content. These message parts SHOULD be ordered so that the
first part after the multilingual preface is in the language believed first part after the multilingual preface is in the language believed
to be the most likely to be recognised by the recipient as this will to be the most likely to be recognized by the recipient; this will
constitute the default part when language negotiation fails and there constitute the default part when language negotiation fails and there
is no Language Independent part. All of the language message parts is no language-independent part. All of the language message parts
MUST have a Content-Language field and a Content-Type field and MAY MUST have a Content-Language field and a Content-Type field; they MAY
have a Content-Translation-Type field. have a Content-Translation-Type field.
The Content-Type for each individual language message part SHOULD be The Content-Type for each individual language message part SHOULD be
message/rfc822 to provide good support with non-conforming email 'message/rfc822' to provide good support with non-conforming email
clients. However, an implementation MAY use message/global as clients. However, an implementation MAY use 'message/global' as
support for message/global becomes more commonplace. See RFC 6532 support for 'message/global' becomes more commonplace. (See RFC 6532
[RFC6532] for details of message/global. Each language message part [RFC6532] for details of 'message/global'.) Each language message
should have a Subject field in the appropriate language for that part should have a Subject field in the appropriate language for that
language part. If there is a From field present, its value MUST language part. If there is a From field present, its value MUST
include the same email address as the top-level From header although include the same email address as the top-level From header field,
the display name MAY be a localised version. If there is a mismatch although the display name MAY be a localized version. If there is a
of sender email address, the top-level From header value SHOULD be mismatch of sender email address, the top-level From header field
used to show to the recipient. value SHOULD be used to show to the recipient.
3.3. The Language Independent Message Part 3.3. The Language-Independent Message Part
If there is language independent content for the recipient to see if If there is language-independent content for the recipient to see if
they have a preferred language other than one of those specified in they have a preferred language other than one of those specified in
the language message parts and the default language message part is the language message parts, and the default language message part is
unlikely to be understood, another part MAY be provided. This part unlikely to be understood, another part MAY be provided. This part
could typically include one or more language independent graphics. could typically include one or more language-independent graphics.
When this part is present, it MUST be the last part and MUST have a 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/ Content-Language field with a value of "zxx" (as described in BCP 47
RFC 5646 [RFC5646]). The part SHOULD have a Content-Type of message/ [RFC5646]). The part SHOULD have a Content-Type of 'message/rfc822'
rfc822 or message/global (to match the language message parts). or 'message/global' (to match the language message parts).
4. Message Part Selection 4. Message Part Selection
The logic for selecting the message part to render and present to the The logic for selecting the message part to render and present to the
recipient is summarised in the next few paragraphs. recipient is summarized in the next few paragraphs.
Firstly, if the email client does not understand multipart/ If the email client does not understand 'multipart/multilingual',
multilingual then it will treat the message as if it was multipart/ then it will treat the message as if it was 'multipart/mixed' and
mixed and render message parts accordingly (in accordance with render message parts accordingly (in accordance with Sections 5.1.3
sections 5.1.3 and 5.1.7 of RFC 2046 [RFC2046]). and 5.1.7 of RFC 2046 [RFC2046]).
If the email client does understand multipart/multilingual then it If the email client does understand 'multipart/multilingual', then it
SHOULD ignore the multilingual preface and select the best match for SHOULD ignore the multilingual preface and select the best match for
the user's preferred language from the language message parts the user's preferred language from the language message parts
available. Also, the user may prefer to see the original message available. Also, the user may prefer to see the original message
content in their second language over a machine translation in their content in their second language over a machine translation in their
first language. The Content-Translation-Type field value can be used first language. The Content-Translation-Type field value can be used
for further selection based on this preference. The selection of for further selection based on this preference. The selection of the
language part may be implemented in a variety of ways, although the language part may be implemented in a variety of ways, although the
matching schemes detailed in RFC 4647 [RFC4647] are RECOMMENDED as a matching schemes detailed in RFC 4647 [RFC4647] are RECOMMENDED as a
starting point for an implementation. The goal is to render the most starting point for an implementation. The goal is to render the most
appropriate translation for the user. appropriate translation for the user.
If there is no match for the user's preferred language (or there is If there is no match for the user's preferred language or there is no
no preferred language information available) the email client SHOULD preferred language information available, the email client SHOULD
select the language independent part (if one exists) or the first select the language-independent part (if one exists) or the first
language part (directly after the multilingual preface) if a language language part directly after the multilingual preface if a language-
independent part does not exist. independent part does not exist.
If there is no translation type preference information available, the If there is no translation type preference information available, the
values of the Content-Translation-Type field may be ignored. values of the Content-Translation-Type field may be ignored.
Additionally, interactive implementations MAY offer the user a choice Additionally, interactive implementations MAY offer the user a choice
from among the available languages or the option to see them all. from among the available languages or the option to see them all.
5. The Content-Language Field 5. The Content-Language Field
The Content-Language field in the individual language message parts The Content-Language field in the individual language message parts
is used to identify the language in which the message part is is used to identify the language in which the message part is
written. Based on the value of this field, a conforming email client written. Based on the value of this field, a conforming email client
can determine which message part to display (given the user's can determine which message part to display (given the user's
language settings). language settings).
The Content-Language MUST comply with RFC 3282 [RFC3282] (which The Content-Language MUST comply with RFC 3282 [RFC3282] (which
defines the Content-Language field) and BCP 47/RFC 5646 [RFC5646] defines the Content-Language field) and BCP 47 [RFC5646] (which
(which defines the structure and semantics for the language tag defines the structure and semantics for the language tag values).
values).
Examples of this field could look like the following: Examples of this field could look like the following:
Content-Language: en-GB Content-Language: en-GB
Content-Language: de Content-Language: de
Content-Language: es-MX, fr Content-Language: es-MX, fr
Content-Language: sr-Cyrl Content-Language: sr-Cyrl
6. The Content-Translation-Type Field 6. The Content-Translation-Type Field
The Content-Translation-Type field can be used in the individual The Content-Translation-Type field can be used in the individual
language message parts to identify the type of translation. Based on language message parts to identify the type of translation. Based on
the value of this parameter and the user's preferences, a conforming the value of this field and the user's preferences, a conforming
email client can determine which message part to display. email client can determine which message part to display.
This field can have one of three possible values: 'original', 'human' This field can have one of three possible values: 'original',
or 'automated' although other values may be added in the future. A 'human', or 'automated' (although other values may be added in the
value of 'original' is given in the language message part that is in future). A value of 'original' is given in the language message part
the original language. A value of 'human' is used when a language that is in the original language. A value of 'human' is used when a
message part is translated by a human translator or a human has language message part is translated by a human translator or a human
checked and corrected an automated translation. A value of has checked and corrected an automated translation. A value of
'automated' is used when a language message part has been translated 'automated' is used when a language message part has been translated
by an electronic agent without proofreading or subsequent correction. by an electronic agent without proofreading or subsequent correction.
New values of the Content-Translation-Type header field New values of the Content-Translation-Type header field
("translTypeExt" in the ABNF) are added according to procedure ("translTypeExt" in the ABNF) are added according to the procedure
specified in Section 10.3. specified in Section 9.3.
Examples of this field include: Examples of this field include:
Content-Translation-Type: original Content-Translation-Type: original
Content-Translation-Type: human Content-Translation-Type: human
The syntax of the Content-Translation-Type field in ABNF RFC 5234 The syntax of the Content-Translation-Type field in ABNF [RFC5234]
[RFC5234] is: is:
Content-Translation-Type = [FWS] translationtype Content-Translation-Type = [FWS] translationtype
FWS = <Defined in RFC 5322> FWS = <Defined in RFC 5322>
translationtype = "original" / "human" / "automated" / translationtype = "original" / "human" / "automated" /
translTypeExt translTypeExt
translTypeExt = 1*atext translTypeExt = 1*atext
atext = <Defined in RFC 5322> atext = <Defined in RFC 5322>
This references RFC 5322 [RFC5322] for the pre-defined rules FWS and This references RFC 5322 [RFC5322] for the predefined rules 'folding
atext. white space (FWS)' and 'atext'.
7. The Subject Field in the Language Message parts 7. The Subject Field in the Language Message Parts
On receipt of the message, conforming email clients will need to On receipt of the message, conforming email clients will need to
render the subject in the correct language for the recipient. To render the subject in the correct language for the recipient. To
enable this the Subject field SHOULD be provided in each language enable this, the Subject field SHOULD be provided in each language
message part. The value for this field should be a translation of message part. The value for this field should be a translation of
the email subject. the email subject.
US-ASCII and 'encoded-word' examples of this field include: US-ASCII and 'encoded-word' examples of this field include:
Subject: A really simple email subject Subject: A really simple email subject
Subject: =?UTF-8?Q?Un_asunto_de_correo_electr=C3=b3nico_ Subject: =?UTF-8?Q?Un_asunto_de_correo_electr=C3=b3nico_
realmente_sencillo?= realmente_sencillo?=
See RFC 2047 [RFC2047] for the specification of 'encoded-word'. See RFC 2047 [RFC2047] for the specification of 'encoded-word'.
The subject to be presented to the recipient SHOULD be selected from The subject to be presented to the recipient SHOULD be selected from
the message part identified during the message part selection stage. the message part identified during the message part selection stage.
If no Subject field is found the top-level Subject header field value If no Subject field is found, the top-level Subject header field
should be used. value should be used.
8. Examples 8. Examples
8.1. An Example of a Simple Multiple language email message 8.1. An Example of a Simple Multiple-Language Email Message
Below is a minimal example of a multiple language email message. It Below is a minimal example of a multiple-language email message. It
has the multilingual preface and two language message parts. has the multilingual preface and two language message parts.
From: Nik@example.com From: Nik@example.com
To: Nathaniel@example.com To: Nathaniel@example.com
Subject: Example of a message in Spanish and English Subject: Example of a message in Spanish and English
Date: Thu, 7 Apr 2017 21:28:00 +0100 Date: Thu, 7 Apr 2017 21:28:00 +0100
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/multilingual; Content-Type: multipart/multilingual;
boundary="01189998819991197253" boundary="01189998819991197253"
skipping to change at page 9, line 15 skipping to change at page 9, line 25
Subject: Example of a message in Spanish and English Subject: Example of a message in Spanish and English
Content-Type: text/plain; charset="US-ASCII" Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 MIME-Version: 1.0
Hello, this message content is provided in your language. Hello, this message content is provided in your language.
--01189998819991197253 --01189998819991197253
Content-Type: message/rfc822 Content-Type: message/rfc822
Content-Language: es-ES Content-Language: es
Content-Translation-Type: human Content-Translation-Type: human
Content-Disposition: inline Content-Disposition: inline
Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?= Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?=
=?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?= =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?=
Content-Type: text/plain; charset="US-ASCII" Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 MIME-Version: 1.0
Hola, el contenido de este mensaje esta disponible en su idioma. Hola, el contenido de este mensaje esta disponible en su idioma.
--01189998819991197253-- --01189998819991197253--
8.2. An Example of a Multiple language email message with language 8.2. An Example of a Multiple-Language Email Message with a Language-
independent part Independent Part
Below is an example of a multiple language email message that has the Below is an example of a multiple-language email message that has the
multilingual preface followed by two language message parts and then multilingual preface followed by two language message parts and then
a language independent png image. a language-independent png image.
From: Nik@example.com From: Nik@example.com
To: Nathaniel@example.com To: Nathaniel@example.com
Subject: Example of a message in Spanish and English Subject: Example of a message in Spanish and English
Date: Thu, 7 Apr 2017 21:08:00 +0100 Date: Thu, 7 Apr 2017 21:08:00 +0100
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/multilingual; Content-Type: multipart/multilingual;
boundary="01189998819991197253" boundary="01189998819991197253"
Content-Type: text/plain; charset="UTF-8" --01189998819991197253
Content-Disposition: inline Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
This is a message in multiple languages. It says the This is a message in multiple languages. It says the
same thing in each language. If you can read it in one language, same thing in each language. If you can read it in one language,
you can ignore the other translations. The other translations may be you can ignore the other translations. The other translations may
presented as attachments or grouped together. be presented as attachments or grouped together.
Este es un mensaje en varios idiomas. Dice lo mismo en Este es un mensaje en varios idiomas. Dice lo mismo en
cada idioma. Si puede leerlo en un idioma, puede ignorar las otras cada idioma. Si puede leerlo en un idioma, puede ignorar las otras
traducciones. Las otras traducciones pueden presentarse como archivos traducciones. Las otras traducciones pueden presentarse como
adjuntos o agrupados. archivos adjuntos o agrupados.
Content-Type: message/rfc822 --01189998819991197253
Content-Language: en-GB Content-Type: message/rfc822
Content-Translation-Type: original Content-Language: en
Content-Disposition: inline Content-Translation-Type: original
Content-Disposition: inline
Subject: Example of a message in Spanish and English Subject: Example of a message in Spanish and English
Content-Type: text/plain; charset="US-ASCII" Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 MIME-Version: 1.0
Hello, this message content is provided in your language. Hello, this message content is provided in your language.
Content-Type: message/rfc822 --01189998819991197253
Content-Language: es-ES Content-Type: message/rfc822
Content-Translation-Type: human Content-Language: es-ES
Content-Disposition: inline Content-Translation-Type: human
Content-Disposition: inline
Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?= Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?=
=?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?= =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?=
Content-Type: text/plain; charset="US-ASCII" Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 MIME-Version: 1.0
Hola, el contenido de este mensaje esta disponible en su idioma. Hola, el contenido de este mensaje esta disponible en su idioma.
Content-Type: message/rfc822; name="Icon" --01189998819991197253
Content-Language: zxx Content-Type: message/rfc822; name="Icon"
Content-Disposition: inline Content-Language: zxx
Content-Disposition: inline
Content-Type: image/png; name="icon.png" Content-Type: image/png; name="icon.png"
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZQAA iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZ
SA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr QAASA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr
997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII= 997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII=
8.3. An Example of a complex Multiple language email message with --01189998819991197253--
language independent part
Below is an example of a more complex multiple language email 8.3. An Example of a Complex Multiple-Language Email Message with a
message. It has the multilingual preface and two language message Language-Independent Part
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 Below is an example of a more complex multiple-language email
To: Nathaniel@example.com message. It has the multilingual preface and two language message
Subject: Example of a message in Spanish and English parts and then a language-independent png image. The language
Date: Thu, 7 Apr 2017 20:55:00 +0100 message parts have 'multipart/alternative' contents and would
MIME-Version: 1.0 therefore require further processing to determine the content to
Content-Type: multipart/multilingual; display.
boundary="01189998819991197253"
Content-Type: text/plain; charset="UTF-8" From: Nik@example.com
Content-Disposition: inline To: Nathaniel@example.com
Content-Transfer-Encoding: quoted-printable 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"
This is a message in multiple languages. It says the --01189998819991197253
same thing in each language. If you can read it in one language, Content-Type: text/plain; charset="UTF-8"
you can ignore the other translations. The other translations may be Content-Disposition: inline
presented as attachments or grouped together. Content-Transfer-Encoding: quoted-printable
Este es un mensaje en varios idiomas. Dice lo mismo en This is a message in multiple languages. It says the
cada idioma. Si puede leerlo en un idioma, puede ignorar las otras same thing in each language. If you can read it in one language,
traducciones. Las otras traducciones pueden presentarse como archivos you can ignore the other translations. The other translations may
adjuntos o agrupados. be presented as attachments or grouped together.
Content-Type: message/rfc822 Este es un mensaje en varios idiomas. Dice lo mismo en
Content-Language: en-GB cada idioma. Si puede leerlo en un idioma, puede ignorar las otras
Content-Translation-Type: original traducciones. Las otras traducciones pueden presentarse como
Content-Disposition: inline archivos adjuntos o agrupados.
Subject: Example of a message in Spanish and English --01189998819991197253
Content-Type: multipart/alternative; Content-Type: message/rfc822
boundary="72530118999911999881"; charset="US-ASCII" Content-Language: en
Content-Transfer-Encoding: 7bit Content-Translation-Type: original
MIME-Version: 1.0 Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII" Subject: Example of a message in Spanish and English
Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative;
Hello, this message content is provided in your language. boundary="72530118999911999881"; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Content-Type: text/html; charset="US-ASCII" --72530118999911999881
Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
<html><body>Hello, this message content is <b>provided</b> in Hello, this message content is provided in your language.
<i>your</i> language.</body></html>
Content-Type: message/rfc822 --72530118999911999881
Content-Language: es-ES Content-Type: text/html; charset="US-ASCII"
Content-Translation-Type: human Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?= <html><body>Hello, this message content is <b>provided</b> in
=?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?= <i>your</i> language.</body></html>
Content-Type: multipart/alternative;
boundary="53011899989991197281"; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII" --72530118999911999881--
Content-Transfer-Encoding: 7bit --01189998819991197253
Content-Type: message/rfc822
Content-Language: es
Content-Translation-Type: human
Content-Disposition: inline
Hola, el contenido de este mensaje esta disponible en su idioma. 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
Content-Type: text/html; charset="US-ASCII" --53011899989991197281
Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
<html><body>Hola, el contenido de este <b>mensaje</b> <i>esta</i> Hola, el contenido de este mensaje esta disponible en su idioma.
disponible en su idioma.</body></html>
Content-Type: message/rfc822; name="Icon" --53011899989991197281
Content-Language: zxx Content-Type: text/html; charset="US-ASCII"
Content-Disposition: inline Content-Transfer-Encoding: 7bit
Content-Type: multipart/mixed; <html><body>Hola, el contenido de este <b>mensaje</b> <i>esta</i>
boundary="99911972530118999881"; charset="US-ASCII" disponible en su idioma.</body></html>
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Content-Type: image/png; name="icon.png" --53011899989991197281--
Content-Disposition: inline --01189998819991197253
Content-Transfer-Encoding: base64 Content-Type: message/rfc822; name="Icon"
Content-Language: zxx
Content-Disposition: inline
iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZQAA Content-Type: multipart/mixed;
SA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr boundary="99911972530118999881"; charset="US-ASCII"
997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII= Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
--99911972530118999881
9. Acknowledgements Content-Type: image/png; name="icon.png"
Content-Disposition: inline
Content-Transfer-Encoding: base64
The authors are grateful for the helpful input received from many iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZ
people but would especially like to acknowledge the help of Harald QAASA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr
Alvestrand, Stephane Bortzmeyer, Eric Burger, Ben Campbell, Mark 997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII=
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 --99911972530118999881--
Pablo for their work on the Spanish translations. --01189998819991197253--
10. IANA Considerations 9. IANA Considerations
10.1. The multipart/multilingual MIME type 9.1. The 'multipart/multilingual' Media Type
The multipart/multilingual MIME type will be registered with IANA The 'multipart/multilingual' Media Type has been registered with
including a reference to this document. This is the registration IANA. This is the registration template based on the template
template: specified in [RFC6838]:
Media Type name: multipart Media Type name: multipart
Media subtype name: multilingual Media subtype name: multilingual
Required parameters: boundary (defined in RFC2046) Required parameters: boundary (defined in RFC 2046)
Optional parameters: N/A Optional parameters: N/A
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.
Encoding considerations: There are no encoding considerations for Security considerations:
this multipart other than that of the embedded body parts. See the Security Considerations section in RFC 8255
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 XXXX
Interoperability considerations: Interoperability considerations:
Existing systems that do not treat unknown multipart subtypes Existing systems that do not treat unknown multipart subtypes
as multipart/mixed may not correctly render a as 'multipart/mixed' may not correctly render a
multipart/multilingual type. These systems would also be non- 'multipart/multilingual' type. These systems would also be non-
compliant with MIME. compliant with MIME.
Author/Change controller: IETF
Published specification: RFC XXXX Published specification: RFC 8255
Applications that use this media type: Applications that use this media type:
Mail Transfer Agents, Mail User Agents, spam detection, Mail Transfer Agents, Mail User Agents, spam detection,
virus detection modules and message authentication modules. virus detection modules, and message authentication modules.
Fragment identifier considerations: N/A
Additional information: Additional information:
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
File extension(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person & email address to contact for further information: Person & email address to contact for further information:
Nik Tomkinson Nik Tomkinson
rfc.nik.tomkinson@gmail.com rfc.nik.tomkinson@gmail.com
Nathaniel Borenstein Nathaniel Borenstein
nsb@mimecast.com nsb@mimecast.com
Intended usage: Common Intended usage: COMMON
10.2. The Content-Translation-Type Field Restrictions on usage: N/A
The Content-Translation-Type field will be added to the IANA Author/Change controller: IETF
"Permanent Message Header Field Names" registry. That entry will
reference this document. This is the registration template: 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 Header field name: Content-Translation-Type
Applicable protocol: mime Applicable protocol: MIME
Status: Standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): RFC XXXX Specification document(s): RFC 8255
Related information: none Related information: none
10.3. The Content-Translation-Type Field Values 9.3. The Content-Translation-Type Header Field Values
IANA is requested to create a new registry for Content-Translation- IANA has created a new registry titled "Content-Translation-Type
Type Header Field values. New values must be registered using Header Field Values". New values must be registered using the
"Specification Required" IANA registration procedure. Registrations "Specification Required" [RFC8126] IANA registration procedure.
must include translation type value, short description and a URI of Registrations must include a translation type value, a short
the specification. description, and a reference to the specification.
This document also registers 3 initial values specified below. This document also registers three initial values specified below.
Value: original Value: original
Description: Description:
Content in the original language Content in the original language
Reference: RFC XXXX Reference: RFC 8255
Value: human Value: human
Description: Description:
Content that has been translated by a human translator Content that has been translated by a human translator
or a human has checked and corrected an automated translation or a human has checked and corrected an automated translation
Reference: RFC XXXX Reference: RFC 8255
Value: automated Value: automated
Description: Description:
Content that has been translated by an electronic agent Content that has been translated by an electronic agent
without proofreading or subsequent correction without proofreading or subsequent correction
Reference: RFC XXXX Reference: RFC 8255
11. Security Considerations 10. Security Considerations
Whilst it is intended that each language message part is a direct Whilst it is intended that each language message part is a direct
translation of the original message, this may not always be the case translation of the original message, this may not always be the case;
and these parts could contain undesirable content. Therefore there these parts could contain undesirable content. Therefore, there is a
is a possible risk that undesirable text or images could be shown to possible risk that undesirable text or images could be shown to the
the recipient if the message is passed through a spam filter that recipient if the message is passed through a spam filter that does
does not check all of the message parts. The risk should be minimal not check all of the message parts. The risk should be minimal due
due to the fact that an unknown multipart subtype should be treated to the fact that an unknown multipart subtype should be treated as
as multipart/mixed and so each message part should be subsequently 'multipart/mixed'; thus, each message part should be subsequently
scanned. scanned.
If the email contains undesirable content in a language that the If the email contains undesirable content in a language that the
recipient cannot understand and this unknown content is assumed to be recipient cannot understand and this unknown content is assumed to be
a direct translation of the content that the recipient can a direct translation of the content that the recipient can
understand, the recipient may unintentionally forward undesirable understand, the recipient may unintentionally forward undesirable
content to a recipient that can understand it. To mitigate this content to a recipient that can understand it. To mitigate this
risk, an interactive implementation may allow the recipient to see risk, an interactive implementation may allow the recipient to see
all of the translations for comparison. all of the translations for comparison.
Because the language message parts have a Content-Type of message/ Because the language message parts have a Content-Type of 'message/
rfc822 or message/global, they might contain From fields which could rfc822' or 'message/global', they might contain From fields that
have different values to that of the top-level From field and may not could have different values from that of the top-level From field,
reflect the actual sender. The inconsistent From field values might and they may not reflect the actual sender. The inconsistent From
get shown to the recipient in a non-conforming email client and may field values might get shown to the recipient in a non-conforming
mislead the recipient into thinking that the email came from someone email client and may mislead the recipient into thinking that the
other than the real sender. email came from someone other than the real sender.
12. Changes from Previous Versions
12.1. Changes from draft-tomkinson-multilangcontent-01 to draft-
tomkinson-slim-multilangcontent-00
o File name and version number changed to reflect the proposed WG
name SLIM (Selection of Language for Internet Media).
o Replaced the Subject-Translation field in the language message
parts with Subject and provided US-ASCII and non-US-ASCII
examples.
o Introduced the language-independent message part.
o Many wording improvements and clarifications throughout the
document.
12.2. Changes from draft-tomkinson-slim-multilangcontent-00 to draft-
tomkinson-slim-multilangcontent-01
o Added Translation-Type in each language message part to identify
the source of the translation (original/human/automated).
12.3. Changes from draft-tomkinson-slim-multilangcontent-01 to draft-
tomkinson-slim-multilangcontent-02
o Changed Translation-Type to be a parameter for the Content-
Language field rather than a new separate field.
o Added a paragraph about using Content-Disposition field to help
non-conforming mail clients correctly render the multilingual
preface.
o Recommended using a Name parameter on the language part Content-
Type to help the recipient identify the translations in non-
conforming mail clients.
o Many wording improvements and clarifications throughout the
document.
12.4. Changes from draft-tomkinson-slim-multilangcontent-02 to draft-
ietf-slim-multilangcontent-00
o Name change to reflect the draft being accepted into SLIM as a
working group document.
o Updated examples to use UTF-8 encoding where required.
o Removed references to 'locale' for identifying language
preference.
o Recommended language matching schemes from RFC 4647 [RFC4647].
o Renamed the unmatched part to language independent part to
reinforce its intended purpose.
o Added requirement for using Content-Language: zxx in the language
independent part.
o Many wording improvements and clarifications throughout the
document.
12.5. Changes from draft-ietf-slim-multilangcontent-00 to draft-ietf-
slim-multilangcontent-01
o Changed the inner content type to require message/rfc822 or
message/global.
o Updated the examples to reflect the new inner content types.
o Added to the security considerations to highlight the risk from
insufficient spam filters.
12.6. Changes from draft-ietf-slim-multilangcontent-01 to draft-ietf-
slim-multilangcontent-02
o Restricted the use of a From field in the language message parts
and the language independent part.
o Updated the security considerations to highlight the risk of an
unmatched sender addresses that could be set in the language
message parts.
12.7. Changes from draft-ietf-slim-multilangcontent-02 to draft-ietf-
slim-multilangcontent-03
o Relaxed the restriction on the use of the From field in the
language message parts to allow a localised version of the
sender's display name.
12.8. Changes from draft-ietf-slim-multilangcontent-03 to draft-ietf-
slim-multilangcontent-04
o Updated the wording of the security considerations section to
reflect the relaxation of the use of the From field in the
language message parts.
12.9. Changes from draft-ietf-slim-multilangcontent-04 to draft-ietf-
slim-multilangcontent-05
o Referenced the RFC for message/global in Language Message Parts
section.
o Removed RFC 2119 keyword in the Message Part Selection section.
o Included full email addresses in all examples.
o Updated reference name of real-time companion document in the
Introduction.
o Removed paragraph warning of over use of language sub-tags.
o Changed 'exponential' to 'significantly' in Introduction.
12.10. Changes from draft-ietf-slim-multilangcontent-05 to draft-ietf-
slim-multilangcontent-06
o Changed parameter Translation-Type back to a new field to reduce
the risk of breaking existing implementations that don't expect
any parameters on Content-Language.
o Improved the IANA Considerations section to include the full
registration template for the multipart/multilingual type and the
new Translation-Type field.
12.11. Changes from draft-ietf-slim-multilangcontent-06 to draft-ietf-
slim-multilangcontent-07
o Updated the Encoding Considerations in the IANA Registration
Template.
12.12. Changes from draft-ietf-slim-multilangcontent-07 to draft-ietf-
slim-multilangcontent-08
o Reordered the sections to make the Security Considerations easier
to find.
o Shortened a line in one of the examples that was longer than 72
characters.
o Updated the link to the real-time companion document to the latest
version.
12.13. Changes from draft-ietf-slim-multilangcontent-08 to draft-ietf-
slim-multilangcontent-09
o Removed the phrase "and SHOULD NOT have a Subject field and SHOULD
NOT have a From field" in section 3.3 because the language
independent part would be message/rfc822 or message/global so it
is likely to have From and Subject fields.
o For the same reason as above, the phrase "(for example if the
language independent part is selected)" was removed from section
7.
o Phrase in part 3.3 was reworded from "This could typically be a
language independent graphic" to "This could typically include a
language independent graphic".
12.14. Changes from draft-ietf-slim-multilangcontent-09 to draft-ietf-
slim-multilangcontent-10
o Added Normative Reference to RFC 3629 for details of UTF-8 in the
Multilingual Preface section.
o Added ABNF for Translation-Type field.
o Updated example 2 to contain a image/png language independent
image directly rather than it being nested inside multipart/mixed
content.
o Inserted Change Controller into IANA template for multipart/
multilingual.
o Replaced references to "This document" with RFC XXXX in the IANA
considerations.
12.15. Changes from draft-ietf-slim-multilangcontent-10 to draft-ietf-
slim-multilangcontent-11
o Updated the applicable protocol for the Translation-Type field in
the IANA registration template to be 'mime' rather than 'mail'.
o Added that updated specification documents would be the source of
new values for the Translation-Type field.
12.16. Changes from draft-ietf-slim-multilangcontent-11 to draft-ietf-
slim-multilangcontent-12
o Updated the ABNF for Translation-Type to allow for future values.
o Added section 10.3 to explain about the Translation-Type values
and providing new values.
12.17. Changes from draft-ietf-slim-multilangcontent-12 to draft-ietf-
slim-multilangcontent-13
o Changed the field name Translation-Type to Content-Translation-
Type.
o Explicitly specified the 3 initial values for Content-Translation-
Type in the IANA Considerations section.
12.18. Changes from draft-ietf-slim-multilangcontent-13 to draft-ietf-
slim-multilangcontent-14
o Added table of contents.
o Added notes about the risk of unwittingly forwarding undesirable
content to the Security Considerations section.
o Updated 'language code' to 'language tag' in section 5 to make it
clear that language tag values including country codes and script
codes are allowed.
o Updated the examples to use language tag values that include a
country code.
o Added a note into section 3.2 to specify what should happen if
mismatched sender addresses are found in the language parts.
o Many wording improvements and clarifications throughout the 11. References
document.
13. References 11.1. Normative References
13.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 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
<http://www.rfc-editor.org/info/rfc2046>. <https://www.rfc-editor.org/info/rfc2046>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, DOI 10.17487/RFC2047, November 1996, RFC 2047, DOI 10.17487/RFC2047, November 1996,
<http://www.rfc-editor.org/info/rfc2047>. <https://www.rfc-editor.org/info/rfc2047>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
Presentation Information in Internet Messages: The Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, Content-Disposition Header Field", RFC 2183,
DOI 10.17487/RFC2183, August 1997, DOI 10.17487/RFC2183, August 1997,
<http://www.rfc-editor.org/info/rfc2183>. <https://www.rfc-editor.org/info/rfc2183>.
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
DOI 10.17487/RFC3282, May 2002, DOI 10.17487/RFC3282, May 2002,
<http://www.rfc-editor.org/info/rfc3282>. <https://www.rfc-editor.org/info/rfc3282>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 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", [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags",
BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006, BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006,
<http://www.rfc-editor.org/info/rfc4647>. <https://www.rfc-editor.org/info/rfc4647>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, <https://www.rfc- DOI 10.17487/RFC5234, January 2008,
editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, <https://www.rfc- DOI 10.17487/RFC5322, October 2008,
editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <http://www.rfc-editor.org/info/rfc6532>. 2012, <https://www.rfc-editor.org/info/rfc6532>.
13.2. Informational References [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>.
[I-D.ietf-slim-negotiating-human-language] [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 Gellens, R., "Negotiating Human Language in Real-Time
Communications", draft-ietf-slim-negotiating-human- Communications", Work in Progress, draft-ietf-slim-
language-13 (work in progress), July 2017. negotiating-human-language-13, July 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 Authors' Addresses
Nik Tomkinson Nik Tomkinson
Mimecast Ltd Mimecast, Ltd.
CityPoint, One Ropemaker Street CityPoint, One Ropemaker Street
London EC2Y 9AW London EC2Y 9AW
United Kingdom United Kingdom
Email: rfc.nik.tomkinson@gmail.com Email: rfc.nik.tomkinson@gmail.com
Nathaniel Borenstein Nathaniel Borenstein
Mimecast Ltd Mimecast, Ltd.
480 Pleasant Street 480 Pleasant Street
Watertown MA 02472 Watertown, MA 02472
North America United States of America
Email: nsb@mimecast.com Email: nsb@mimecast.com
 End of changes. 139 change blocks. 
572 lines changed or deleted 397 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/