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

[Nik Tomkinson <[e-mail]>]

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

On 17 August 2017 at 14:35, Eric Rescorla <[e-mail]> wrote:

> 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
>
>
>
> On Thu, Aug 17, 2017 at 6:12 AM, Alexey Melnikov <[e-mail]>
> wrote:
>
>> On Thu, Aug 17, 2017, at 01:59 PM, Eric Rescorla wrote:
>>
>>
>>
>> On Thu, Aug 17, 2017 at 2:27 AM, Alexey Melnikov <[e-mail]>
>> wrote:
>>
>> Hi Ekr,
>>
>> On Wed, Aug 16, 2017, at 12:10 AM, Eric Rescorla wrote:
>> > Eric Rescorla has entered the following ballot position for
>> > draft-ietf-slim-multilangcontent-13: No Objection
>>
>> > 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?
>>
>> 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?
>>
>>
>>
>> -Ekr
>>
>>
>>
>> Best Regards,
>> Alexey
>>
>>
>> > That seems at least
>> > disfavored if not impossible (because I can't tag that one with
>> > its actual language). Am I missing something?
>> >
>> >
>>
>>
>>
>


-- 

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

https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/

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