Multiple Language Content Type
draft-ietf-slim-multilangcontent-14
Yes
No Objection
Warren Kumari
(Deborah Brungard)
(Spencer Dawkins)
(Suresh Krishnan)
Note: This ballot was opened for revision 11 and is now closed.
Warren Kumari
No Objection
Alexey Melnikov Former IESG member
Yes
Yes
(2017-08-17 for -13)
Unknown
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.
Ben Campbell Former IESG member
Yes
Yes
(2017-08-16 for -13)
Unknown
Hi, just some minor comments: Substantive: - 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)? Editorial: - 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"?
Adam Roach Former IESG member
No Objection
No Objection
(2017-08-16 for -13)
Unknown
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.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -13)
Unknown
Eric Rescorla Former IESG member
No Objection
No Objection
(2017-08-15 for -13)
Unknown
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?
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2017-08-15 for -13)
Unknown
Thanks for your work on this well-written draft!
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2017-08-15 for -13)
Unknown
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.
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -13)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -13)
Unknown