From nobody Fri May 1 12:23:51 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F9A3A1A61 for ; Fri, 1 May 2020 12:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=peabody-io.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 m0kJEKwCHM8C for ; Fri, 1 May 2020 12:23:24 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 8218F3A1A5C for ; Fri, 1 May 2020 12:23:24 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id a32so275564pje.5 for ; Fri, 01 May 2020 12:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peabody-io.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=N+wxHD2Ehx2bJzfNu0Kl45D0t2grndXyXhherJKRlsE=; b=Y5I8bewRhoSOgEQB6inm63wUhbrPzBlNwvedT6iEmhStvI7XlDwXiNHksMJHh/zPDZ JuUMrPvaWUCmCnIbpGANbNvB0yWbLYIpvNdII+1p5Ac/E3XmJ6i0PSk5WTVMBcxarvFL uC9xU1DrDtG5/8+XtFJMyNN1q7wXa4ylQd8IgtHsuo+ls9gTkvDYqJg5ZEQ9qdem54PK gSHe7Q9HO/vO1qaRGpzbAdFZ1/fJehGOhmwIjFt9nRILM250UsKmnQSUCIL53NVBGKLT +6iLHCUseaQjWdjnUGTF/PsGeNWvD6BOtRNLvYHZHjG4IRz3mppjL1Rfd7vjv883vZX+ dQdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=N+wxHD2Ehx2bJzfNu0Kl45D0t2grndXyXhherJKRlsE=; b=kd3ynvqAIyrhLSrHAzotmnOtzDZ5bj35M1Mr5GmkE4RVqIWQP1TVzVpCnQ7jlkZgLt 49Vxwd1Anjcq5SStvxffbKrsVpUdkgrhS40sKj1vg8u+qgecSXRWXsJD0vxr7Zyj1xUl wtgcrqOOyjwbV+gk1S9M+irx+OBfsUeQZsZKZAbnzzVR/NjPNNRfK6HbIUWspCSCfxJw c2c2SZei2cYWYrEedcv2AgxDRtm6cnBwbaRCwBhTskTdjInbrm02dYuPtAd4XrhkB//N KBvEi5FNF78ejGBDyB6juGgHQY4hfF3FigzJbVdizZBj24Pku37NBFbRvfsEYr5JFoG+ QxHQ== X-Gm-Message-State: AGi0PuaxSs3a7M0cY0kWQwrtBIyjlLkEuHKnFVycfgklwSRyeAQxfUZL l1e202zADA6vED4WJrF93158qBQatw== X-Google-Smtp-Source: APiQypKIZ0NgDXJcCz7Yi1PPMcowNPflHK2EWyOh1yLOBzhb1CDVIL7CXgDABJzCHY0dL2oEDOfdHw== X-Received: by 2002:a17:90a:e2d0:: with SMTP id fr16mr1365209pjb.146.1588361003573; Fri, 01 May 2020 12:23:23 -0700 (PDT) Received: from BGPMacBookPro.charter.com ([2600:6c50:7f:5954:80a1:9342:10c:2eb0]) by smtp.gmail.com with ESMTPSA id p62sm2863921pfb.93.2020.05.01.12.23.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 May 2020 12:23:23 -0700 (PDT) To: "Murray S. Kucherawy" Cc: DISPATCH list References: <87tv3a9hjo.fsf@hobgoblin.ariadne.com> <2b167f97-b380-2701-d1fd-e6f72d15f9a3@peabody.io> From: Brad Peabody Message-ID: <4a9cec49-b9f1-3741-45dc-24d61735e426@peabody.io> Date: Fri, 1 May 2020 12:23:21 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4CFAD290DED653EC7B8ED0E4" Content-Language: en-US Archived-At: Subject: Re: [dispatch] UUID Version 6 Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 19:23:28 -0000 This is a multi-part message in MIME format. --------------4CFAD290DED653EC7B8ED0E4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Murray, There's actually been quite a bit of feedback on this overall - some of it in the IETF meetings, or on the mailing list.  Some of it in separate emails.  I've started trying to collect the information here https://github.com/uuid6/uuid6-ietf-draft as a way to succinctly describe all of the arguments and the outcome as regards the draft.  (The draft itself will have background info, but I think there is more detail than is appropriate for a draft. I'm trying to document the various "why we are choosing do/not do it this way" items.  I think this helps both for when people agree with the decision and when they don't and would like to change it - at least the arguments are clearly laid out for discussion and not only tucked away in an email archive.) I do plan on doing a new updated draft at some point, hopefully soon. As regards DISPATCH, I'm not sure what the next step is.  One idea that was mentioned (for another item) on the IETF call was creating a non-WG mailing list to continue the discussion. Is that a possibility for UUID6? Otherwise my plan was to collect up and organize all of the information that has arisen on this and then begin discussion again after the draft has been updated, and we have this clear and concise list of arguments that covers the points that have been brought up.  That way discussion that follows can be as focused as possible. Best, Brad On 4/29/20 10:30 PM, Murray S. Kucherawy wrote: > On Mon, Mar 2, 2020 at 11:54 AM Brad Peabody > wrote: > > Thanks Dale.  This first draft was intended to clearly outline the > problem, since the initial feedback I received on this idea from > general > mailing list could be summarized as "why do we need this". > > I agree with your point though, it needs more detail.  I will make > it my > next step on this to outline the specific fields.  Even if I refer to > RFC 4122 I think summarizing what goes where in this document > makes good > sense. > > > Is a new version of this planned based on the feedback received? > > As for process: This came up in the ART area of IETF 107, not > DISPATCH, so it was up for area-wide interest discussion but no > specific action yet.  I'd like to see what response there is to a > revision. > > -MSK --------------4CFAD290DED653EC7B8ED0E4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Murray,

There's actually been quite a bit of feedback on this overall - some of it in the IETF meetings, or on the mailing list.  Some of it in separate emails.  I've started trying to collect the information here https://github.com/uuid6/uuid6-ietf-draft as a way to succinctly describe all of the arguments and the outcome as regards the draft.  (The draft itself will have background info, but I think there is more detail than is appropriate for a draft. I'm trying to document the various "why we are choosing do/not do it this way" items.  I think this helps both for when people agree with the decision and when they don't and would like to change it - at least the arguments are clearly laid out for discussion and not only tucked away in an email archive.)

I do plan on doing a new updated draft at some point, hopefully soon.

As regards DISPATCH, I'm not sure what the next step is.  One idea that was mentioned (for another item) on the IETF call was creating a non-WG mailing list to continue the discussion. Is that a possibility for UUID6?

Otherwise my plan was to collect up and organize all of the information that has arisen on this and then begin discussion again after the draft has been updated, and we have this clear and concise list of arguments that covers the points that have been brought up.  That way discussion that follows can be as focused as possible.

Best, Brad


On 4/29/20 10:30 PM, Murray S. Kucherawy wrote:
On Mon, Mar 2, 2020 at 11:54 AM Brad Peabody <brad@peabody.io> wrote:
Thanks Dale.  This first draft was intended to clearly outline the
problem, since the initial feedback I received on this idea from general
mailing list could be summarized as "why do we need this".

I agree with your point though, it needs more detail.  I will make it my
next step on this to outline the specific fields.  Even if I refer to
RFC 4122 I think summarizing what goes where in this document makes good
sense.

Is a new version of this planned based on the feedback received?

As for process: This came up in the ART area of IETF 107, not DISPATCH, so it was up for area-wide interest discussion but no specific action yet.  I'd like to see what response there is to a revision.

-MSK
--------------4CFAD290DED653EC7B8ED0E4-- From nobody Fri May 8 13:18:48 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACF93A0E11; Fri, 8 May 2020 13:17:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: John Levine via Datatracker To: Cc: dispatch@ietf.org, draft-ietf-dispatch-javascript-mjs.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158896904545.17044.5288882047334991439@ietfa.amsl.com> Reply-To: John Levine Date: Fri, 08 May 2020 13:17:25 -0700 Archived-At: Subject: [dispatch] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 20:17:26 -0000 Reviewer: John Levine Review result: Ready with Issues This is my take on issues with this document mostly from my personal review but also after some discussion we've had on the i18ndir list. Some parts of this draft are quite hard to follow, so I'm giving my understanding of the parts I'm commenting on in case I got them wrong. I realize that a lot of this is unchanged from 4329, which we should have reviewed more carefully 15 years ago. Section 4 on Encoding: I believe it says that the preferred encoding for all javascript is UTF-8, but some sources use other encodings and sometimes mislabel them. So for anything that you don't know is a module, you have to sniff the contents to see if starts with a BOM, and if so, use the BOM's encoding and delete the BOM. If the BOM uses an encoding the consumer doesn't support, fail. If there's no BOM, use the declared character set, or if it's one the consumer doesn't understand, treat it as UTF-8 anyway. Step 1 says "The longest matching octet sequence determines the encoding." which I don't understand, since none of the encodings overlap. Does that mean it should interpret a partial BOM, e.g., EF BB 20 for UTF-8? Also, why is the BOM deleted? ECMAscript says a BOM is a space so it should be harmless. While I understand that there is a lot of history here, I'm wondering if the range mislabeling is really as extreme as this implies. Is there, say, text labelled Shift-JIS which is really UTF-8 or UTF-16? If the mislabelled stuff is consistently mislabelled as one of UTF-8/16/16BE/16LE perhaps it could say to try the BOM trick on those encodings and fail otherwise. I don't understand step 3, "The character encoding scheme is determined to be UTF-8." How can it be determined to be UTF-8 other than by steps 1 and 2? Or is it saying that if the declared charset is one the consumer doesn't understand such as KOI8-U, assume it's UTF-8 anyway. I'd suggest rewriting the section to make it clearer that if it's not a module, you look for a BOM, use its encoding if you find one, and (I think) otherwise use the declared encoding. Section 4.3 on error handling: I think it says that if there's a byte sequence that isn't a valid code point in the current encoding, it can fail or it can turn the bytes into Unicode replacement characters, but MUST NOT try anything else. I agree with this advice but again it could be clearer. Section 3 on Modules: I believe it says that JS scripts and modules have different syntax but you can't easily tell them apart by inspection. (The term "goal" is familiar since I used to write books about compiler tools, and I realize it's what the ECMAscript spec uses, but it's confusing if you're not a programming language expert. How about just saying that scripts and modules have different syntax?) Hence some software uses a .mjs filename as a hint that something is a module. Again I realize that there is a bunch of existing code but this is not great MIME practice. If the difference matters, it's worth providing a new MIME type such as text/jsmodule, which could have consistently accurate content encodings. It would coexist with all of the other old MIME types and the .mjs hints. Since this draft deprecates a bunch of existing types and de-deprecates another, this seems as good a time as any to do it. I also wonder whether it's worth making a distinction in MIME processing between modules and scripts. Would there be any harm in saying to sniff everything for a BOM? If a .mjs file turns out to have a UTF-16 BOM, it's wrong, but is it likely to be anything other than a javascript module in UTF-16? From nobody Fri May 8 16:19:08 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F373A1032; Fri, 8 May 2020 16:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 GxrU3KUxWoUt; Fri, 8 May 2020 16:19:03 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 9DF3F3A0FFE; Fri, 8 May 2020 16:19:00 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id z2so3471866iol.11; Fri, 08 May 2020 16:19:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E0WjntUYlYjWvjz3ahh4ucg3kXdAqEcPfBK4em24L0A=; b=EkIMdp5i2yYK6TKXYnP4KvkQzCcSISLAxk5DQHi5jwmZ2N26raUiMgeZIAxLQY6evB i0I53TO6K4xr7us6v6jyMGkKZjYg5WX4aKrnyj3jW7BB8KfMDFfInA5gxYomDEDqDFwG YPbtTk1pdutmqaQDBdzZo/NUooXLuadxkUdnBobV6Tfc9rdjlAjgBdxh/xCrAOmw5l8k guDFXtmXScSYdGTfyX8v7DHnQNs8K2yYRqwfuUGAKd3leCoPbN40RjpqoyAp7rvZB3Io EJC7/mwc5amago7lsggBfFpA+k3R7a+RuX7VEpy4FdWWXZTvqvxPKuooiiOb9wcn2OkH aWtQ== X-Gm-Message-State: AGi0PuZTsQEeM3R1PtgTen1JcbcVzB9VIvhmQ+wjlRS9yTbyuRsaKreX pdWCnRuzsMgUc043AhlGJm7TjDf7VzaTmnFERBc= X-Google-Smtp-Source: APiQypJiN6KcMMSIQyVUNcg+BeLyegxarysN8Ab3Pmh8d4h6TlxwTzrUMb5zl/C8hgsItmmttxUjrCHIpwW2ExEfZ4E= X-Received: by 2002:a02:b794:: with SMTP id f20mr4924875jam.118.1588979939622; Fri, 08 May 2020 16:18:59 -0700 (PDT) MIME-Version: 1.0 References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> In-Reply-To: <158896904545.17044.5288882047334991439@ietfa.amsl.com> From: Barry Leiba Date: Fri, 8 May 2020 19:18:48 -0400 Message-ID: To: John Levine Cc: dispatch@ietf.org, draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org Content-Type: multipart/alternative; boundary="000000000000db446305a52b3889" Archived-At: Subject: Re: [dispatch] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 23:19:06 -0000 --000000000000db446305a52b3889 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, John, for taking the time on this. It=E2=80=99s a really helpful r= eview, and appreciated. Barry On Fri, May 8, 2020 at 4:17 PM John Levine via Datatracker wrote: > Reviewer: John Levine > Review result: Ready with Issues > > This is my take on issues with this document mostly from my personal > review but also after some discussion we've had on the i18ndir list. > > Some parts of this draft are quite hard to follow, so I'm giving my > understanding of the parts I'm commenting on in case I got them wrong. > I realize that a lot of this is unchanged from 4329, which we should > have reviewed more carefully 15 years ago. > > Section 4 on Encoding: I believe it says that the preferred encoding > for all javascript is UTF-8, but some sources use other encodings and > sometimes mislabel them. So for anything that you don't know is a > module, you have to sniff the contents to see if starts with a BOM, > and if so, use the BOM's encoding and delete the BOM. If the BOM uses > an encoding the consumer doesn't support, fail. If there's no BOM, > use the declared character set, or if it's one the consumer doesn't > understand, treat it as UTF-8 anyway. > > Step 1 says "The longest matching octet sequence determines the encoding.= " > which I don't understand, since none of the encodings overlap. Does that > mean it should interpret a partial BOM, e.g., EF BB 20 for UTF-8? Also, > why is the BOM deleted? ECMAscript says a BOM is a space so it should be > harmless. > > While I understand that there is a lot of history here, I'm wondering if > the range mislabeling is really as extreme as this implies. Is there, > say, text labelled Shift-JIS which is really UTF-8 or UTF-16? If the > mislabelled stuff is consistently mislabelled as one of UTF-8/16/16BE/16L= E > perhaps it could say to try the BOM trick on those encodings and fail > otherwise. > > I don't understand step 3, "The character encoding scheme is > determined to be UTF-8." How can it be determined to be UTF-8 other > than by steps 1 and 2? Or is it saying that if the declared charset > is one the consumer doesn't understand such as KOI8-U, assume it's > UTF-8 anyway. > > I'd suggest rewriting the section to make it clearer that if it's not > a module, you look for a BOM, use its encoding if you find one, and (I > think) otherwise use the declared encoding. > > Section 4.3 on error handling: I think it says that if there's a byte > sequence that isn't a valid code point in the current encoding, it can > fail or it can turn the bytes into Unicode replacement characters, but > MUST NOT try anything else. I agree with this advice but again it > could be clearer. > > Section 3 on Modules: I believe it says that JS scripts and modules have > different syntax but you can't easily tell them apart by inspection. > (The term "goal" is familiar since I used to write books about compiler > tools, and I realize it's what the ECMAscript spec uses, but it's > confusing if you're not a programming language expert. How about just > saying that scripts and modules have different syntax?) > > Hence some software uses a .mjs filename as a hint that something is a > module. Again I realize that there is a bunch of existing code but > this is not great MIME practice. If the difference matters, it's > worth providing a new MIME type such as text/jsmodule, which could > have consistently accurate content encodings. It would coexist with > all of the other old MIME types and the .mjs hints. Since this draft > deprecates a bunch of existing types and de-deprecates another, this > seems as good a time as any to do it. > > I also wonder whether it's worth making a distinction in MIME > processing between modules and scripts. Would there be any harm in > saying to sniff everything for a BOM? If a .mjs file turns out to > have a UTF-16 BOM, it's wrong, but is it likely to be anything other > than a javascript module in UTF-16? > > > > --000000000000db446305a52b3889 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, John, for taking the time on this.=C2=A0 It= =E2=80=99s a really helpful review, and appreciated.

Barry

On Fri, May 8, 2020 at 4:17 PM= John Levine via Datatracker <norepl= y@ietf.org> wrote:
Reviewer= : John Levine
Review result: Ready with Issues

This is my take on issues with this document mostly from my personal
review but also after some discussion we've had on the i18ndir list.
Some parts of this draft are quite hard to follow, so I'm giving my
understanding of the parts I'm commenting on in case I got them wrong.<= br> I realize that a lot of this is unchanged from 4329, which we should
have reviewed more carefully 15 years ago.

Section 4 on Encoding: I believe it says that the preferred encoding
for all javascript is UTF-8, but some sources use other encodings and
sometimes mislabel them.=C2=A0 So for anything that you don't know is a=
module, you have to sniff the contents to see if starts with a BOM,
and if so, use the BOM's encoding and delete the BOM.=C2=A0 If the BOM = uses
an encoding the consumer doesn't support, fail.=C2=A0 If there's no= BOM,
use the declared character set, or if it's one the consumer doesn't=
understand, treat it as UTF-8 anyway.

Step 1 says "The longest matching octet sequence determines the encodi= ng."
which I don't understand, since none of the encodings overlap.=C2=A0 Do= es that
mean it should interpret a partial BOM, e.g., EF BB 20 for UTF-8? Also, why is the BOM deleted?=C2=A0 ECMAscript says a BOM is a space so it should= be
harmless.

While I understand that there is a lot of history here, I'm wondering i= f
the range mislabeling is really as extreme as this implies.=C2=A0 Is there,=
say, text labelled Shift-JIS which is really UTF-8 or UTF-16? If the
mislabelled stuff is consistently mislabelled as one of UTF-8/16/16BE/16LE<= br> perhaps it could say to try the BOM trick on those encodings and fail other= wise.

I don't understand step 3, "The character encoding scheme is
determined to be UTF-8."=C2=A0 How can it be determined to be UTF-8 ot= her
than by steps 1 and 2?=C2=A0 Or is it saying that if the declared charset is one the consumer doesn't understand such as KOI8-U, assume it's<= br> UTF-8 anyway.

I'd suggest rewriting the section to make it clearer that if it's n= ot
a module, you look for a BOM, use its encoding if you find one, and (I
think) otherwise use the declared encoding.

Section 4.3 on error handling: I think it says that if there's a byte sequence that isn't a valid code point in the current encoding, it can<= br> fail or it can turn the bytes into Unicode replacement characters, but
MUST NOT try anything else.=C2=A0 I agree with this advice but again it
could be clearer.

Section 3 on Modules: I believe it says that JS scripts and modules have different syntax but you can't easily tell them apart by inspection.=C2= =A0
(The term "goal" is familiar since I used to write books about co= mpiler
tools, and I realize it's what the ECMAscript spec uses, but it's <= br> confusing if you're not a programming language expert.=C2=A0 How about = just
saying that scripts and modules have different syntax?)

Hence some software uses a .mjs filename as a hint that something is a
module.=C2=A0 Again I realize that there is a bunch of existing code but this is not great MIME practice.=C2=A0 If the difference matters, it's<= br> worth providing a new MIME type such as text/jsmodule, which could
have consistently accurate content encodings.=C2=A0 It would coexist with all of the other old MIME types and the .mjs hints. Since this draft
deprecates a bunch of existing types and de-deprecates another, this
seems as good a time as any to do it.

I also wonder whether it's worth making a distinction in MIME
processing between modules and scripts.=C2=A0 Would there be any harm in saying to sniff everything for a BOM?=C2=A0 If a .mjs file turns out to
have a UTF-16 BOM, it's wrong, but is it likely to be anything other than a javascript module in UTF-16?



--000000000000db446305a52b3889-- From nobody Fri May 8 16:25:30 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44E33A1011 for ; Fri, 8 May 2020 16:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.099 X-Spam-Level: X-Spam-Status: No, score=-17.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 t8dClS0XjDSs for ; Fri, 8 May 2020 16:24:59 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 0FDEC3A0E2C for ; Fri, 8 May 2020 16:24:58 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id k110so2874499otc.2 for ; Fri, 08 May 2020 16:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=11+GTKXDK5niqCTcEtmZyPK7Z5kZNmEhXPkivEa2FA8=; b=R28CwxsHgEAcLqFQ5y4Al+DRdEImOejOYKM5MdWkkzwGtCnra4mP+VTP5i04E0bkmh 55nxhQbabznaFzdkE9SLRFCjaewEEGq5AjojhY5y6l5lhnbD3o+GQj7prlQvZQj8wAH1 SwX7W+F3PuJpVqhf2cKLfvgTJuxgLEfMWqozHc7YMEnYfUYM8NWxtNN6kkdsqGhxdqMa wbgS6oM5PR+TuMTfxb8NccQ5aJyrg6QUd7OZG+M/RKc/gUQbtyFtoqCZ0LMWlaDHkN7c rws1yxGUpv+L+9LCRm7qzxtDMFvuliDd8H8v0Bv+5rlTRQBjKv+XKlus3lSMGzAxpRYI 1iNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=11+GTKXDK5niqCTcEtmZyPK7Z5kZNmEhXPkivEa2FA8=; b=t3gP3B8YHu1DLMkBrw61XWtQ8G5WCFle6Rfyu8z6Xf+dnOXTDONEbggTqwIrehiAgB 6yYVdZRC30esIllp+kEll740g/6Ojk3xZJ6sWNZnTYxR21lnOpH//91zjKIYhntwgODW ddvF3/guhppMI8v1Zs3Lo0DeJeViGvu0uI2ZTaB4abUCkT5PNrYhkpH/+4Eg6SbJPwzv opLx0tjWl7ygGe6AIA3Z3nlr+FxkFXaPYLktl74mPyzuxflORsP/NbJE8/Dy668S32T3 vuL544iWh16dF4+kMIXL5fb/Qp9tM7K8Ql1tLf8dazKe9CxKFU/xrAz5ZoY2HfpSBu3m HaKQ== X-Gm-Message-State: AGi0PuZzMQz8Q1LhX6Y40ESpCYs35tFW6U4ECbRW3xFYVRFRW74nFDW0 inMLeKXMhEn8Q0kDfB0l/MJ9u45+WJhYJEzybU/+/g== X-Google-Smtp-Source: APiQypKAPLlMJbslU+YCDMBGcwpcpA2kmxRl6GP4Z/uoTMF3ALbY8xrlDFq9Ai8IiShFbm7bLgIKlY8FMubUOP9VvLc= X-Received: by 2002:a9d:12e2:: with SMTP id g89mr4091366otg.289.1588980297608; Fri, 08 May 2020 16:24:57 -0700 (PDT) MIME-Version: 1.0 References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> In-Reply-To: From: Myles Borins Date: Fri, 8 May 2020 19:24:46 -0400 Message-ID: To: Barry Leiba Cc: John Levine , DISPATCH WG , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org Content-Type: multipart/alternative; boundary="000000000000320ce905a52b4e28" Archived-At: Subject: Re: [dispatch] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 23:25:03 -0000 --000000000000320ce905a52b4e28 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Regarding the mime type "text/javascript" The HTML Specification is rather explicit Servers should use text/javascript for JavaScript resources. Servers should not use other JavaScript MIME types for JavaScript resources, and must not use non-JavaScript MIME types. Browsers validate that source text being loaded is delivered with the "text/javascript" mime type and fails if it is any other mime is used. There is no in-band way to determine the goal of a Module, and Node.js needed a signal to be able to determine how to interpret source text. This was the motivation behind creating .mjs. The problem this created was that webservers, not knowing the extension, were not serving the test/javascript mimetype and browsers were then in turn failing to load them as modules. This was a pretty awful developer experience, especially for folks experimenting with a newer technology they didn't entirely understand to begin with. With this context in mind I don't think it is really worth going and making a distinct mimetype for modules, at least not one that would be strictly enforced, at the very least this probably shouldn't be pursued without broader socialization and buy-in from browser vendors. My gut is that we are best to use this proposal to document the existing status quo... what people are using and is working, rather than introduce new constraints that do not have any existing implementation or adoption. I'll let folks more familiar with your other notes field those questions. On Fri, May 8, 2020 at 7:19 PM Barry Leiba wrote: > Thanks, John, for taking the time on this. It=E2=80=99s a really helpful= review, > and appreciated. > > Barry > > On Fri, May 8, 2020 at 4:17 PM John Levine via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: John Levine >> Review result: Ready with Issues >> >> This is my take on issues with this document mostly from my personal >> review but also after some discussion we've had on the i18ndir list. >> >> Some parts of this draft are quite hard to follow, so I'm giving my >> understanding of the parts I'm commenting on in case I got them wrong. >> I realize that a lot of this is unchanged from 4329, which we should >> have reviewed more carefully 15 years ago. >> >> Section 4 on Encoding: I believe it says that the preferred encoding >> for all javascript is UTF-8, but some sources use other encodings and >> sometimes mislabel them. So for anything that you don't know is a >> module, you have to sniff the contents to see if starts with a BOM, >> and if so, use the BOM's encoding and delete the BOM. If the BOM uses >> an encoding the consumer doesn't support, fail. If there's no BOM, >> use the declared character set, or if it's one the consumer doesn't >> understand, treat it as UTF-8 anyway. >> >> Step 1 says "The longest matching octet sequence determines the >> encoding." >> which I don't understand, since none of the encodings overlap. Does tha= t >> mean it should interpret a partial BOM, e.g., EF BB 20 for UTF-8? Also, >> why is the BOM deleted? ECMAscript says a BOM is a space so it should b= e >> harmless. >> >> While I understand that there is a lot of history here, I'm wondering if >> the range mislabeling is really as extreme as this implies. Is there, >> say, text labelled Shift-JIS which is really UTF-8 or UTF-16? If the >> mislabelled stuff is consistently mislabelled as one of UTF-8/16/16BE/16= LE >> perhaps it could say to try the BOM trick on those encodings and fail >> otherwise. >> >> I don't understand step 3, "The character encoding scheme is >> determined to be UTF-8." How can it be determined to be UTF-8 other >> than by steps 1 and 2? Or is it saying that if the declared charset >> is one the consumer doesn't understand such as KOI8-U, assume it's >> UTF-8 anyway. >> >> I'd suggest rewriting the section to make it clearer that if it's not >> a module, you look for a BOM, use its encoding if you find one, and (I >> think) otherwise use the declared encoding. >> >> Section 4.3 on error handling: I think it says that if there's a byte >> sequence that isn't a valid code point in the current encoding, it can >> fail or it can turn the bytes into Unicode replacement characters, but >> MUST NOT try anything else. I agree with this advice but again it >> could be clearer. >> >> Section 3 on Modules: I believe it says that JS scripts and modules have >> different syntax but you can't easily tell them apart by inspection. >> (The term "goal" is familiar since I used to write books about compiler >> tools, and I realize it's what the ECMAscript spec uses, but it's >> confusing if you're not a programming language expert. How about just >> saying that scripts and modules have different syntax?) >> >> Hence some software uses a .mjs filename as a hint that something is a >> module. Again I realize that there is a bunch of existing code but >> this is not great MIME practice. If the difference matters, it's >> worth providing a new MIME type such as text/jsmodule, which could >> have consistently accurate content encodings. It would coexist with >> all of the other old MIME types and the .mjs hints. Since this draft >> deprecates a bunch of existing types and de-deprecates another, this >> seems as good a time as any to do it. >> >> I also wonder whether it's worth making a distinction in MIME >> processing between modules and scripts. Would there be any harm in >> saying to sniff everything for a BOM? If a .mjs file turns out to >> have a UTF-16 BOM, it's wrong, but is it likely to be anything other >> than a javascript module in UTF-16? >> >> >> >> --000000000000320ce905a52b4e28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Regarding the mime type "text/javascript"
<= div>
Servers should use text/javascript for JavaScript resources. = Servers should not use other JavaScript MIME types for JavaScript resources= , and must not use non-JavaScript MIME types.

Br= owsers validate that source text being loaded is delivered with the "t= ext/javascript" mime type and fails if it is any other mime is used. T= here is no in-band way to determine the goal of a Module, and Node.js neede= d a signal to be able to determine how to interpret=C2=A0source text. This = was the motivation behind creating .mjs.

The probl= em this created was that webservers, not knowing the extension, were not se= rving the test/javascript mimetype=C2=A0and browsers were then in turn fail= ing to load them as modules. This was a pretty awful=C2=A0developer experie= nce, especially for folks experimenting with a newer technology they didn&#= 39;t entirely=C2=A0understand to begin with.

With = this context in mind I don't think it is really worth going and making = a distinct mimetype=C2=A0for modules, at least not one that would be strict= ly=C2=A0enforced, at the very least this probably shouldn't be pursued= =C2=A0without broader socialization and buy-in from browser vendors.
<= div>
My gut is that we are best to use this proposal to docum= ent the existing status quo... what people are using and is working, rather= than introduce new constraints that do not have any existing implementatio= n or adoption.

I'll let folks more familiar=C2= =A0with your other notes field those questions.

On Fri, May 8, 2020 = at 7:19 PM Barry Leiba <barry= leiba@computer.org> wrote:
Thanks, John, for taking the time = on this.=C2=A0 It=E2=80=99s a really helpful review, and appreciated.
=

Barry

On Fri, May 8= , 2020 at 4:17 PM John Levine via Datatracker <noreply@ietf.org> wrote:
Reviewer: John Levine
Review result: Ready with Issues

This is my take on issues with this document mostly from my personal
review but also after some discussion we've had on the i18ndir list.
Some parts of this draft are quite hard to follow, so I'm giving my
understanding of the parts I'm commenting on in case I got them wrong.<= br> I realize that a lot of this is unchanged from 4329, which we should
have reviewed more carefully 15 years ago.

Section 4 on Encoding: I believe it says that the preferred encoding
for all javascript is UTF-8, but some sources use other encodings and
sometimes mislabel them.=C2=A0 So for anything that you don't know is a=
module, you have to sniff the contents to see if starts with a BOM,
and if so, use the BOM's encoding and delete the BOM.=C2=A0 If the BOM = uses
an encoding the consumer doesn't support, fail.=C2=A0 If there's no= BOM,
use the declared character set, or if it's one the consumer doesn't=
understand, treat it as UTF-8 anyway.

Step 1 says "The longest matching octet sequence determines the encodi= ng."
which I don't understand, since none of the encodings overlap.=C2=A0 Do= es that
mean it should interpret a partial BOM, e.g., EF BB 20 for UTF-8? Also, why is the BOM deleted?=C2=A0 ECMAscript says a BOM is a space so it should= be
harmless.

While I understand that there is a lot of history here, I'm wondering i= f
the range mislabeling is really as extreme as this implies.=C2=A0 Is there,=
say, text labelled Shift-JIS which is really UTF-8 or UTF-16? If the
mislabelled stuff is consistently mislabelled as one of UTF-8/16/16BE/16LE<= br> perhaps it could say to try the BOM trick on those encodings and fail other= wise.

I don't understand step 3, "The character encoding scheme is
determined to be UTF-8."=C2=A0 How can it be determined to be UTF-8 ot= her
than by steps 1 and 2?=C2=A0 Or is it saying that if the declared charset is one the consumer doesn't understand such as KOI8-U, assume it's<= br> UTF-8 anyway.

I'd suggest rewriting the section to make it clearer that if it's n= ot
a module, you look for a BOM, use its encoding if you find one, and (I
think) otherwise use the declared encoding.

Section 4.3 on error handling: I think it says that if there's a byte sequence that isn't a valid code point in the current encoding, it can<= br> fail or it can turn the bytes into Unicode replacement characters, but
MUST NOT try anything else.=C2=A0 I agree with this advice but again it
could be clearer.

Section 3 on Modules: I believe it says that JS scripts and modules have different syntax but you can't easily tell them apart by inspection.=C2= =A0
(The term "goal" is familiar since I used to write books about co= mpiler
tools, and I realize it's what the ECMAscript spec uses, but it's <= br> confusing if you're not a programming language expert.=C2=A0 How about = just
saying that scripts and modules have different syntax?)

Hence some software uses a .mjs filename as a hint that something is a
module.=C2=A0 Again I realize that there is a bunch of existing code but this is not great MIME practice.=C2=A0 If the difference matters, it's<= br> worth providing a new MIME type such as text/jsmodule, which could
have consistently accurate content encodings.=C2=A0 It would coexist with all of the other old MIME types and the .mjs hints. Since this draft
deprecates a bunch of existing types and de-deprecates another, this
seems as good a time as any to do it.

I also wonder whether it's worth making a distinction in MIME
processing between modules and scripts.=C2=A0 Would there be any harm in saying to sniff everything for a BOM?=C2=A0 If a .mjs file turns out to
have a UTF-16 BOM, it's wrong, but is it likely to be anything other than a javascript module in UTF-16?



--000000000000320ce905a52b4e28-- From nobody Fri May 8 16:38:03 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC5F3A005C for ; Fri, 8 May 2020 16:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Hj9Z9oW+; dkim=pass (1536-bit key) header.d=taugh.com header.b=aL4zkxxY 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 sWjnhr3DS7cC for ; Fri, 8 May 2020 16:37:58 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 545303A003E for ; Fri, 8 May 2020 16:37:58 -0700 (PDT) Received: (qmail 44270 invoked from network); 8 May 2020 23:31:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=acec.5eb5ebc4.k2005; i=johnl-iecc.com@submit.iecc.com; bh=ZZpkjCKg0ZU2U8uNbDwe4jqiRitE0t6x5ry2UMHfUWU=; b=Hj9Z9oW+gnllNgur5rYVLeCKK9lst0Bxhx8+PynrpLbZvWh7Tc0OosSLA8fhsh7dPvFxazCcMTrGjFyQEvm46uJTd9mq3ermY1giaJUDbxM59i/0Iid9nrIgZmUlZ15PzKAToNUYiBQ/ejAqfoLTnm939aNAgffRJqhpryMl6JZrnYbOqoxiid52YHMjk7ETdwJsW0+tvXto1BDb8Hvhh1Bg7a11/dKI0LbgFFj0rtLwpF6796bOeAfhHJvuNgAN DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=acec.5eb5ebc4.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=ZZpkjCKg0ZU2U8uNbDwe4jqiRitE0t6x5ry2UMHfUWU=; b=aL4zkxxYkZWolpQW1mCQn5BpkseCyRL44oIG8V/H8ALrD+x19ams1ajuAfPrVfy38O2ojDrRB1y4BQXCPH965U/m0Gz/nBEkVJxVBhr6IWgPo9nIoW2m+NA3lGV2chNmKWKcjWcGDCgWC6C5vxO4dU3H/bujsDS78nB7+XqE+DWuO3WMN6EP2Ifv0t3L8v71YFOSVhIroBjI+Qj1glh1QTW8750eTBaFlXaSeTZuh392h3OmImd3bxC6/BTnoV6q Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 08 May 2020 23:31:15 -0000 Date: 8 May 2020 19:31:15 -0400 Message-ID: From: "John R Levine" To: "Myles Borins" , "Barry Leiba" Cc: "DISPATCH WG" , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org In-Reply-To: References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dispatch] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 23:38:00 -0000 > With this context in mind I don't think it is really worth going and making > a distinct mimetype for modules, at least not one that would be > strictly enforced, at the very least this probably shouldn't be > pursued without broader socialization and buy-in from browser vendors. > > My gut is that we are best to use this proposal to document the existing > status quo... what people are using and is working, rather than introduce > new constraints that do not have any existing implementation or adoption. I completely agree that for something like this which is widely implemented, the spec should describe what actually works. But I was wondering if you could narrow down the range of what you describe so future implementors don't waste time worrying about screwups that aren't an issue in practice. I'm sorry to hear that people are using filename extensions to tell what's in a file. I'd hoped that all of the badness from old versions of Windows doing that might have been a hint. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri May 8 17:02:13 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755303A017E for ; Fri, 8 May 2020 17:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.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 R3VvPjMEHzcE for ; Fri, 8 May 2020 17:00:06 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 895B53A011F for ; Fri, 8 May 2020 17:00:02 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id k18so3600824ion.0 for ; Fri, 08 May 2020 17:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=K5cJzbmUn3YqJzUmQobAkPKl1D5hOqp0iK/mCsv5uLk=; b=zJnrZx8QxZXNKJjGFyKLaDWEuwiGTW8dznUHsX7zk+8cCjRITpZbDd+lbJAbRL/TkW MmIbrXyOSCIO5dfQn9yI2uT3rtmGm/zCKSMXZf+ZE/GIHK6Pn8gm4IsZ6z0ylvj2NRcJ jZWvyAeQw2BqVzy7EFNMtu9s+r/p3ORzUzajIJ4yHYx3ZjAi1z2HaT/1IRKOTCnoTVfK NXQuUthZWWxOcDR4azoFAHJ0/3jqcfTli9z/2Ez5qFbsyq8Ug6IQyNFT+GpJRmaKOpQt nRIdFqik0yJprVnXy/pWSpEbaH4BMQ7WSn4dqK8FmUR/l6+HOxa9CLGTFw8kkYcoJcdu KVPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=K5cJzbmUn3YqJzUmQobAkPKl1D5hOqp0iK/mCsv5uLk=; b=S0JGV7BIcrjfkMZVbt5M9HLpo47QTAOVdV2Id6QUK+byjqHyMA/SU7MfqIYKuUIWwG nd2hv3hZuxHrjUNRWCXn4yjvN9SLUNvYvOV5uHdBlxXS8+4L7KFWz1dyC8Pyoca2+xhG GeXDu4d8JnPXUXzZvH5D3pY6QOXsU7J2kcrAdlX3uaZxsW0xpKdZEidEwpto/vk6ZnuV YgLbTVvxDLzLff8deuk9ksHo04byYU5GdSsn8j70bP8JUHskA5JavJx+COVjK4VuiVO0 JNjaAFV6kbuXfH67dujqLSqOJkCvRXEfTAPX31NBDE9nev7yiRJOe5FCqE83EjX7K0Uh TjLA== X-Gm-Message-State: AGi0PuZyghtZqs8lBp3npevixju+zBGDOEB93z6iZxQLgf0CQjldxnjF 5aW8norftsh9sJ13yieQ8d03aw== X-Google-Smtp-Source: APiQypJbnn40906RNpP8sBVI2AZJIIjTnboKyPcEQdWpe1pxywjOSAY3ifobHyBMCF/rOF+LqFzz6w== X-Received: by 2002:a02:b19a:: with SMTP id t26mr5141030jah.111.1588982401809; Fri, 08 May 2020 17:00:01 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:19d9:fc77:2aa8:83c9]) by smtp.gmail.com with ESMTPSA id w23sm548777iod.9.2020.05.08.17.00.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 17:00:01 -0700 (PDT) To: Myles Borins , Barry Leiba Cc: John Levine , DISPATCH WG , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> From: "Matthew A. Miller" Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE= Message-ID: <791ca602-758e-cb0f-a1a4-8fb6b74a8b61@outer-planes.net> Date: Fri, 8 May 2020 18:00:00 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 00:00:19 -0000 Thank you very much for the review, John. This is very helpful, and will work on changes to resolve the concerns. Regarding the encoding: UTF-8 is strongly encouraged, and required for a source to be a module. Preferring BOM sniffing over a charset declaration is the result of general purpose browsers having to deal with a myriad of misconfigured servers; this being the defense mechanism that permitted the best interoperability. The part about "longest matching octet sequence" is a missed remnant from the original document which included UTF-32BE/LE entries. As UTF-32BE/LE is no longer found in the wild*, those entries were removed but I missed cleaning up that sentence. Implementations today do ignore the BOM once the character encoding is worked out, so this was portion from Section 4.2 was kept to reflect that. I'm not sure what changes to make here regarding that, although the ending "to source text" is another missed remnant from my editing that will be removed. Section 4.2 still includes step #3 to deal with the (in practice quite common) case of a missing BOM and the media type missing a charset parameter. There are also too many servers that set this to "ISO-8859-1" without otherwise examining the sources being served. We'll make it clearer this is a default/fallback case. - m&m Matthew A. Miller * Web browsers haven't accepted UTF-32 encodings of JavaScript for quite a long while On 20/05/08 17:24, Myles Borins wrote: > Regarding the mime type "text/javascript" > > The HTML Specification is rather explicit > > > Servers should use text/javascript for JavaScript resources. Servers > should not use other JavaScript MIME types for JavaScript resources, > and must not use non-JavaScript MIME types. > > > Browsers validate that source text being loaded is delivered with the > "text/javascript" mime type and fails if it is any other mime is used. > There is no in-band way to determine the goal of a Module, and Node.js > needed a signal to be able to determine how to interpret source text. > This was the motivation behind creating .mjs. > > The problem this created was that webservers, not knowing the extension, > were not serving the test/javascript mimetype and browsers were then in > turn failing to load them as modules. This was a pretty awful developer > experience, especially for folks experimenting with a newer technology > they didn't entirely understand to begin with. > > With this context in mind I don't think it is really worth going and > making a distinct mimetype for modules, at least not one that would be > strictly enforced, at the very least this probably shouldn't be > pursued without broader socialization and buy-in from browser vendors. > > My gut is that we are best to use this proposal to document the existing > status quo... what people are using and is working, rather than > introduce new constraints that do not have any existing implementation > or adoption. > > I'll let folks more familiar with your other notes field those questions. > > On Fri, May 8, 2020 at 7:19 PM Barry Leiba > wrote: > > Thanks, John, for taking the time on this.  It’s a really helpful > review, and appreciated. > > Barry > > On Fri, May 8, 2020 at 4:17 PM John Levine via Datatracker > > wrote: > > Reviewer: John Levine > Review result: Ready with Issues > > This is my take on issues with this document mostly from my personal > review but also after some discussion we've had on the i18ndir list. > > Some parts of this draft are quite hard to follow, so I'm giving my > understanding of the parts I'm commenting on in case I got them > wrong. > I realize that a lot of this is unchanged from 4329, which we should > have reviewed more carefully 15 years ago. > > Section 4 on Encoding: I believe it says that the preferred encoding > for all javascript is UTF-8, but some sources use other > encodings and > sometimes mislabel them.  So for anything that you don't know is a > module, you have to sniff the contents to see if starts with a BOM, > and if so, use the BOM's encoding and delete the BOM.  If the > BOM uses > an encoding the consumer doesn't support, fail.  If there's no BOM, > use the declared character set, or if it's one the consumer doesn't > understand, treat it as UTF-8 anyway. > > Step 1 says "The longest matching octet sequence determines the > encoding." > which I don't understand, since none of the encodings overlap.  > Does that > mean it should interpret a partial BOM, e.g., EF BB 20 for > UTF-8? Also, > why is the BOM deleted?  ECMAscript says a BOM is a space so it > should be > harmless. > > While I understand that there is a lot of history here, I'm > wondering if > the range mislabeling is really as extreme as this implies.  Is > there, > say, text labelled Shift-JIS which is really UTF-8 or UTF-16? If > the > mislabelled stuff is consistently mislabelled as one of > UTF-8/16/16BE/16LE > perhaps it could say to try the BOM trick on those encodings and > fail otherwise. > > I don't understand step 3, "The character encoding scheme is > determined to be UTF-8."  How can it be determined to be UTF-8 other > than by steps 1 and 2?  Or is it saying that if the declared charset > is one the consumer doesn't understand such as KOI8-U, assume it's > UTF-8 anyway. > > I'd suggest rewriting the section to make it clearer that if > it's not > a module, you look for a BOM, use its encoding if you find one, > and (I > think) otherwise use the declared encoding. > > Section 4.3 on error handling: I think it says that if there's a > byte > sequence that isn't a valid code point in the current encoding, > it can > fail or it can turn the bytes into Unicode replacement > characters, but > MUST NOT try anything else.  I agree with this advice but again it > could be clearer. > > Section 3 on Modules: I believe it says that JS scripts and > modules have > different syntax but you can't easily tell them apart by > inspection.  > (The term "goal" is familiar since I used to write books about > compiler > tools, and I realize it's what the ECMAscript spec uses, but it's > confusing if you're not a programming language expert.  How > about just > saying that scripts and modules have different syntax?) > > Hence some software uses a .mjs filename as a hint that > something is a > module.  Again I realize that there is a bunch of existing code but > this is not great MIME practice.  If the difference matters, it's > worth providing a new MIME type such as text/jsmodule, which could > have consistently accurate content encodings.  It would coexist with > all of the other old MIME types and the .mjs hints. Since this draft > deprecates a bunch of existing types and de-deprecates another, this > seems as good a time as any to do it. > > I also wonder whether it's worth making a distinction in MIME > processing between modules and scripts.  Would there be any harm in > saying to sniff everything for a BOM?  If a .mjs file turns out to > have a UTF-16 BOM, it's wrong, but is it likely to be anything other > than a javascript module in UTF-16? > > > From nobody Fri May 8 23:03:57 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774C43A07D5; Fri, 8 May 2020 23:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se 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 6-SWlr4yUj9d; Fri, 8 May 2020 23:03:48 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (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 4BA733A0474; Fri, 8 May 2020 23:03:48 -0700 (PDT) Received: from [192.165.72.241] (unknown [IPv6:2a02:80:3ffc:0:4461:8a41:6460:34a1]) by mail.frobbit.se (Postfix) with ESMTPSA id E8AC3289F1; Sat, 9 May 2020 08:03:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1589004226; bh=UadEYOakqs/oVDc5GwlYvkoxk1biKLtDN+SrtPFgGOU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M8L3KVfuQLFNXXEBQNxtGpIICq3wG1oM2H/Mnoq6njxYL6S5cNX+HH6WJafAbHRQQ CuY8QM3279dJnxrgbSzFHATI1dB2g2KthjxjoJeAcjEu+zdJHvyfWT24MfPc7PXDkE EN1hsVyU39f3A9nuhGKfNJWUySZRcy0nNt96sWtQ= From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John R Levine" Cc: "Myles Borins" , "Barry Leiba" , "DISPATCH WG" , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org Date: Sat, 09 May 2020 08:03:43 +0200 X-Mailer: MailMate (1.13.1r5676) Message-ID: In-Reply-To: References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_40758AEF-C6E3-4F9F-9B01-DA18757DF618_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [dispatch] [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 06:03:55 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_40758AEF-C6E3-4F9F-9B01-DA18757DF618_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 9 May 2020, at 1:31, John R Levine wrote: > I completely agree that for something like this which is widely impleme= nted, the spec should describe what actually works. But I was wondering = if you could narrow down the range of what you describe so future impleme= ntors don't waste time worrying about screwups that aren't an issue in pr= actice. It is also the case that the IETF document can explain exactly this, that= the use of filename extensions is discouraged (for a multitude of reason= s), and still define a new MIME-type which is the recommended use case. C= ollaboration with W3C is of course essential. > I'm sorry to hear that people are using filename extensions to tell wha= t's in a file. I'd hoped that all of the badness from old versions of Wi= ndows doing that might have been a hint. This is something that just must go away, and I think a big note in non-f= riendly letters must be added in the security considerations section is n= eeded that explain the situation and why the current practice is not real= ly what we want in the wild. I.e. yes, while still documenting "what works", that should not be the go= al. It will lead to even more problems getting secure mechanisms in brows= ers deployed. Patrik --=_MailMate_40758AEF-C6E3-4F9F-9B01-DA18757DF618_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iHAEARECADAWIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCXrZHvxIccGF0cmlrQGZy b2JiaXQuc2UACgkQrMabGguI181CYQCdHmMlpnPBUWnWEb6jEavAp0kwdfIAmgIW Mlp12oj1kvWalndpFbEg8iLA =LxH/ -----END PGP SIGNATURE----- --=_MailMate_40758AEF-C6E3-4F9F-9B01-DA18757DF618_=-- From nobody Sat May 9 09:43:05 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5A83A0F20 for ; Sat, 9 May 2020 09:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=UTF+67Qh; dkim=pass (1536-bit key) header.d=taugh.com header.b=QUb/iXoe 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 omBN6kRBmApb for ; Sat, 9 May 2020 09:43:01 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 65CAE3A0F1B for ; Sat, 9 May 2020 09:43:01 -0700 (PDT) Received: (qmail 47052 invoked from network); 9 May 2020 16:36:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b7c6.5eb6dc04.k2005; i=johnl-iecc.com@submit.iecc.com; bh=r/Jy1svjDIgUX5mfgwij4YdOqRUeyZE0OJHN8n0fmjI=; b=UTF+67Qh2Te6miv0ox/egp2TFnYr4knpoN5rU2Dqscf6ZWVVdCZT/DREXT/JDq3LbqAPyin20jX/g0Z5UVbyiIuWIqf2N0xVxPQepbde0Otjy70DnHrN2ebBeNsBlK4yhCATYEF9tI2GN8e04AZUGYzjasmqkDarGEpc4WMI6PkRWPT2x490b3mIwxhqBtbL3trlGD3Xagjkenw9t42QZV1qzjO9sMI+hJMKQ/VUN85tFNqiFJsDsdMjZCv0GPpT DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b7c6.5eb6dc04.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=r/Jy1svjDIgUX5mfgwij4YdOqRUeyZE0OJHN8n0fmjI=; b=QUb/iXoe6io1BKFSAcbkjx1t5C0hLKBODSG+lHG6gGKcA53F5zT4xjqH9ZNEiyKYOEgOP1XbUWZd04KPkQaFsoeoGw24VO8gtFKF7XiWtHhQDCsJKOfmmi9QCR/qd+iOPbzMG+8fGIRRhko6gW2CfasoVheaBsBYVJ8mS4UZQxnNFgataVcSVaz34HwuUp+iBvDzqEQYA/vOZ8Lfx99DzJnUB4mpHwhwB8/As4KhVfa2rbb4Eqw32f9wXy5mIqk2 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 09 May 2020 16:36:20 -0000 Date: 9 May 2020 12:36:20 -0400 Message-ID: From: "John R Levine" To: "=?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?=" Cc: "Myles Borins" , "DISPATCH WG" , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org In-Reply-To: References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-63736491-1589042180=:84818" Archived-At: Subject: Re: [dispatch] [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 16:43:03 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-63736491-1589042180=:84818 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 9 May 2020, Patrik Fältström wrote: >> I'm sorry to hear that people are using filename extensions to tell what's in a file. I'd hoped that all of the badness from old versions of Windows doing that might have been a hint. > > This is something that just must go away, and I think a big note in non-friendly letters must be added in the security considerations section is needed that explain the situation and why the current practice is not really what we want in the wild. > > I.e. yes, while still documenting "what works", that should not be the goal. It will lead to even more problems getting secure mechanisms in browsers deployed. I agree with Patrik, this reinvents a security hole from the floppy disk era and is not something we should let pass without at least making it clear that we believe it is a significant mistake. It occurs to me that http clients can send an Accept header, so how about saying that modules SHOULD be text/jsmodule, but MAY be text/javascript for backward compatibiltiy with clients that don't handle text/jsmodule? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-63736491-1589042180=:84818-- From nobody Sat May 9 10:19:56 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409353A0CFE; Sat, 9 May 2020 10:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 2GzO3heUn9Yy; Sat, 9 May 2020 10:19:51 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A24C3A0C7F; Sat, 9 May 2020 10:19:51 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jXT8b-0000Ir-Mr; Sat, 09 May 2020 13:19:45 -0400 Date: Sat, 09 May 2020 13:19:39 -0400 From: John C Klensin To: John R Levine , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= cc: Myles Borins , DISPATCH WG , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org Message-ID: <5BDA07C38DB9D03729015B9A@PSB> In-Reply-To: References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 17:19:54 -0000 --On Saturday, May 9, 2020 12:36 -0400 John R Levine wrote: > On Sat, 9 May 2020, Patrik F=C3=A4ltstr=C3=B6m wrote: >>> I'm sorry to hear that people are using filename extensions >>> to tell what's in a file. I'd hoped that all of the badness >>> from old versions of Windows doing that might have been a >>> hint. >>=20 >> This is something that just must go away, and I think a big >> note in non-friendly letters must be added in the security >> considerations section is needed that explain the situation >> and why the current practice is not really what we want in >> the wild. >>=20 >> I.e. yes, while still documenting "what works", that should >> not be the goal. It will lead to even more problems getting >> secure mechanisms in browsers deployed. >=20 > I agree with Patrik, this reinvents a security hole from the > floppy disk era and is not something we should let pass > without at least making it clear that we believe it is a > significant mistake. >=20 > It occurs to me that http clients can send an Accept header, > so how about saying that modules SHOULD be text/jsmodule, but > MAY be text/javascript for backward compatibiltiy with clients > that don't handle text/jsmodule? And these kinds of suggestions (both of them) along with some caveats about heuristics that will work well most of the time but maybe not always, and some text that should be much more obvious to someone reading quickly to figure out what to do (even if they are clear to a very careful reader) identify, to me, the main deficiencies in the current I-D. john From nobody Sat May 9 11:36:50 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7503A0E66; Sat, 9 May 2020 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 6JcLdNZ1PMAi; Sat, 9 May 2020 11:36:47 -0700 (PDT) Received: from mail-il1-f171.google.com (mail-il1-f171.google.com [209.85.166.171]) (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 C6F783A0EBD; Sat, 9 May 2020 11:36:46 -0700 (PDT) Received: by mail-il1-f171.google.com with SMTP id s10so4542089iln.11; Sat, 09 May 2020 11:36:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bz5E/9LL/Q+VOoy1DpgqzqS/4qzlsFcTntxIUgBd/K4=; b=DXeKtkjwJEDyVtBTu0VBFEoVXd3LjjR1xb3Y2T7B/roDc6My+vzOAzZXli60mHPNrC opuDl8tFE628fV2ahp8W/Q35auXsIMvlKSW2uAE2CyZMuphC2rGaCDuLbx4K7vZjbwSZ KuCUZpYIx91Fg97rDStcl52bokBi+jLljRDNJWlouSXhwjX5w2Yo0TIGF7E4WiMiQ1N/ W86KP9ZY2zKnojyqlxadeS75awP+8sc95n4MiWoIR34gw1OsVIXTCbKTxDKop7xBMUBM Vy0rYM1GGFAJeUi6Z09smkz+3bDkFzwQN/HaV5TjfUCb/4YACVIMJONhLBA5IcY80rpR 8Cuw== X-Gm-Message-State: AGi0PuYQ9nwkRlMP0DmS0l0ROYTL2YQT2d6dx5AOGLRD35JvT3zixbCu KC9VkaKX/aaRRKu1bE5v4G+idfsPVBaGDafUQCE= X-Google-Smtp-Source: APiQypKHghcV4KvANC9KwCDQO8PRYjG0nJ2ADDCoIR6orcvNKXGmaR3L+9KX/CGUYeKDawOlPg4Py8yq9YWtpM9w6aM= X-Received: by 2002:a92:414d:: with SMTP id o74mr9264374ila.266.1589049405807; Sat, 09 May 2020 11:36:45 -0700 (PDT) MIME-Version: 1.0 References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Sat, 9 May 2020 14:36:34 -0400 Message-ID: To: John R Levine Cc: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , Myles Borins , DISPATCH WG , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dispatch] [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 18:36:49 -0000 > It occurs to me that http clients can send an Accept header, so how about > saying that modules SHOULD be text/jsmodule, but MAY be text/javascript > for backward compatibiltiy with clients that don't handle text/jsmodule? I'm very much not fond of the SHOULD... but MAY construction, because I think the MAY contradicts the SHOULD. I think the right way to say this is more along the line of "SHOULD use text/jsmodule. If that is not practical because backward compatibility with clients that do not support text/jsmodule is necessary, then the alternative MUST be text/javascript." Barry From nobody Sat May 9 12:21:28 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8443A0F8C for ; Sat, 9 May 2020 12:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=wrWGhaNs; dkim=pass (1536-bit key) header.d=taugh.com header.b=h/WTXLeX 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 elJD6kOCLcZm for ; Sat, 9 May 2020 12:21:24 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 1E80E3A0F8B for ; Sat, 9 May 2020 12:21:24 -0700 (PDT) Received: (qmail 91642 invoked from network); 9 May 2020 19:14:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=165f8.5eb70122.k2005; i=johnl-iecc.com@submit.iecc.com; bh=rBJ0t7JPpWcFwc0NjMf7P6Z8eLaLONUZ7zOvGYJDX18=; b=wrWGhaNsS/DdtMw/oa3b2veIaCOSu91Dx5LIBjWmACSECCDFPFqpPVTDUle0qKRigNRK+Keyt0CC0EcwstRzl9LpAFODDdJotlIPccG4qcGeFiu3xLY3c6uVHPuZHvQgqBRFOhXvNDN9AcNdjB9A733HYxg3/v9KnZU4yHZI7MW2dKdldmJSyae1NJucAaZNZHWzZh67K0GTmKnLabSn3PmRh6C8KKocs17ZWAgEUHWoVmAniIzXcLNiASx+K4l4 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=165f8.5eb70122.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=rBJ0t7JPpWcFwc0NjMf7P6Z8eLaLONUZ7zOvGYJDX18=; b=h/WTXLeXaD+Eo5BH8NGDjc+nIXVXuIK41VmOidYq+cFuvBUZTh08jp/GP6//chz71RgHrt5rQX8u/TiMLMU0uyH7AxKQ+/Kw1zCnaVwswnvEMIEVXS4vhh7EvbJhHubMqT4DRx7Yb4PFV9IqUlmumuG2VKE5PkaR5WpNETU7B04eTH+TOAZhE1WFn5MwcP8aXRinIgZXva+G1OQh0dPjm+VnkdW1Jb1M4f46mL6sZsJoNiHR9BSaeoxzLX5gfCB9 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 09 May 2020 19:14:42 -0000 Date: 9 May 2020 15:14:41 -0400 Message-ID: From: "John R Levine" To: "Barry Leiba" Cc: "DISPATCH WG" , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org In-Reply-To: References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dispatch] [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 19:21:26 -0000 On Sat, 9 May 2020, Barry Leiba wrote: >> It occurs to me that http clients can send an Accept header, so how about >> saying that modules SHOULD be text/jsmodule, but MAY be text/javascript >> for backward compatibiltiy with clients that don't handle text/jsmodule? > I think the right way to say this is more along the line of "SHOULD > use text/jsmodule. If that is not practical because backward > compatibility with clients that do not support text/jsmodule is > necessary, then the alternative MUST be text/javascript." Fine by me. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat May 9 13:28:59 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4DD3A0CD5; Sat, 9 May 2020 13:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 CdiV9zTV5qib; Sat, 9 May 2020 13:28:18 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E706A3A0CD1; Sat, 9 May 2020 13:28:17 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jXW4v-0001on-0A; Sat, 09 May 2020 16:28:09 -0400 Date: Sat, 09 May 2020 16:28:03 -0400 From: John C Klensin To: Barry Leiba , John R Levine cc: Myles Borins , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , DISPATCH WG , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org Message-ID: <5C4E8FFB57EBAE9A3C3BEA61@PSB> In-Reply-To: References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 20:28:20 -0000 +1, fwiw. john --On Saturday, May 9, 2020 14:36 -0400 Barry Leiba wrote: >> It occurs to me that http clients can send an Accept header, >> so how about saying that modules SHOULD be text/jsmodule, but >> MAY be text/javascript for backward compatibiltiy with >> clients that don't handle text/jsmodule? > > I'm very much not fond of the SHOULD... but MAY construction, > because I think the MAY contradicts the SHOULD. > > I think the right way to say this is more along the line of > "SHOULD use text/jsmodule. If that is not practical because > backward compatibility with clients that do not support > text/jsmodule is necessary, then the alternative MUST be > text/javascript." > > Barry From nobody Sat May 9 21:49:15 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994683A073E; Sat, 9 May 2020 21:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se 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 qoTzPsCgMVRd; Sat, 9 May 2020 21:49:07 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (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 66E603A0736; Sat, 9 May 2020 21:49:06 -0700 (PDT) Received: from [192.165.72.241] (unknown [IPv6:2a02:80:3ffc:0:1906:82e6:93dc:cd08]) by mail.frobbit.se (Postfix) with ESMTPSA id 8CB4A288C6; Sun, 10 May 2020 06:49:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1589086143; bh=ANTXe3qQw9MpXJXe7nzPcu/6MXc8RswKRL6wTnuFszE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=v/47i7S+Vv2bGvRp2A+SjrUt/TxyfJ2u/5CWqPk06AmntcAXOK81wW9FLbKuW8rYz ZGkkuCobNAtvZpNmQ3yfNG+wc29LjAqZpxCY3vkQELNLDnBFPNG6wMhuhPT7VKwgXs R8P6o2rcqn11QL/Cb7a3aZayPiTfxI1hf9FCkMH8= From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John C Klensin" Cc: "Barry Leiba" , "John R Levine" , "Myles Borins" , "DISPATCH WG" , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org Date: Sun, 10 May 2020 06:49:02 +0200 X-Mailer: MailMate (1.13.1r5676) Message-ID: In-Reply-To: <5C4E8FFB57EBAE9A3C3BEA61@PSB> References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> <5C4E8FFB57EBAE9A3C3BEA61@PSB> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_67D30FDB-D23F-44AF-A950-2C0307E03404_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [dispatch] [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 04:49:12 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_67D30FDB-D23F-44AF-A950-2C0307E03404_= Content-Type: text/plain On 9 May 2020, at 22:28, John C Klensin wrote: > +1, fwiw. Agree > john > > > --On Saturday, May 9, 2020 14:36 -0400 Barry Leiba > wrote: > >>> It occurs to me that http clients can send an Accept header, >>> so how about saying that modules SHOULD be text/jsmodule, but >>> MAY be text/javascript for backward compatibiltiy with >>> clients that don't handle text/jsmodule? >> >> I'm very much not fond of the SHOULD... but MAY construction, >> because I think the MAY contradicts the SHOULD. >> >> I think the right way to say this is more along the line of >> "SHOULD use text/jsmodule. If that is not practical because >> backward compatibility with clients that do not support >> text/jsmodule is necessary, then the alternative MUST be >> text/javascript." >> >> Barry --=_MailMate_67D30FDB-D23F-44AF-A950-2C0307E03404_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iHAEARECADAWIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCXreHvhIccGF0cmlrQGZy b2JiaXQuc2UACgkQrMabGguI182KGACeIudjehuLUg7KAWeRD6W29u5HMowAnRWu XAihVthH+kQeZALK+30/azFS =meCG -----END PGP SIGNATURE----- --=_MailMate_67D30FDB-D23F-44AF-A950-2C0307E03404_=-- From nobody Mon May 11 00:22:55 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D825F3A08B5 for ; Mon, 11 May 2020 00:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.099 X-Spam-Level: X-Spam-Status: No, score=-17.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 lUpf5-ev5D1I for ; Mon, 11 May 2020 00:22:50 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 279153A0747 for ; Mon, 11 May 2020 00:22:49 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id ee19so603952qvb.11 for ; Mon, 11 May 2020 00:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+Y/uDBEwwu4H5HoQvAuDDTwBY50dhm3CWcwbvSNfROQ=; b=OXxYJn/G1Ch2ZPl/IKIUvpvK79NzFQJvzErogHtNLDMvteoWfvAOghRLs3vviWhwVK aGOgj/lt17mtugYXJ5cQM6s72a70vRhXtoD+5gdVRXa37pej4XFwx9sDWQnx5rXYiXgB 1VmMTDM6xWNES7SRhBmsqXPUJh5421VuWlkVH352siNyKUZhvZfHG4RszBvgfCnTIz0I gwcKioa9iM+byDrM9jM4cceZo0HraAD7onRCxo8E/ICrRPeoTuTgWTJ6jvHSl6dslNWR 9u1CmZE/hitVnymUigjxj6+Qj2Vn+DuIoRfQmDEUMTf+7XsjTQ2cLIFRKVhS5uW9OZCZ LeSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+Y/uDBEwwu4H5HoQvAuDDTwBY50dhm3CWcwbvSNfROQ=; b=uMdeFFYrPTKR5PJJrFmoOfK6Eg66Yijb5kogQjLVGd3diLuLumXn9KOgYmm5ztVA6I ua+mPLhd4ANzdRIvBI7QeFG5JEY2oG/qNvOUgkJpbcEyUkbCkPf684wITe+tieyYaZOF k5sc6bd3tl5R2OHdSa6jq4jxEK0HMbuGICPw2WNT7R4qXhiNBIKUPyGZg+jDo9+YAELa 62tVT81co/0YoAW3IOJfUaqzIHee9vFFRLU3uuyBqlluw3EFkCV3x0uWN934uJ6F5Pxy byhBbvmmdFjIA6+3KXiwOuEBqYw8+T7geO7lpAGX3oePsymsk3eiTq5VFuaZBUmojuSM Ztug== X-Gm-Message-State: AGi0PuZE9exVzPawd5IEe1y05SIvnthEcif/YFAyQdbrECsYr8Xd4kOy N0DQqmUDHqrJlBg5JbwUhL4m7IroDd6qbXI2V9Dg3w== X-Google-Smtp-Source: APiQypISmdz1A5gH6CaFHgEfNN8CpLYtN4EPWvKTfzNqnzb/HVjxdVeSFp7EUjw3mox++Zp3g6jjoZaUlf3nv1oo9Iw= X-Received: by 2002:ad4:4105:: with SMTP id i5mr14335603qvp.205.1589181767662; Mon, 11 May 2020 00:22:47 -0700 (PDT) MIME-Version: 1.0 References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> In-Reply-To: From: Mathias Bynens Date: Mon, 11 May 2020 09:22:36 +0200 Message-ID: To: John R Levine Cc: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , Myles Borins , DISPATCH WG , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org, annevk@annevk.nl Content-Type: multipart/alternative; boundary="000000000000bf2f8805a55a36f4" Archived-At: Subject: Re: [dispatch] [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 07:22:52 -0000 --000000000000bf2f8805a55a36f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, May 9, 2020 at 6:36 PM John R Levine wrote: > On Sat, 9 May 2020, Patrik F=C3=A4ltstr=C3=B6m wrote: > >> I'm sorry to hear that people are using filename extensions to tell > what's in a file. I'd hoped that all of the badness from old versions of > Windows doing that might have been a hint. > > > > This is something that just must go away, and I think a big note in > non-friendly letters must be added in the security considerations section > is needed that explain the situation and why the current practice is not > really what we want in the wild. > > > > I.e. yes, while still documenting "what works", that should not be the > goal. It will lead to even more problems getting secure mechanisms in > browsers deployed. I agree with Patrik, this reinvents a security hole from the floppy disk > era and is not something we should let pass without at least making it > clear that we believe it is a significant mistake. > > It occurs to me that http clients can send an Accept header, so how about > saying that modules SHOULD be text/jsmodule, but MAY be text/javascript > for backward compatibiltiy with clients that don't handle text/jsmodule? > I agree it would have been nice if the HTML spec + browsers had restricted modules to a new MIME type, but this proposal was discussed and rejected . In 2017, all major browsers supported JavaScript modules using the recommended MIME type of text/javascript (Myles already posted the details), or any other JS MIME type as fallback. At this point, I=E2=80=99m afraid the ship has sailed. Introducing yet anot= her MIME type *now* is unlikely to gain adoption in the HTML Standard, browsers, or on the web (because it wouldn=E2=80=99t be backwards compatible). Let=E2=80= =99s not publish specs that intentionally conflict with both the HTML Standard and web reality. Also, why is the BOM deleted? ECMAscript says a BOM is a space so it > should be harmless. It=E2=80=99s not entirely harmless. The following JS program behaves differ= ently if it=E2=80=99s preceded by a BOM: #!/usr/bin/env bash Without BOM, this is a hashbang comment, and no exception is thrown. With BOM, this is invalid syntax, resulting in a SyntaxError exception. Stripping away the BOM is something hosts (e.g. browsers) do before processing the source as JS. --000000000000bf2f8805a55a36f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, May 9, 2020 at 6:36 PM John R= Levine <johnl@taugh.com> wrot= e:
On Sat, 9 May= 2020, Patrik F=C3=A4ltstr=C3=B6m wrote:
>> I'm sorry to hear that people are using filename extensions to= tell what's in a file.=C2=A0 I'd hoped that all of the badness fro= m old versions of Windows doing that might have been a hint.
>
> This is something that just must go away, and I think a big note in no= n-friendly letters must be added in the security considerations section is = needed that explain the situation and why the current practice is not reall= y what we want in the wild.
>
> I.e. yes, while still documenting "what works", that should = not be the goal. It will lead to even more problems getting secure mechanis= ms in browsers deployed.=C2=A0=C2=A0
=C2=A0
I agree with Patrik, this reinvents a security hole from = the floppy disk
era and is not something we should let pass without at least making it
clear that we believe it is a significant mistake.

It occurs to me that http clients can send an Accept header, so how about <= br> saying that modules SHOULD be text/jsmodule, but MAY be text/javascript for backward compatibiltiy with clients that don't handle text/jsmodule= ?

I agree it would have been nice if th= e HTML spec + browsers had restricted modules to a new MIME type, but this proposal was discusse= d and rejected. In 2017, all major browsers supported JavaScript module= s using the recommended MIME type of text/javascript (Myles already posted = the details), or any other JS MIME type=C2=A0as fallback.

At this point, I=E2=80=99m afraid the ship has sailed. Introducing ye= t another MIME type now is unlikely to gain adoption in the HTML Sta= ndard, browsers, or on the web (because it wouldn=E2=80=99t be backwards co= mpatible).=C2=A0Let=E2=80=99s not publish specs that intentionally conflict= with both the HTML Standard and web reality.

Also, why is the BOM deleted?=C2= =A0 ECMAscript says a BOM is a space so it should be harmless.=

It=E2=80=99s not entirely harmless. The following JS pr= ogram behaves differently if it=E2=80=99s preceded by a BOM:

=
#!/usr/bin/env bash

Without BOM, this i= s a hashbang comment, and no exception is thrown. With BOM, this is invalid= syntax, resulting in a SyntaxError exception. Stripping away the BOM is so= mething hosts (e.g. browsers) do before processing the source as JS.
<= /div>
--000000000000bf2f8805a55a36f4-- From nobody Mon May 11 10:08:48 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E2C3A0B01 for ; Mon, 11 May 2020 09:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=lH/phKJ0; dkim=pass (1536-bit key) header.d=taugh.com header.b=dHgkMqVJ 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 MgszFdYM0e-X for ; Mon, 11 May 2020 09:55:30 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 7EF963A0B00 for ; Mon, 11 May 2020 09:55:30 -0700 (PDT) Received: (qmail 94829 invoked from network); 11 May 2020 16:55:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=17269.5eb9837f.k2005; i=johnl-iecc.com@submit.iecc.com; bh=Cy/yjPVuOAuSTvrjQ2h5857u8h61u2vyFKdAkUGXL0Q=; b=lH/phKJ02rQfiUP54Rmutiz92ybZo/CKzuZEW+O9250rLLMHZWVVOgIrRxP5Gn91Llr1+fTtgdakfaKYqg0Y/iYsvDI6hE24do/YEQ/BPRvqz2LBx4hllQ7MwKK2MyQ04cGkMIfEZRbzQhpxpbSd1FqIs750RjNcQQPZLpUcZ8Uc1A1ZdX2VPNX5wNc/kNGLh010GTMcMChye9/Noc7Cao2CoudqxsuGzkMTUsqoNsmqVPZmvhmaInRnGjPM2eCY DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=17269.5eb9837f.k2005; olt=johnl-iecc.com@submit.iecc.com; bh=Cy/yjPVuOAuSTvrjQ2h5857u8h61u2vyFKdAkUGXL0Q=; b=dHgkMqVJ0oOg/Go+B36RVcNcOcjdHtScpgAPKMbqDM1pzYFTLR8pmcsTli76dmSAywE7dmWvo1zuYZqtHBpUBuoEnc9EgQowufWlCmFvMpiFwsLjhIq6JlQxEGQMRBR4dHBPKEIPBxXw92CwOxxxSaTRkbu6AcnOkioBgbqe5VyX/Gh0pVFNBFqfqhTF1HsFr8kOJ5eZ4BGuO43wLRIokcOQD7DhCfxQijCeAep3k3EjprsiWU6XuZBsQwIOg5V8 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 11 May 2020 16:55:27 -0000 Date: 11 May 2020 12:55:26 -0400 Message-ID: From: "John R Levine" To: "Mathias Bynens" Cc: "DISPATCH WG" , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org In-Reply-To: References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-369232136-1589216127=:4953" Archived-At: Subject: Re: [dispatch] [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 16:55:39 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-369232136-1589216127=:4953 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > At this point, I’m afraid the ship has sailed. Introducing yet another MIME > type *now* is unlikely to gain adoption in the HTML Standard, browsers, or > on the web (because it wouldn’t be backwards compatible). Let’s not publish > specs that intentionally conflict with both the HTML Standard and web > reality. It actually would be backward compatible because of the advice to use Accept media types to tell when to send which media type, but if browsers aren't going to do it, I guess we put a warning in the security section and give up. > It’s not entirely harmless. The following JS program behaves differently if > it’s preceded by a BOM: > > #!/usr/bin/env bash I really don't want to know when self-running shell scripts became part of Ecmascript. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-369232136-1589216127=:4953-- From nobody Mon May 11 12:16:43 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64B03A0C5A; Mon, 11 May 2020 12:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 Vy9IBytOMc9x; Mon, 11 May 2020 12:16:36 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414F13A0C55; Mon, 11 May 2020 12:16:31 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jYDuc-000HBH-GH; Mon, 11 May 2020 15:16:26 -0400 Date: Mon, 11 May 2020 15:16:18 -0400 From: John C Klensin To: John R Levine , Mathias Bynens cc: DISPATCH WG , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org Message-ID: <841F372D6CFE1C52B07D0A25@PSB> In-Reply-To: References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 19:16:39 -0000 --On Monday, May 11, 2020 12:55 -0400 John R Levine wrote: >> At this point, I'm afraid the ship has sailed. Introducing >> yet another MIME type *now* is unlikely to gain adoption in >> the HTML Standard, browsers, or on the web (because it >> wouldn't be backwards compatible). Let's not publish >> specs that intentionally conflict with both the HTML Standard >> and web reality. > > It actually would be backward compatible because of the advice > to use Accept media types to tell when to send which media > type, but if browsers aren't going to do it, I guess we put a > warning in the security section and give up. Well, just a minute. Despite approval by DISPATCH for further discussion and processing, this is basically an individual submission, not a draft developed by a WG. With the understanding that what I'm about to say is not I18n-specific and therefore should perhaps go on the agenda of the next DISPATCH meeting or wait for IETF Last Call, the IETF has, as Patrik has pointed out, both a collection of standards-track and BCP specifications in these areas and experience with what happens when other approaches (like reliance on name suffixes) are used instead. Recommending something else is not just a matter of Security Considerations and, fwiw, I note that at least one document has been stuck after IETF Last Call completed in September because the IESG had DISCUSS-level concerns about telling implementers what they should do if they chose to not conform to the IETF's normative recommendations. If this is really just a description of what browser vendors are doing or will do now and in the future, then we have a long history of publishing "for the information of the community, this is what some vendor or cluster of vendors are doing" descriptive Informational documents. They are not standards track, they do not use normative language (2119/8174 terminology included), they just describe what is being done and are quite explicit about that. So, if the decision criteria for what belongs in this I-D is "whatever the browser vendors are going to do whether the IETF thinks it is a good idea or not", then let's see it recast as a "what is being done in practice" description, with the normative language removed or transformed into "if you want to do what the vendors are doing, then this is what you need to do" (or even "should" do - noting lower case). If that means updating the registration for text/javascript (which, I note, is in the registry at https://www.iana.org/assignments/media-types/media-types.xhtml#text as "OBSOLETED in favor of application/javascript" -- exactly the opposite of which this I-D proposes) and application/javascript to treat them as vendor registrations (applying the exception for non-faceted names allowed by Appendix A of RFC 6838) then so be it... because that is, apparently, the truth of the matter. Sorry, but it seems to me that this document is trying to have it both (or all three) ways: to be a normative document without meeting the higher bar the IETF usually applies for standards track documents, to be a vendor specification without making that clear in the text (and noting that vendor specifications are still expected to have accurate Security Considerations sections), and to make requirements that are at variances with significant community experience about bad results when similar things have been done in only slightly different areas and still expect IETF consensus for the document. I don't think that works. YMMD. And... >> It's not entirely harmless. The following JS program >> behaves differently if it's preceded by a BOM: >> >> # !/usr/bin/env bash > > I really don't want to know when self-running shell scripts > became part of Ecmascript. Presumably, by an extension of the comments that caused the rant above, whatever "part of ECMAscript" means, they are a consideration because some or all browser vendors decided to treat them as if they were. john From nobody Mon May 11 15:21:45 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F273A0D67; Mon, 11 May 2020 15:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 5hrAeO6dZ83N; Mon, 11 May 2020 15:21:40 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 06C963A0D66; Mon, 11 May 2020 15:21:40 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id d207so4978172wmd.0; Mon, 11 May 2020 15:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aFD10kEu4pWn23/diGlU8+6Fz90g+oMSK/DOmun9lPA=; b=AHKYnpD/o+IeVqhviE6N6Y7uZUSlYttANTESKkl9gHQRMIr5O6EJulptUaq0+n3Fxc 4vMtv5sMHysbJV+WayyWKk/YLVNHYiQfyGAgjVlX0HPZ4NCf1RHw217Awrrqdh+J8P7b y3fyawF2wDneY1SedJIwqa7omzzS6C/0lOfhs1Y2rdMWDO9eIwy42a2+XesXJicU3n5g M9BA8NNYHAmuOLeeW9JaVhhFmV5vqpUzh0P+Y9GnbUo9GEi7OvPoSKSTzwfihHt/JBp6 SM3E1jmdmhe6Swj23oLCBAVc69iXF6MN4so8CoAVv96QUXO0CmP9cn1T5fYuRIwy7hXz JMKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aFD10kEu4pWn23/diGlU8+6Fz90g+oMSK/DOmun9lPA=; b=So/pPfYJBWNpPQwPmMsON85sYACxyH9fLxC5G/dZfP9LGV4bQ71Du89SMtGePmbCJJ tc58tPkvhF8Rmr3QI9sF+nzLbeteWEjQBPn0LEJVIwpqvwYjFyyPX/2D6Uozr3JYjnxf atZKbyAw9nyqN1SeyhzKKjDuXqlwRX26PMZsQPGYMTvyPFL44TY6KFMgD3iEtVfqccI2 hiXYXTissrhDTbHI8t5FMdCE/38lNP2c4/I+5CC00nJqPYJAvmZzaevtEZ4/nXq4z2nS gDco8WBG+jzTS0VWIHC1aYMnwNJrpUtrSdRSLvnQIR2zrfhx2ogKTnQhVEC+58Y5dEFm rofw== X-Gm-Message-State: AGi0PuZ7ulsifv6AkudWhvYKviVPerWEdHYzZ8vM1smk5c+yTFPBB9S3 W5LSSt9/K+Hp4ViqQHv2+UL5ptgKGhUPdZTN7F8= X-Google-Smtp-Source: APiQypKB44pikM+SQAgBPJzql32vW0ed1MpztJ8SRR/zXxW+ucGPoZDvy2xwKLsxOdpb7Oe5Wim4wmwHUOa1Iszu+H8= X-Received: by 2002:a1c:5419:: with SMTP id i25mr30201816wmb.156.1589235698275; Mon, 11 May 2020 15:21:38 -0700 (PDT) MIME-Version: 1.0 References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> <841F372D6CFE1C52B07D0A25@PSB> In-Reply-To: <841F372D6CFE1C52B07D0A25@PSB> From: Bradley Farias Date: Mon, 11 May 2020 17:21:27 -0500 Message-ID: To: John C Klensin Cc: John R Levine , Mathias Bynens , DISPATCH WG , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org Content-Type: multipart/alternative; boundary="00000000000042991305a566c53a" Archived-At: Subject: Re: [dispatch] [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 22:21:44 -0000 --00000000000042991305a566c53a Content-Type: text/plain; charset="UTF-8" Forgive me, but the tone appears to be rather harsh against people who have spent quite a few years waiting on this document to even get to a visibility that we can discuss things. Per Adam Roach's recommendation we did not go through a WG when I made this document years ago. The past few emails seem rather derisive against such decisions, but I am still new to IETF workings and would love help through the process; there seems to be issues that cause me some personal confusion on the intent of a review. Is there a way we can follow or be aided such that we can reach the "higher bar" that we are unaware we were missing here such that we can go for a normative change? I'm unclear but it seems like there is a desire to design some solution for concerns about ECMA262 in host environments but I'm unclear on this being the venue to do so and would be appreciative of guidance on how to proceed. Additionally, I have concerns with shipping things like MIMEs that are not supported in any environment and are not discussed in the host venues they intend to be used in and without any buy in from a host. This document is trying to be normative to match the environment scenarios of not just browsers but other environments that run ECMAScript such as server side environments like Node.js are using text/javascript as the preferred non-obsoleted form in order to coalesce around a standard that matches the browser recommendations. The reversal of the application/javascript as the preferred MIME was intentionally discussed in those environments. I'm unclear on how creation of a new MIME would help here given we cannot remove support for the status quo; creation of a new MIME seems like it would require implementer interest to be a viable replacement. Per things like hash bang comments and concerns about the language being different from when older RFCs existed; I would view this document as being a way to catch up to at least the status quo; creation of unrelated evolution of standards paths that are not intended to match the status quo likely won't be useful without other standards groups buy in. In the future I'm sure people with such varied interests in the evolution of ECMAScript certainly could participate in the evolution of the language if they want to, but that was not the intent of this document. It seems like an additional RFC might be desirable for other issues we are seeing brought up here? Once again, I'm less familiar with IETF process and am unclear if all possible design decisions need to be made in this document. On Mon, May 11, 2020 at 2:16 PM John C Klensin wrote: > > > --On Monday, May 11, 2020 12:55 -0400 John R Levine > wrote: > > >> At this point, I'm afraid the ship has sailed. Introducing > >> yet another MIME type *now* is unlikely to gain adoption in > >> the HTML Standard, browsers, or on the web (because it > >> wouldn't be backwards compatible). Let's not publish > >> specs that intentionally conflict with both the HTML Standard > >> and web reality. > > > > It actually would be backward compatible because of the advice > > to use Accept media types to tell when to send which media > > type, but if browsers aren't going to do it, I guess we put a > > warning in the security section and give up. > > Well, just a minute. Despite approval by DISPATCH for further > discussion and processing, this is basically an individual > submission, not a draft developed by a WG. With the > understanding that what I'm about to say is not I18n-specific > and therefore should perhaps go on the agenda of the next > DISPATCH meeting or wait for IETF Last Call, the IETF has, as > Patrik has pointed out, both a collection of standards-track and > BCP specifications in these areas and experience with what > happens when other approaches (like reliance on name suffixes) > are used instead. Recommending something else is not just a > matter of Security Considerations and, fwiw, I note that at > least one document has been stuck after IETF Last Call completed > in September because the IESG had DISCUSS-level concerns about > telling implementers what they should do if they chose to not > conform to the IETF's normative recommendations. If this is > really just a description of what browser vendors are doing or > will do now and in the future, then we have a long history of > publishing "for the information of the community, this is what > some vendor or cluster of vendors are doing" descriptive > Informational documents. They are not standards track, they do > not use normative language (2119/8174 terminology included), > they just describe what is being done and are quite explicit > about that. > > So, if the decision criteria for what belongs in this I-D is > "whatever the browser vendors are going to do whether the IETF > thinks it is a good idea or not", then let's see it recast as a > "what is being done in practice" description, with the normative > language removed or transformed into "if you want to do what the > vendors are doing, then this is what you need to do" (or even > "should" do - noting lower case). If that means updating the > registration for text/javascript (which, I note, is in the > registry at > https://www.iana.org/assignments/media-types/media-types.xhtml#text > as "OBSOLETED in favor of application/javascript" -- exactly the > opposite of which this I-D proposes) and application/javascript > to treat them as vendor registrations (applying the exception > for non-faceted names allowed by Appendix A of RFC 6838) then so > be it... because that is, apparently, the truth of the matter. > > Sorry, but it seems to me that this document is trying to have > it both (or all three) ways: to be a normative document without > meeting the higher bar the IETF usually applies for standards > track documents, to be a vendor specification without making > that clear in the text (and noting that vendor specifications > are still expected to have accurate Security Considerations > sections), and to make requirements that are at variances with > significant community experience about bad results when similar > things have been done in only slightly different areas and still > expect IETF consensus for the document. I don't think that > works. YMMD. > > And... > > >> It's not entirely harmless. The following JS program > >> behaves differently if it's preceded by a BOM: > >> > >> # !/usr/bin/env bash > > > > I really don't want to know when self-running shell scripts > > became part of Ecmascript. > > Presumably, by an extension of the comments that caused the rant > above, whatever "part of ECMAscript" means, they are a > consideration because some or all browser vendors decided to > treat them as if they were. > > john > > --00000000000042991305a566c53a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forgive me, but the tone appears to be ra= ther harsh against people who have spent quite a few years waiting on this = document to even get to a visibility that=C2=A0we can discuss things. Per A= dam Roach's recommendation we did not go through a WG when I made this = document years ago. The past few emails seem rather derisive against such d= ecisions, but I am still new to IETF workings and would love help through t= he process; there seems to be issues that cause me some personal confusion = on the intent of a review.

Is there a way we can follow or be aided such that we can reach the "= higher bar" that we are unaware we were missing here such that we can = go for a normative change? I'm unclear but it seems like there is a des= ire to design some solution for concerns about ECMA262 in host environments= but=C2=A0I'm unclear on this being the venue to do so and would be app= reciative of guidance on how=C2=A0to proceed.

Additionally, I have concerns with shipping things like= MIMEs that are not supported in any environment and are not discussed in t= he host venues they intend to be used in and without any buy in from a host= . This document is trying to be normative to match the environment scenario= s of not just browsers but other environments that run ECMAScript such as s= erver side environments like Node.js are using text/javascript as the prefe= rred non-obsoleted form in order to coalesce around a standard that matches= the browser recommendations. The reversal of the application/javascript as= the preferred=C2=A0MIME was intentionally discussed in those environments.= I'm unclear on how creation of a new MIME would help here given we can= not remove support for the status quo; creation of a new MIME seems like it= would require implementer interest to=C2=A0be a viable replacement.
<= div dir=3D"ltr">
Per things like hash bang comments and conce= rns about the language being different from when older RFCs existed; I woul= d view this document as being a way to catch up to at least the status quo;= creation of unrelated=C2=A0evolution of standards paths that are not inten= ded to match the status quo likely won't be useful without other standa= rds groups buy in. In the future I'm sure people with such varied inter= ests in the evolution of ECMAScript certainly could participate in the evol= ution of the language if they want to, but that was not the intent of this = document. It seems like an additional RFC might be desirable for other issu= es we are seeing brought up here? Once again, I'm less familiar with IE= TF process and am unclear if all possible design decisions need to be made = in this document.

On Mon, May 11, 2020 at 2:16 PM John C Klensin <<= a href=3D"mailto:john-ietf@jck.com">john-ietf@jck.com> wrote:


--On Monday, May 11, 2020 12:55 -0400 John R Levine
<johnl@taugh.com> wrote:

>> At this point, I'm afraid the ship has sailed. Introducing
>> yet another MIME type *now* is unlikely to gain adoption in
>> the HTML Standard, browsers, or on the web (because it
>> wouldn't be backwards compatible). Let's not publish
>> specs that intentionally conflict with both the HTML Standard
>> and web reality.
>
> It actually would be backward compatible because of the advice
> to use Accept media types to tell when to send which media
> type, but if browsers aren't going to do it, I guess we put a
> warning in the security section and give up.

Well, just a minute.=C2=A0 Despite approval by DISPATCH for further
discussion and processing, this is basically an individual
submission, not a draft developed by a WG.=C2=A0 With the
understanding that what I'm about to say is not I18n-specific
and therefore should perhaps go on the agenda of the next
DISPATCH meeting or wait for IETF Last Call, the IETF has, as
Patrik has pointed out, both a collection of standards-track and
BCP specifications in these areas and experience with what
happens when other approaches (like reliance on name suffixes)
are used instead.=C2=A0 Recommending something else is not just a
matter of Security Considerations and, fwiw, I note that at
least one document has been stuck after IETF Last Call completed
in September because the IESG had DISCUSS-level concerns about
telling implementers what they should do if they chose to not
conform to the IETF's normative recommendations.=C2=A0 =C2=A0If this is=
really just a description of what browser vendors are doing or
will do now and in the future, then we have a long history of
publishing "for the information of the community, this is what
some vendor or cluster of vendors are doing" descriptive
Informational documents.=C2=A0 They are not standards track, they do
not use normative language (2119/8174 terminology included),
they just describe what is being done and are quite explicit
about that.=C2=A0

So, if the decision criteria for what belongs in this I-D is
"whatever the browser vendors are going to do whether the IETF
thinks it is a good idea or not", then let's see it recast as a "what is being done in practice" description, with the normative<= br> language removed or transformed into "if you want to do what the
vendors are doing, then this is what you need to do" (or even
"should" do - noting lower case).=C2=A0 If that means updating th= e
registration for text/javascript (which, I note, is in the
registry at
https://www.iana.org/assignments/= media-types/media-types.xhtml#text
as "OBSOLETED in favor of application/javascript" -- exactly the<= br> opposite of which this I-D proposes) and application/javascript
to treat them as vendor registrations (applying the exception
for non-faceted names allowed by Appendix A of RFC 6838) then so
be it... because that is, apparently, the truth of the matter.

Sorry, but it seems to me that this document is trying to have
it both (or all three) ways: to be a normative document without
meeting the higher bar the IETF usually applies for standards
track documents, to be a vendor specification without making
that clear in the text (and noting that vendor specifications
are still expected to have accurate Security Considerations
sections), and to make requirements that are at variances with
significant community experience about bad results when similar
things have been done in only slightly different areas and still
expect IETF consensus for the document.=C2=A0 I don't think that
works.=C2=A0 YMMD.

And...

>> It's not entirely harmless. The following JS program
>> behaves differently if it's preceded by a BOM:
>>
>> # !/usr/bin/env bash
>
> I really don't want to know when self-running shell scripts
> became part of Ecmascript.

Presumably, by an extension of the comments that caused the rant
above, whatever "part of ECMAscript" means, they are a
consideration because some or all browser vendors decided to
treat them as if they were.

=C2=A0 =C2=A0 john

--00000000000042991305a566c53a-- From nobody Mon May 11 15:57:41 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7043A0DC4; Mon, 11 May 2020 15:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 FxTNYpeKGhbp; Mon, 11 May 2020 15:57:29 -0700 (PDT) Received: from mail-il1-f170.google.com (mail-il1-f170.google.com [209.85.166.170]) (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 A70E43A0D82; Mon, 11 May 2020 15:57:28 -0700 (PDT) Received: by mail-il1-f170.google.com with SMTP id b71so3556524ilg.8; Mon, 11 May 2020 15:57:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kp521LaELJvYUdXwZMn+yRywltR9LHVMPMAAhf3eByU=; b=pfWBxe/Fr8/q3dBPP+NV8J1JKUnY4eMKofnxLDi5CkqogOTT/9SM/mANyeNDzooYPo Zq0eD+snJwFaAqLdsk42Pzqtcs986D5bZPgWfW1j8ZIMv4mTH2pDvyso5INhg7rSULQw MP33K60OdlQS5TzvpXRe3nkgNx5/z3SchGV5gUbWb+km+gtLNhwlo6eD845IV6+UkFv+ KcKnxz39YTO5BMsnQW3tVRhAHUblCLif3lhbOJeYuy3jpTKJrLp9uGdwtlm1vpAwiKDT Qo0XVFvhX+iqYcTkbh3CtsMFt8gLudoWLEJcis2VF7jRVGAcWkaR+fSKrCiUBiAcblQb ig3Q== X-Gm-Message-State: AGi0PuZcKSUVmC6caMhkIsyV3WiybYL9TA6ISzSORSTC5FAJfzxZN/1a JnhMHMX8sycytselznfBDo1J2Nn0sNIVgKVaTyY= X-Google-Smtp-Source: APiQypITC48M23pM/0L59zNKoXW/b9I8muXtqsbikg5KoCxfJHk1se5NLCLYa4OYr8M/F3e5Lwk/LNPp0lrI6IEpNLM= X-Received: by 2002:a05:6e02:12a2:: with SMTP id f2mr12682185ilr.140.1589237847558; Mon, 11 May 2020 15:57:27 -0700 (PDT) MIME-Version: 1.0 References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> <841F372D6CFE1C52B07D0A25@PSB> In-Reply-To: From: Barry Leiba Date: Mon, 11 May 2020 18:57:16 -0400 Message-ID: To: Bradley Farias Cc: DISPATCH WG , John C Klensin , John R Levine , Mathias Bynens , draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org Content-Type: multipart/alternative; boundary="0000000000005e11d905a5674573" Archived-At: Subject: Re: [dispatch] [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 22:57:34 -0000 --0000000000005e11d905a5674573 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for this, Bradley. A couple of clarifications, to make sure we=E2= =80=99re together on this: The IETF crowd can tend to be blunt =E2=80=94 sorry for that. If it helps,= keep in mind that the purpose in that bluntness is not to insult, but to aim for the highest quality documents we can get. As to the higher bar for non-WG documents, it=E2=80=99s not that there=E2= =80=99s a higher bar for the document content =E2=80=94 we=E2=80=99re looking, as I say, for= high quality in general =E2=80=94 but a higher bar for getting reviews at this stage. Work= ing group documents have time in working group development and review, and the IETF last call process is bringing the document to the community beyond the working group for final review. Non-WG documents lack the work and review in the working group, and, frequently, the first significant review is during last call. There is, consequently, a stronger-than-usual desire to ensure thorough review at this stage. I, as the sponsoring AD, am aware of the work that=E2=80=99s been done on t= he document already, and am not concerned, in general, about the quality of that. That said, this particular review is from experts in internationalization issues, and that=E2=80=99s a quite specialized skill s= et held by a relatively few participants. It=E2=80=99s really important to get thi= s part right, and I very much appreciate their review and discussion. I hope we can put all this together to make the document even better. Barry, ART AD On Mon, May 11, 2020 at 6:21 PM Bradley Farias wrote: > Forgive me, but the tone appears to be rather harsh against people who > have spent quite a few years waiting on this document to even get to a > visibility that we can discuss things. Per Adam Roach's recommendation we > did not go through a WG when I made this document years ago. The past few > emails seem rather derisive against such decisions, but I am still new to > IETF workings and would love help through the process; there seems to be > issues that cause me some personal confusion on the intent of a review. > > Is there a way we can follow or be aided such that we can reach the > "higher bar" that we are unaware we were missing here such that we can go > for a normative change? I'm unclear but it seems like there is a desire t= o > design some solution for concerns about ECMA262 in host environments > but I'm unclear on this being the venue to do so and would be appreciativ= e > of guidance on how to proceed. > > Additionally, I have concerns with shipping things like MIMEs that are no= t > supported in any environment and are not discussed in the host venues the= y > intend to be used in and without any buy in from a host. This document is > trying to be normative to match the environment scenarios of not just > browsers but other environments that run ECMAScript such as server side > environments like Node.js are using text/javascript as the preferred > non-obsoleted form in order to coalesce around a standard that matches th= e > browser recommendations. The reversal of the application/javascript as th= e > preferred MIME was intentionally discussed in those environments. I'm > unclear on how creation of a new MIME would help here given we cannot > remove support for the status quo; creation of a new MIME seems like it > would require implementer interest to be a viable replacement. > > Per things like hash bang comments and concerns about the language being > different from when older RFCs existed; I would view this document as bei= ng > a way to catch up to at least the status quo; creation of > unrelated evolution of standards paths that are not intended to match the > status quo likely won't be useful without other standards groups buy in. = In > the future I'm sure people with such varied interests in the evolution of > ECMAScript certainly could participate in the evolution of the language i= f > they want to, but that was not the intent of this document. It seems like > an additional RFC might be desirable for other issues we are seeing broug= ht > up here? Once again, I'm less familiar with IETF process and am unclear i= f > all possible design decisions need to be made in this document. > > On Mon, May 11, 2020 at 2:16 PM John C Klensin wrote: > >> >> >> --On Monday, May 11, 2020 12:55 -0400 John R Levine >> wrote: >> >> >> At this point, I'm afraid the ship has sailed. Introducing >> >> yet another MIME type *now* is unlikely to gain adoption in >> >> the HTML Standard, browsers, or on the web (because it >> >> wouldn't be backwards compatible). Let's not publish >> >> specs that intentionally conflict with both the HTML Standard >> >> and web reality. >> > >> > It actually would be backward compatible because of the advice >> > to use Accept media types to tell when to send which media >> > type, but if browsers aren't going to do it, I guess we put a >> > warning in the security section and give up. >> >> Well, just a minute. Despite approval by DISPATCH for further >> discussion and processing, this is basically an individual >> submission, not a draft developed by a WG. With the >> understanding that what I'm about to say is not I18n-specific >> and therefore should perhaps go on the agenda of the next >> DISPATCH meeting or wait for IETF Last Call, the IETF has, as >> Patrik has pointed out, both a collection of standards-track and >> BCP specifications in these areas and experience with what >> happens when other approaches (like reliance on name suffixes) >> are used instead. Recommending something else is not just a >> matter of Security Considerations and, fwiw, I note that at >> least one document has been stuck after IETF Last Call completed >> in September because the IESG had DISCUSS-level concerns about >> telling implementers what they should do if they chose to not >> conform to the IETF's normative recommendations. If this is >> really just a description of what browser vendors are doing or >> will do now and in the future, then we have a long history of >> publishing "for the information of the community, this is what >> some vendor or cluster of vendors are doing" descriptive >> Informational documents. They are not standards track, they do >> not use normative language (2119/8174 terminology included), >> they just describe what is being done and are quite explicit >> about that. >> >> So, if the decision criteria for what belongs in this I-D is >> "whatever the browser vendors are going to do whether the IETF >> thinks it is a good idea or not", then let's see it recast as a >> "what is being done in practice" description, with the normative >> language removed or transformed into "if you want to do what the >> vendors are doing, then this is what you need to do" (or even >> "should" do - noting lower case). If that means updating the >> registration for text/javascript (which, I note, is in the >> registry at >> https://www.iana.org/assignments/media-types/media-types.xhtml#text >> as "OBSOLETED in favor of application/javascript" -- exactly the >> opposite of which this I-D proposes) and application/javascript >> to treat them as vendor registrations (applying the exception >> for non-faceted names allowed by Appendix A of RFC 6838) then so >> be it... because that is, apparently, the truth of the matter. >> >> Sorry, but it seems to me that this document is trying to have >> it both (or all three) ways: to be a normative document without >> meeting the higher bar the IETF usually applies for standards >> track documents, to be a vendor specification without making >> that clear in the text (and noting that vendor specifications >> are still expected to have accurate Security Considerations >> sections), and to make requirements that are at variances with >> significant community experience about bad results when similar >> things have been done in only slightly different areas and still >> expect IETF consensus for the document. I don't think that >> works. YMMD. >> >> And... >> >> >> It's not entirely harmless. The following JS program >> >> behaves differently if it's preceded by a BOM: >> >> >> >> # !/usr/bin/env bash >> > >> > I really don't want to know when self-running shell scripts >> > became part of Ecmascript. >> >> Presumably, by an extension of the comments that caused the rant >> above, whatever "part of ECMAscript" means, they are a >> consideration because some or all browser vendors decided to >> treat them as if they were. >> >> john >> >> --0000000000005e11d905a5674573 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for this, Bradley.=C2=A0 A couple of clarific= ations, to make sure we=E2=80=99re together on this:

The IETF crowd can tend to be blunt =E2= =80=94 sorry for that.=C2=A0 If it helps, keep in mind that the purpose in = that bluntness is not to insult, but to aim for the highest quality documen= ts we can get.

As to the= higher bar for non-WG documents, it=E2=80=99s not that there=E2=80=99s a h= igher bar for the document content =E2=80=94 we=E2=80=99re looking, as I sa= y, for high quality in general =E2=80=94 but a higher bar for getting revie= ws at this stage.=C2=A0 Working group documents have time in working group = development and review, and the IETF last call process is bringing the docu= ment to the community beyond the working group for final review.=C2=A0 Non-= WG documents lack the work and review in the working group, and, frequently= , the first significant review is during last call.=C2=A0 There is, consequ= ently, a stronger-than-usual desire to ensure thorough review at this stage= .

I, as the sponsoring A= D, am aware of the work that=E2=80=99s been done on the document already, a= nd am not concerned, in general, about the quality of that. =C2=A0 =C2=A0Th= at said, this particular review is from experts in internationalization iss= ues, and that=E2=80=99s a quite specialized skill set held by a relatively = few participants.=C2=A0 It=E2=80=99s really important to get this part righ= t, and I very much appreciate their review and discussion.=C2=A0 I hope we = can put all this together to make the document even better.

Barry, ART AD

On Mon, May 11, 202= 0 at 6:21 PM Bradley Farias <b= radley.meck@gmail.com> wrote:
Forgive me, but the tone appears to be = rather harsh against people who have spent quite a few years waiting on thi= s document to even get to a visibility that=C2=A0we can discuss things. Per= Adam Roach's recommendation we did not go through a WG when I made thi= s document years ago. The past few emails seem rather derisive against such= decisions, but I am still new to IETF workings and would love help through= the process; there seems to be issues that cause me some personal confusio= n on the intent of a review.

Is there a way we can follow or be aided such that we can reach the &quo= t;higher bar" that we are unaware we were missing here such that we ca= n go for a normative change? I'm unclear but it seems like there is a d= esire to design some solution for concerns about ECMA262 in host environmen= ts but=C2=A0I'm unclear on this being the venue to do so and would be a= ppreciative of guidance on how=C2=A0to proceed.

<= /div>
Additionally, I have concerns with shipping things li= ke MIMEs that are not supported in any environment and are not discussed in= the host venues they intend to be used in and without any buy in from a ho= st. This document is trying to be normative to match the environment scenar= ios of not just browsers but other environments that run ECMAScript such as= server side environments like Node.js are using text/javascript as the pre= ferred non-obsoleted form in order to coalesce around a standard that match= es the browser recommendations. The reversal of the application/javascript = as the preferred=C2=A0MIME was intentionally discussed in those environment= s. I'm unclear on how creation of a new MIME would help here given we c= annot remove support for the status quo; creation of a new MIME seems like = it would require implementer interest to=C2=A0be a viable replacement.

Per things like hash bang comments and con= cerns about the language being different from when older RFCs existed; I wo= uld view this document as being a way to catch up to at least the status qu= o; creation of unrelated=C2=A0evolution of standards paths that are not int= ended to match the status quo likely won't be useful without other stan= dards groups buy in. In the future I'm sure people with such varied int= erests in the evolution of ECMAScript certainly could participate in the ev= olution of the language if they want to, but that was not the intent of thi= s document. It seems like an additional RFC might be desirable for other is= sues we are seeing brought up here? Once again, I'm less familiar with = IETF process and am unclear if all possible design decisions need to be mad= e in this document.

On Mon, May 11, 2020 at 2:16 PM John C Klensin <= ;john-ietf@jck.com> wrote:

--On Monday, May 11, 2020 12:55 -0400 John R Levine
<johnl@taugh.com> wrote:

>> At this point, I'm afraid the ship has sailed. Introducing
>> yet another MIME type *now* is unlikely to gain adoption in
>> the HTML Standard, browsers, or on the web (because it
>> wouldn't be backwards compatible). Let's not publish
>> specs that intentionally conflict with both the HTML Standard
>> and web reality.
>
> It actually would be backward compatible because of the advice
> to use Accept media types to tell when to send which media
> type, but if browsers aren't going to do it, I guess we put a
> warning in the security section and give up.

Well, just a minute.=C2=A0 Despite approval by DISPATCH for further
discussion and processing, this is basically an individual
submission, not a draft developed by a WG.=C2=A0 With the
understanding that what I'm about to say is not I18n-specific
and therefore should perhaps go on the agenda of the next
DISPATCH meeting or wait for IETF Last Call, the IETF has, as
Patrik has pointed out, both a collection of standards-track and
BCP specifications in these areas and experience with what
happens when other approaches (like reliance on name suffixes)
are used instead.=C2=A0 Recommending something else is not just a
matter of Security Considerations and, fwiw, I note that at
least one document has been stuck after IETF Last Call completed
in September because the IESG had DISCUSS-level concerns about
telling implementers what they should do if they chose to not
conform to the IETF's normative recommendations.=C2=A0 =C2=A0If this is=
really just a description of what browser vendors are doing or
will do now and in the future, then we have a long history of
publishing "for the information of the community, this is what
some vendor or cluster of vendors are doing" descriptive
Informational documents.=C2=A0 They are not standards track, they do
not use normative language (2119/8174 terminology included),
they just describe what is being done and are quite explicit
about that.=C2=A0

So, if the decision criteria for what belongs in this I-D is
"whatever the browser vendors are going to do whether the IETF
thinks it is a good idea or not", then let's see it recast as a "what is being done in practice" description, with the normative<= br> language removed or transformed into "if you want to do what the
vendors are doing, then this is what you need to do" (or even
"should" do - noting lower case).=C2=A0 If that means updating th= e
registration for text/javascript (which, I note, is in the
registry at
https://www.iana.org/assignments/= media-types/media-types.xhtml#text
as "OBSOLETED in favor of application/javascript" -- exactly the<= br> opposite of which this I-D proposes) and application/javascript
to treat them as vendor registrations (applying the exception
for non-faceted names allowed by Appendix A of RFC 6838) then so
be it... because that is, apparently, the truth of the matter.

Sorry, but it seems to me that this document is trying to have
it both (or all three) ways: to be a normative document without
meeting the higher bar the IETF usually applies for standards
track documents, to be a vendor specification without making
that clear in the text (and noting that vendor specifications
are still expected to have accurate Security Considerations
sections), and to make requirements that are at variances with
significant community experience about bad results when similar
things have been done in only slightly different areas and still
expect IETF consensus for the document.=C2=A0 I don't think that
works.=C2=A0 YMMD.

And...

>> It's not entirely harmless. The following JS program
>> behaves differently if it's preceded by a BOM:
>>
>> # !/usr/bin/env bash
>
> I really don't want to know when self-running shell scripts
> became part of Ecmascript.

Presumably, by an extension of the comments that caused the rant
above, whatever "part of ECMAscript" means, they are a
consideration because some or all browser vendors decided to
treat them as if they were.

=C2=A0 =C2=A0 john

--0000000000005e11d905a5674573-- From nobody Fri May 15 10:59:38 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D086D3A0FAC for ; Fri, 15 May 2020 10:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 O0j1EO8LA_O7 for ; Fri, 15 May 2020 10:59:34 -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 310D53A0FA9 for ; Fri, 15 May 2020 10:59:34 -0700 (PDT) Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 04FHxT48064152 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 15 May 2020 12:59:30 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589565570; bh=tkYbGaPqfegHdHA8XTEPA5TVjkRDxQTqc2rYGIasUvg=; h=From:Subject:References:To:Date; b=iVc8BB6oic4XibuEN3vrcmJ27ZqFNqLDylhk3gDHnqnE16stLiOZEYd8TUkhvBkXb /NxxjbbKrBgVlzGZP01Pk+xZaVb/DcE37S7QVZ2T/ZB5BjKq6aHIKLtk8HIkifpTmG pg/LLI0YebudzkgyZB7VH/NuRe1ok8Ludvnu8k90= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239] From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_A9480570-7084-4941-948A-E1532BB7B5D1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <9CA24141-557B-4EDA-BAA0-7B3B74C31580@nostrum.com> References: <83D4CBCE-E464-4CCC-8679-592531EF7448@ietf.org> To: DISPATCH WG Date: Fri, 15 May 2020 12:59:24 -0500 X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [dispatch] Fwd: IETF 108 will be an online meeting X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 17:59:37 -0000 --Apple-Mail=_A9480570-7084-4941-948A-E1532BB7B5D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYi, just in case anyone hasn=E2=80=99t already seen this elsewhere: Thanks! Ben. > Begin forwarded message: >=20 > From: IETF Chair > Subject: IETF 108 will be an online meeting > Date: May 14, 2020 at 4:07:47 PM CDT > To: IETF-Announce , irtf-announce@irtf.org, = IETF > Reply-To: IETF >=20 > The Internet Engineering Steering Group (IESG), the IETF LLC Board of = Directors, and the Internet Research Task Force (IRTF) Chair have = decided to replace the in-person IETF 108 Madrid meeting with an online = meeting. This decision is based on the IETF Executive Director=E2=80=99s = recommendation, which was made after conducting an assessment of local = conditions using the criteria set out in the assessment framework [1] = developed with community input. >=20 > The recommendation and full assessment are available at: = https://www.ietf.org/media/documents/IETF_108_Madrid_go_no-go_assessment.p= df >=20 > The online IETF 108 meeting will take place 27-31 July from 11:00 to = 16:00 UTC each day. The end time of 16:00 UTC is approximate; some days = may be shorter depending on scheduling. These time blocks were chosen = based on the survey feedback [2] we received. >=20 > Further details about the online meeting will be shared as they become = available. >=20 > Sincerely, > Alissa Cooper, IETF Chair > Colin Perkins, IRTF Chair > Jason Livingood, IETF LLC Board Chair >=20 > [1] = https://www.ietf.org/blog/assessment-criteria-decision-personvirtual-ietf-= 108/? > [2] = https://www.ietf.org/media/documents/survey-planning-possible-online-meeti= ngs-responses.pdf --Apple-Mail=_A9480570-7084-4941-948A-E1532BB7B5D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYi, = just in case anyone hasn=E2=80=99t already seen this elsewhere:

Thanks!

Ben.

Begin forwarded message:

From: = IETF Chair <chair@ietf.org>
Subject: = IETF 108 will be = an online meeting
Date: May 14, 2020 at 4:07:47 PM CDT
To: IETF-Announce <ietf-announce@ietf.org>, irtf-announce@irtf.org, IETF <ietf@ietf.org>
Reply-To: = IETF <ietf@ietf.org>

The= Internet Engineering Steering Group (IESG), the IETF LLC Board of = Directors, and the Internet Research Task Force (IRTF) Chair have = decided to replace the in-person IETF 108 Madrid meeting with an online = meeting. This decision is based on the IETF Executive Director=E2=80=99s = recommendation, which was made after conducting an assessment of local = conditions using the criteria set out in the assessment framework [1] = developed with community input.

The = recommendation and full assessment are available at: https://www.ietf.org/media/documents/IETF_108_Madrid_go_no-go_a= ssessment.pdf

The online IETF 108 = meeting will take place 27-31 July from 11:00 to 16:00 UTC each day. The = end time of 16:00 UTC is approximate; some days may be shorter depending = on scheduling. These time blocks were chosen based on the survey = feedback [2] we received.

Further details = about the online meeting will be shared as they become available.

Sincerely,
Alissa Cooper, IETF = Chair
Colin Perkins, IRTF Chair
Jason = Livingood, IETF LLC Board Chair

[1] https://www.ietf.org/blog/assessment-criteria-decision-personvi= rtual-ietf-108/?
[2] https://www.ietf.org/media/documents/survey-planning-possible-o= nline-meetings-responses.pdf

= --Apple-Mail=_A9480570-7084-4941-948A-E1532BB7B5D1--