Subject: [Slim] Ben Campbell's Yes on draft-ietf-slim-multilangcontent-13: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 16 Aug 2017 15:10:12 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-slim-multilangcontent-13: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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"?

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Aug 2017 10:41:39 +0100

Hi Ben,

> from the ones used by the language specific body parts?

This is a good question. I think I agree that it can be potentially
generated per the list of languages used.

> there be multiple language-Independent attachments?

This is generally allowed by MIME. One way of doing this is:

 Top level multipart/mixed
   child 1: multipart/multilingual
   child 2: <1st language-Independent attachment>
   child 3: <2nd language-Independent attachment>

Alternatively, you can use multipart/multilingual:

 Top level multipart/multilingual
   child 1: text/plain
   child 2: message/rfc822 with nested message in English
   child 3: message/rfc822 with nested message in French
   child 4: message/rfc822 with nested message in German
   child 5: multipart/mixed (language independent part)
    child 5.1: <1st language-Independent attachment>
    child 5.2: <2nd language-Independent attachment>

> this descriptively rather than normatively?

Good comments/questions that editors should comment on.

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

I agree.

Best Regards,
Alexey

---

From: Nik Tomkinson <[email-masked]>
Date: Thu, 17 Aug 2017 21:54:38 +0100

Hi Ben,

thanks for all of your comments.

Regarding the multilingual preface, the implementation I am working on at
the moment does select the languages to include in the preface from the
language parts that have been added into the email and the preface
paragraphs are all hard-coded strings. The preface should not be static as
a whole for any specific MUA.

It is reasonable for the sender to know which languages are going to be
included as they will have the translations ready to insert into the
different parts of the email. I suppose this really is a question of the
specification defining how an implementation should work or how the email
should be structured. I have always understood it to be a specification of
the email structure not implementation behaviour.

I would not have imagined that any implementation would expect the sender
to construct the preface but just include it automatically. Any
hand-written multilingual email would have include a hand-written preface
of course.

---

Intent - yes, I'll remove that word as it may be superfluous.

---

As for multiple language independent parts, yes this could happen and
either of the ways that Alexey identified would be valid.

---

The section 11 (Security Considerations) comment is a good point. I had not
thought of that, but if filtering logic checks the different languages,
then there should be no profanity or offensive material to forward on. I
think I will add this case to section 11 anyway.

---

I will update the I-D based on your Editorial comments as well as they are
all valid. I assume you mean that section 3.2 the SHOULD should be a should?
Also, in section 7 do you mean the first, the last or both 'should's should
be SHOULD?

Thanks again,

Nik.

-- 

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:

-----------------------------------------------------------------

---

From: Ben Campbell <[email-masked]>
Date: Thu, 17 Aug 2017 16:14:43 -0500

> On Aug 17, 2017, at 3:54 PM, Nik Tomkinson <[email-masked]> wrote:
> 
> Hi Ben,
> 
> Regarding the multilingual preface, the implementation I am working on at the moment does select the languages to include in the preface from the language parts that have been added into the email and the preface paragraphs are all hard-coded strings. The preface should not be static as a whole for any specific MUA.

Out of curiosity: Am I correct that if there is a language part exists where you have no matching pre-translated version of the preface paragraph, that language just gets left out of the preface?

> 
> It is reasonable for the sender to know which languages are going to be included as they will have the translations ready to insert into the different parts of the email. I suppose this really is a question of the specification defining how an implementation should work or how the email should be structured. I have always understood it to be a specification of the email structure not implementation behaviour. 

It seems to me that a statement that the preface paragraph should be translated into all included languages implies a requirement for implementations to actually do that :-) But to clarify a bit: I’m not sure we can assume the MUA has access to pre-translated versions of the preface for every language a user might include, nor can we assume it is always convenient to create a new translated version on the fly. Maybe it would make sense to put a “where reasonably possible” or even “where convenient” disclaimer on that requirement?  (I’m open to arguments that the SHOULD already allows that—but guidance about the wiggle room in a given SHOULD is often helpful.)

> 
> I would not have imagined that any implementation would expect the sender to construct the preface but just include it automatically. Any hand-written multilingual email would have include a hand-written preface of course.
> 
> ---
> 
> As for multiple language independent parts, yes this could happen and either of the ways that Alexey identified would be valid.

My concern was the text seemed to assume a single language-independent part. Perhaps this could be clarified to allow one or more?  I don’t expect you to go into deep details of nested body parts.

> 
> ---
> 
> The section 11 (Security Considerations) comment is a good point. I had not thought of that, but if filtering logic checks the different languages, then there should be no profanity or offensive material to forward on. I think I will add this case to section 11 anyway.

Thanks! (It’s fairly easy to construct deeply offensive text that would be hard to filter mechanically).

> 
> ---
> 
> I will update the I-D based on your Editorial comments as well as they are all valid. I assume you mean that section 3.2 the SHOULD should be a should?

Yes.

> Also, in section 7 do you mean the first, the last or both 'should's should be SHOULD?

The first one.

Thanks!

Ben.