[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)
>