[dispatch] Fwd: WGLC: draft-ietf-dispatch-javascript-mjs-02.txt
Bradley Meck <bradley.meck@gmail.com> Thu, 12 July 2018 14:36 UTC
Return-Path: <bradley.meck@gmail.com>
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 6D8C213112D; Thu, 12 Jul 2018 07:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 YVDqZ8Q6Klne; Thu, 12 Jul 2018 07:36:45 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B83B130E3E; Thu, 12 Jul 2018 07:36:45 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id p17-v6so7074685itc.2; Thu, 12 Jul 2018 07:36:45 -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; bh=gYorm+Sp3uSAhQThZU5C55XCrZnfWwcbJ4z4TybqA3s=; b=QYeNs8xDHPSX02yA4XpPS7hcMWSmYOHmJKVdn9U1TreWft534agQ+z6P/AbNhckEsM 6EUQyuaFLesOZDQgWtYdJY3MjjJTD0Onkft9gLoDiE5aQYlOEne7D8vVBDkQFVMWV2SW nD/zSaoESfjMPgV5nRJ/OVGoC3bnN+MlN0nn7WyubEoXHM9Rqhv/eDQfWiq3fu0TVs2y eLF3PIIbGen/MZDhkdc2QVf8/u7PA0zjwhI+owUngX/kB5sQIEai7+VvKRAGNCgz6V4H TSwJp/AMJS0AX7ya+3vfVrjlxhBOVvOLFU5gK8MB/pN9tZU4wExYQjsr40HlEtH8JRgo V3Sw==
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; bh=gYorm+Sp3uSAhQThZU5C55XCrZnfWwcbJ4z4TybqA3s=; b=rWeZ7skkPfqXz2EVcEYY+PSxJkSzYGZMZtMNwVPzKBOZTnJS2l7S377siH0wydl9Qo Z8sSTxJTIz564+MyniKyDe8Xq5340GAhWAqHaX0QEiU/8T4UNTcS0g1m+rQpiSu/xXXI wxZcX3baVP25soAAdmjzfWSrNS7QTJPW5f26D2MfFFmoZdDSoCvtQb3VJ6z/HMelF5Kc 4qDDRfk8ZmnbC3dAnxU7YEUrp0GsYIuK7aY7ese2jbf+TPXsYNfTjBG1Ihl9b+uVMXFt /qElWnLWsH9VxqRxsqeV/N63ZSHF4lAgE9lZhVCzGGNBKwHFeRzgnyQbqXBFukM99hTw XIpw==
X-Gm-Message-State: AOUpUlHggCYw8ymu5VIwHuRlgxVig47eIRSfppKYiLa4ZxjZ3betk5ci h59Obfi5+wVC0iE1vv4wsZSXiERvAMrTuybipi3uAf5o
X-Google-Smtp-Source: AAOMgpf8LccxCh173pQSiXLjnlrcty2gL9aQm28jXyDNzDuHxwzxmVTsC7+shTgpA431qYtzgfCuZOY5QwMWN8NJN80=
X-Received: by 2002:a02:8895:: with SMTP id n21-v6mr1743766jaj.21.1531406204504; Thu, 12 Jul 2018 07:36:44 -0700 (PDT)
MIME-Version: 1.0
References: <CAHBDyN5kB=yi_eFty2hRO4LpadKrSSY0KY-BAS2447Y84pPoWg@mail.gmail.com> <20180711010505.GA4920@pescadero.dbaron.org> <CANnEKUY-L3pb_vBQh+VW_oX6WSsU+nRa8=DsSgyk4u8i4FYyaA@mail.gmail.com>
In-Reply-To: <CANnEKUY-L3pb_vBQh+VW_oX6WSsU+nRa8=DsSgyk4u8i4FYyaA@mail.gmail.com>
From: Bradley Meck <bradley.meck@gmail.com>
Date: Thu, 12 Jul 2018 09:36:34 -0500
Message-ID: <CANnEKUZtN9HA3_pB5xUo0YwjTC-N-N226gM9V__fFf=jqgpCxQ@mail.gmail.com>
To: DISPATCH <dispatch@ietf.org>, draft-ietf-dispatch-javascript-mjs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d394150570ce4aef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/yeBFYNcixsSplND6Th-Dxv2uRis>
Subject: [dispatch] Fwd: WGLC: draft-ietf-dispatch-javascript-mjs-02.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2018 14:36:51 -0000
this mailing list workflow is not my norm, sorry for the forwarding ---------- Forwarded message --------- From: Bradley Meck <bradley.meck@gmail.com> Date: Thu, Jul 12, 2018 at 9:27 AM Subject: Re: [dispatch] WGLC: draft-ietf-dispatch-javascript-mjs-02.txt To: <dbaron@dbaron.org> This seems like a reasonable thing to suggest as the intended use of the .mjs extension, but I think it could be read to imply that implementations should change their behavior as a result of file extensions, which would be a rather unusual requirement on the Web. If that requirement were the intent, it would seem to contradict the processing rules for script elements in the HTML specification at: https://html.spec.whatwg.org/multipage/scripting.html#attr-script-type which specify that the type attribute on the script element determines whether a script is interpreted as a classic script or as a module script. ---- Browsers use MIME to determine how to interpret resources when under `<script type=module>` but do not use MIME for other forms of `<script type=...>`. This is notable since it means charset is not honored and actually prevents execution of JS in browsers if places in the attribute : http://jsfiddle.net/uhfvxy69/2/ . It is actually looking at strings within the `type` attribute even though they resemble MIMEs, they are not. In addition `<script type=text/javascript>` does not use MIMEs even for the source text they load, this is easily seen by comparing it with `<script type=module>` using data URLs : http://jsfiddle.net/urg89f6d/2/ . Per the extension, the specification in https://mimesniff.spec.whatwg.org/#interpreting-the-resource-metadata , it explicitly calls out that file extensions are not used in order to obtain MIMEs. The only concern for file extensions from web standards is left up to browser environments themselves per https://html.spec.whatwg.org/multipage/input.html#file-upload-state-(type=file) : On platforms that only use file extensions to describe file types, the extensions listed here can be used to filter the allowed documents, while the MIME types can be used with the system's type registration table (mapping MIME types to extensions used by the system), if any, to determine any other extensions to allow. Similarly, on a system that does not have file names or extensions but labels documents with MIME types internally, the MIME types can be used to pick the allowed files, while the extensions can be used if the system has an extension registration table that maps known extensions to MIME types used by the system. This draft would not affect existing behavior of `<script type=text/javascript>` through the changes to the MIME. There is the addition of the `goal=` parameter that could be supported by browsers per a PR in https://github.com/whatwg/html/pull/3205 , but even if it is not supported by browsers it is allowed to be ignored if it is an unrecognized parameter per https://tools.ietf.org/html/rfc2045#section-5 . MIME implementations must ignore any parameters whose names they do not recognize. ---- Additionally, I wonder whether it would be useful to have a section that documents the changes from RFC4329. The introduction to section 4 (Registration) seems to document some of them, but I noticed that it doesn't mention that application/ecmascript and application/javascript have been changed to Obsolete, and a number of types not previously listed in RFC4329 (but listed in https://mimesniff.spec.whatwg.org/#javascript-mime-type) have been added as Obsolete. (I didn't check for other differences.) ---- Only `text/javascript` is considered to be common anymore due to we specification in https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages : 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. We could perhaps just phrase this that it makes *all* other MIMEs obsolete rather than making a list? On Tue, Jul 10, 2018 at 8:05 PM L. David Baron <dbaron@dbaron.org> wrote: > Hi - > > I have a few comments on the document: > > > There are two things that might be read to imply that processors > (e.g., browsers) should change their behavior as a result of file > extensions. In particular, in section 4 (Registration): > > In addition, > a new file extension of .mjs is to be added to the list of file > extensions with the restriction that it must correspond to the Module > grammar of [ECMA-262]. > > and then repeatedly in the subsections of that section: > > Restrictions on usage: The file extension .mjs must be parsed using > the Module grammar of [ECMA-262] > > This seems like a reasonable thing to suggest as the intended use of > the .mjs extension, but I think it could be read to imply that > implementations should change their behavior as a result of file > extensions, which would be a rather unusual requirement on the Web. > > If that requirement were the intent, it would seem to contradict the > processing rules for script elements in the HTML specification at: > https://html.spec.whatwg.org/multipage/scripting.html#attr-script-type > which specify that the type attribute on the script element > determines whether a script is interpreted as a classic script or as > a module script. > > > Additionally, I wonder whether it would be useful to have a section > that documents the changes from RFC4329. The introduction to > section 4 (Registration) seems to document some of them, but I > noticed that it doesn't mention that application/ecmascript and > application/javascript have been changed to Obsolete, and a number > of types not previously listed in RFC4329 (but listed in > https://mimesniff.spec.whatwg.org/#javascript-mime-type) have been > added as Obsolete. (I didn't check for other differences.) > > > I'm happy to see the obsolete/common distinction in this draft > reflecting current practice. > > -David > > > On Tuesday 2018-07-10 13:15 -0500, Mary Barnes wrote: > > Hi all, > > > > > > We would like to start a 2 week WGLC for this document. If you think > the > > document is ready, please respond to this email. If you have comments > that > > you would like considered and/or any editorial suggestions, please post > > those as well. > > > > > > The WGLC ends on July 25, 2018. > > > > > > Regards, > > > > Mary > > > > DISPATCH WG tri-chair > > > > ---------- Forwarded message ---------- > > From: <internet-drafts@ietf.org>; > > Date: Tue, May 8, 2018 at 5:41 PM > > Subject: [dispatch] I-D Action: draft-ietf-dispatch-javascript-mjs-02.txt > > To: i-d-announce@ietf.org > > Cc: dispatch@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Dispatch WG of the IETF. > > > > Title : ECMAScript Media Types Updates > > Authors : Bradley Farias > > Matthew A. Miller > > Filename : draft-ietf-dispatch-javascript-mjs-02.txt > > Pages : 21 > > Date : 2018-05-08 > > > > Abstract: > > This document proposes updates to the ECMAScript media types, > > superseding the existing registrations for "application/javascript" > > and "text/javascript" by adding an additional extension and removing > > usage warnings. This document updates RFC4329, "Scripting Media > > Types". > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dispatch-javascript-mjs-02 > > > https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs-02 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dispatch-javascript-mjs-02 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla https://www.mozilla.org/ 𝄂 > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. > - Robert Frost, Mending Wall (1914) >
- [dispatch] WGLC: draft-ietf-dispatch-javascript-m… Mary Barnes
- Re: [dispatch] WGLC: draft-ietf-dispatch-javascri… Martin Thomson
- Re: [dispatch] WGLC: draft-ietf-dispatch-javascri… L. David Baron
- [dispatch] Fwd: WGLC: draft-ietf-dispatch-javascr… Bradley Meck
- [dispatch] Fwd: WGLC: draft-ietf-dispatch-javascr… Bradley Meck
- Re: [dispatch] Fwd: WGLC: draft-ietf-dispatch-jav… Martin Thomson
- Re: [dispatch] Fwd: WGLC: draft-ietf-dispatch-jav… Larry Masinter
- Re: [dispatch] Fwd: WGLC: draft-ietf-dispatch-jav… Bradley Meck
- Re: [dispatch] Fwd: WGLC: draft-ietf-dispatch-jav… Larry Masinter
- Re: [dispatch] Fwd: WGLC: draft-ietf-dispatch-jav… Bradley Meck
- Re: [dispatch] WGLC: draft-ietf-dispatch-javascri… Mark Nottingham