Multiple Language Content Type

Note: This ballot was opened for revision 11 and is now closed.

Ben Campbell Yes

Comment (2017-08-16 for -13)
Hi, just some minor comments:


- 3.1: "This initial message part SHOULD explain briefly to the recipient
   that the message contains multiple languages and the parts may be
   rendered sequentially or as attachments.  This SHOULD be presented in
   the same languages that are provided in the subsequent language
   message parts."

It seems likely that this message will be relatively static (perhaps preloaded or configured) for messages sent by any particular MUA. Is it reasonable to expect the MUA (or the person who configures it) to know in advance all languages likely to be used? Is it expected to dynamically select the languages from the ones used by the language specific body parts?

-3.3: I'm not sure I understand the first sentence. Why does that ''intent" matter? 

This section seems to take about a single language-independent part. Could there be multiple language-Independent attachments?

-11, first paragraph: It seems like there might be some more subtle abuses than slipping past a spam filter. For example, if a recipient falsely assumes that all the body parts say the same thing, might they be induced into taking some action? (e.g.  forwarding offensive material targeted at speakers of a specific language)?


- Abstract: Please consider mentioning the subtype by name in the abstract.

- 1: "The objective of this document is to define..."
Did it succeed in its objective? :-)   (Consider "This document defines...:)

- 3.2: "Each language message part SHOULD have a Subject field in the appropriate language for that language part."
Since section 7 restates this SHOULD, and covers the topic in more detail, perhaps section 3.2 should state this descriptively rather than normatively?

-7, last paragraph: Should the first "should" be a "SHOULD"?

Alexey Melnikov Yes

Comment (2017-08-17 for -13)
Comments from Ben and Mirja need to be considered.

Also Adam's points about using Language codes instead of Language tags also needs a clarification.

Deborah Brungard No Objection

Spencer Dawkins No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Mirja K├╝hlewind No Objection

Comment (2017-08-15 for -13)
Minor comments:
- sec 3.2:
"If there is a From field present, its value MUST
   include the same email address as the top-level From header..."
What happen if they are no the same? The security considerations section mentions this case but there is no guidance given what to do in this case (which address to display)?

- The security considerations section mentions the risk that the content might actually be different in different languages. I think it would be nice to give some recommendation that there SHOULD be a way for the user to see all content fields.

Kathleen Moriarty No Objection

Comment (2017-08-15 for -13)
Thanks for your work on this well-written draft!

Eric Rescorla No Objection

Comment (2017-08-15 for -13)
As I understand it, this is designed so that if you have an MUA which
doesn't understand this document you get the preface as the first
thing you see. That doesn't seem crazy, but isn't the common case that
you have one preferred language that most recipients speak and then
some translations. Wouldn't it make sense to at least allow people to
have that be what non-updated MUAs display? That seems at least
disfavored if not impossible (because I can't tag that one with
its actual language). Am I missing something?

Adam Roach No Objection

Comment (2017-08-16 for -13)
I note that this mechanism uses only language tags and implicitly leaves aside any discussion of script or region tags. I'm going to assume this was a intentional decision that was considered by the group with the end result being that there was no perceived need to distinguish between (e.g.) Latin and Jawi scripts for Malay, or (e.g.) Brazilian and Portuguese variations of 'pt'. (If this was not an explicit decision made by the WG, I would ask that it be posed to the WG for an explicit decision -- the current mechanism seems somewhat deficient in this regard from my admittedly brief analysis of the situation.)

I'm a little worried that an imprecise reading by implementors of the citation to RFC5646 may lead them to believe that script and region tags may be included in the Content-Language header fields. If the assumptions I discuss above are true, please add text making it clear that script and region tags are forbidden.