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

[Ben Campbell <[e-mail]>]

> On Aug 17, 2017, at 3:54 PM, Nik Tomkinson <[e-mail]> wrote:
> 
> 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.

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.
> 
> ---
> 
> 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.

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.

> 
> Thanks again,
> 
> Nik.
> 
> On 17 August 2017 at 10:41, Alexey Melnikov <[e-mail]> wrote:
> Hi Ben,
> 
> On Wed, Aug 16, 2017, at 11:10 PM, Ben Campbell wrote:
> > Ben Campbell has entered the following ballot position for
> > draft-ietf-slim-multilangcontent-13: Yes
> 
> > 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?
> 
> This is a good question. I think I agree that it can be potentially
> generated per the list of languages used.
> 
> > -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?
> 
> 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>
> 
> > -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?
> 
> Good comments/questions that editors should comment on.
> 
> > -7, last paragraph: Should the first "should" be a "SHOULD"?
> 
> I agree.
> 
> Best Regards,
> Alexey
> 
> 
> 
> -- 
> -----------------------------------------------------------------
> Multiple Language Content Type Internet Draft:
> https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/
> -----------------------------------------------------------------
>