--- 1/draft-ietf-slim-multilangcontent-07.txt 2017-06-12 15:13:36.414102484 -0700 +++ 2/draft-ietf-slim-multilangcontent-08.txt 2017-06-12 15:13:36.498104507 -0700 @@ -1,18 +1,18 @@ IETF N. Tomkinson Internet-Draft N. Borenstein Intended status: Standards Track Mimecast Ltd -Expires: November 5, 2017 May 4, 2017 +Expires: December 14, 2017 June 12, 2017 Multiple Language Content Type - draft-ietf-slim-multilangcontent-07 + draft-ietf-slim-multilangcontent-08 Abstract This document defines an addition to the Multipurpose Internet Mail Extensions (MIME) standard to make it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings. Status of This Memo @@ -23,21 +23,21 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 5, 2017. + This Internet-Draft will expire on December 14, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -473,21 +473,22 @@ --72530118999911999881 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello, this message content is provided in your language. --72530118999911999881 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit -Hello, this message content is provided in your language. +Hello, this message content is provided in +your language. --72530118999911999881-- --01189998819991197253 Content-Type: message/rfc822 Content-Language: es Translation-Type: human Content-Disposition: inline Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?= =?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?= @@ -525,61 +526,161 @@ Content-Disposition: inline Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZQAA SA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr 997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII= --99911972530118999881-- --01189998819991197253-- -9. Changes from Previous Versions +9. Acknowledgements -9.1. Changes from draft-tomkinson-multilangcontent-01 to draft- + 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, Mark Davis, Doug Ewell, + Randall Gellens, Gunnar Hellstrom, Barry Leiba, Sean Leonard, John + Levine, Alexey Melnikov, Addison Phillips, Julian Reschke, Pete + Resnick, 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. + +10. IANA Considerations + +10.1. The multipart/multilingual MIME type + + The multipart/multilingual MIME type will be registered with IANA + including a reference to this document. This is the registration + template: + + Media Type name: multipart + + Media subtype name: multilingual + + Required parameters: boundary (defined in RFC2046) + + 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. + + Security considerations: See the Security Considerations section + in this document + + Interoperability considerations: + Existing systems that do not treat unknown multipart subtypes + as multipart/mixed may not correctly render a + multipart/multilingual type. + + Published specification: This document + + Applications that use this media type: + Mail Transfer Agents, Mail User Agents, spam detection, + virus detection modules and message authentication modules. + + Additional information: + Deprecated alias names for this type: N/A + Magic number(s): N/A + File extension(s): N/A + Macintosh file type code(s): N/A + + Person & email address to contact for further information: + Nik Tomkinson + rfc.nik.tomkinson@gmail.com + + Nathaniel Borenstein + nsb@mimecast.com + + Intended usage: Common + +10.2. The Translation-Type field + + The Translation-Type field will be added to the IANA "Permanent + Message Header Field Names" registry. That entry will reference this + document. This is the registration template: + + Header field name: Translation-Type + + Applicable protocol: mail + + Status: Standard + + Author/Change controller: IETF + + Specification document(s): this document + + Related information: none + +11. Security Considerations + + Whilst it is intended that each language message part is a direct + translation of the original message, this may not always be the case + and these parts could contain undesirable content. Therefore there + is a possible risk that undesirable text or images could be shown to + the recipient if the message is passed through a spam filter that + does not check all of the message parts. The risk should be minimal + due to the fact that an unknown multipart subtype should be treated + as multipart/mixed and so each message part should be subsequently + scanned. + + Because the language message parts have a Content-Type of message/ + rfc822 or message/global, they might contain From fields which could + have different values to that of the top-level From field and may not + reflect the actual sender. The inconsistent From field values might + get shown to the recipient in a non-conforming email client and may + mislead the recipient into thinking that the email came from someone + other than the real sender. + +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. -9.2. Changes from draft-tomkinson-slim-multilangcontent-00 to draft- +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). -9.3. Changes from draft-tomkinson-slim-multilangcontent-01 to draft- +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. -9.4. Changes from draft-tomkinson-slim-multilangcontent-02 to draft- +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. @@ -587,188 +688,100 @@ 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. -9.5. Changes from draft-ietf-slim-multilangcontent-00 to draft-ietf- +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. -9.6. Changes from draft-ietf-slim-multilangcontent-01 to draft-ietf- +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. -9.7. Changes from draft-ietf-slim-multilangcontent-02 to draft-ietf- +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. -9.8. Changes from draft-ietf-slim-multilangcontent-03 to draft-ietf- +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. -9.9. Changes from draft-ietf-slim-multilangcontent-04 to draft-ietf- +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. -9.10. Changes from draft-ietf-slim-multilangcontent-05 to draft-ietf- +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. -9.11. Changes from draft-ietf-slim-multilangcontent-06 to draft-ietf- +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. -10. 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, Mark Davis, Doug Ewell, - Randall Gellens, Gunnar Hellstrom, Barry Leiba, Sean Leonard, John - Levine, Alexey Melnikov, Addison Phillips, Julian Reschke, Pete - Resnick, 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. - -11. IANA Considerations - -11.1. The multipart/multilingual MIME type - - The multipart/multilingual MIME type will be registered with IANA - including a reference to this document. This is the registration - template: - - Media Type name: multipart - - Media subtype name: multilingual - - Required parameters: boundary (defined in RFC2046) - - 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. - - Security considerations: See the Security Considerations section - in this document - - Interoperability considerations: - Existing systems that do not treat unknown multipart subtypes - as multipart/mixed may not correctly render a - multipart/multilingual type. - - Published specification: This document - - Applications that use this media type: - Mail Transfer Agents, Mail User Agents, spam detection, - virus detection modules and message authentication modules. - - Additional information: - Deprecated alias names for this type: N/A - Magic number(s): N/A - File extension(s): N/A - Macintosh file type code(s): N/A - - Person & email address to contact for further information: - Nik Tomkinson - rfc.nik.tomkinson@gmail.com - - Nathaniel Borenstein - nsb@mimecast.com - - Intended usage: Common - -11.2. The Translation-Type field - - The Translation-Type field will be added to the IANA "Permanent - Message Header Field Names" registry. That entry will reference this - document. This is the registration template: - - Header field name: Translation-Type - - Applicable protocol: mail - - Status: Standard - - Author/Change controller: IETF - - Specification document(s): this document - - Related information: none +12.12. Changes from draft-ietf-slim-multilangcontent-07 to draft-ietf- + slim-multilangcontent-08 -12. Security Considerations + o Reordered the sections to make the Security Considerations easier + to find. - Whilst it is intended that each language message part is a direct - translation of the original message, this may not always be the case - and these parts could contain undesirable content. Therefore there - is a possible risk that undesirable text or images could be shown to - the recipient if the message is passed through a spam filter that - does not check all of the message parts. The risk should be minimal - due to the fact that an unknown multipart subtype should be treated - as multipart/mixed and so each message part should be subsequently - scanned. + o Shortened a line in one of the examples that was longer than 72 + characters. - Because the language message parts have a Content-Type of message/ - rfc822 or message/global, they might contain From fields which could - have different values to that of the top-level From field and may not - reflect the actual sender. The inconsistent From field values might - get shown to the recipient in a non-conforming email client and may - mislead the recipient into thinking that the email came from someone - other than the real sender. + o Updated the link to the real-time companion document to the latest + version. 13. References 13.1. Normative References [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . @@ -802,21 +815,21 @@ [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, . 13.2. Informational References [I-D.ietf-slim-negotiating-human-language] Gellens, R., "Negotiating Human Language in Real-Time Communications", draft-ietf-slim-negotiating-human- - language-04 (work in progress), July 2016. + language-10 (work in progress), May 2017. Authors' Addresses Nik Tomkinson Mimecast Ltd CityPoint, One Ropemaker Street London EC2Y 9AW United Kingdom Email: rfc.nik.tomkinson@gmail.com