draft-ietf-slim-multilangcontent-03.txt   draft-ietf-slim-multilangcontent-04.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 22, 2017 July 21, 2016 Expires: January 26, 2017 July 25, 2016
Multiple Language Content Type Multiple Language Content Type
draft-ietf-slim-multilangcontent-03 draft-ietf-slim-multilangcontent-04
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 22, 2017. This Internet-Draft will expire on January 26, 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 14, line 12 skipping to change at page 14, line 12
unmatched sender addresses that could be set in the language unmatched sender addresses that could be set in the language
message parts. message parts.
9.7. Changes from draft-ietf-slim-multilangcontent-02 to draft-ietf- 9.7. Changes from draft-ietf-slim-multilangcontent-02 to draft-ietf-
slim-multilangcontent-03 slim-multilangcontent-03
o Relaxed the restriction on the use of the From field in the o Relaxed the restriction on the use of the From field in the
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-
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.
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 14, line 43 skipping to change at page 14, line 50
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
scanned. scanned.
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 which could
have different values to that of the top-level From field and may not have different values to that of the top-level From field and may not
reflect the actual sender. An implementation might choose to include reflect the actual sender. The inconsistent From field values might
a From field, even though it is specified in this document that the get shown to the recipient in a non-conforming email client and may
language message parts SHOULD NOT have a From field. The incorrect mislead the recipient into thinking that the email came from someone
From field values might get shown to the recipient in a non- other than the real sender.
conforming email client and may mislead the recipient into thinking
that the email came from someone other than the real sender.
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>.
 End of changes. 5 change blocks. 
9 lines changed or deleted 14 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/