Subject: [dispatch] WGLC: draft-ietf-dispatch-javascript-mjs-02.txt

From: Mary Barnes <[email-masked]>
Date: Tue, 10 Jul 2018 13:15:04 -0500

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: <[email-masked]>
Date: Tue, May 8, 2018 at 5:41 PM
Subject: [dispatch] I-D Action: draft-ietf-dispatch-javascript-mjs-02.txt
To: [email-masked]
Cc: [email-masked]

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
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jul 2018 09:49:17 +1000

LGTM

It's odd to see Matt listed in the acknowledgments and as an author.

It would help to have a short statement saying which of the many media
types is not obsolete, as the bulk of them are.
On Wed, Jul 11, 2018 at 4:15 AM Mary Barnes <[email-masked]> 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.
>
>
> Cc: dispatch@ietf..org
> A New Internet-Draft is available from the on-line Internet-Drafts directories.

---

From: "L. David Baron" <[email-masked]>
Date: Wed, 11 Jul 2018 11:05:05 +1000

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:
> From: <[email-masked]>;

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

---

From: Bradley Meck <[email-masked]>
Date: Thu, 12 Jul 2018 09:35:51 -0500

this mailing list workflow is not my norm, sorry for the forwarding

---------- Forwarded message ---------
From: Bradley Meck <[email-masked]>
Date: Thu, Jul 12, 2018 at 9:09 AM
Subject: Re: [dispatch] WGLC: draft-ietf-dispatch-javascript-mjs-02.txt
To: Martin Thomson <[email-masked]>

I added Matt because he spent a considerable amount of time in helping me
make the document. Only `text/javascript` is not obsolete per
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 add a paragraph stating that the other MIMEs are only there for
backwards compatibility concerns at the top if that makes sense.

On Tue, Jul 10, 2018 at 6:49 PM Martin Thomson <[email-masked]>
wrote:

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

---

From: Bradley Meck <[email-masked]>
Date: Thu, 12 Jul 2018 09:36:34 -0500

---------- Forwarded message ---------
From: Bradley Meck <[email-masked]>
Date: Thu, Jul 12, 2018 at 9:27 AM
Subject: Re: [dispatch] WGLC: draft-ietf-dispatch-javascript-mjs-02.txt
To: <[email-masked]>

----

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.

----

----

Only `text/javascript` is considered to be common anymore due to we
specification in
https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages :

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 <[email-masked]> wrote:

> the

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Jul 2018 09:55:43 +1000

On Fri, Jul 13, 2018 at 12:36 AM Bradley Meck <[email-masked]> wrote:
> I added Matt because he spent a considerable amount of time in helping me make the document. Only `text/javascript` is not obsolete per https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages :

You don't need to acknowledge a co-author; that's all :)

I think that a paragraph on text/javascript would be ideal.  It's
otherwise buried in a lot of noise.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 17 Jul 2018 07:15:36 -0700

➢ Only `text/javascript` is not obsolete per https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages 

I wonder about the utility of newly registering (or updating the registration) of types that are obsolete.
If there’s significant deployment of names that new implementations need to be aware of, then ‘obsolete’ isn’t the right status; if not, then who would use the new, but obsolete, definition?

Larry
http://LarryMasinter.net

---

From: Bradley Meck <[email-masked]>
Date: Tue, 17 Jul 2018 09:25:18 -0500

Per https://github.com/bmeck/I-D/issues/2

The extra registrations are to match up with the Web specification on
accepted MIME types for historical reasons
https://mimesniff.spec.whatwg.org/#javascript-mime-type

On Tue, Jul 17, 2018 at 9:15 AM Larry Masinter <[email-masked]> wrote:

> ➢ Only `text/javascript` is not obsolete per
> https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages
>
> I wonder about the utility of newly registering (or updating the
> registration) of types that are obsolete.
> If there’s significant deployment of names that new implementations need
> to be aware of, then ‘obsolete’ isn’t the right status; if not, then who
> would use the new, but obsolete, definition?
>
> Larry
> http://LarryMasinter.net
>
>
>
>
>

---

From: Larry Masinter <[email-masked]>
Date: Wed, 18 Jul 2018 21:17:19 -0700

I was hoping to avoid stuffing the MIME registry with (and making everyone review) lots of useless obsolete templates; the use of OBSOLETE in “Intended use” should only be for previously registered types. Not new (dubious) registrations.

Sent: Tuesday, July 17, 2018 7:25 AM
To: [email-masked]
Cc: DISPATCH <[email-masked]>; [email-masked]
Subject: Re: [dispatch] Fwd: WGLC: draft-ietf-dispatch-javascript-mjs-02.txt

The extra registrations are to match up with the Web specification on accepted MIME types for historical reasons https://mimesniff.spec.whatwg.org/#javascript-mime-type

On Tue, Jul 17, 2018 at 9:15 AM Larry Masinter <[email-masked] <mailto:[email-masked]> > wrote:

➢ Only `text/javascript` is not obsolete per https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages <https://html.spec..whatwg.org/multipage/scripting.html#scriptingLanguages>  

Larry
http://LarryMasinter.net

---

From: Bradley Meck <[email-masked]>
Date: Thu, 19 Jul 2018 08:02:04 -0500

I think reflecting reality is important, is the only concern the number of
types / review time? Should that be split into a separate RFC to add all
the obsolete types so that it can take more time to land all of those.
Regardless of intent, there MIMEs are in use and part of the web standards
used by browsers. Having them documented/registered seems important if the
MIME registry is intended to reflect actual usage.

On Wed, Jul 18, 2018 at 11:17 PM Larry Masinter <[email-masked]> wrote:

> I was hoping to avoid stuffing the MIME registry with (and making everyone
> review) lots of useless obsolete templates; the use of OBSOLETE in
> “Intended use” should only be for previously registered types. Not new
> (dubious) registrations.
>
>
>
> *Sent:* Tuesday, July 17, 2018 7:25 AM
> *To:* [email-masked]
> *Cc:* DISPATCH <[email-masked]>;
> [email-masked]
> *Subject:* Re: [dispatch] Fwd: WGLC:
> draft-ietf-dispatch-javascript-mjs-02.txt
>
>
>
> <https://html.spec..whatwg.org/multipage/scripting.html#scriptingLanguages>
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 19 Jul 2018 09:21:42 -0400

+1. There's confusion about their status; the registry is the right place to set the record straight.

> On 19 Jul 2018, at 9:02 am, Bradley Meck <[email-masked]> wrote:
> 
> I think reflecting reality is important, is the only concern the number of types / review time? Should that be split into a separate RFC to add all the obsolete types so that it can take more time to land all of those. Regardless of intent, there MIMEs are in use and part of the web standards used by browsers. Having them documented/registered seems important if the MIME registry is intended to reflect actual usage.
> 

--
Mark Nottingham   https://www.mnot.net/