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

[Eric Rescorla <[e-mail]>]

On Thu, Aug 17, 2017 at 12:44 PM, Nik Tomkinson <[e-mail]
> wrote:

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

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


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