draft-ietf-slim-multilangcontent-04.txt   draft-ietf-slim-multilangcontent-05.txt 
IETF N. Tomkinson IETF N. Tomkinson
Internet-Draft N. Borenstein Internet-Draft N. Borenstein
Intended status: Standards Track Mimecast Ltd Intended status: Standards Track Mimecast Ltd
Expires: January 26, 2017 July 25, 2016 Expires: February 18, 2017 August 17, 2016
Multiple Language Content Type Multiple Language Content Type
draft-ietf-slim-multilangcontent-04 draft-ietf-slim-multilangcontent-05
Abstract Abstract
This document defines an addition to the Multipurpose Internet Mail This document defines an addition to the Multipurpose Internet Mail
Extensions (MIME) standard to make it possible to send one message Extensions (MIME) standard to make it possible to send one message
that contains multiple language versions of the same information. that contains multiple language versions of the same information.
The translations would be identified by a language tag and selected The translations would be identified by a language tag and selected
by the email client based on a user's language settings. by the email client based on a user's language settings.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 26, 2017. This Internet-Draft will expire on February 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 multi-cultural cities and formed departments and teams
that span continents, cultures and languages, so the need to that span continents, cultures and languages, so the need to
communicate efficiently with little margin for miscommunication has communicate efficiently with little margin for miscommunication has
grown exponentially. grown significantly.
The objective of this document is to define an addition to the The objective of this document is to define an addition to the
Multipurpose Internet Mail Extensions (MIME) standard, to make it Multipurpose Internet Mail Extensions (MIME) standard, to make it
possible to send a single message to a group of people in such a way 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 that all of the recipients can read the email in their preferred
language. The methods of translation of the message content are language. The methods of translation of the message content are
beyond the scope of this document, but the structure of the email beyond the scope of this document, but the structure of the email
itself is defined herein. itself is defined herein.
Whilst this document depends on identification of language in message Whilst this document depends on identification of language in message
parts for non-real-time communication, there is a companion document parts for non-real-time communication, there is a companion document
that is concerned with a similar problem for real-time communication: that is concerned with a similar problem for real-time communication:
[I-D.gellens-slim-negotiating-human-language] [I-D.ietf-slim-negotiating-human-language]
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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" MIME subtype allows the sending of a
skipping to change at page 4, line 33 skipping to change at page 4, line 33
to be the most likely to be recognised by the recipient as this will to be the most likely to be recognised by the recipient as 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 and MAY
have a Translation-Type parameter applied to the Content-Language have a Translation-Type parameter applied to the Content-Language
field. 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. Each language support for message/global becomes more commonplace. See RFC 6532
message part SHOULD have a Subject field in the appropriate language [RFC6532] for details of message/global. Each language message part
for that language part. If there is a From field present, its value SHOULD have a Subject field in the appropriate language for that
MUST include the same email address as the top-level From header language part. If there is a From field present, its value MUST
although the display name MAY be a localised version. include the same email address as the top-level From header although
the display name MAY be a localised version.
3.3. The Language Independent Message Part 3.3. The Language Independent Message Part
If there is language independent content intended for the recipient If there is language independent content intended for the recipient
to see if they have a preferred language other than one of those to see if they have a preferred language other than one of those
specified in the language message parts and the default language specified in the language message parts and the default language
message part is unlikely to be understood, another part MAY be message part is unlikely to be understood, another part MAY be
provided. This could typically be a language independent graphic. provided. This could typically be a language independent graphic.
When this part is present, it MUST be the last part, MUST have a When this part is present, it MUST be the last part, 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/
skipping to change at page 5, line 11 skipping to change at page 5, line 11
NOT have a From field. The part SHOULD have a Content-Type of NOT have a From field. The part SHOULD have a Content-Type of
message/rfc822 or message/global (to match the language message message/rfc822 or message/global (to match the language message
parts). 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 summarised in the next few paragraphs.
Firstly, if the email client does not understand multipart/ Firstly, if the email client does not understand multipart/
multilingual then it SHOULD treat the message as if it was multipart/ multilingual then it should treat the message as if it was multipart/
mixed and render message parts accordingly. mixed and render message parts accordingly.
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 Translation-Type parameter of the Content- first language. The Translation-Type parameter of the Content-
Language field value can be used for further selection based on this Language field value can be used for further selection based on this
preference. The selection of language part may be implemented in a preference. The selection of language part may be implemented in a
skipping to change at page 5, line 49 skipping to change at page 5, line 49
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/RFC 5646 [RFC5646]
(which defines the structure and semantics for the language code (which defines the structure and semantics for the language code
values). While RFC 5646 provides a mechanism accommodating values).
increasingly fine-grained distinctions, in the interest of maximum
interoperability, each Content-Language value SHOULD be restricted to Examples of this field for English, German and an instruction manual
the largest granularity of language tags; in other words, it is in Spanish and French, could look like the following:
RECOMMENDED to specify only a Primary-subtag and NOT to include
subtags (e.g., for region or dialect) unless the languages might be
mutually incomprehensible without them. Examples of this field for
English, German and an instruction manual in Spanish and French,
could look like the following:
Content-Language: en Content-Language: en
Content-Language: de Content-Language: de
Content-Language: es, fr Content-Language: es, fr
6. The Translation-Type Parameter 6. The Translation-Type Parameter
The Translation-Type parameter can be applied to the Content-Language The Translation-Type parameter can be applied to the Content-Language
skipping to change at page 7, line 22 skipping to change at page 7, line 16
part is selected) the top-level Subject header field value should be part is selected) the top-level Subject header field value should be
used. 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 From: Nik@example.com
To: Nathaniel 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 Jul 2016 21:28:00 +0100 Date: Thu, 7 Jul 2016 21:28:00 +0100
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/multilingual; Content-Type: multipart/multilingual;
boundary="01189998819991197253" boundary="01189998819991197253"
--01189998819991197253 --01189998819991197253
Content-Type: text/plain; charset="UTF-8" Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable
skipping to change at page 8, line 31 skipping to change at page 8, line 24
--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 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 From: Nik@example.com
To: Nathaniel 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 Jul 2016 21:08:00 +0100 Date: Thu, 7 Jul 2016 21:08:00 +0100
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/multilingual; Content-Type: multipart/multilingual;
boundary="01189998819991197253" boundary="01189998819991197253"
--01189998819991197253 --01189998819991197253
Content-Type: text/plain; charset="UTF-8" Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable
skipping to change at page 10, line 4 skipping to change at page 9, line 45
Content-Type: image/png; name="icon.png" Content-Type: image/png; name="icon.png"
Content-Disposition: inline Content-Disposition: inline
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZQAA iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZQAA
SA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr SA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr
997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII= 997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII=
--99911972530118999881-- --99911972530118999881--
--01189998819991197253-- --01189998819991197253--
8.3. An Example of a complex Multiple language email message with 8.3. An Example of a complex Multiple language email message with
language independent part language independent part
Below is an example of a more complex multiple language email Below is an example of a more complex multiple language email
message. It has the multilingual preface and two language message message. It has the multilingual preface and two language message
parts and then a language independent png image. The language parts and then a language independent png image. The language
message parts have multipart/alternative contents and would therefore message parts have multipart/alternative contents and would therefore
require further processing to determine the content to display. require further processing to determine the content to display.
From: Nik From: Nik@example.com
To: Nathaniel 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 Jul 2016 20:55:00 +0100 Date: Thu, 7 Jul 2016 20:55:00 +0100
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/multilingual; Content-Type: multipart/multilingual;
boundary="01189998819991197253" boundary="01189998819991197253"
--01189998819991197253 --01189998819991197253
Content-Type: text/plain; charset="UTF-8" Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable
skipping to change at page 14, line 19 skipping to change at page 14, line 5
language message parts to allow a localised version of the language message parts to allow a localised version of the
sender's display name. sender's display name.
9.8. Changes from draft-ietf-slim-multilangcontent-03 to draft-ietf- 9.8. Changes from draft-ietf-slim-multilangcontent-03 to draft-ietf-
slim-multilangcontent-04 slim-multilangcontent-04
o Updated the wording of the security considerations section to o Updated the wording of the security considerations section to
reflect the relaxation of the use of the From field in the reflect the relaxation of the use of the From field in the
language message parts. language message parts.
9.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.
10. Acknowledgements 10. Acknowledgements
The authors are grateful for the helpful input received from many The authors are grateful for the helpful input received from many
people but would especially like to acknowledge the help of Harald people but would especially like to acknowledge the help of Harald
Alvestrand, Stephane Bortzmeyer, Eric Burger, Mark Davis, Doug Ewell, Alvestrand, Stephane Bortzmeyer, Eric Burger, Mark Davis, Doug Ewell,
Randall Gellens, Gunnar Hellstrom, Sean Leonard, John Levine, Alexey Randall Gellens, Gunnar Hellstrom, Sean Leonard, John Levine, Alexey
Melnikov, Addison Phillips, Pete Resnick, Brian Rosen, Fiona Melnikov, Addison Phillips, Pete Resnick, Brian Rosen, Fiona
Tomkinson, Simon Tyler and Daniel Vargha. Tomkinson, Simon Tyler and Daniel Vargha.
The authors would also like to thank Fernando Alvaro and Luis de The authors would also like to thank Fernando Alvaro and Luis de
skipping to change at page 15, line 44 skipping to change at page 15, line 46
<http://www.rfc-editor.org/info/rfc3282>. <http://www.rfc-editor.org/info/rfc3282>.
[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>. <http://www.rfc-editor.org/info/rfc4647>.
[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, <http://www.rfc-editor.org/info/rfc5646>. September 2009, <http://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, <http://www.rfc-editor.org/info/rfc6532>.
13.2. Informational References 13.2. Informational References
[I-D.gellens-slim-negotiating-human-language] [I-D.ietf-slim-negotiating-human-language]
Gellens, R., "Negotiating Human Language in Real-Time Gellens, R., "Negotiating Human Language in Real-Time
Communications", draft-gellens-slim-negotiating-human- Communications", draft-ietf-slim-negotiating-human-
language-02 (work in progress), July 2015. language-04 (work in progress), July 2016.
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
 End of changes. 16 change blocks. 
29 lines changed or deleted 47 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/