bmeck / i-d Goto Github PK

In #16 it became apparent that maybe nobody plans to implement goal. If that's the case I don't think we should add it.

Within Section 4. Registration is stated:

The ECMAScript media types are to be updated to point to a non-vendor
specific standard undated specification of ECMAScript. 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]. Finally, the [HTML] specification is using
text/javascript as the default media type of ECMAScript when
preparing script tags; therefore, text/javascript has been moved
intended usage from OBSOLETE to COMMON.

Issue(s)

1. This proposal also changes application/ecmascript from COMMON to OBSOLETE. The list of javascript MIME types has been addressed ad nauseam in the past and would not like to revisit the pushback and waste of time seen when attempting to update the MIME list previously. Also, there are some applications that indeed respond with application/ecmascript which works perfectly fine within the script parser.

2. The file extension is changed from .es to .js for application/ecmascript while also adding .mjs. Adding .mjs file extension shouldn't cause this extension to be obsoleted. If it does then should be driven by real world use cases which would cause this to be obsolete. IMHO this is out of scope to adding .mjs.

Recommendation(s)

The proposal at maximum should merely make the proper .mjs addendum to application/ecmascript.

Thank you for your time @bmeck

The charset and encoding instructions that carry over from RFC 4329 may not be correct.

At least for HTML-based agents, the following is relevant:

• https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script (step 21)
• https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-classic-script (step 6,7)
• https://encoding.spec.whatwg.org/#decode (step 4)

Reconciling the above rules with the instructions from RFC 4329 may be needed.

Given whatwg/html#558 , we might want to rephrase the usage restriction. I am still intending the restriction to apply to all applications using .mjs + JS MIME but we might be able to find a better wording.

From #kde-devel:

‎[17:50] ‎<‎tosky‎>‎ chalker_: that's really new - and there is a typo: "4.1 appliaction/ecmascript" instead of application/ecmascript
‎[17:50] ‎<‎tosky‎>‎ not sure how to report it (if you know please do :)

That is currently present in https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs

It looks to be present in several places here.

Full search: https://github.com/bmeck/I-D/search?q=appliaction&type=Code

There's a small typo in the "Informative References" section:

The title of the issue has an extra 5 at the end:

• "Add `application/javascript+module` mime to remove ambiguity5" (current)
• "Add `application/javascript+module` mime to remove ambiguity" (fixed)

(Also, the new line in the URL breaks the link in the HTML-rendered version)

.mjs is literally the worst way possible to distinguish ES6 modules from ES6 scripts.

I do not believe that it should ever be standardised and it should have never seen the light of day.

See also: https://codeburst.io/the-javascript-modules-limbo-585eedbb182e

I believe the reference to TC39's # 332 - Add application/javascript+module mime to remove ambiguity does not need to be a normative reference, but instead an informative reference. According to the IESG's statement, a normative reference is one "that must be read to understand or implement the technology"; this issue provides worthwhile context but I don't think it's necessary to read in order to implement .mjs module support.

Thanks for carrying this torch!

Note throughout that the proper capitalization is ECMAScript not EcmaScript

ECMA-262: author: org: European Computer Manufacturers Association title: "Standard ECMA-262" date: August 2017 target: http://www.ecma-international.org/publications/standards/Ecma-262-arch.htm

I'd reference this as:

ECMA-262: author: org: Ecma International title: "Standard ECMA-262: ECMAScript Language Specification" date: August 2017 target: http://www.ecma-international.org/publications/standards/Ecma-262.htm

because the Ecma-262.htm link will always contain information about the most current edition of the standard. Or perhaps use https://www.ecma-international.org/ecma-262/ which should always take you directly to the html version of the most current edition. In general, we want the revised RFC to have an edition-free reference to ECMA-262 which means use the current edition, whatever that might be.

Also note that the official name of the standards organization has been "Ecma International" for quite a few years.

In the [ECMA-262] 6th Edition of the EcmaScript language standard a new top level grammar was introduced for EcmaScript Modules. This now makes two possible top level grammars for any given Source Text of EcmaScript.

I recommend rewording this so you don't have to reference obsolete versions of ECMA-262. Maybe:

In order to formalize support for modular programs [ECMA-262] now defines two top-level goal symbols for the ECMAScript grammar. This means that (in the absence of additional information) there are two possible interpretations for any given ECMAScript Source Text.

(BTW, it seems to me that this and subsequent material makes a strong argument for the application/javascript+module. If MIME types are supposed to be the mechanism that conveys out-of-band info on how to interpret a document and out-of-band info is needed to choose the correct parsing goal symbol for ECMAScript documents then the MIME type needs to encode that info. The fact that HTML has another mechanism doesn't seem adequate because it doesn't account for non-HTML agents that need to use MIME types to transmit ECMAScript documents).

Nits for the next go-round:

1. The document needs "updates" added to the document metadata
2. The title is far more narrow than document content (which does more than simply adding a filename extension)
3. Don't include citations in Abstracts, and give documents some kind of description (e.g. This document updates RFC 4329, "Scripting Media Types".)

cc @linuxwolf at his request

This draft, if it passes, will mark application/javascript as OBSOLETE, despite it being the second most used JavaScript Media Type.

I propose to instead keep it’s intended usage as a non‑OBSOLETE value.

https://html.spec.whatwg.org/#javascript-mime-type has a nice list.

(Although I do wonder if we need a whole RFC for this. It seems HTML Standard should be sufficient as it has been for other things too. In that case you could just do an RFC for that new MIME type.)

I've seen it used in an ASCII case-insensitive way, but it's not defined as such.

It's also not stated how it's to be used while parsing.

Also, not all hosts are going to use it since this kind of thing was rejected for HTML integration of JavaScript modules. So perhaps there should be some note that not all consumers/clients will use it.

cc @domenic