From nobody Tue Aug 1 09:37:38 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B3D131DF7; Tue, 1 Aug 2017 09:37:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150160545023.9635.18134734821561048075@ietfa.amsl.com> Date: Tue, 01 Aug 2017 09:37:30 -0700 Archived-At: Subject: [Slim] I-D Action: draft-ietf-slim-multilangcontent-10.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 16:37:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Selection of Language for Internet Media WG of the IETF. Title : Multiple Language Content Type Authors : Nik Tomkinson Nathaniel Borenstein Filename : draft-ietf-slim-multilangcontent-10.txt Pages : 20 Date : 2017-08-01 Abstract: This document defines an addition to the Multipurpose Internet Mail Extensions (MIME) standard to make it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-slim-multilangcontent-10 https://datatracker.ietf.org/doc/html/draft-ietf-slim-multilangcontent-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-multilangcontent-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 1 14:46:22 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD69E131CA0 for ; Tue, 1 Aug 2017 14:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBK5JaNzXJGg for ; Tue, 1 Aug 2017 14:46:18 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69EF129B40 for ; Tue, 1 Aug 2017 14:46:17 -0700 (PDT) X-Halon-ID: d3369d22-7702-11e7-ba9e-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.71.228.111]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id d3369d22-7702-11e7-ba9e-005056917f90; Tue, 01 Aug 2017 23:46:08 +0200 (CEST) To: Randall Gellens , Bernard Aboba References: <518f72c7-da4f-120e-f77f-cd61719410f3@alum.mit.edu> <7f6b44ad-8b90-0c21-b841-763be03c32af@omnitor.se> <5f73c02c-801e-bf33-c41d-1809dd9dc25b@comcast.net> Cc: slim@ietf.org, Paul Kyzivat From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <71dcb50e-6d36-1445-6cc5-6b91f001bc50@omnitor.se> Date: Tue, 1 Aug 2017 23:46:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 21:46:21 -0000 Den 2017-07-27 kl. 01:11, skrev Randall Gellens: > At 3:20 PM -0700 7/26/17, Bernard Aboba wrote: > >> Randy said: >> >> "Therefore, if the asterisk is causing heartburn, we can remove it >> without technical impact." >> >> [BA] Unless there is some compelling reason to keep it, removing the >> "*" might be the simplest way to resolve Issue 26. > > There is no compelling reason to keep it, especially since it's purely > advisory. > > I suggest we delete it, revise the draft, and advance it. In my view, > we've spent far too much time on the asterisk, which is a supremely > trivial aspect of the draft. > > --Randy +1 Gunnar > >> >> On Wed, Jul 26, 2017 at 3:12 PM, Randall Gellens >> <rg+ietf@randy.pensive.org> wrote: >> >> At 2:35 PM -0700 7/26/17, Bernard Aboba wrote: >> >> Paul said: >> >> "Then what is the expectation regarding whether to accept a call >> with no matching language?" >> >> I guess it would make the most sense for the callee to accept the >> call unless he doesn't want a call without matching language. Then if >> the callee does accept the call without the matching language the >> caller can still terminate the call once he realizes that is the >> situation. >> >> That seems reasonable to me." >> >> [BA] The inability to negotiate a matching language is different >> from other SDP negotiation failures such as the inability to >> negotiate a matching codec, since even without a matching language, >> it still may be useful to successfully negotiate media >> characteristics and bring up the call. Therefore it is not clear to >> me how much value the "*" has in the current draft, regardless of how >> it is defined. >> >> For example, if the callee has policy that dictates that it will >> always accept the call (e.g. a PSAP), the callee might always ignore >> the "*". This might be frustrating to the caller, but the caller may >> still choose not to terminate the call. >> >> Even if the callee cares deeply about a matching language (e.g. a >> voice recognition or chat bot system that is only supports a subset >> of languages), the callee might still choose to ignore the "*". >> >> For example, the callee might accept the call in order to provide >> information to the caller (e.g. a pre-recorded voice or text message >> indicating that the caller's languages are not supported). >> >> >> The draft has said for some time that the asterisk is nothing more >> than advisory, and has explicitly said that the callee is free to >> ignore either the presence or absence of an asterisk: >> >> The called party MAY ignore the indication, e.g., for the emergency >> services use case, regardless of the absence of an asterisk, a PSAP >> will likely not fail the call; some call centers might reject a call >> even if the offer contains an asterisk. >> >> Therefore, if the asterisk is causing heartburn, we can remove it >> without technical impact. >> >> --Randy >> >> >> On Wed, Jul 26, 2017 at 1:46 PM, Paul Kyzivat >> <paul.kyzivat@comcast.net>paul.kyzivat@comcast.net> >> wrote: >> >> On 7/26/17 2:35 PM, Randall Gellens wrote: >> >> Why don't we just take out of the current draft the asterisk and >> the ability to indicate a caller preference to not fail the call? >> Then Gunnar's draft(s) are free to use the asterisk. >> >> >> Then what is the expectation regarding whether to accept a call >> with no matching language? >> >> I guess it would make the most sense for the callee to accept the >> call unless he doesn't want a call without matching language. Then if >> the callee does accept the call without the matching language the >> caller can still terminate the call once he realizes that is the >> situation. >> >> That seems reasonable to me. >> >> Thanks, >> Paul >> >> >> _______________________________________________ >> SLIM mailing list >> >> SLIM@ietf.org>SLIM@ietf.org >> >> >> >> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim >> >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> >> https://www.ietf.org/mailman/listinfo/slim >> >> >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> It isn't pollution that's harming the environment. It's the >> impurities in our air and water that are doing it. >> --Dan Quayle (then-U.S. Vice-President) >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Tue Aug 1 15:02:02 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5228D124217 for ; Tue, 1 Aug 2017 15:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXRfmB50a7x2 for ; Tue, 1 Aug 2017 15:01:55 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78FF1126B6E for ; Tue, 1 Aug 2017 15:01:55 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id x10so11515300vkd.0 for ; Tue, 01 Aug 2017 15:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=mpRBEWXvwSwHoKaRZpebCTYUvjKjymV+O2XEID1k7a0=; b=BDBgG+QWIDViLVRvUPXk3Yn/cU1/t82owGtReUHKhrMZl58+OFwN3vq/nH4vlXBJhW OEs43NFcsDi7gmGsIuBntHLWZ1OVit0kX41daUMGmjQhKYZksRcGs3g5niwjd2bcFfZT iLAqD+hgtPoruArd62jyQrLpIi8XtJa1GhOZ4fhSyOUj1vQKJZ7CJ2Uut3DWiTQPcI1z Bv3go3xIDp4VNws46p8qjeMixhm92O0i4UmCyGbrF35Zfqpvz5t0OZbsPitAbl0MUE8i g1DrDoU7oSonSkTTLZogvDyJyAXnMABL4Ge4lEQURV0OJti+USGsJhMwaZqg9ymQuV/U 6KsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=mpRBEWXvwSwHoKaRZpebCTYUvjKjymV+O2XEID1k7a0=; b=L3trlESkL4/KCX3usFJh8FOoOxtDN7UfdnmQ5IyHpxJrB+ZjYoNk+YvvNFJB6nZukh n4pmiZ3axX6oj6yiI6NwN/fU358YtL4YGuhYRjaC4B8L5Ud6YLYH2p3Zihr0YlG2WQiI UFTxf/XCvv29jjwtPTtJ2DGYzAh7/D14x6lrzuDRytGMhaw+hYqzolv8Lvy8/vOzWWNE CtxN6BJSrF0hsaE0g1QT31jfOt2KXhTgQbI51kTzAx3r2hPzqvn8Lj0VRS03EqkEW/Nm 4sLbFq2OsB9br6Hcc0wzcFG6f97othcSWdiodBZYICnqouLh2gWXpelFf8Fq6oJzcn5v zq5A== X-Gm-Message-State: AIVw112pnUrLT9SiyKa6MprZb12vbcTfNcNjzvlhZ8cL43SkfYOzRkKK gqZ9BQlz2rJ/8RXOxpL3wmFf3quKTi2N X-Received: by 10.31.107.66 with SMTP id g63mr13191064vkc.76.1501624914167; Tue, 01 Aug 2017 15:01:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.111 with HTTP; Tue, 1 Aug 2017 15:01:33 -0700 (PDT) In-Reply-To: <71dcb50e-6d36-1445-6cc5-6b91f001bc50@omnitor.se> References: <518f72c7-da4f-120e-f77f-cd61719410f3@alum.mit.edu> <7f6b44ad-8b90-0c21-b841-763be03c32af@omnitor.se> <5f73c02c-801e-bf33-c41d-1809dd9dc25b@comcast.net> <71dcb50e-6d36-1445-6cc5-6b91f001bc50@omnitor.se> From: Bernard Aboba Date: Tue, 1 Aug 2017 15:01:33 -0700 Message-ID: To: slim@ietf.org Content-Type: multipart/alternative; boundary="001a11478fea984d7f0555b84b4d" Archived-At: Subject: Re: [Slim] Human-language Issue 26: Asterisk modifier scope X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 22:02:01 -0000 --001a11478fea984d7f0555b84b4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A potential resolution has been proposed to Issue 26: Delete the Asterisk. Are there any objections to this approach? On Tue, Aug 1, 2017 at 2:46 PM, Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> wrote: > Den 2017-07-27 kl. 01:11, skrev Randall Gellens: > >> At 3:20 PM -0700 7/26/17, Bernard Aboba wrote: >> >> Randy said: >>> >>> "Therefore, if the asterisk is causing heartburn, we can remove it >>> without technical impact." >>> >>> [BA] Unless there is some compelling reason to keep it, removing the >>> "*" might be the simplest way to resolve Issue 26. >>> >> >> There is no compelling reason to keep it, especially since it's purely >> advisory. >> >> I suggest we delete it, revise the draft, and advance it. In my view, >> we've spent far too much time on the asterisk, which is a supremely triv= ial >> aspect of the draft. >> >> --Randy >> > +1 > Gunnar > > >> >>> On Wed, Jul 26, 2017 at 3:12 PM, Randall Gellens <>> rg+ietf@randy.pensive.org>rg+ietf@randy.pensive.org> wrote: >>> >>> At 2:35 PM -0700 7/26/17, Bernard Aboba wrote: >>> >>> Paul said: >>> >>> "Then what is the expectation regarding whether to accept a call with >>> no matching language?" >>> >>> I guess it would make the most sense for the callee to accept the cal= l >>> unless he doesn't want a call without matching language. Then if the ca= llee >>> does accept the call without the matching language the caller can still >>> terminate the call once he realizes that is the situation. >>> >>> That seems reasonable to me." >>> >>> [BA] The inability to negotiate a matching language is different from >>> other SDP negotiation failures such as the inability to negotiate a >>> matching codec, since even without a matching language, it still may be >>> useful to successfully negotiate media characteristics and bring up the >>> call. Therefore it is not clear to me how much value the "*" has in the >>> current draft, regardless of how it is defined. >>> >>> For example, if the callee has policy that dictates that it will >>> always accept the call (e.g. a PSAP), the callee might always ignore th= e >>> "*". This might be frustrating to the caller, but the caller may still >>> choose not to terminate the call. >>> >>> Even if the callee cares deeply about a matching language (e.g. a >>> voice recognition or chat bot system that is only supports a subset of >>> languages), the callee might still choose to ignore the "*". >>> >>> For example, the callee might accept the call in order to provide >>> information to the caller (e.g. a pre-recorded voice or text message >>> indicating that the caller's languages are not supported). >>> >>> >>> The draft has said for some time that the asterisk is nothing more tha= n >>> advisory, and has explicitly said that the callee is free to ignore eit= her >>> the presence or absence of an asterisk: >>> >>> The called party MAY ignore the indication, e.g., for the emergency >>> services use case, regardless of the absence of an asterisk, a PSAP >>> will likely not fail the call; some call centers might reject a cal= l >>> even if the offer contains an asterisk. >>> >>> Therefore, if the asterisk is causing heartburn, we can remove it >>> without technical impact. >>> >>> --Randy >>> >>> >>> On Wed, Jul 26, 2017 at 1:46 PM, Paul Kyzivat <>> paul.kyzivat@comcast.net>paul.kyzivat@comcast.net>>> comcast.net>paul.kyzivat@comcast.net> wrote: >>> >>> On 7/26/17 2:35 PM, Randall Gellens wrote: >>> >>> Why don't we just take out of the current draft the asterisk and the >>> ability to indicate a caller preference to not fail the call? Then Gunn= ar's >>> draft(s) are free to use the asterisk. >>> >>> >>> Then what is the expectation regarding whether to accept a call with >>> no matching language? >>> >>> I guess it would make the most sense for the callee to accept the cal= l >>> unless he doesn't want a call without matching language. Then if the ca= llee >>> does accept the call without the matching language the caller can still >>> terminate the call once he realizes that is the situation. >>> >>> That seems reasonable to me. >>> >>> Thanks, >>> Paul >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> >>> SLIM@ietf.org> >>> SLIM@ietf.org >>> >>> >>> <https://www. >>> ietf.org/mailman/listinfo/slim>>> /listinfo/slim>https://www.ietf.org/mailman/listinfo/slim >>> >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> >>> https://www.ietf >>> .org/mailman/listinfo/slim >>> >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself onl= y >>> -------------- Randomly selected tag: --------------- >>> It isn't pollution that's harming the environment. It's the >>> impurities in our air and water that are doing it. >>> --Dan Quayle (then-U.S. Vice-President) >>> >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >>> >> >> >> > -- > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > --001a11478fea984d7f0555b84b4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A potential resolution has been proposed to Issue 26: Dele= te the Asterisk.=C2=A0

Are there any objections to this = approach?

On Tue, Aug 1, 2017 at 2:46 PM, Gunnar Hellstr=C3=B6m <gunna= r.hellstrom@omnitor.se> wrote:
Den 2017-07-27 kl. 01:11, skrev Randall Gellens:
At 3:20 PM -0700 7/26/17, Bernard Aboba wrote:

=C2=A0Randy said:

=C2=A0"Therefore, if the asterisk is causing heartburn, we can remove = it without technical impact."

=C2=A0[BA] Unless there is some compelling reason to keep it, removing the = "*" might be the simplest way to resolve Issue 26.

There is no compelling reason to keep it, especially since it's purely = advisory.

I suggest we delete it, revise the draft, and advance it.=C2=A0 In my view,= we've spent far too much time on the asterisk, which is a supremely tr= ivial aspect of the draft.

--Randy
 +1
Gunnar



=C2=A0On Wed, Jul 26, 2017 at 3:12 PM, Randall Gellens <<mailto:rg+ietf@randy.p= ensive.org>rg+ietf@randy.pensive.org> wrote:

=C2=A0At 2:35 PM -0700 7/26/17, Bernard Aboba wrote:

=C2=A0 Paul said:

=C2=A0 "Then what is the expectation regarding whether to accept a cal= l with no matching language?"

=C2=A0 I guess it would make the most sense for the callee to accept the ca= ll unless he doesn't want a call without matching language. Then if the= callee does accept the call without the matching language the caller can s= till terminate the call once he realizes that is the situation.

=C2=A0 That seems reasonable to me."

=C2=A0 [BA] The inability to negotiate a matching language is different fro= m other SDP negotiation failures such as the inability to negotiate a match= ing codec, since even without a matching language, it still may be useful t= o successfully negotiate media characteristics and bring up the call. There= fore it is not clear to me how much value the "*" has in the curr= ent draft, regardless of how it is defined.

=C2=A0 For example, if the callee has policy that dictates that it will alw= ays accept the call (e.g. a PSAP), the callee might always ignore the "= ;*".=C2=A0 This might be frustrating to the caller, but the caller may= still choose not to terminate the call.

=C2=A0 Even if the callee cares deeply about a matching language (e.g. a vo= ice recognition or chat bot system that is only supports a subset of langua= ges), the callee might still choose to ignore the "*".

=C2=A0 For example, the callee might accept the call in order to provide in= formation to the caller (e.g. a pre-recorded voice or text message indicati= ng that the caller's languages are not supported).


=C2=A0The draft has said for some time that the asterisk is nothing more th= an advisory, and has explicitly said that the callee is free to ignore eith= er the presence or absence of an asterisk:

=C2=A0 =C2=A0 The called party MAY ignore the indication, e.g., for the eme= rgency
=C2=A0 =C2=A0 services use case, regardless of the absence of an asterisk, = a PSAP
=C2=A0 =C2=A0 will likely not fail the call; some call centers might reject= a call
=C2=A0 =C2=A0 even if the offer contains an asterisk.

=C2=A0Therefore, if the asterisk is causing heartburn, we can remove it wit= hout technical impact.

=C2=A0--Randy


=C2=A0 On Wed, Jul 26, 2017 at 1:46 PM, Paul Kyzivat <<mailto:<mai= lto:paul.kyzi= vat@comcast.net>paul.kyzivat@comcast.net><mailto:paul.kyzivat@comcast= .net>p= aul.kyzivat@comcast.net> wrote:

=C2=A0 On 7/26/17 2:35 PM, Randall Gellens wrote:

=C2=A0 Why don't we just take out of the current draft the asterisk and= the ability to indicate a caller preference to not fail the call? Then Gun= nar's draft(s) are free to use the asterisk.


=C2=A0 Then what is the expectation regarding whether to accept a call with= no matching language?

=C2=A0 I guess it would make the most sense for the callee to accept the ca= ll unless he doesn't want a call without matching language. Then if the= callee does accept the call without the matching language the caller can s= till terminate the call once he realizes that is the situation.

=C2=A0 That seems reasonable to me.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul


=C2=A0 _______________________________________________
=C2=A0 SLIM mailing list

<mailto:<mailto:SL= IM@ietf.org>= SLIM@ietf.org><mailto:SLIM@ietf.org>SLIM@ietf.org


<<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim><https://www.ietf.org/mailman/listinfo/slim= >https://www.ietf.org/mailman/listinfo/slim



=C2=A0 _______________________________________________
=C2=A0 SLIM mailing list
=C2=A0 <mailto:SLIM@i= etf.org>SLIM@iet<= wbr>f.org

<https://www.ietf.org/mailman/listinfo/slim>= ;https://www.ietf.org/mailman/listinfo/slim



=C2=A0--
=C2=A0Randall Gellens
=C2=A0Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I= speak for myself only
=C2=A0-------------- Randomly selected tag: ---------------
=C2=A0It isn't pollution that's harming the environment.=C2=A0 It&#= 39;s the
=C2=A0impurities in our air and water that are doing it.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--Dan Quayle = (then-U.S. Vice-President)



=C2=A0_______________________________________________
=C2=A0SLIM mailing list
=C2=A0SLIM@ietf.org<= br> =C2=A0https://www.ietf.org/mailman/listinfo/slim<= br>



--
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hel= lstrom@omnitor.se
+46 708 204 288


--001a11478fea984d7f0555b84b4d-- From nobody Mon Aug 7 11:29:07 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AFD1327ED; Mon, 7 Aug 2017 11:29:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150213054570.19041.5979593327993029872@ietfa.amsl.com> Date: Mon, 07 Aug 2017 11:29:05 -0700 Archived-At: Subject: [Slim] I-D Action: draft-ietf-slim-multilangcontent-11.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 18:29:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Selection of Language for Internet Media WG of the IETF. Title : Multiple Language Content Type Authors : Nik Tomkinson Nathaniel Borenstein Filename : draft-ietf-slim-multilangcontent-11.txt Pages : 20 Date : 2017-08-07 Abstract: This document defines an addition to the Multipurpose Internet Mail Extensions (MIME) standard to make it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-slim-multilangcontent-11 https://datatracker.ietf.org/doc/html/draft-ietf-slim-multilangcontent-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-multilangcontent-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 7 23:15:58 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FA412420B; Mon, 7 Aug 2017 23:15:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: Cc: slim@ietf.org, draft-ietf-slim-multilangcontent.all@ietf.org, ietf@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150217294315.12399.13728808737116015156@ietfa.amsl.com> Date: Mon, 07 Aug 2017 23:15:43 -0700 Archived-At: Subject: [Slim] Opsdir last call review of draft-ietf-slim-multilangcontent-11 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 06:15:43 -0000 Reviewer: Dan Romascanu Review result: Ready Ready. This document extends MIME with the capability of supporting sending one message that contains multiple language versions of the same information. Translations are identified by a language tag and selected by the email client based on a user's language settings. The document belongs to the application space and there are no direct implications for the operators of networks. An RFC 5706 review does not apply. The document is Ready from an operational and manageability point of view. Some information or references about possible errors and how application debugging is performed in cases of errors would have been useful - I suppose that such information may be included in other MIME documents. From nobody Tue Aug 8 18:56:55 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AD6131CEC; Tue, 8 Aug 2017 18:56:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Hoffman To: Cc: slim@ietf.org, draft-ietf-slim-multilangcontent.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150224380784.3639.13154779501460690796@ietfa.amsl.com> Date: Tue, 08 Aug 2017 18:56:47 -0700 Archived-At: Subject: [Slim] Secdir last call review of draft-ietf-slim-multilangcontent-11 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 01:56:48 -0000 Reviewer: Paul Hoffman Review result: Ready This document simply allows a MIME message to say that it contains more than one (human) language. It follows the MIME spec closely and makes a completely obvious addition to the MIME spec. The two security considerations listed are both far stretches; this protocol extension does not create any significant security issues. From nobody Wed Aug 9 03:18:48 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C72C126BF3; Wed, 9 Aug 2017 03:18:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150227391501.3690.8543824502048004814@ietfa.amsl.com> Date: Wed, 09 Aug 2017 03:18:35 -0700 Archived-At: Subject: [Slim] I-D Action: draft-ietf-slim-multilangcontent-12.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 10:18:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Selection of Language for Internet Media WG of the IETF. Title : Multiple Language Content Type Authors : Nik Tomkinson Nathaniel Borenstein Filename : draft-ietf-slim-multilangcontent-12.txt Pages : 20 Date : 2017-08-09 Abstract: This document defines an addition to the Multipurpose Internet Mail Extensions (MIME) standard to make it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-slim-multilangcontent-12 https://datatracker.ietf.org/doc/html/draft-ietf-slim-multilangcontent-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-multilangcontent-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 11 05:15:30 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4765B13261B; Fri, 11 Aug 2017 05:15:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150245372122.24535.15257036769785001856@ietfa.amsl.com> Date: Fri, 11 Aug 2017 05:15:21 -0700 Archived-At: Subject: [Slim] I-D Action: draft-ietf-slim-multilangcontent-13.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 12:15:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Selection of Language for Internet Media WG of the IETF. Title : Multiple Language Content Type Authors : Nik Tomkinson Nathaniel Borenstein Filename : draft-ietf-slim-multilangcontent-13.txt Pages : 21 Date : 2017-08-11 Abstract: This document defines an addition to the Multipurpose Internet Mail Extensions (MIME) standard to make it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-slim-multilangcontent-13 https://datatracker.ietf.org/doc/html/draft-ietf-slim-multilangcontent-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-multilangcontent-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 15 05:24:26 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B041913219E; Tue, 15 Aug 2017 05:24:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-slim-multilangcontent@ietf.org, Bernard Aboba , slim-chairs@ietf.org, bernard.aboba@gmail.com, slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150279986062.20971.4568019868114855413.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 05:24:20 -0700 Archived-At: Subject: [Slim] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-slim-multilangcontent-13=3A_=28with_COMMENT=29?= X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 12:24:21 -0000 Mirja Kühlewind 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: ---------------------------------------------------------------------- Minor comments: - sec 3.2: "If there is a From field present, its value MUST include the same email address as the top-level From header..." What happen if they are no the same? The security considerations section mentions this case but there is no guidance given what to do in this case (which address to display)? - The security considerations section mentions the risk that the content might actually be different in different languages. I think it would be nice to give some recommendation that there SHOULD be a way for the user to see all content fields. From nobody Tue Aug 15 16:10:24 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 176BA132428; Tue, 15 Aug 2017 16:10:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-slim-multilangcontent@ietf.org, Bernard Aboba , slim-chairs@ietf.org, bernard.aboba@gmail.com, slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150283861901.12577.8051576617087935003.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 16:10:19 -0700 Archived-At: Subject: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 23:10:19 -0000 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 nobody Wed Aug 16 15:10:18 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A1A132710; Wed, 16 Aug 2017 15:10:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-slim-multilangcontent@ietf.org, Bernard Aboba , slim-chairs@ietf.org, bernard.aboba@gmail.com, slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150292141204.12197.13535898303505156655.idtracker@ietfa.amsl.com> Date: Wed, 16 Aug 2017 15:10:12 -0700 Archived-At: Subject: [Slim] Ben Campbell's Yes on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 22:10:12 -0000 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 nobody Wed Aug 16 16:50:08 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 517B2132143; Wed, 16 Aug 2017 16:50:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-slim-multilangcontent@ietf.org, Bernard Aboba , slim-chairs@ietf.org, bernard.aboba@gmail.com, slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150292740024.12316.10186295594648032334.idtracker@ietfa.amsl.com> Date: Wed, 16 Aug 2017 16:50:00 -0700 Archived-At: Subject: [Slim] Adam Roach's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 23:50:00 -0000 Adam Roach 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: ---------------------------------------------------------------------- I note that this mechanism uses only language tags and implicitly leaves aside any discussion of script or region tags. I'm going to assume this was a intentional decision that was considered by the group with the end result being that there was no perceived need to distinguish between (e.g.) Latin and Jawi scripts for Malay, or (e.g.) Brazilian and Portuguese variations of 'pt'. (If this was not an explicit decision made by the WG, I would ask that it be posed to the WG for an explicit decision -- the current mechanism seems somewhat deficient in this regard from my admittedly brief analysis of the situation.) I'm a little worried that an imprecise reading by implementors of the citation to RFC5646 may lead them to believe that script and region tags may be included in the Content-Language header fields. If the assumptions I discuss above are true, please add text making it clear that script and region tags are forbidden. From nobody Thu Aug 17 02:27:22 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06FB13247A; Thu, 17 Aug 2017 02:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=P2/AvmPB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XHQaVGnB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHlz9QBf9xml; Thu, 17 Aug 2017 02:27:20 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77EB13281F; Thu, 17 Aug 2017 02:27:14 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 42AA520C12; Thu, 17 Aug 2017 05:27:14 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 17 Aug 2017 05:27:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=GOXwcEJHKT4RdzobE8UGZKqd3lSWn dlDr4yVOZwgee0=; b=P2/AvmPB35yCd+k+obPe95CRK8v5OONY2LUsjj04+Sj5k 1xCE6a8/S7Nho9lVhQn/3xFAVZE23dOtnQos2QAOJlGBO3AhsMbluYoh/LKpkDCh LEyL+1mtkkCGJ4p+ZUBau9c7i74Hfv9jwkuOeqUB9O44NNNHr4SsEu1XnTfYRjBK hNtxy2vxFm4+hfA3el3i0Xjb9fhZP3kMAvEOvQnO3Q/LAcF/MOYoouExsyUJmnon VpvPi1R8PbiDl5nVN7e1YRZz5+/Z2ySr8BGjEE/rTDmz2pSvuijzStLs4z5M1p2U mKv7aJNOr0/S4seqHgcz375MUcdywaCqa3CfJYk0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=GOXwcE JHKT4RdzobE8UGZKqd3lSWndlDr4yVOZwgee0=; b=XHQaVGnBr/kBs27FRrWMEw U+/m5DKupWRFw0hBOy5NkkhMrLMpgTSs0Qqydnby4BDM6O+3zInqabSti+QFDqZg oPrQWIAlswx7D6axsk2igDXMtbL9TnomxWDE0F9SaZbLGTNZzDi8K/8e+WOAuiJQ l4+tJBRCAmaKXUeSONp1Xa9YaIdsDJPOdxLoYnqofvUaYyzKBZTtWg/2o7s+JtDU TyRXp2YgwNj/CfmbxRmUfmZGZwRNg2t1Vz+KYcLe7jd4/FxNtnjZUKybEGSsLvBe 9/lp0O7aIElt0p/JJjCIRr8bF2Cp1Dptba8rnE4jK64Age/gHL/XXkSITUYkal9g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 06B299E308; Thu, 17 Aug 2017 05:27:14 -0400 (EDT) Message-Id: <1502962033.1590356.1076217016.709F842F@webmail.messagingengine.com> From: Alexey Melnikov To: Eric Rescorla , The IESG Cc: slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 Date: Thu, 17 Aug 2017 10:27:13 +0100 In-Reply-To: <150283861901.12577.8051576617087935003.idtracker@ietfa.amsl.com> References: <150283861901.12577.8051576617087935003.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 09:27:21 -0000 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. 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? > > From nobody Thu Aug 17 02:29:44 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B2413247A; Thu, 17 Aug 2017 02:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Q8tXIedn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XuaT1RFS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8iPUOLlEz5F; Thu, 17 Aug 2017 02:29:36 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B76132358; Thu, 17 Aug 2017 02:29:36 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id F2AA020CF0; Thu, 17 Aug 2017 05:29:35 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 17 Aug 2017 05:29:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=+gzLtMk9IlYEUuiX7DqRGp1G0gHly IRQrRVjgzWX4zE=; b=Q8tXIednp8jec7f7KTvEkoXSUMsOEb+zBj6KLfYeQ1xJo gV/NtNmCrc9HE+nuc+sGgYHkWshIA9CVy+uA6pr/OgJTVBTSUjFZeqLlAi1K0LGJ 6H88OmUao925cb2IzTsLkE1rbzrqzRjHzjbdquDVRWk0V9bmwAjBu1PdgVxBqn8A Gl1Z6bJUdd52ipizZtAY4UuxRhBbBNonJn1VwvbwnABtTZwcFa2R64EPzcMvGuIP GHzXEwDEzFJxvldSGbZXR33j6B8IunAbj19Hoq0f2t+oqarNi4/6ZslsCKYYso42 IhTMqXgDU8aUiYzjGbeXxsvqrFuhTQMYnK2Tip+Lg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+gzLtM k9IlYEUuiX7DqRGp1G0gHlyIRQrRVjgzWX4zE=; b=XuaT1RFST2h526d0jMBNFt XqrhZYbP1icfS6wSd07G/8Rtcb9iNFT2Cvfbl7c/lw+MFDhr44hyerUyhNgWxTr2 PNsj3iLrdI2JWrwQxh8n2dyyU6ztKBFsk5KPhAD1WAefZDu+gNEVO6ceGCtK+uG7 a5JftOvpkMyb5L4+qAgMESTp0V5bWaLmx3Yi24D2Io0rvRKEMcZM2RoQ+frpvBE2 Falcj64K5J5hdOlJaZhLXfs5NlgnDwUmYb/fu8bsqS17DFrnTfB/udb8BqQVHW9M IPKnud/Lj0Oa+KL/Pj0P1JARXvPGxn19HFsd5m8fDMfy55XpTWvdthrTmFQyE4xA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C7FA49E308; Thu, 17 Aug 2017 05:29:35 -0400 (EDT) Message-Id: <1502962175.1590900.1076220224.097DD098@webmail.messagingengine.com> From: Alexey Melnikov To: Adam Roach , The IESG Cc: slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 References: <150292740024.12316.10186295594648032334.idtracker@ietfa.amsl.com> In-Reply-To: <150292740024.12316.10186295594648032334.idtracker@ietfa.amsl.com> Date: Thu, 17 Aug 2017 10:29:35 +0100 Archived-At: Subject: Re: [Slim] Adam Roach's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 09:29:38 -0000 Hi Adam, On Thu, Aug 17, 2017, at 12:50 AM, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-slim-multilangcontent-13: No Objection > I note that this mechanism uses only language tags and implicitly leaves > aside > any discussion of script or region tags. Actually this is not true. Language Tags as specified in RFC 5646 can optionally include all of these things. > I'm going to assume this was a > intentional decision that was considered by the group with the end result > being > that there was no perceived need to distinguish between (e.g.) Latin and > Jawi > scripts for Malay, or (e.g.) Brazilian and Portuguese variations of 'pt'. > (If > this was not an explicit decision made by the WG, I would ask that it be > posed > to the WG for an explicit decision -- the current mechanism seems > somewhat > deficient in this regard from my admittedly brief analysis of the > situation.) > > I'm a little worried that an imprecise reading by implementors of the > citation > to RFC5646 may lead them to believe that script and region tags may be > included > in the Content-Language header fields. They are absolutely allowed. > If the assumptions I discuss above > are > true, please add text making it clear that script and region tags are > forbidden. Best Regards, Alexey From nobody Thu Aug 17 02:41:48 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BBF132358; Thu, 17 Aug 2017 02:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=5UY7O1SA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bosdnFEi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77Sd2O2VmFKt; Thu, 17 Aug 2017 02:41:40 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C22C1321A8; Thu, 17 Aug 2017 02:41:40 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E3D8120F48; Thu, 17 Aug 2017 05:41:39 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 17 Aug 2017 05:41:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=m2xgeGhei4kjLvOTj+A5lRlmM8dUo ZT138lO3ZuKuQw=; b=5UY7O1SAPw8FC6Lq4CUS459OvIZuKQfAxxE213C502i95 xZo9ni2507hsmiwlgnLW6i7ZXcl+BJiGwbEOwQhpKTpaKg1lTcK1n2Nha9IS4u8k fm22vXFmp2Uhb9w21LblJaO4naJnb+B66hUykXn2dEXVmTTBgRDZWF9I4RLqiLHZ xJ6Lyz11B6/fETHBwmjvEepRcTUfLnTM6iBk42QZyv4hnZgl6e2YTwct8O55nLdp kUZH352uzI3TX4262eSNIc6vEB1+FrSD8Gsh9UzaRYzvSd+Q9GQ7ZR0kETzDIZRb V8NnjGvDl6NeUmBJv13gDoaSKGMmHUmrqfiktxmyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=m2xgeG hei4kjLvOTj+A5lRlmM8dUoZT138lO3ZuKuQw=; b=bosdnFEiJMeey6WxBzpY4u fubb53cqhtzxGJjv5JZO4CnentigzOSixI1ickmGjnDQpX6F2QyTNwkKyXPTlMO/ bJc4QJp4twta0rz0GP3DibwQgufb9Nw2x7Z3h21nzHJh920tYovQ1UXxQOaTXQju YvFEcEZmnSpT/iol4dafrqlaFbddFmnW4hKnhJPkvs2r2kCxWwA44t9rMI9Rer0I eOxjZtfRq9jjrd+nCA30QWWwYWoujU9Zajh5v3hiW/fkuparpBsYNV++IKcQxBoi Jn03o6Y3rxla7nqHMULdY+3AmVsTDOQPOtAlxqZ1nJydyhRTQxgA/FwQhlcvrwWw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C2A7D9E308; Thu, 17 Aug 2017 05:41:39 -0400 (EDT) Message-Id: <1502962899.1592674.1076222888.5B74D570@webmail.messagingengine.com> From: Alexey Melnikov To: Ben Campbell , The IESG Cc: slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 Date: Thu, 17 Aug 2017 10:41:39 +0100 In-Reply-To: <150292141204.12197.13535898303505156655.idtracker@ietfa.amsl.com> References: <150292141204.12197.13535898303505156655.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 09:41:42 -0000 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 From nobody Thu Aug 17 02:54:59 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4B4132418; Thu, 17 Aug 2017 02:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpyuPvKFhfK0; Thu, 17 Aug 2017 02:54:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E8A13239C; Thu, 17 Aug 2017 02:54:55 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7H9slKS063636 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Aug 2017 04:54:49 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Alexey Melnikov , The IESG Cc: slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com References: <150292740024.12316.10186295594648032334.idtracker@ietfa.amsl.com> <1502962175.1590900.1076220224.097DD098@webmail.messagingengine.com> From: Adam Roach Message-ID: Date: Thu, 17 Aug 2017 04:54:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1502962175.1590900.1076220224.097DD098@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Slim] Adam Roach's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 09:54:57 -0000 On 8/17/17 4:29 AM, Alexey Melnikov wrote: > Hi Adam, > > On Thu, Aug 17, 2017, at 12:50 AM, Adam Roach wrote: >> Adam Roach has entered the following ballot position for >> draft-ietf-slim-multilangcontent-13: No Objection >> I note that this mechanism uses only language tags and implicitly leaves >> aside >> any discussion of script or region tags. > Actually this is not true. Language Tags as specified in RFC 5646 can > optionally include all of these things. > >> I'm going to assume this was a >> intentional decision that was considered by the group with the end result >> being >> that there was no perceived need to distinguish between (e.g.) Latin and >> Jawi >> scripts for Malay, or (e.g.) Brazilian and Portuguese variations of 'pt'. >> (If >> this was not an explicit decision made by the WG, I would ask that it be >> posed >> to the WG for an explicit decision -- the current mechanism seems >> somewhat >> deficient in this regard from my admittedly brief analysis of the >> situation.) >> >> I'm a little worried that an imprecise reading by implementors of the >> citation >> to RFC5646 may lead them to believe that script and region tags may be >> included >> in the Content-Language header fields. > They are absolutely allowed. Wow. If I had gone to implement this, I would have gotten it 100% wrong, and argued with anyone who told me as much. The document says: The Content-Language MUST comply with RFC 3282 [RFC3282] (which defines the Content-Language field) and BCP 47/RFC 5646 [RFC5646] (which defines the structure and semantics for the language code values). What is worth taking note of here is the fact that this says "language *code* values," not "language *tag* values." RFC 5646 defines a Language _Tag_ (e.g., "sr-Latn-RS"), that is composed of a Language _Code_ (e.g., "sr") followed by an optional Script Code (e.g., "Latn") and an optional Country Code (e.g., "RS"). As if to reinforce this, the examples then show values of the Content-Language header field that consist exclusively of language codes, even though it predominantly uses two languages with regional variations (en and es): to my eye, "en" by itself looks strange, as I'm used to always seeing that language written as either "en-US" or "en-GB". So I would suggest (a) the passage above be changed to say "...for the language tag values...", and (b) the examples be amended to show more than simple language codes; e.g.: Content-Language: en-US Content-Language: de Content-Language: es-ES, fr Content-Language: sr-Cyrl /a From nobody Thu Aug 17 03:15:12 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE351323B4; Thu, 17 Aug 2017 03:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=gR8i5EIl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XnGdgUd4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p2ORf3a72iP; Thu, 17 Aug 2017 03:15:09 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EA2126B71; Thu, 17 Aug 2017 03:15:09 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A4E7720DBF; Thu, 17 Aug 2017 06:15:08 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 17 Aug 2017 06:15:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=PR9P5tDnzrqDtz4zao6TZ5C4Yi7Gs BXeRCchffM5uwA=; b=gR8i5EIl9R9I3cRN6ypHz/zMNRL3BkKt8bwAP9NmPFPlX NDrWTEnBuOemFKYwips/4o0pfptESJjJnjiehCMBBOds9QJqEtnNQcy2JbtYwv0J Q+y+UyhMun49hRQR9tGdziLJ9i9s/gmQsMVhdw154T+NuX8i0QldAyRk38Adpa9A BTrnHyb6/2eeptSiMpCWRyllpYzkqTJQRAKEAspFBDMddIhYR2DVwspUnzUQI4Do 6feZ0M7asqjtKTluS/6y9y7IKuW+xj9ulLHhiGo+QqID58RjRTp6d3BQ7vZ7rcvd jLw5pOroRHaUCF9KbYfC3F4CIUonyGU394H5togZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=PR9P5t DnzrqDtz4zao6TZ5C4Yi7GsBXeRCchffM5uwA=; b=XnGdgUd40ohWXrJP1tJ6W9 LvO9G7qbdnAz+uzHKbICgqS4JL6+0IzLjYOuAA6Ls4DA/OcDER5+8eRrBXIkteyT N1fHKrckNDX7q7sgeimNlmNrPEAd4PLBmG36iQuO+vOhmw+ralV0QdOJIpW/8NfH eK4eG37gPYUhNs2n6P+ftEjcaqJKZaqz4Er8FGFKbO5/wdccTsmSlCpcNSkK/cAw o0y3bK26GHTQqHwU+ohFsRP2D5qoEB5V0/nj/wERFE84gtUHgn1OpmoKp22yzD/s 96SKF8G0VmVL0ociitvNr9+eu8+cgL430oq6GG1iCq867LB4NFGrY2ILqTMzwSsg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 82ECA9E30E; Thu, 17 Aug 2017 06:15:08 -0400 (EDT) Message-Id: <1502964908.2431249.1076255576.026440DD@webmail.messagingengine.com> From: Alexey Melnikov To: Adam Roach , The IESG Cc: slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 In-Reply-To: References: <150292740024.12316.10186295594648032334.idtracker@ietfa.amsl.com> <1502962175.1590900.1076220224.097DD098@webmail.messagingengine.com> Date: Thu, 17 Aug 2017 11:15:08 +0100 Archived-At: Subject: Re: [Slim] Adam Roach's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 10:15:11 -0000 Hi Adam, On Thu, Aug 17, 2017, at 10:54 AM, Adam Roach wrote: > On 8/17/17 4:29 AM, Alexey Melnikov wrote: > > Hi Adam, > > > > On Thu, Aug 17, 2017, at 12:50 AM, Adam Roach wrote: > >> Adam Roach has entered the following ballot position for > >> draft-ietf-slim-multilangcontent-13: No Objection > >> I note that this mechanism uses only language tags and implicitly leaves > >> aside > >> any discussion of script or region tags. > > Actually this is not true. Language Tags as specified in RFC 5646 can > > optionally include all of these things. > > > >> I'm going to assume this was a > >> intentional decision that was considered by the group with the end result > >> being > >> that there was no perceived need to distinguish between (e.g.) Latin and > >> Jawi > >> scripts for Malay, or (e.g.) Brazilian and Portuguese variations of 'pt'. > >> (If > >> this was not an explicit decision made by the WG, I would ask that it be > >> posed > >> to the WG for an explicit decision -- the current mechanism seems > >> somewhat > >> deficient in this regard from my admittedly brief analysis of the > >> situation.) > >> > >> I'm a little worried that an imprecise reading by implementors of the > >> citation > >> to RFC5646 may lead them to believe that script and region tags may be > >> included > >> in the Content-Language header fields. > > They are absolutely allowed. > > Wow. If I had gone to implement this, I would have gotten it 100% wrong, > and argued with anyone who told me as much. The document says: > > The Content-Language MUST comply with RFC 3282 [RFC3282] (which > defines the Content-Language field) and BCP 47/RFC 5646 [RFC5646] > (which defines the structure and semantics for the language code > values). > > > What is worth taking note of here is the fact that this says "language > *code* values," not "language *tag* values." RFC 5646 defines a Language > _Tag_ (e.g., "sr-Latn-RS"), that is composed of a Language _Code_ (e.g., > "sr") followed by an optional Script Code (e.g., "Latn") and an optional > Country Code (e.g., "RS"). Good point. Content-Language is defined for language tags, we didn't change that. I don't think the above difference was intentional. Authors? > As if to reinforce this, the examples then show values of the > Content-Language header field that consist exclusively of language > codes, even though it predominantly uses two languages with regional > variations (en and es): to my eye, "en" by itself looks strange, as I'm > used to always seeing that language written as either "en-US" or "en-GB". > > So I would suggest (a) the passage above be changed to say "...for the > language tag values...", and (b) the examples be amended to show more > than simple language codes; e.g.: > > Content-Language: en-US > > Content-Language: de > > Content-Language: es-ES, fr > > Content-Language: sr-Cyrl Yes, good idea to use better examples. From nobody Thu Aug 17 06:00:27 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153271323C6 for ; Thu, 17 Aug 2017 06:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UguzxrOVmO9J for ; Thu, 17 Aug 2017 06:00:24 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78222132400 for ; Thu, 17 Aug 2017 06:00:19 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id n83so12462834ywn.2 for ; Thu, 17 Aug 2017 06:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BI0U6DrgNiY44ftCyFlqqSnwkXEG97bwZvb9VahtLO0=; b=mOUGJui5UsWB2H5farrpunKm31x30MXJ9TqrVSTyTwZr+nYOWVWiILEt6OQZZEkQ39 rwdAgfDsqo4Src4QAz1Dc8rqCoDtvXyuBh9PB1hmEJMR8NjCcna0ZRqP3YvWA/k/OZTF 2Lvd4bWnZzYZ7N0z8IQPUVCeu6sBVi+SoQtv6SjRMsh5w/d/zGTHmsINmsSvS+1DkvBi qLWcoXuofxVm1Syf+rzUJ6EWN8OhrSB/Ws8n2eUlCe5a8qefUBz0XtHesvfDU8JRqKES YwdT6q4v/E1jHDpdy0PICCViEE0WWfjiSFXj0G7bP0yw+8q0sp7JieQCUunm/OvPyei7 hNfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BI0U6DrgNiY44ftCyFlqqSnwkXEG97bwZvb9VahtLO0=; b=jmCqy8Iaz6sYKGSPQr7khaJMgy88fpJG3HE1V26Ub3JfoATaWp/swIgBviCq5a0HPP PR/7FM6i1twQrMch/iRdfAY+LbMEAGqSA4DGUgk0rtnEQRMDQcSHkfuF5GeYzk3dOnyo 4UNAZmT8u1gvZR8As/cH4isNsQ1oDojO+F/ZPjBCB4/GlwYigclwL+cVjH0YSLySh+ZU 0CgHdCKBBbEBZBFuElPPNvy+HICCX526QvvWfR9GqCQgeRnqLV2xs+olvjTsaXBn9lVd iJrCs7dOB2mb3+MtSzSKEg4G8C4uqC3/WEqi2tlNx3lE9qmgeMPHAIQzhHCse7CRFEiw Q5Fg== X-Gm-Message-State: AHYfb5haZSWwF3Ft2f1pVpvOaolLqGofzYv/31eoNKSeRHaKY2KlBCZ8 0pkjPjsmD359l5l7GsYCDXk6uMDjaUCW X-Received: by 10.129.71.212 with SMTP id u203mr4505296ywa.72.1502974818424; Thu, 17 Aug 2017 06:00:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Thu, 17 Aug 2017 05:59:37 -0700 (PDT) In-Reply-To: <1502962033.1590356.1076217016.709F842F@webmail.messagingengine.com> References: <150283861901.12577.8051576617087935003.idtracker@ietfa.amsl.com> <1502962033.1590356.1076217016.709F842F@webmail.messagingengine.com> From: Eric Rescorla Date: Thu, 17 Aug 2017 05:59:37 -0700 Message-ID: To: Alexey Melnikov Cc: The IESG , slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, Bernard Aboba Content-Type: multipart/alternative; boundary="001a114d78f628d1230556f298d4" Archived-At: Subject: Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 13:00:26 -0000 --001a114d78f628d1230556f298d4 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 2:27 AM, Alexey Melnikov 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) -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? > > > > > --001a114d78f628d1230556f298d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 17, 2017 at 2:27 AM, Alexey Melnikov <= aamelnikov@fast= mail.fm> 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 i= f you have an MUA which
> doesn't understand this document you get the preface as the first<= br> > thing you see. That doesn't seem crazy, but isn't the common c= ase 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 th= e
first part will be displayed first (otherwise why the requireme= nt)

-Ekr
=C2=A0

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

--001a114d78f628d1230556f298d4-- From nobody Thu Aug 17 06:12:29 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFF4132400; Thu, 17 Aug 2017 06:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=XulnPOLp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Q09KG9qg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7YgLkoKaRGn; Thu, 17 Aug 2017 06:12:27 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526491323AC; Thu, 17 Aug 2017 06:12:26 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C1BC520C64; Thu, 17 Aug 2017 09:12:25 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 17 Aug 2017 09:12:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=3t1jQYxOdO1o+x6asCS5UukU87nm3 s4m2Fds+Ivjxlg=; b=XulnPOLpaUNab+YE56WdnuRL0SkQ5J+99LMLXoWiM9jjh wXTD3YoYdzrAOAiJGY0eYiUevjr66PcxpDZQl9o7XGDQ5Z/Z9XHYtaubmyi4rcOX jOC0hBsHIz9TtyfdMyTCzEHLRV8seyM5FmCsLeESMOAyrnc0jxQpWe/SoP0QWK7B 2UYc0HtgT6iCVYgknyKsQizY79GBwkq1QFjfuQsBiEzhVZfwSxrilmPxz2YcXe8J Of1W8FUxJ013xEUrVqOY4SJ+5JLYajO+W792YGqXOLZ5eSMsm1o+VSXgxE+y7Ah8 vFFz7ufmdiX8dTtky0S0HwVLT7jTMTwEi80CuCEtA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3t1jQY xOdO1o+x6asCS5UukU87nm3s4m2Fds+Ivjxlg=; b=Q09KG9qg1ct+x3fxn82wNy JCvZ+5HnGU6kYfxMO1XYnmGeplLzZYjRy+7Oo5HWfoQ3fOHRn7rBItJ97omQBuDS +WGzQAhexLk3bTfrtZSfyvjh0L9NT6FlZT0hLKEgFzG38TKz2X50NToJFNouvKgX BbT9nYlDs0l0HFa1hNnl+1KOBDMYeffbsABMEztp6k5l/RLKatUwtH3OEuIiP6oS YFvdY5RYeEw3gFu7R9mCluISqdIHIHCVEAh/fGxDgCE/twzq1rvwDUUk8ewC5d/z LdXO1YMH5VOpypo/m7DHUVEpFVk9gbSQ/zu7Ho4BJQxpp1U4eTWf+zTAe8TLl0wA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9220A9E308; Thu, 17 Aug 2017 09:12:25 -0400 (EDT) Message-Id: <1502975545.35612.1076405336.64591061@webmail.messagingengine.com> From: Alexey Melnikov To: Eric Rescorla Cc: The IESG , slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, Bernard Aboba MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1502975545356120" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 Date: Thu, 17 Aug 2017 14:12:25 +0100 In-Reply-To: References: <150283861901.12577.8051576617087935003.idtracker@ietfa.amsl.com> <1502962033.1590356.1076217016.709F842F@webmail.messagingengine.com> Archived-At: Subject: Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 13:12:28 -0000 This is a multi-part message in MIME format. --_----------=_1502975545356120 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, Aug 17, 2017, at 01:59 PM, Eric Rescorla wrote: > > > On Thu, Aug 17, 2017 at 2:27 AM, Alexey Melnikov > 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? >> > >> > --_----------=_1502975545356120 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, Aug 17, 2017, at 01:59 PM, Eric Rescorla wrote:


On Thu, Aug 17, 2017 at 2:27 AM, Alexey Melnikov <aamelnikov@fastmail.fm> 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?
>
>

--_----------=_1502975545356120-- From nobody Thu Aug 17 06:21:13 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731B5132410; Thu, 17 Aug 2017 06:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVSB2OO8n6Ie; Thu, 17 Aug 2017 06:21:08 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163AE12700F; Thu, 17 Aug 2017 06:21:08 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id y15so29454442lfd.5; Thu, 17 Aug 2017 06:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=alACEI9oRejgzDV1F1cDMTyDHb+FRkZqsmguvjIz/eU=; b=k9wacOnwffy2wGwHVgbcjNOrs/F0rm8qIR+amXE2VwkG+1qbpMOGHOtWNaKhrRWsH+ vT42YEYKIrAXL3RMHp4YLihqBN6BVlCxvhKg5ugF24yJSAALx+SMsO3GIjCarmzzZZ7B 2Eo7wEF2phd4jl4kPirZeRLOiqLdlmOyDdfzZ8G+vHPyN73CIpfb6izzMlqt1zfaTM9r lApjV2Ho9xN3sDcHHh9MCC5d7hwunk6Y1/6mM021MQDXDQb02liZ/4e2BF2DiW1LKcXk L0Fxs5giiGn4FKokuXmpetA+MhQJnj4HuuTAMwWP/pJ2Z0yBP6gzVxDMdCQET6kbvbwj uBOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=alACEI9oRejgzDV1F1cDMTyDHb+FRkZqsmguvjIz/eU=; b=tY/mrq6YX2Gsp1wYCh+O+6NNJ6PGwV0OMogZ7Deb3M9GBfRMa3XPHgqdpe5jdl3nTD vGaGhuMOIz73gje8CjQ5UctJvJpXVTUxENrXRrKXQMq0M8rE2SN+txFDV6VF9FYrIeoK 9UeXI1i8HHjqCU6ycRbPI6KeWrbQxJ3u+MGiIWIKOq7Y3XZVIpeTFdxQNWSWWJMMIw8Q dyXyDHPp8u9ort4/CJus1i/+RpEo3Z1POgyX5CmqmTT/AgsMt5Fj8vTnliGIAmQbjtOl BWWJt+wGbEDc1qOBEorLhozlhSahVeJaFx4PB6hq2NFMIthKRI/99xtKctty8WtlwSHc l7ZA== X-Gm-Message-State: AHYfb5jSeV6fTBYaqBHNd0OKEp8cnNh3ROYIHMyhswAM4eE5cqPVzZTm yQSG/kf9/c4504T79uhz2RkliCTq8w== X-Received: by 10.46.32.41 with SMTP id g41mr1772732ljg.96.1502976066329; Thu, 17 Aug 2017 06:21:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.211.15 with HTTP; Thu, 17 Aug 2017 06:21:05 -0700 (PDT) In-Reply-To: <1502964908.2431249.1076255576.026440DD@webmail.messagingengine.com> References: <150292740024.12316.10186295594648032334.idtracker@ietfa.amsl.com> <1502962175.1590900.1076220224.097DD098@webmail.messagingengine.com> <1502964908.2431249.1076255576.026440DD@webmail.messagingengine.com> From: Nik Tomkinson Date: Thu, 17 Aug 2017 14:21:05 +0100 Message-ID: To: Alexey Melnikov Cc: Adam Roach , The IESG , slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, Bernard Aboba Content-Type: multipart/alternative; boundary="001a1142c1968a21f60556f2e241" Archived-At: Subject: Re: [Slim] Adam Roach's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 13:21:11 -0000 --001a1142c1968a21f60556f2e241 Content-Type: text/plain; charset="UTF-8" Hi, Thanks for your comments. I will try to address these (and the other comments) and respond later today. Nik. On 17 August 2017 at 11:15, Alexey Melnikov wrote: > Hi Adam, > > On Thu, Aug 17, 2017, at 10:54 AM, Adam Roach wrote: > > On 8/17/17 4:29 AM, Alexey Melnikov wrote: > > > Hi Adam, > > > > > > On Thu, Aug 17, 2017, at 12:50 AM, Adam Roach wrote: > > >> Adam Roach has entered the following ballot position for > > >> draft-ietf-slim-multilangcontent-13: No Objection > > >> I note that this mechanism uses only language tags and implicitly > leaves > > >> aside > > >> any discussion of script or region tags. > > > Actually this is not true. Language Tags as specified in RFC 5646 can > > > optionally include all of these things. > > > > > >> I'm going to assume this was a > > >> intentional decision that was considered by the group with the end > result > > >> being > > >> that there was no perceived need to distinguish between (e.g.) Latin > and > > >> Jawi > > >> scripts for Malay, or (e.g.) Brazilian and Portuguese variations of > 'pt'. > > >> (If > > >> this was not an explicit decision made by the WG, I would ask that it > be > > >> posed > > >> to the WG for an explicit decision -- the current mechanism seems > > >> somewhat > > >> deficient in this regard from my admittedly brief analysis of the > > >> situation.) > > >> > > >> I'm a little worried that an imprecise reading by implementors of the > > >> citation > > >> to RFC5646 may lead them to believe that script and region tags may be > > >> included > > >> in the Content-Language header fields. > > > They are absolutely allowed. > > > > Wow. If I had gone to implement this, I would have gotten it 100% wrong, > > and argued with anyone who told me as much. The document says: > > > > The Content-Language MUST comply with RFC 3282 [RFC3282] (which > > defines the Content-Language field) and BCP 47/RFC 5646 [RFC5646] > > (which defines the structure and semantics for the language code > > values). > > > > > > What is worth taking note of here is the fact that this says "language > > *code* values," not "language *tag* values." RFC 5646 defines a Language > > _Tag_ (e.g., "sr-Latn-RS"), that is composed of a Language _Code_ (e.g., > > "sr") followed by an optional Script Code (e.g., "Latn") and an optional > > Country Code (e.g., "RS"). > > Good point. Content-Language is defined for language tags, we didn't > change that. I don't think the above difference was intentional. > Authors? > > > As if to reinforce this, the examples then show values of the > > Content-Language header field that consist exclusively of language > > codes, even though it predominantly uses two languages with regional > > variations (en and es): to my eye, "en" by itself looks strange, as I'm > > used to always seeing that language written as either "en-US" or "en-GB". > > > > So I would suggest (a) the passage above be changed to say "...for the > > language tag values...", and (b) the examples be amended to show more > > than simple language codes; e.g.: > > > > Content-Language: en-US > > > > Content-Language: de > > > > Content-Language: es-ES, fr > > > > Content-Language: sr-Cyrl > > Yes, good idea to use better examples. > -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ ----------------------------------------------------------------- --001a1142c1968a21f60556f2e241 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Thanks for your comments.

I will try to address these (and the other comments) = and respond later today.

Nik.

On 17 August 2017 at 11:15= , Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Hi Adam,

On Thu, Aug 17, 2017, at 10:54 AM, Adam Roach wrote:
> On 8/17/17 4:29 AM, Alexey Melnikov wrote:
> > Hi Adam,
> >
> > On Thu, Aug 17, 2017, at 12:50 AM, Adam Roach wrote:
> >> Adam Roach has entered the following ballot position for
> >> draft-ietf-slim-multilangcontent-13: No Objection
> >> I note that this mechanism uses only language tags and implic= itly leaves
> >> aside
> >> any discussion of script or region tags.
> > Actually this is not true. Language Tags as specified in RFC 5646= can
> > optionally include all of these things.
> >
> >> I'm going to assume this was a
> >> intentional decision that was considered by the group with th= e end result
> >> being
> >> that there was no perceived need to distinguish between (e.g.= ) Latin and
> >> Jawi
> >> scripts for Malay, or (e.g.) Brazilian and Portuguese variati= ons of 'pt'.
> >> (If
> >> this was not an explicit decision made by the WG, I would ask= that it be
> >> posed
> >> to the WG for an explicit decision -- the current mechanism s= eems
> >> somewhat
> >> deficient in this regard from my admittedly brief analysis of= the
> >> situation.)
> >>
> >> I'm a little worried that an imprecise reading by impleme= ntors of the
> >> citation
> >> to RFC5646 may lead them to believe that script and region ta= gs may be
> >> included
> >> in the Content-Language header fields.
> > They are absolutely allowed.
>
> Wow. If I had gone to implement this, I would have gotten it 100% wron= g,
> and argued with anyone who told me as much. The document says:
>
>=C2=A0 =C2=A0 =C2=A0The Content-Language MUST comply with RFC 3282 [RFC= 3282] (which
>=C2=A0 =C2=A0 =C2=A0defines the Content-Language field) and BCP 47/RFC = 5646 [RFC5646]
>=C2=A0 =C2=A0 =C2=A0(which defines the structure and semantics for the = language code
>=C2=A0 =C2=A0 =C2=A0values).
>
>
> What is worth taking note of here is the fact that this says "lan= guage
> *code* values," not "language *tag* values." RFC 5646 d= efines a Language
> _Tag_ (e.g., "sr-Latn-RS"), that is composed of a Language _= Code_ (e.g.,
> "sr") followed by an optional Script Code (e.g., "Latn&= quot;) and an optional
> Country Code (e.g., "RS").

Good point. Content-Language is defined for language tags, we d= idn't
change that. I don't think the above difference was intentional.
Authors?

> As if to reinforce this, the examples then show values of the
> Content-Language header field that consist exclusively of language
> codes, even though it predominantly uses two languages with regional > variations (en and es): to my eye, "en" by itself looks stra= nge, as I'm
> used to always seeing that language written as either "en-US"= ; or "en-GB".
>
> So I would suggest (a) the passage above be changed to say "...fo= r the
> language tag values...", and (b) the examples be amended to show = more
> than simple language codes; e.g.:
>
>=C2=A0 =C2=A0 =C2=A0Content-Language: en-US
>
>=C2=A0 =C2=A0 =C2=A0Content-Language: de
>
>=C2=A0 =C2=A0 =C2=A0Content-Language: es-ES, fr
>
>=C2=A0 =C2=A0 =C2=A0Content-Language: sr-Cyrl

Yes, good idea to use better examples.



--
------------------------= -----------------------------------------
Multiple Language Content Type= Internet Draft:
https://datatracker=
.ietf.org/doc/draft-ietf-slim-multilangcontent/
------------------------------------=
-----------------------------

<= /div>
--001a1142c1968a21f60556f2e241-- From nobody Thu Aug 17 06:36:35 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF681321A2 for ; Thu, 17 Aug 2017 06:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xoK-zZBU3mE for ; Thu, 17 Aug 2017 06:36:29 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FCB132499 for ; Thu, 17 Aug 2017 06:36:25 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id s143so40949302ywg.1 for ; Thu, 17 Aug 2017 06:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6DnYCrzLLlxmBgn5WbrOu57qTW5FKPRLX3YZlVddAGk=; b=cSPPODkjwmU/deSTs72nEYdYnStRlNy4sEkojMSR5Kh0PTXhQZEN1b+fQdzQn5uH5X FSIFCpBSsovglhADDeWn4BZuTcdfSs7KMLUS8bLRga5kkgpg7Nec1XWPpRbS5/EM2cUL PL6tyCZDWtFGHwoYNMgAkxAV1pl/1pIMNLr1VQ5D9sVoPJ/pzRxUfVbnMprlzU11la3H NZ8JxlWNdhuhfIuhl/ADFpdAAUUNBxfT4NxM8y/rxVj/W/tZcSxhgFVgLs2Ey/o9iDe7 3/9ZMtdAs38ZkMfs37mJy4Gd8r1+VmcedW1fv5hjnnIDgBIv/wPDWYtIjEr8eglGOGBB HBhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6DnYCrzLLlxmBgn5WbrOu57qTW5FKPRLX3YZlVddAGk=; b=MJJ+U8URfxJp8oTHklnv1blw5nRU6OJtNDBJ2ZImJ1lNwPqj/hkBlxhdDKDjWLKvOE HKfuGI2zQSGcdLE9kQTSpP4+9UTDeKJ7LJNhkszrzrovBtFtgOVipPOinqyIqmKUEMcJ WnHUDhDw15ByGsS39VvMZ9tJyePBI1Pl+m+wiExXxouhhEcLJBLbxr1aGHxPQnUMtpQH eoCCR237j6da6P5rmM2UmCBIxRlZAl2d3u86UY85wN62w4f+uYQcht36i30STjSzzfO9 ICQ1vzPnk/VTt9U+FnfKlYge7MRs+AIb2zqFcOlPC1XKBTZBzNrIOS14zc86TU/LF3Hb hjeQ== X-Gm-Message-State: AHYfb5iFWHM7uSj8u7XbE4N6xLdBYdvj+BcpHRJWmAJSDHJxUdUbDe/i UEg8GCa8XCqPNtb5ZLyoPFsxr6ZD5Jd73D10uQ== X-Received: by 10.37.56.12 with SMTP id f12mr4641356yba.289.1502976984174; Thu, 17 Aug 2017 06:36:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Thu, 17 Aug 2017 06:35:43 -0700 (PDT) In-Reply-To: <1502975545.35612.1076405336.64591061@webmail.messagingengine.com> References: <150283861901.12577.8051576617087935003.idtracker@ietfa.amsl.com> <1502962033.1590356.1076217016.709F842F@webmail.messagingengine.com> <1502975545.35612.1076405336.64591061@webmail.messagingengine.com> From: Eric Rescorla Date: Thu, 17 Aug 2017 06:35:43 -0700 Message-ID: To: Alexey Melnikov Cc: The IESG , slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, Bernard Aboba Content-Type: multipart/alternative; boundary="94eb2c03e4c23f706f0556f319e5" Archived-At: Subject: Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 13:36:30 -0000 --94eb2c03e4c23f706f0556f319e5 Content-Type: text/plain; charset="UTF-8" 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 wrote: > On Thu, Aug 17, 2017, at 01:59 PM, Eric Rescorla wrote: > > > > On Thu, Aug 17, 2017 at 2:27 AM, Alexey Melnikov > 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? > > > > > > > --94eb2c03e4c23f706f0556f319e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What I am keying off of is this:

=C2=A0 = =C2=A0In order for the message to be received and displayed in non-
=C2=A0 =C2=A0conforming email clients, the message SHOULD contain an exp= lanatory
=C2=A0 =C2=A0message part which MUST NOT be marked with = a Content-Language field
=C2=A0 =C2=A0and MUST be the first of th= e message parts.=C2=A0

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

-Ekr
<= div>


On Thu, Aug 17, 2017 at 6:12 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
On Thu, Aug 17, 2017, at 01:59 PM, Eric Rescorla= wrote:


On Thu, Aug 17, 2017 at 2:27 AM, Alexey Melnikov <aamelniko= v@fastmail.fm> 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 whi= ch
> doesn't understand this document you get the preface as the= first
> thing you see. That doesn't seem crazy, but isn't t= he common case that
> you have one preferred language that most reci= pients speak and then
> some translations. Wouldn't it make sens= e to at least allow people to
> have that be what non-updated MUAs d= isplay?

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

Sure, but it seems like there's a clear assumption in this documen= t that the
first part will be displayed first (otherwise why the requirement)
=
Can you point me to the specific text which is con= fusing or misleading?



-Ekr
=C2=A0

Best Regards,
Alexey


> That seems at least
> disfavored if not impossible (because I can't tag that one w= ith
> its actual language). Am I missing something?
>
>


--94eb2c03e4c23f706f0556f319e5-- From nobody Thu Aug 17 12:44:32 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C384132668; Thu, 17 Aug 2017 12:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdvoqOiDLWvt; Thu, 17 Aug 2017 12:44:27 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23CD132669; Thu, 17 Aug 2017 12:44:26 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id y15so34008467lfd.5; Thu, 17 Aug 2017 12:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5wdGNiXGsCCGz8b+70WZH/HusxUL+umBB0x9VfYOf08=; b=IEfMIbIf7sjcaQ0tdHsEpocIFiQwRohYGJJS8PHSKQp0z4PSJwDbJvPgdF3WEtjVQR XRjGSxxIY//LmeKl3DefPo4lxlXkdsoCGju1ly+d5Ll+BGGg3uwkA1d6VMWgwjMd6gF5 NmrxNaJPZMFx5srhgp2eohCcXrGRVC5awhva230DIAOzwQ2M108J4ZzF9xP4eqDlI5GC B+8hMz1XaL24SKlmnev4uzc9FKhPIhyZoRukLMML8F1MX4x7WOPSZY4hNU1HvYDdv3Bp fymHijv3nOKjW6gn78OXiERc4/s/jH5Vei22B48BQWKGZL0q6KWVlVKK7Hg7vWB2QRxI /ICw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5wdGNiXGsCCGz8b+70WZH/HusxUL+umBB0x9VfYOf08=; b=rPp4Ni1X2mHE2fBsUhvSo7eQ+App95JRERY5t5vX/fRYU03xaGzBg3n5xiqDsl0AVf pr+n+YXqJQo798XiC5DJA/NhGaBAfmq04Z9y7jQfp9KpuqKh7He91Gx1dz54bE8CffSL yRx9OWlWBCzbY6KneAdgDEjDzWp+yk1nqeTFZF7wxkqSpWmR0jR234s5CsJt8VYa3WaE 87YqE/rMBXfouPgKPUUNn29TDzoepnSbl5Wto/E3HEtsMKHbHJqG817GF4U/HMo56t8I JesE+XD5XZJUdKpawRjzxIb/i6an1jbVEgAArD2psNKocJ/6eCBOsIRHWLuql8SiQaIX uoqw== X-Gm-Message-State: AHYfb5j6hax0VsZKMHBNcWoEUvou1ehve92AtmoHC8ZwODj9O+14GCue keagpoqMiDaEPFhBqQaXALoERhvfCw== X-Received: by 10.46.83.10 with SMTP id h10mr2584193ljb.44.1502999065156; Thu, 17 Aug 2017 12:44:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.211.15 with HTTP; Thu, 17 Aug 2017 12:44:24 -0700 (PDT) In-Reply-To: References: <150283861901.12577.8051576617087935003.idtracker@ietfa.amsl.com> <1502962033.1590356.1076217016.709F842F@webmail.messagingengine.com> <1502975545.35612.1076405336.64591061@webmail.messagingengine.com> From: Nik Tomkinson Date: Thu, 17 Aug 2017 20:44:24 +0100 Message-ID: To: Eric Rescorla Cc: Alexey Melnikov , The IESG , slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, Bernard Aboba Content-Type: multipart/alternative; boundary="94eb2c1cee766061b30556f83db3" Archived-At: Subject: Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 19:44:30 -0000 --94eb2c1cee766061b30556f83db3 Content-Type: text/plain; charset="UTF-8" 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 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 > wrote: > >> On Thu, Aug 17, 2017, at 01:59 PM, Eric Rescorla wrote: >> >> >> >> On Thu, Aug 17, 2017 at 2:27 AM, Alexey Melnikov >> 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/ ----------------------------------------------------------------- --94eb2c1cee766061b30556f83db3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

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

<= /div>
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) trea= t 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 firs= t part will be shown.=C2=A0

If instead, the first = part shown is just the first (original) translation and the other translati= ons are attachments, then the recipient will not know that there is a versi= on 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 do= n't understand the first (original) translation at all then they have e= ven less of an idea and are likely to just delete the email.

=
If the other translations are shown inline, then the multilingua= l preface would typically be read first and direct the recipient to their t= ranslation and helps them to understand that they can skim the email until = they see their version.=C2=A0


Also:=

The ordering of the parts is important because MU= As 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 204= 6):
   The "mixed" su=
btype 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 recog=
nize
   must be treated as being of subtype "mixed".



I hope t= hat helps to explain some of the I-D wording,

Thanks,

Nik

On 17 August 2017 at 14:35, Eric Re= scorla <ekr@rtfm.com> wrote:
What I am keying off of is this:

=
=C2=A0 =C2=A0In order for the message to be received and displaye= d in non-
=C2=A0 =C2=A0conforming email clients, the message SHOU= LD contain an explanatory
=C2=A0 =C2=A0message part which MUST NO= T be marked with a Content-Language field
=C2=A0 =C2=A0and MUST b= e the first of the message parts.=C2=A0

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 <a= amelnikov@fastmail.fm> wrote:
On Thu, Aug 17, 2017, at 01:59 PM, Eric Rescorla wrote:
=


On Thu, Aug 17, 2017 at 2:27 AM, Alexey Melnikov <aamelniko= v@fastmail.fm> 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 whi= ch
> doesn't understand this document you get the preface as the= first
> thing you see. That doesn't seem crazy, but isn't t= he common case that
> you have one preferred language that most reci= pients speak and then
> some translations. Wouldn't it make sens= e to at least allow people to
> have that be what non-updated MUAs d= isplay?

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

Sure, but it seems like there's a clear assumption in this documen= t that the
first part will be displayed first (otherwise why the requirement)
=
Can you point me to the specific text which is con= fusing or misleading?



-Ekr
=C2=A0

Best Regards,
Alexey


> That seems at least
> disfavored if not impossible (because I can't tag that one w= ith
> its actual language). Am I missing something?
>
>





--
= 
-------------------------------------=
----------------------------
Multiple Language Content Type Internet Dra=
ft:
https://datatracker.ietf.org/doc=
/draft-ietf-slim-multilangcontent/
---------------------------------------=
--------------------------

--94eb2c1cee766061b30556f83db3-- From nobody Thu Aug 17 13:05:06 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0679D13267B for ; Thu, 17 Aug 2017 13:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dzPPu_7gEbk for ; Thu, 17 Aug 2017 13:04:58 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3AFF132654 for ; Thu, 17 Aug 2017 13:04:51 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id s143so47589367ywg.1 for ; Thu, 17 Aug 2017 13:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d3uSV1xUx8bpeUvWuKlRKXUWC8ojanjF6r9zRqlwCjs=; b=W5ZIYQCleYpxiAyFvZPeGxjx+fMar64ojimUImxY7CvZTfQYvZOm4yUqo3szmcoxCe 8dY0yklnuBRbULMoN0q+sd6Le+s49lENmNK9UlQK8bc7uITwhectYcRgU6HUaS0ZlAZA 6dx5h3vlieCrt+oxFW5UQviJqUao+FQJy66a2UsM+5HJrREYApYURFQ4tEVwIgDcNZnr y+InUVmob9m5VOCAsPsks60XLgAuM6fhLe6nor25x1FZ7tPR3vG45VG7dts5MH1Cwvzq a65E8dL/ZUX+1P6arR/xnLY2M0oyd/CgGyjAY/ftoFQX67zy6VlsITfX1Hf/a6IVq+C/ 0c+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d3uSV1xUx8bpeUvWuKlRKXUWC8ojanjF6r9zRqlwCjs=; b=BN4sN8mUaYdsOMTlD9HNP5NE5Kqk2z5/lKmrtBMZHjOaEjZZBitdHhSSAYszgxHa1b FyV+vTtRTM4RtZFbjkvFQ3nhUBqpTcMBB80verkSSOoqJfIJkvIx9ehAcIgtfRmeNpZw MyvvAm3P/o0SpFhYf8m7DluK6KHJecjkJQkVr46bzaIM40Wvb2vvZybTPREPH3LA0LzV kj/vyASacC/klJv65fsiqDJygPYqzhFFhGBNI0sBneYeCy68dGxuNUkyIvdwQHtdSaif uSKyoOY9M9DYvJIS6iXcdyLEhm08mGXA/GnHQuoJUVp1SkkhXQVYkLUDYMfgCLFdhXKh YO8g== X-Gm-Message-State: AHYfb5jnm9d/XQwFWnRm7cX0uz5hb/z2npGkMKh/wFU20pYyb1fBeD1K 5Tf00xvwc9vQ5ri9rMtcExnSgXnvnotb X-Received: by 10.37.203.79 with SMTP id b76mr5306690ybg.256.1503000290978; Thu, 17 Aug 2017 13:04:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Thu, 17 Aug 2017 13:04:10 -0700 (PDT) In-Reply-To: References: <150283861901.12577.8051576617087935003.idtracker@ietfa.amsl.com> <1502962033.1590356.1076217016.709F842F@webmail.messagingengine.com> <1502975545.35612.1076405336.64591061@webmail.messagingengine.com> From: Eric Rescorla Date: Thu, 17 Aug 2017 13:04:10 -0700 Message-ID: To: Nik Tomkinson Cc: Alexey Melnikov , The IESG , slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, Bernard Aboba Content-Type: multipart/alternative; boundary="94eb2c05a9627104bc0556f88682" Archived-At: Subject: Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 20:05:01 -0000 --94eb2c05a9627104bc0556f88682 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 12:44 PM, Nik Tomkinson 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 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 >> wrote: >> >>> On Thu, Aug 17, 2017, at 01:59 PM, Eric Rescorla wrote: >>> >>> >>> >>> On Thu, Aug 17, 2017 at 2:27 AM, Alexey Melnikov >> > 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/ > > ----------------------------------------------------------------- > > --94eb2c05a9627104bc0556f88682 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 17, 2017 at 12:44 PM, Nik Tomkinson <<= a href=3D"mailto:rfc.nik.tomkinson@gmail.com" target=3D"_blank">rfc.nik.tom= kinson@gmail.com> 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 s= howing 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.=C2=A0

If instead, the first pa= rt shown is just the first (original) translation and the other translation= s are attachments, then the recipient will not know that there is a version= in their own language attached without opening each attachment. In this ca= se it would be pointless sending it in more than one language. If they don&= #39;t understand the first (original) translation at all then they have eve= n less of an idea and are likely to just delete the email.

I agree that this can happen, and it's a fa= ir 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 woul= d 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.=C2=A0


Also:
The ordering of the parts is important because MUAs will treat = a multipart/multilingual email as multipart/mixed which they will respect t= he part ordering of because of this (section 5.1.3 of RFC 2046):
= 
   The "mixed&=
quot; 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 recog=
nize
   must be treated as being of subtype "mixed".



I hope that helps to explain some of th= e I-D wording,

Thanks,

Nik

<= /div>
On 17 August 2017 at 14:35, Eric Rescorla <= span dir=3D"ltr"><ekr@= rtfm.com> wrote:
What I am keying off of is this:

<= div>=C2=A0 =C2=A0In order for the message to be received and displayed in n= on-
=C2=A0 =C2=A0conforming email clients, the message SHOULD con= tain an explanatory
=C2=A0 =C2=A0message part which MUST NOT be m= arked with a Content-Language field
=C2=A0 =C2=A0and MUST be the = first of the message parts.=C2=A0

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

= -Ekr



On Thu, Aug 17, 201= 7 at 6:12 AM, Alexey Melnikov <aamelnikov@fastmail.fm> = wrote:
On Thu, Aug 17, 2017, at 01:59 PM, Eric Rescorla wrote:
=


On Thu, Aug 17, 2017 at 2:27 AM, Alexey Melnikov <aamelniko= v@fastmail.fm> 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 whi= ch
> doesn't understand this document you get the preface as the= first
> thing you see. That doesn't seem crazy, but isn't t= he common case that
> you have one preferred language that most reci= pients speak and then
> some translations. Wouldn't it make sens= e to at least allow people to
> have that be what non-updated MUAs d= isplay?

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

Sure, but it seems like there's a clear assumption in this documen= t that the
first part will be displayed first (otherwise why the requirement)
=
Can you point me to the specific text which is con= fusing or misleading?



-Ekr
=C2=A0

Best Regards,
Alexey


> That seems at least
> disfavored if not impossible (because I can't tag that one w= ith
> its actual language). Am I missing something?
>
>





<= /div>-- 
------------------------------<=
wbr>-----------------------------------
Multiple Language Content T=
ype Internet Draft:
https://datatrac=
ker.ietf.org/doc/draft-ietf-slim-multilangcontent/
=
-------------=
----------------------------------------------------

--94eb2c05a9627104bc0556f88682-- From nobody Thu Aug 17 13:07:24 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA9B132670; Thu, 17 Aug 2017 13:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vuTmakM-wAI; Thu, 17 Aug 2017 13:07:20 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6CE213228D; Thu, 17 Aug 2017 13:07:19 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id o85so34340961lff.3; Thu, 17 Aug 2017 13:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wNEOdVF+Ovswdo90hTbRUiNG5mb0H/T5onzVys/bX8o=; b=fGDjzclHwWUFuHu6in7kJAqsrXP3oStSj+k2tgEj5TpLyhwQvhNW/4x2UbWQmXGGsU bPJtJWDO3Ao/Amz9NfW//RfJtE36O2cfH2yefG7Fsbk15uiHOE1V+czXodxqUxrmmtDV p9G+LsYpulu45WZ9WTn2aG5VJLmEy9Vag+SoiuskfyM7TO6Pid+BHPyGdwnOLVOODxUF +J3/MldpUsTin1TNlyOVpcyD1AFAAmrtoQDNI/vZrvcQKN9EBbqSgdFUimrvLzj8KXpS JuK7Y/lb6lPNG6a0CUFLsI/pTE3xABQvOtZQaJ2NUQhV5d5tuZELYq0bRW5MF/SCEZOA 4hAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wNEOdVF+Ovswdo90hTbRUiNG5mb0H/T5onzVys/bX8o=; b=f4IAnPr6KhMZ/Uzdl/RxPN0f+jsFXZDCGygbe0uDxXX60tOWSEXE2DwXQWKmJkJzbu 60idIQiZjmLdRdr+WY8gVHIgj9Is/wkf56gXFhw8lzJ6K2d0+ufoD4ZWwsfuWJ8TyPHE ZWmsTv8Isdg1BseZtb8fkoS7OmagfFeGqvlR+/TKWVfVxa3EpAm4nAvq0922H9ujk1zf rUPKejH7Jq9JBZ8Fc3RvcOArZgPnlDS0tCwf+rrL6cFj8+6K5aRkoiyc35QoHasrV/jO gvQTBAms2ts89W6ZP31ofZ1RuPKmuitSChd1eBVVW9O6vEVXx+6ahySyHi51Vy1w6/wJ F9Sw== X-Gm-Message-State: AHYfb5iloQh5H1iiMzTYaSaTPO7ZdKGNgKjrjizjOwgalsFPTZ0JAosb T9WS83ozPCLlthSuWj3e+88HNhJkzQ== X-Received: by 10.46.77.77 with SMTP id a74mr2426248ljb.53.1503000438118; Thu, 17 Aug 2017 13:07:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.211.15 with HTTP; Thu, 17 Aug 2017 13:07:17 -0700 (PDT) In-Reply-To: References: <150292740024.12316.10186295594648032334.idtracker@ietfa.amsl.com> <1502962175.1590900.1076220224.097DD098@webmail.messagingengine.com> <1502964908.2431249.1076255576.026440DD@webmail.messagingengine.com> From: Nik Tomkinson Date: Thu, 17 Aug 2017 21:07:17 +0100 Message-ID: To: Alexey Melnikov Cc: Adam Roach , The IESG , slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, Bernard Aboba Content-Type: multipart/alternative; boundary="94eb2c1ab91e361d850556f88f83" Archived-At: Subject: Re: [Slim] Adam Roach's No Objection on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 20:07:22 -0000 --94eb2c1ab91e361d850556f88f83 Content-Type: text/plain; charset="UTF-8" Hi Adam, thanks for your comments. The usage of the phrase 'language code' in that paragraph was certainly unintentional and now I understand how much difference it makes, I will of course update that. I'll also update the examples. We originally had a paragraph that recommended using the highest level of categorisation for language tags to get an improved interoperability but this was later removed. I think the original assumption was that matching preferred languages with the tag values would be difficult if script codes and country codes were also included. This is probably not the case. Thanks again, Nik. On 17 August 2017 at 14:21, Nik Tomkinson wrote: > Hi, > > Thanks for your comments. > > I will try to address these (and the other comments) and respond later > today. > > Nik. > > On 17 August 2017 at 11:15, Alexey Melnikov > wrote: > >> Hi Adam, >> >> On Thu, Aug 17, 2017, at 10:54 AM, Adam Roach wrote: >> > On 8/17/17 4:29 AM, Alexey Melnikov wrote: >> > > Hi Adam, >> > > >> > > On Thu, Aug 17, 2017, at 12:50 AM, Adam Roach wrote: >> > >> Adam Roach has entered the following ballot position for >> > >> draft-ietf-slim-multilangcontent-13: No Objection >> > >> I note that this mechanism uses only language tags and implicitly >> leaves >> > >> aside >> > >> any discussion of script or region tags. >> > > Actually this is not true. Language Tags as specified in RFC 5646 can >> > > optionally include all of these things. >> > > >> > >> I'm going to assume this was a >> > >> intentional decision that was considered by the group with the end >> result >> > >> being >> > >> that there was no perceived need to distinguish between (e.g.) Latin >> and >> > >> Jawi >> > >> scripts for Malay, or (e.g.) Brazilian and Portuguese variations of >> 'pt'. >> > >> (If >> > >> this was not an explicit decision made by the WG, I would ask that >> it be >> > >> posed >> > >> to the WG for an explicit decision -- the current mechanism seems >> > >> somewhat >> > >> deficient in this regard from my admittedly brief analysis of the >> > >> situation.) >> > >> >> > >> I'm a little worried that an imprecise reading by implementors of the >> > >> citation >> > >> to RFC5646 may lead them to believe that script and region tags may >> be >> > >> included >> > >> in the Content-Language header fields. >> > > They are absolutely allowed. >> > >> > Wow. If I had gone to implement this, I would have gotten it 100% wrong, >> > and argued with anyone who told me as much. The document says: >> > >> > The Content-Language MUST comply with RFC 3282 [RFC3282] (which >> > defines the Content-Language field) and BCP 47/RFC 5646 [RFC5646] >> > (which defines the structure and semantics for the language code >> > values). >> > >> > >> > What is worth taking note of here is the fact that this says "language >> > *code* values," not "language *tag* values." RFC 5646 defines a Language >> > _Tag_ (e.g., "sr-Latn-RS"), that is composed of a Language _Code_ (e.g., >> > "sr") followed by an optional Script Code (e.g., "Latn") and an optional >> > Country Code (e.g., "RS"). >> >> Good point. Content-Language is defined for language tags, we didn't >> change that. I don't think the above difference was intentional. >> Authors? >> >> > As if to reinforce this, the examples then show values of the >> > Content-Language header field that consist exclusively of language >> > codes, even though it predominantly uses two languages with regional >> > variations (en and es): to my eye, "en" by itself looks strange, as I'm >> > used to always seeing that language written as either "en-US" or >> "en-GB". >> > >> > So I would suggest (a) the passage above be changed to say "...for the >> > language tag values...", and (b) the examples be amended to show more >> > than simple language codes; e.g.: >> > >> > Content-Language: en-US >> > >> > Content-Language: de >> > >> > Content-Language: es-ES, fr >> > >> > Content-Language: sr-Cyrl >> >> Yes, good idea to use better examples. >> > > > > -- > > ----------------------------------------------------------------- > Multiple Language Content Type Internet Draft: > > https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ > > ----------------------------------------------------------------- > > -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ ----------------------------------------------------------------- --94eb2c1ab91e361d850556f88f83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adam,

thanks for your comments.=C2= =A0

The usage of the phrase 'language code'= ; in that paragraph was certainly unintentional and now I understand how mu= ch difference it makes, I will of course update that.

<= div>I'll also update the examples.

We original= ly had a paragraph that recommended using the highest level of categorisati= on for language tags to get an improved interoperability but this was later= removed. I think the original assumption was that matching preferred langu= ages with the tag values would be difficult if script codes and country cod= es were also included. This is probably not the case.

<= div>Thanks again,

Nik.=C2=A0

On 17 August 2017 at 14:21,= Nik Tomkinson <rfc.nik.tomkinson@gmail.com> wrote= :
Hi,=C2=A0

Thanks for your comments.

I will try to add= ress these (and the other comments) and respond later today.

=
Nik.

On 17 August 2017 at 11:15, Alexey Melniko= v <aamelnikov@fastmail.fm> wrote:
Hi Adam,

On Thu, Aug 17, 2017, at 10:54 AM, Adam Roach wrote:
> On 8/17/17 4:29 AM, Alexey Melnikov wrote:
> > Hi Adam,
> >
> > On Thu, Aug 17, 2017, at 12:50 AM, Adam Roach wrote:
> >> Adam Roach has entered the following ballot position for
> >> draft-ietf-slim-multilangcontent-13: No Objection
> >> I note that this mechanism uses only language tags and implic= itly leaves
> >> aside
> >> any discussion of script or region tags.
> > Actually this is not true. Language Tags as specified in RFC 5646= can
> > optionally include all of these things.
> >
> >> I'm going to assume this was a
> >> intentional decision that was considered by the group with th= e end result
> >> being
> >> that there was no perceived need to distinguish between (e.g.= ) Latin and
> >> Jawi
> >> scripts for Malay, or (e.g.) Brazilian and Portuguese variati= ons of 'pt'.
> >> (If
> >> this was not an explicit decision made by the WG, I would ask= that it be
> >> posed
> >> to the WG for an explicit decision -- the current mechanism s= eems
> >> somewhat
> >> deficient in this regard from my admittedly brief analysis of= the
> >> situation.)
> >>
> >> I'm a little worried that an imprecise reading by impleme= ntors of the
> >> citation
> >> to RFC5646 may lead them to believe that script and region ta= gs may be
> >> included
> >> in the Content-Language header fields.
> > They are absolutely allowed.
>
> Wow. If I had gone to implement this, I would have gotten it 100% wron= g,
> and argued with anyone who told me as much. The document says:
>
>=C2=A0 =C2=A0 =C2=A0The Content-Language MUST comply with RFC 3282 [RFC= 3282] (which
>=C2=A0 =C2=A0 =C2=A0defines the Content-Language field) and BCP 47/RFC = 5646 [RFC5646]
>=C2=A0 =C2=A0 =C2=A0(which defines the structure and semantics for the = language code
>=C2=A0 =C2=A0 =C2=A0values).
>
>
> What is worth taking note of here is the fact that this says "lan= guage
> *code* values," not "language *tag* values." RFC 5646 d= efines a Language
> _Tag_ (e.g., "sr-Latn-RS"), that is composed of a Language _= Code_ (e.g.,
> "sr") followed by an optional Script Code (e.g., "Latn&= quot;) and an optional
> Country Code (e.g., "RS").

Good point. Content-Language is defined for language tags, we d= idn't
change that. I don't think the above difference was intentional.
Authors?

> As if to reinforce this, the examples then show values of the
> Content-Language header field that consist exclusively of language
> codes, even though it predominantly uses two languages with regional > variations (en and es): to my eye, "en" by itself looks stra= nge, as I'm
> used to always seeing that language written as either "en-US"= ; or "en-GB".
>
> So I would suggest (a) the passage above be changed to say "...fo= r the
> language tag values...", and (b) the examples be amended to show = more
> than simple language codes; e.g.:
>
>=C2=A0 =C2=A0 =C2=A0Content-Language: en-US
>
>=C2=A0 =C2=A0 =C2=A0Content-Language: de
>
>=C2=A0 =C2=A0 =C2=A0Content-Language: es-ES, fr
>
>=C2=A0 =C2=A0 =C2=A0Content-Language: sr-Cyrl

Yes, good idea to use better examples.



--
= 
--------------------=
---------------------------------------------
Multiple Languag=
e Content Type Internet Draft:
https=
://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/=

--------------=
---------------------------------------------------



--
------------------------= -----------------------------------------
Multiple Language Content Type= Internet Draft:
https://datatracker=
.ietf.org/doc/draft-ietf-slim-multilangcontent/
------------------------------------=
-----------------------------

<= /div>
--94eb2c1ab91e361d850556f88f83-- From nobody Thu Aug 17 13:54:51 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6797D126B6E; Thu, 17 Aug 2017 13:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YfHgGLExE13; Thu, 17 Aug 2017 13:54:41 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53370126BF3; Thu, 17 Aug 2017 13:54:41 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id o85so34800903lff.3; Thu, 17 Aug 2017 13:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WAGYVgFL4RwQWoveTplH337SQsfDQBzcdyUMJeuBvZU=; b=kHEJcGydBAGSebaNdBJla1umks5f4ns7n9+gsI2osPRh0kDRQ2FwiXPibZcW3QLIem aScBde4hyu2sct+KbFoCFaxYwHw/b8UCFfu4nj2Uf8nU4A8WcYqoICoHIMZTHtbKIvRw vUwwwQOaOedpaRu+c+9QOfNBkThQiLlv2pGi58swQj9PM3YNVPqyZCAPw/veZSTA+AJt kRngNJUT/4tHYo/dblznbhzMULqTG3VUeUG/AojnWExMXIrfBQi0+DpPRC3Oy5qGowCp Alzs+IsUhhQFXbvldfhEbfxbI5v7LD5jjfytTVDIMqxXvmHcctoK/rw4V1YnapH1XFlA u+ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WAGYVgFL4RwQWoveTplH337SQsfDQBzcdyUMJeuBvZU=; b=RKSxxRqvSXj7vqab7YO59nfYOGD5Xk4GtAveHqy/21QLh80/ZwC9SCfcd+NXwuBo5A VLVkmxdgdAahWwverkr4336G70YOs+ewcg/Kz39ol9IRr7Fj9nbpVDlh1eezUzuHQI9/ ovivtfJX1dcq8lUn7ph54avy68Y/8MQLJ2mnrjilHmlGhMnWwKGw4hgX5UsWqRzj/pHs 2rOHWQqurKf+UktseVW8vbl+LlaYAra8fN2APfUgAoTPz5/y9PYHEQQYpT+cvuoBG1kQ xcCx4BJRzuWq2TacA2KWb0XQEAvgVzUnaXYsSugt8XyEpE6cJJugMBf98OtxJ74Q6xa3 vPYQ== X-Gm-Message-State: AHYfb5ig7QA2UbqnDEnDbFX11CTA39Nk2d6XMpRPGaO/PK7y5XGCUs16 NX0YvvE+OURCzgeOhy0sPaz+SeuyEg== X-Received: by 10.46.77.77 with SMTP id a74mr2461449ljb.53.1503003279584; Thu, 17 Aug 2017 13:54:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.211.15 with HTTP; Thu, 17 Aug 2017 13:54:38 -0700 (PDT) In-Reply-To: <1502962899.1592674.1076222888.5B74D570@webmail.messagingengine.com> References: <150292141204.12197.13535898303505156655.idtracker@ietfa.amsl.com> <1502962899.1592674.1076222888.5B74D570@webmail.messagingengine.com> From: Nik Tomkinson Date: Thu, 17 Aug 2017 21:54:38 +0100 Message-ID: To: Alexey Melnikov Cc: Ben Campbell , The IESG , slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, Bernard Aboba Content-Type: multipart/alternative; boundary="94eb2c1ab91e9373760556f938b2" Archived-At: Subject: Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 20:54:44 -0000 --94eb2c1ab91e9373760556f938b2 Content-Type: text/plain; charset="UTF-8" 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. On 17 August 2017 at 10:41, Alexey Melnikov 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/ ----------------------------------------------------------------- --94eb2c1ab91e9373760556f938b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

thanks for all of your comments= .

Regarding the multilingual preface, the implemen= tation I am working on at the moment does select the languages to include i= n the preface from the language parts that have been added into the email a= nd the preface paragraphs are all hard-coded strings. The preface should no= t 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 part= s of the email. I suppose this really is a question of the specification de= fining how an implementation should work or how the email should be structu= red. I have always understood it to be a specification of the email structu= re not implementation behaviour.=C2=A0

I would not= have imagined that any implementation would expect the sender to construct= the preface but just include it automatically. Any hand-written multilingu= al 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 happe= n and either of the ways that Alexey identified would be valid.
<= br>
---

The section 11 (Security Conside= rations) comment is a good point. I had not thought of that, but if filteri= ng 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 sectio= n 11 anyway.

---

I will u= pdate the I-D based on your Editorial comments as well as they are all vali= d. I assume you mean that section 3.2 the SHOULD should be a should?
<= div>Also, in section 7 do you mean the first, the last or both 'should&= #39;s should be SHOULD?

Thanks again,
Nik.

On 17 August 2017 at 10:41, Alexey Melnikov &= lt;aamelnikov@f= astmail.fm> wrote:
Hi Ben,<= br>
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 r= ecipient
>=C2=A0 =C2=A0 that the message contains multiple languages and the part= s may be
>=C2=A0 =C2=A0 rendered sequentially or as attachments.=C2=A0 This SHOUL= D be presented in
>=C2=A0 =C2=A0 the same languages that are provided in the subsequent la= nguage
>=C2=A0 =C2=A0 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 reasonab= le
> to
> expect the MUA (or the person who configures it) to know in advance al= l
> languages likely to be used? Is it expected to dynamically select the<= br> > 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<= br> generated per the list of languages used.

> -3.3: I'm not sure I understand the first sentence. Why does that<= br> > ''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:

=C2=A0Top level multipart/mixed
=C2=A0 =C2=A0child 1: multipart/multilingual
=C2=A0 =C2=A0child 2: <1st language-Independent attachment>
=C2=A0 =C2=A0child 3: <2nd language-Independent attachment>

Alternatively, you can use multipart/multilingual:

=C2=A0Top level multipart/multilingual
=C2=A0 =C2=A0child 1: text/plain
=C2=A0 =C2=A0child 2: message/rfc822 with nested message in English
=C2=A0 =C2=A0child 3: message/rfc822 with nested message in French
=C2=A0 =C2=A0child 4: message/rfc822 with nested message in German
=C2=A0 =C2=A0child 5: multipart/mixed (language independent part)
=C2=A0 =C2=A0 child 5.1: <1st language-Independent attachment>
=C2=A0 =C2=A0 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 assum= es
> that
> all the body parts say the same thing, might they be induced into taki= ng
> some
> action? (e.g.=C2=A0 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? :-)=C2=A0 =C2=A0(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 res= tates
> this
> SHOULD, and covers the topic in more detail, perhaps section 3.2 shoul= d
> state
> this descriptively rather than normatively?

Good comments/questions that editors should comment on.

> -7, last paragraph: Should the first "should" be a "SHO= ULD"?

I agree.

Best Regards,
Alexey



--
------------------------= -----------------------------------------
Multiple Language Content Type= Internet Draft:
https://datatracker=
.ietf.org/doc/draft-ietf-slim-multilangcontent/
------------------------------------=
-----------------------------

<= /div>
--94eb2c1ab91e9373760556f938b2-- From nobody Thu Aug 17 14:14:54 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDB91321DE; Thu, 17 Aug 2017 14:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L64Q3vvPL3KD; Thu, 17 Aug 2017 14:14:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA91A1323A6; Thu, 17 Aug 2017 14:14:50 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7HLEiJA082733 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Aug 2017 16:14:45 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Thu, 17 Aug 2017 16:14:43 -0500 Cc: Alexey Melnikov , The IESG , slim@ietf.org, draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, Bernard Aboba Content-Transfer-Encoding: quoted-printable Message-Id: <3A1C76CD-C6F8-4677-86AB-28E387CB4E07@nostrum.com> References: <150292141204.12197.13535898303505156655.idtracker@ietfa.amsl.com> <1502962899.1592674.1076222888.5B74D570@webmail.messagingengine.com> To: Nik Tomkinson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Slim] Ben Campbell's Yes on draft-ietf-slim-multilangcontent-13: (with COMMENT) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 21:14:53 -0000 > On Aug 17, 2017, at 3:54 PM, Nik Tomkinson = wrote: >=20 > Hi Ben, >=20 > thanks for all of your comments. >=20 > 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? >=20 > 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.=20 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=E2=80=99m = 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 =E2=80=9Cwhere reasonably possible=E2=80= =9D or even =E2=80=9Cwhere convenient=E2=80=9D disclaimer on that = requirement? (I=E2=80=99m open to arguments that the SHOULD already = allows that=E2=80=94but guidance about the wiggle room in a given SHOULD = is often helpful.) >=20 > 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. >=20 > --- >=20 > Intent - yes, I'll remove that word as it may be superfluous. >=20 > --- >=20 > 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=E2=80=99= t expect you to go into deep details of nested body parts. >=20 > --- >=20 > 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=E2=80=99s fairly easy to construct deeply offensive text = that would be hard to filter mechanically). >=20 > --- >=20 > 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. >=20 > Thanks again, >=20 > Nik. >=20 > On 17 August 2017 at 10:41, Alexey Melnikov = wrote: > Hi Ben, >=20 > 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 >=20 > > 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? >=20 > This is a good question. I think I agree that it can be potentially > generated per the list of languages used. >=20 > > -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? >=20 > This is generally allowed by MIME. One way of doing this is: >=20 > Top level multipart/mixed > child 1: multipart/multilingual > child 2: <1st language-Independent attachment> > child 3: <2nd language-Independent attachment> >=20 > Alternatively, you can use multipart/multilingual: >=20 > 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> >=20 > > -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? >=20 > Good comments/questions that editors should comment on. >=20 > > -7, last paragraph: Should the first "should" be a "SHOULD"? >=20 > I agree. >=20 > Best Regards, > Alexey >=20 >=20 >=20 > --=20 > ----------------------------------------------------------------- > Multiple Language Content Type Internet Draft: > https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ > ----------------------------------------------------------------- >=20 From nobody Thu Aug 17 16:53:31 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5501326C6; Thu, 17 Aug 2017 16:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHej8dGu5EKY; Thu, 17 Aug 2017 16:53:27 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD271326C2; Thu, 17 Aug 2017 16:53:27 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id d17so36067203lfe.0; Thu, 17 Aug 2017 16:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bxD7AH/3wUjpdyjgvHb4+RJORZ2FZKFsf71tknM83g8=; b=rlPF40MLgOZNWqYPB1OhERGDpnLqkMxRHMVvvzNs9zdtVrHhytq2930dck4WWuwC+C e0nWLozNq62ZeO70YxANp2A+mhhIfQShXSs4rbj/awMq+S2lVdtjKRTA0+0T2PFzHySD EO3Oa6/ZvXAm/0vYZMBOQu0be+x7J2I2QfYzu9Z1Wnt2K/LifGgNXPHSbzAe916Y7b4O ZYo2N0AuUguOIMXUWM5yQA5mJ0BpUqD/76f3hDAbAUu2K2GJSIxprcS2nhy7DEisx7Li UvJPxSQHdnsRwlX9ZbUXdBh0F6DkPUC49jOJ+9CryBORgw3q8sUqQnwylZU4zzMBAvI0 s7ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bxD7AH/3wUjpdyjgvHb4+RJORZ2FZKFsf71tknM83g8=; b=Aiq9NebZcJgEbs62nHLfp+RF4jf3lbXQX1PUJysKXbQeoxE8wZSMPBDcEi0wNoqo1r moUA8lPKwlQZXu/WoZRIK+JxiHxRSif/DrtkTCjgkQHN5f39AYUs2AClpiOioROfnQ2J Sj9Ej7qhSCvbd3MI58I14awwyTlNdP621iKvfeaclZNJ8fxBHGusYvsQCCK0r0lArlOE lfJublkojelBGJM4Nw9ICMWfu+i/mIihFuCcttR4QRuS1jz+hWNLuxDOl6rknkvZjzLJ j7d5ipEk8xPS+oQjBHCUhkzcVGl3NYUkuJlVo4YSCN6hxVKkzMQoLf4cDOghJpds7ex8 RCgg== X-Gm-Message-State: AHYfb5gF912opmeB5mWC+6hrlE+wAcfjvcQ+O1hmgbgJ6vlIgSOUbAn8 2oYcLqimkTpvg7geqagV3Z0dQchSfg== X-Received: by 10.46.5.141 with SMTP id 135mr2799180ljf.95.1503014005634; Thu, 17 Aug 2017 16:53:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.211.15 with HTTP; Thu, 17 Aug 2017 16:53:24 -0700 (PDT) In-Reply-To: <150279986062.20971.4568019868114855413.idtracker@ietfa.amsl.com> References: <150279986062.20971.4568019868114855413.idtracker@ietfa.amsl.com> From: Nik Tomkinson Date: Fri, 18 Aug 2017 00:53:24 +0100 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-slim-multilangcontent@ietf.org, Bernard Aboba , slim-chairs@ietf.org, slim@ietf.org Content-Type: multipart/alternative; boundary="001a114a737ce5ff550556fbb773" Archived-At: Subject: Re: [Slim] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-slim-multilangcontent-13=3A_=28with_COMMENT=29?= X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 23:53:30 -0000 --001a114a737ce5ff550556fbb773 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, Regarding the mismatched email addresses, I'll have a think and add some text to the I-D. Regarding the second point, the last paragraph in section 4 says that 'Additionally, interactive implementations MAY offer the user a choice from among the available languages'. Is this what you had in mind or do you think this should be also mentioned in the Security Considerations as a mitigating response to the risk? Nik. On 15 August 2017 at 13:24, Mirja K=C3=BChlewind wrot= e: > Mirja K=C3=BChlewind 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: > ---------------------------------------------------------------------- > > Minor comments: > - sec 3.2: > "If there is a From field present, its value MUST > include the same email address as the top-level From header..." > What happen if they are no the same? The security considerations section > mentions this case but there is no guidance given what to do in this case > (which address to display)? > > - The security considerations section mentions the risk that the content > might > actually be different in different languages. I think it would be nice to > give > some recommendation that there SHOULD be a way for the user to see all > content > fields. > > > --=20 ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ ----------------------------------------------------------------- --001a114a737ce5ff550556fbb773 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja,

Regarding the mismatched emai= l addresses, I'll have a think and add some text to the I-D.
=
Regarding the second point, the last paragraph in section 4 = says that 'Additionally, interactive implementations MAY offer the user= a choice from among the available languages'. Is this what you had in = mind or do you think this should be also mentioned in the Security Consider= ations as a mitigating response to the risk?

Nik.<= /div>

On 15 = August 2017 at 13:24, Mirja K=C3=BChlewind <ietf@kuehlewind.net><= /span> wrote:
Mirja K=C3=BChlewind has en= tered 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/<= wbr>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:
-----------------------------------------------------------------= -----

Minor comments:
- sec 3.2:
"If there is a From field present, its value MUST
=C2=A0 =C2=A0include the same email address as the top-level From header...= "
What happen if they are no the same? The security considerations section mentions this case but there is no guidance given what to do in this case (which address to display)?

- The security considerations section mentions the risk that the content mi= ght
actually be different in different languages. I think it would be nice to g= ive
some recommendation that there SHOULD be a way for the user to see all cont= ent
fields.





--
------------------------= -----------------------------------------
Multiple Language Content Type= Internet Draft:
https://datatracker=
.ietf.org/doc/draft-ietf-slim-multilangcontent/
------------------------------------=
-----------------------------

<= /div>
--001a114a737ce5ff550556fbb773-- From nobody Fri Aug 18 01:50:02 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EF213291C for ; Fri, 18 Aug 2017 01:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRSZly8lav-T for ; Fri, 18 Aug 2017 01:49:58 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449F2132397 for ; Fri, 18 Aug 2017 01:49:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=l5eCnu9ZcDQshlMlwubcRUho8PZEkDsifhNh41YTHnkfn8XGC/6bRYQqAl+YgwhMwElbGfmYYBAzPyfNVJA85sM0FaVgqnW6+VQFGOxPISbBJnaNhWQ64yNrOoQ9HwD0adRk/V7aEmd07GPzXrY3tDkHR+zy+uDibq2Z/Offmu8=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 3691 invoked from network); 18 Aug 2017 10:49:56 +0200 Received: from p5dec23ce.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.35.206) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Aug 2017 10:49:56 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Fri, 18 Aug 2017 10:49:53 +0200 Cc: The IESG , draft-ietf-slim-multilangcontent@ietf.org, Bernard Aboba , slim-chairs@ietf.org, slim@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4EBDC6C0-8F6B-423F-A43C-D197753FABB9@kuehlewind.net> References: <150279986062.20971.4568019868114855413.idtracker@ietfa.amsl.com> To: Nik Tomkinson X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170818084956.3682.87134@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Slim] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-slim-multilangcontent-13=3A_=28with_COMMENT=29?= X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 08:50:00 -0000 Hi Nik, see below. > Am 18.08.2017 um 01:53 schrieb Nik Tomkinson = : >=20 > Hi Mirja, >=20 > Regarding the mismatched email addresses, I'll have a think and add = some text to the I-D. Great! >=20 > Regarding the second point, the last paragraph in section 4 says that = 'Additionally, interactive implementations MAY offer the user a choice = from among the available languages'. Is this what you had in mind or do = you think this should be also mentioned in the Security Considerations = as a mitigating response to the risk? I was rather thinking about providing a way to see multiple or all = languages. So that someone how speaks multiples languages or what to = manually apply some translation system, could check if the content is = the same. So yes, it would be good to mention this in the security = considerations but there might also be other use case, e.g. I read it in = my prefer language but there is some unclarity and reading another = version in another language could help to clarify the meaning. So maybe = it=E2=80=99s something you want to mention earlier as well and just = refer to in the security considerations. Mirja >=20 > Nik. >=20 > On 15 August 2017 at 13:24, Mirja K=C3=BChlewind = wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-slim-multilangcontent-13: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Minor comments: > - sec 3.2: > "If there is a =46rom field present, its value MUST > include the same email address as the top-level =46rom header..." > What happen if they are no the same? The security considerations = section > mentions this case but there is no guidance given what to do in this = case > (which address to display)? >=20 > - The security considerations section mentions the risk that the = content might > actually be different in different languages. I think it would be nice = to give > some recommendation that there SHOULD be a way for the user to see all = content > fields. >=20 >=20 >=20 >=20 >=20 > --=20 > ----------------------------------------------------------------- > Multiple Language Content Type Internet Draft: > https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ > ----------------------------------------------------------------- >=20 From nobody Fri Aug 18 05:54:01 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E12B1204DA; Fri, 18 Aug 2017 05:53:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150306083247.14182.7009589498286274826@ietfa.amsl.com> Date: Fri, 18 Aug 2017 05:53:52 -0700 Archived-At: Subject: [Slim] I-D Action: draft-ietf-slim-multilangcontent-14.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 12:53:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Selection of Language for Internet Media WG of the IETF. Title : Multiple Language Content Type Authors : Nik Tomkinson Nathaniel Borenstein Filename : draft-ietf-slim-multilangcontent-14.txt Pages : 23 Date : 2017-08-18 Abstract: This document defines the multipart/multilingual content type, which is an addition to the Multipurpose Internet Mail Extensions (MIME) standard to make it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-slim-multilangcontent-14 https://datatracker.ietf.org/doc/html/draft-ietf-slim-multilangcontent-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-multilangcontent-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 18 06:02:27 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A088913235A; Fri, 18 Aug 2017 06:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OGqDzABX-yg; Fri, 18 Aug 2017 06:02:19 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E359E132064; Fri, 18 Aug 2017 06:02:18 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id d17so42192775lfe.0; Fri, 18 Aug 2017 06:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XWNyVl3hY07Mowvt9NEU5fOGltH7t11NvanVJ1vEVBc=; b=LiEHiTNlJnWZFPtoYJPVVdIGRddze7A64rkDiIFalLuF2kmKrYODxI8nfLnldpWSno HaPekt56iT+xc4I5ig7t7ChB7IWPfxgY2tFMdyvHECiMTkVqCTZGyk2mpzxHXGh4TjBv aiB8HsC2Qj6BgTsAGFuKbCoqA0UFgb1rRO5EbiTuqJqu9qbnQClxGHf7F4vdwpm5zDMD hqVYpl8EEzSoTTbP+J2fYKCMxhFFeqBq0evxWy4qFHH6MO51nW+1c+xBBRiwq4diICAo yaASbfIztaWVXlmUvJbahrRWE1c1LUa+2gvxBIyd6mf6nIC8hXz1o9eVlvdd0ifgbF/e hoDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XWNyVl3hY07Mowvt9NEU5fOGltH7t11NvanVJ1vEVBc=; b=sHV3LRK4qDyjjeztE5AZZk+Te+LedMmIqK08ox+JSJK9C7LxhW7x41f6vuP89FgrL5 LfMC7h8psH9rQ78+IWJwUPoxtVGe37xb0DI4ais105XnjEkvb3EaMtkuBR1qwHytIqwC pUtmtwAsCZ1kO+An2cVTFkU7gohkOqiK4atkOaKYDjgZLWqy7lvOB0EDkkVCOmK9beXI RF1ZVmvSiLwKQB2n8boGucCReqYFvdrWMJslt513CbI9Y6R+N9EnhQL4AlgOfjRi1myn SyZC8wjnjWYRl5YVXBmsHh0ZhsSamZXEicHt6bUJsyumj3YP4yJAu58F+Z+11IvwS9XT 0XCA== X-Gm-Message-State: AHYfb5h23n1zemLyUmYpqw4qFc7L5FrKvdVKtYaGF52MgwMsn1axJT00 4eTFFnV0aTVw3BGO4sAMsZYcFsDXmw== X-Received: by 10.25.100.81 with SMTP id b17mr3388296lfj.237.1503061337070; Fri, 18 Aug 2017 06:02:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.211.15 with HTTP; Fri, 18 Aug 2017 06:02:16 -0700 (PDT) In-Reply-To: <4EBDC6C0-8F6B-423F-A43C-D197753FABB9@kuehlewind.net> References: <150279986062.20971.4568019868114855413.idtracker@ietfa.amsl.com> <4EBDC6C0-8F6B-423F-A43C-D197753FABB9@kuehlewind.net> From: Nik Tomkinson Date: Fri, 18 Aug 2017 14:02:16 +0100 Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: The IESG , draft-ietf-slim-multilangcontent@ietf.org, Bernard Aboba , slim-chairs@ietf.org, slim@ietf.org Content-Type: multipart/alternative; boundary="f403045ea3ca126067055706bda8" Archived-At: Subject: Re: [Slim] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-slim-multilangcontent-13=3A_=28with_COMMENT=29?= X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 13:02:22 -0000 --f403045ea3ca126067055706bda8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, I have added some text and made some recommendations in a new version which I have just submitted. I think it suitably addresses the use case without adding too strong a requirement to the specification. Nik. On 18 August 2017 at 09:49, Mirja Kuehlewind (IETF) wrote: > Hi Nik, > > see below. > > > Am 18.08.2017 um 01:53 schrieb Nik Tomkinson < > rfc.nik.tomkinson@gmail.com>: > > > > Hi Mirja, > > > > Regarding the mismatched email addresses, I'll have a think and add som= e > text to the I-D. > > Great! > > > > > Regarding the second point, the last paragraph in section 4 says that > 'Additionally, interactive implementations MAY offer the user a choice fr= om > among the available languages'. Is this what you had in mind or do you > think this should be also mentioned in the Security Considerations as a > mitigating response to the risk? > > I was rather thinking about providing a way to see multiple or all > languages. So that someone how speaks multiples languages or what to > manually apply some translation system, could check if the content is the > same. So yes, it would be good to mention this in the security > considerations but there might also be other use case, e.g. I read it in = my > prefer language but there is some unclarity and reading another version i= n > another language could help to clarify the meaning. So maybe it=E2=80=99s= something > you want to mention earlier as well and just refer to in the security > considerations. > > Mirja > > > > > Nik. > > > > On 15 August 2017 at 13:24, Mirja K=C3=BChlewind = wrote: > > Mirja K=C3=BChlewind 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: > > ---------------------------------------------------------------------- > > > > Minor comments: > > - sec 3.2: > > "If there is a From field present, its value MUST > > include the same email address as the top-level From header..." > > What happen if they are no the same? The security considerations sectio= n > > mentions this case but there is no guidance given what to do in this ca= se > > (which address to display)? > > > > - The security considerations section mentions the risk that the conten= t > might > > actually be different in different languages. I think it would be nice > to give > > some recommendation that there SHOULD be a way for the user to see all > content > > fields. > > > > > > > > > > > > -- > > ----------------------------------------------------------------- > > Multiple Language Content Type Internet Draft: > > https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ > > ----------------------------------------------------------------- > > > > --=20 ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ ----------------------------------------------------------------- --f403045ea3ca126067055706bda8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja,

I have added some text and ma= de some recommendations in a new version which I have just submitted.
=

I think it suitably addresses the use case without addi= ng too strong a requirement to the specification.

= Nik.

O= n 18 August 2017 at 09:49, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net<= /a>> wrote:
Hi Nik,

see below.

> Am 18.08.2017 um 01:53 schrieb Nik Tomkinson <rfc.nik.tomkinson@gmail.com>:
>
> Hi Mirja,
>
> Regarding the mismatched email addresses, I'll have a think and ad= d some text to the I-D.

Great!

>
> Regarding the second point, the last paragraph in section 4 says that = 'Additionally, interactive implementations MAY offer the user a choice = from among the available languages'. Is this what you had in mind or do= you think this should be also mentioned in the Security Considerations as = a mitigating response to the risk?

I was rather thinking about providing a way to see multiple or all l= anguages. So that someone how speaks multiples languages or what to manuall= y apply some translation system, could check if the content is the same. So= yes, it would be good to mention this in the security considerations but t= here might also be other use case, e.g. I read it in my prefer language but= there is some unclarity and reading another version in another language co= uld help to clarify the meaning. So maybe it=E2=80=99s something you want t= o mention earlier as well and just refer to in the security considerations.=

Mirja

>
> Nik.
>
> On 15 August 2017 at 13:24, Mirja K=C3=BChlewind <ietf@kuehlewind.net> wrote:
> Mirja K=C3=BChlewind 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<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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:
> ------------------------------------------------------------= ----------
>
> Minor comments:
> - sec 3.2:
> "If there is a From field present, its value MUST
>=C2=A0 =C2=A0 include the same email address as the top-level From head= er..."
> What happen if they are no the same? The security considerations secti= on
> mentions this case but there is no guidance given what to do in this c= ase
> (which address to display)?
>
> - The security considerations section mentions the risk that the conte= nt might
> actually be different in different languages. I think it would be nice= to give
> some recommendation that there SHOULD be a way for the user to see all= content
> fields.
>
>
>
>
>
> --
> ------------------------------------------------------------= -----
> Multiple Language Content Type Internet Draft:
> https://datatracker.ietf.org/= doc/draft-ietf-slim-multilangcontent/
> ------------------------------------------------------------= -----
>




--
= 
-----------=
------------------------------------------------------
Multiple Language=
 Content Type Internet Draft:
https:=
//datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/
=
-------------------------=
----------------------------------------

--f403045ea3ca126067055706bda8-- From nobody Wed Aug 30 12:16:06 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D7913292B; Wed, 30 Aug 2017 12:15:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Cc: slim@ietf.org, The IESG , draft-ietf-slim-multilangcontent@ietf.org, slim-chairs@ietf.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org, Bernard Aboba , bernard.aboba@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150412055424.21490.7081089400518365371.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 12:15:54 -0700 Archived-At: Subject: [Slim] Protocol Action: 'Multiple Language Content Type' to Proposed Standard (draft-ietf-slim-multilangcontent-14.txt) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 19:15:54 -0000 The IESG has approved the following document: - 'Multiple Language Content Type' (draft-ietf-slim-multilangcontent-14.txt) as Proposed Standard This document is the product of the Selection of Language for Internet Media Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ Technical Summary: The objective of this document is to define an addition to the Multipurpose Internet Mail Extensions (MIME) standard, to make it possible to send a single message to a group of people in such a way that all of the recipients can read the email in their preferred language. Working Group Summary: This document has been non-controversial. Document Quality: There are no known implementations, however some testing was done with how existing clients handle new multipart media type. IANA review of the new multipart media type was performed and some minor changes were done by the editors. Personnel: Bernard Aboba (SLIM WG co-chair) is the Document Shepherd. The responsible area director is Alexey Melnikov (ART AD).