Subject: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Aug 2017 16:10:19 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-slim-multilangcontent-13: No Objection

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

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?

---

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

Hi Ekr,

> have that be what non-updated MUAs display?

According to MIME (one of RFCs 2045-2047) any unrecognized multipart
subtypes must be treated as multipart/mixed, so all body parts will be
displayed. Beyond that there is no control of which specific body part a
non compliant client will display.

Best Regards,
Alexey

> That seems at least

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Aug 2017 05:59:37 -0700

> non compliant client will display.

Sure, but it seems like there's a clear assumption in this document that the
first part will be displayed first (otherwise why the requirement)

-Ekr

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Aug 2017 14:12:25 +0100

On Thu, Aug 17, 2017, at 01:59 PM, Eric Rescorla wrote:
> 
> 
> On Thu, Aug 17, 2017 at 2:27 AM, Alexey Melnikov
> <[email-masked]> wrote:>> Hi Ekr,
>>
>>  > Eric Rescorla has entered the following ballot position for draft-ietf-slim-multilangcontent-
>>  > 13: No Objection
>>
>>  > 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?
>>
>> According to MIME (one of RFCs 2045-2047) any unrecognized multipart>>  subtypes must be treated as multipart/mixed, so all body parts
>>  will be>>  displayed. Beyond that there is no control of which specific body
>>  part a>>  non compliant client will display.
> 
> Sure, but it seems like there's a clear assumption in this document
> that the> first part will be displayed first (otherwise why the requirement)
Can you point me to the specific text which is confusing or misleading?

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Aug 2017 06:35:43 -0700

What I am keying off of is this:

   In order for the message to be received and displayed in non-
   conforming email clients, the message SHOULD contain an explanatory
   message part which MUST NOT be marked with a Content-Language field
   and MUST be the first of the message parts.

Why do we require this to be first if it's not special?

-Ekr

---

From: Nik Tomkinson <[email-masked]>
Date: Thu, 17 Aug 2017 20:44:24 +0100

Hi Eric,

There are a few reasons for the multilingual preface. I think this is the
most important:

If a MUA does not understand the new multipart/multilingual type is SHOULD
(according to sections 5.1.3 and 5.1.7 of the MIME RFC 2046) treat it as if
it was a multipart/mixed. This is typically dealt with by either showing
the first part and presenting the subsequent parts as attachments or
showing all of the parts inline one by one in order. Either way the first
part will be shown.

If instead, the first part shown is just the first (original) translation
and the other translations are attachments, then the recipient will not
know that there is a version in their own language attached without opening
each attachment. In this case it would be pointless sending it in more than
one language. If they don't understand the first (original) translation at
all then they have even less of an idea and are likely to just delete the
email.

If the other translations are shown inline, then the multilingual preface
would typically be read first and direct the recipient to their translation
and helps them to understand that they can skim the email until they see
their version.

Also:

The ordering of the parts is important because MUAs will treat a
multipart/multilingual email as multipart/mixed which they will respect the
part ordering of because of this (section 5.1.3 of RFC 2046):

   The "mixed" subtype of "multipart" is intended for use when the body
   parts are independent and need to be bundled in a particular order.
   Any "multipart" subtypes that an implementation does not recognize
   must be treated as being of subtype "mixed".

I hope that helps to explain some of the I-D wording,

Thanks,

Nik

-- 

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Aug 2017 13:04:10 -0700

On Thu, Aug 17, 2017 at 12:44 PM, Nik Tomkinson <[email-masked]

> all then they have even less of an idea and are likely to just delete the

I agree that this can happen, and it's a fair argument for doing it this
way, but I'm not sure it
really justifies a requirement....

-Ekr

>>> On Thu, Aug 17, 2017 at 2:27 AM, Alexey Melnikov <[email-masked]
>>> > wrote:
>>>
>>> Hi Ekr,
>>>