draft-ietf-slim-multilangcontent-09.txt   draft-ietf-slim-multilangcontent-10.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 25, 2018 July 24, 2017 Expires: February 2, 2018 August 1, 2017
Multiple Language Content Type Multiple Language Content Type
draft-ietf-slim-multilangcontent-09 draft-ietf-slim-multilangcontent-10
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 25, 2018. This Internet-Draft will expire on February 2, 2018.
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 (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 3, line 43 skipping to change at page 3, line 43
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 explain briefly 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 encoding is used for this message part. UTF-8 charset is used for this message part. See RFC 3629 [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, because conforming email clients SHOULD only
show the single language message part identified by the user's show the single language message part identified by the user's
preferred language and the language message part's Content-Language. 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]
skipping to change at page 5, line 11 skipping to change at page 5, line 11
described in BCP 47/RFC 5646 [RFC5646]). The part SHOULD have a described in BCP 47/RFC 5646 [RFC5646]). The part SHOULD have a
Content-Type of message/rfc822 or message/global (to match the Content-Type of message/rfc822 or message/global (to match the
language message parts). 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 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 will treat the message as if it was multipart/
mixed and render message parts accordingly. 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 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 field value can be used for first language. The Translation-Type field value can be used for
further selection based on this preference. The selection of further selection based on this preference. The selection of
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
skipping to change at page 6, line 33 skipping to change at page 6, line 36
checked and corrected an automated translation. A value of 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.
Examples of this field include: Examples of this field include:
Translation-Type: original Translation-Type: original
Translation-Type: human Translation-Type: human
The syntax of the Translation-Type field in ABNF RFC 5234 [RFC5234]
is:
Translation-Type = [FWS] translationtype
FWS = <Defined in RFC 5322>
translationtype = "original" / "human" / "automated"
This references RFC 5322 [RFC5322] for a pre-defined rule FWS.
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:
skipping to change at page 9, line 32 skipping to change at page 9, line 43
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
Content-Type: message/rfc822; name="Icon" Content-Type: message/rfc822; name="Icon"
Content-Language: zxx Content-Language: zxx
Content-Disposition: inline Content-Disposition: inline
Content-Type: multipart/mixed;
boundary="99911972530118999881"; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Content-Type: image/png; name="icon.png" Content-Type: image/png; name="icon.png"
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=
--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.
skipping to change at page 13, line 19 skipping to change at page 13, line 19
Required parameters: boundary (defined in RFC2046) Required parameters: boundary (defined in RFC2046)
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: There are no encoding considerations for Encoding considerations: There are no encoding considerations for
this multipart other than that of the embedded body parts. this multipart other than that of the embedded body parts.
The embedded body parts (typically one text/plain plus one or The embedded body parts (typically one text/plain plus one or
more message/*) may contain 7-bit, 8-bit or binary encodings. more message/*) may contain 7-bit, 8-bit or binary encodings.
Security considerations: See the Security Considerations section Security considerations: See the Security Considerations section
in this document 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. multipart/multilingual type. These systems would also be non-
compliant with MIME.
Published specification: This document Author/Change controller: IETF
Published specification: RFC XXXX
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.
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
skipping to change at page 14, line 13 skipping to change at page 14, line 19
document. This is the registration template: document. This is the registration template:
Header field name: Translation-Type Header field name: Translation-Type
Applicable protocol: mail Applicable protocol: mail
Status: Standard Status: Standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): this document Specification document(s): RFC XXXX
Related information: none Related information: none
11. Security Considerations 11. 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 and these parts could contain undesirable content. Therefore there
is a possible risk that undesirable text or images could be shown to 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 the recipient if the message is passed through a spam filter that
skipping to change at page 17, line 38 skipping to change at page 17, line 43
o Reordered the sections to make the Security Considerations easier o Reordered the sections to make the Security Considerations easier
to find. to find.
o Shortened a line in one of the examples that was longer than 72 o Shortened a line in one of the examples that was longer than 72
characters. characters.
o Updated the link to the real-time companion document to the latest o Updated the link to the real-time companion document to the latest
version. 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.
13. References 13. References
13.1. Normative References 13.1. Normative References
[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>. <http://www.rfc-editor.org/info/rfc2046>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
skipping to change at page 18, line 20 skipping to change at page 19, line 15
[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>. <http://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>. <http://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, <http://www.rfc-editor.org/info/rfc3629>.
[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>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<http://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, <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 [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, <http://www.rfc-editor.org/info/rfc6532>.
13.2. Informational References 13.2. Informational References
[I-D.ietf-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-ietf-slim-negotiating-human- Communications", draft-ietf-slim-negotiating-human-
language-10 (work in progress), May 2017. language-13 (work in progress), July 2017.
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 North America
Email: nsb@mimecast.com Email: nsb@mimecast.com
 End of changes. 18 change blocks. 
18 lines changed or deleted 74 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/