Re: [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07

Mathias Bynens <> Mon, 11 May 2020 07:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05F4B3A08B5 for <>; Mon, 11 May 2020 00:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.099
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 240ACO3svn_Y for <>; Mon, 11 May 2020 00:22:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B7CA3A07D6 for <>; Mon, 11 May 2020 00:22:49 -0700 (PDT)
Received: by with SMTP id di6so4008326qvb.10 for <>; Mon, 11 May 2020 00:22:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+Y/uDBEwwu4H5HoQvAuDDTwBY50dhm3CWcwbvSNfROQ=; b=qCjStmTSTdnUj0au15am7H8ibv1qmqK6KEb9w9TvL4J7hWTPUX9T3Yr4KkrxU63M9e /r50H7AkGKUpJkAGPcctGBhIY9OfFzwBATkTX7Z7hNl4uBangJiIwvsqLTovc81ep5fu OQc6AOS3VDJe9mMnW34Rf+4s3jubxxGveDZcH0nXuBhZgTQrKC8N+P5JGZkMbcv+bwEz RNaCpW7OuD2274bA1n/qrj/Zu74YxgldL/IPIhtXkQC7bFtfr1xoocYuDhnJAE51+wf9 pB2IKSGE82HlwLkKE582z3kQSHZym+d++PtXYWtrb/myXDSbBOZF8gxGzGPSxau/oVbr k8Og==
X-Gm-Message-State: AGi0PuYFJaj9IYMevg9qL95czmXiYDU2GY+izb3ibGgp9HAVXqz+dxdi iYWlmpnopYfhd+xjTo/663Kf3LYoo0Ev2K7C5GdR2w==
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: <> <> <> <alpine.OSX.2.22.407.2005081926580.81728@ary.qy> <> <alpine.OSX.2.22.407.2005091233350.84818@ary.qy>
In-Reply-To: <alpine.OSX.2.22.407.2005091233350.84818@ary.qy>
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 <>,,,
Content-Type: multipart/alternative; boundary="000000000000bf2f8805a55a36f4"
Archived-At: <>
Subject: Re: [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 May 2020 07:22:53 -0000

On Sat, May 9, 2020 at 6:36 PM John R Levine <> wrote:

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

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

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

It’s not entirely harmless. The following JS program behaves differently if
it’s 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.