draft-ietf-slim-multilangcontent-11.txt   draft-ietf-slim-multilangcontent-12.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: February 8, 2018 August 7, 2017 Expires: February 10, 2018 August 9, 2017
Multiple Language Content Type Multiple Language Content Type
draft-ietf-slim-multilangcontent-11 draft-ietf-slim-multilangcontent-12
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 February 8, 2018. This Internet-Draft will expire on February 10, 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 6, line 22 skipping to change at page 6, line 22
Content-Language: es, fr Content-Language: es, fr
6. The Translation-Type Field 6. The Translation-Type Field
The Translation-Type field can be used in the individual language The Translation-Type field can be used in the individual language
message parts to identify the type of translation. Based on the message parts to identify the type of translation. Based on the
value of this parameter and the user's preferences, a conforming value of this parameter 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', 'human'
or 'automated' although other values may be added in the future in or 'automated' although other values may be added in the future. A
updated specification documents. A value of 'original' is given in value of 'original' is given in the language message part that is in
the language message part that is in the original language. A value the original language. A value of 'human' is used when a language
of 'human' is used when a language message part is translated by a message part is translated by a human translator or a human has
human translator or a human has checked and corrected an automated checked and corrected an automated translation. A value of
translation. A value of 'automated' is used when a language message 'automated' is used when a language message part has been translated
part has been translated by an electronic agent without proofreading by an electronic agent without proofreading or subsequent correction.
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] The syntax of the Translation-Type field in ABNF RFC 5234 [RFC5234]
is: is:
Translation-Type = [FWS] translationtype Translation-Type = [FWS] translationtype
FWS = <Defined in RFC 5322> FWS = <Defined in RFC 5322>
translationtype = "original" / "human" / "automated" translationtype = "original" / "human" / "automated" / translTypeExt
translTypeExt = 1*atext
atext = <Defined in RFC 5322>
This references RFC 5322 [RFC5322] for a pre-defined rule FWS. This references RFC 5322 [RFC5322] for the pre-defined rules 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:
skipping to change at page 14, line 5 skipping to change at page 14, line 5
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 Translation-Type field 10.2. The Translation-Type Field
The Translation-Type field will be added to the IANA "Permanent The Translation-Type field will be added to the IANA "Permanent
Message Header Field Names" registry. That entry will reference this Message Header Field Names" registry. That entry will reference this
document. This is the registration template: document. This is the registration template:
Header field name: Translation-Type Header field name: 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 XXXX
Related information: none Related information: none
10.3. The Translation-Type Field Values
IANA is requested to create a new registry for Translation-Type
Header Field values. New values must be registered using
"Specification Required" IANA registration procedure. Registrations
must include translation type value, short description and a URI of
the specification.
This document also registers 3 initial values specified in Section 6.
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
does not check all of the message parts. The risk should be minimal 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 due to the fact that an unknown multipart subtype should be treated
as multipart/mixed and so each message part should be subsequently as multipart/mixed and so each message part should be subsequently
skipping to change at page 18, line 40 skipping to change at page 19, line 5
12.15. Changes from draft-ietf-slim-multilangcontent-10 to draft-ietf- 12.15. Changes from draft-ietf-slim-multilangcontent-10 to draft-ietf-
slim-multilangcontent-11 slim-multilangcontent-11
o Updated the applicable protocol for the Translation-Type field in o Updated the applicable protocol for the Translation-Type field in
the IANA registration template to be 'mime' rather than 'mail'. the IANA registration template to be 'mime' rather than 'mail'.
o Added that updated specification documents would be the source of o Added that updated specification documents would be the source of
new values for the Translation-Type field. 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.
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)
 End of changes. 9 change blocks. 
15 lines changed or deleted 35 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/