Error in Section 4. Registration

[snuggs]

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

[bmeck]

@snuggs I'm not sure how 1 is a problem? HTML explicitly states that servers should use text/javascript instead of alternatives. They continue support them for backwards compatibility not for recommendation of usage.

2 seems like an error, will fix.

[bmeck]

https://github.com/bmeck/I-D/commit/323af03b5e6f978ff92d41799dd9e4fd0760df1d should fix 2.

[snuggs]

The operative word is SHOULD. Also states afterwards SHOULD NOT use other media types. An update to MUST NOT would be needed in the HTML spec as well wouldn't it? (Not recommending just going off the standard IETF conventions https://www.ietf.org/rfc/rfc2119.txt). Just checked about 12 common sites and majority of them are responding with application/javascript as a mime type. Irony is this type is being moved from COMMON here. Even this very site we are on now responds with application/javascript which indeed goes against spec recommendations but doesn't actually veer from the spec as servers can and will have bespoke use cases.

This document updates the existing media types for the ECMAScript programming language. It supersedes the media types registrations in [RFC4329] for "application/javascript" and "text/javascript".

Would have to include application/ecmascript and text/ecmascript for this to be a valid statement? These types are indeed updated with (at minimum) .mjs

To be clear I am totally against these registration changes but wanted to be fair and read through the spec and give it the attention it deserved. However anyone that knows me in the community knows i'm as objective as they come. Just because I don't like something doesn't mean I can't wish to see it better. If only the rest of the world...

P.S. Glad I could help on #2 😄

[bmeck]

@snuggs we added the extra MIME changes after https://github.com/bmeck/I-D/issues/2 , I'm not sure what to do since there seems to be disagreement. HTML would not update to MUST NOT since they are intended to keep working.

Just checked about 12 common sites and majority of them are responding with application/javascript as a mime type. Irony is this type is being moved from COMMON here. Even this very site we are on now responds with application/javascript which indeed goes against spec recommendations but doesn't actually veer from the spec as servers can and will have bespoke use cases.

I'm not sure this relates to the intention of HTML in this case. Do you have a case where MIMEs are used outside of HTML that would be affected? HTML saying that they should not use that MIME seems that it should be moved to OBSOLETE.

To be clear I am totally against this change.

Which change is "this" referring to?

[snuggs]

Do you have a case where MIMEs are used outside of HTML that would be affected?

1. Trivially wikipedia for instance 😸
   

2. More seriously The MIME Sniffing standard for instance

3. Ample updates to mime-db. Am actually surprised you updated application/javascript out of all the mimetypes to add .mjs to. Isn't this entire registration about you bringing text/javascript coupled with .mjs to the forefront?

I am attempting to understand context. However still failing to see the benefit of these changes. I feel the most traction will be made from doing what you did over on mime-db Or at least a more thoroughly completed update that aligns with this registration.

Which change is "this" referring to?

1. Tampering with file extensions (Which you corrected)
2. Changing (although not recommended) supported Javascript MIME types to OBSOLETE when LIMITED USE (although rarely used) is a valid option. Smells like the latter is our use case rather than the former. Examples using this strategy go all the way back to 1998 here and here

Not certain what you are trying to do here but I do know Intended Usage: LIMITED USE I have seen around the rfc block for about a decade now when dealing with "We don't like it but it must stay to not break the internet" situations. Someone like yourself is all too familiar with this yes?

I hope this answers your questions!

Godspeed & good luck Bradley!

[bmeck]

@snuggs Most of this is just registration of the MIMEs. I am getting confused with all the "this" and "these" being passed around.

It doesn't sound like any of the complaints are to adding .mjs, having multiple MIMEs being updated, or the goal parameter? Is there a specific thing you are objecting to about those?

I can change it to LIMITED USE if that seems more desirable?

[snuggs]

I'll attempt to be more terse without sounding harsh. It's really simple. The addition of MJS should not OBSOLETE anything let along a currently valid Javascript type Full stop. Please complete complimentary work done in mime-db as well as your changes from August are out of sync from this registration.

Please add .mjs where applicable and nothing more. The community is already going through enough damage control. I DO believe adding .mjs MAY help this situation However could equally as such cause the same hardships for some people.

Making text/javascript COMMON is up to you but I wouldn't do it. As long as these mimetypes are valid JavaScript in HTML there is no added benefit in deprecating any of the valid JavaScript MIME types in the IANA. Even Domenic mentioned to you about HTML actually being a valid place to hold said mime types. If anything application/node should stop hijacking .js as you clearly pointed out yourself which is perfect example of something that should take priority to .mjs. Many people who use .js do not use Node and is unfortunate this was registered last year.

Truth be told the more I recon i'm realizing this is 100% a Node.js issue as the other ecosystems have moved along accordingly.

Some of this may be a personal gripe about the (not funny at all) joke going around in the community about "Michael Jackson Script". Amazes me how easy someone from my culture is belittled to a file extension that brings so much (misunderstood) pain. But that's a personal issue. :-) Previous points still 100% valid. Trust when I tell you I have given the due diligence of reading through every single blog post, closed issue, Github PR, comments after comments and documenting along the way before commenting here. Trust I want this relieved as much as you as it's gone on for many years.

IMHO if the amount of time it's taken me to read all the (impressive) areas you've touched has reached into the months on this topic, I can just imagine how much of your life is being taken up by this. The risk / reward ratio is not worth it to me going by all the pushback i've seen from maintaners with very valid points. At the end of the day it's a Node problem. Unless i'm mistaken.

Take my recommendations as a grain of salt. Just doesn't seem worth the effort...could be wrong.

[snuggs]

Addendum. Our conversation did bring up something i'm highly concerned about in userland. I DO actually see adding .mjs to be a positive thing to all related mimes even if just for IDE's sake 😎 unless that's not how the OS works with files being read (or input type=file. I use VIM personally. :-)

Perhaps this is another leg to stand on?

LIMITED USE is better than OBSOLETE for any mime listed here that's for certain. I would keep COMMON on text/javascript (even though I don't want to say that. But the way our interwebs is set up :-/)

COMMON on application/javascript. Although Domenic mentioned many using text/javascript I believe the reasoning is because old(er) IE versions would barf on anything other than text/javascript. As of late, many many servers are responding with application/javascript as well (Including Github's). Technically speaking the would make the HTML spec, your registration, and existing intent of rfc4329. I believe we may have a win, win, win with that one....LITERALLY. Or...the lesser of 3 loses.

And thanks for your time. You've already spent enough on this (i've seen it). Please let me know where I can help. I can grab the mime-db catching up PR for .mjs if you like!

I feel then this issue can be closed up for certain.

[annevk]

Why would you prefer anything other than text/javascript? It seems much more suitable to describe the format than any of others.

[snuggs]

@annevk I DO prefer. However the way the internet is set up...

On second though I probably wouldn't prefer as IMHO javascript is not text. it's executable code so I "understand" application/javascript. But am stating now that's a personal private opinion that I don't think I have the legs to debate in public ATM. :-)

For instance Github...

Even the main library responsible for mime types in Ruby, .NET, Golang, AND Node returns application/javascript. To your point doesn't mean it's right. But as I always say facts don't seem to care about my opinions.

[annevk]

We certainly decode JavaScript as text and I think text/javascript has been its MIME type since forever. The first RFC to cover JavaScript didn't really embrace that and went into some different direction for unclear reasons. I think it's about time that got fixed.

It doesn't seem that big of a deal that sites have other defaults as they'll continue to work indefinitely. We don't want to create multiple lists. But I also don't think we want to say all those 16 MIME types are equal. That'd just be confusing.

[snuggs]

But I also don't think we want to say all those 16 MIME types are equal. That'd just be confusing. @annevk

INDEED! Hence my LIMITED USE recommendation and COMMON for text/javascript until WHATWG starts deprecating existing JS mime types on the web which I highly doubt would/should happen. Like I mentioned that could be the win, win, win.

I think we are saying the same thing just using different words. Perhaps my fault good sir. :-)

[snuggs]

@annevk I know Domenic stated we went to text/javascript simply because that's what people were using. So "We just chose that as a default and kept moving". Upon further research found an email thread between Brendan and Douglas stating much of that was because IE6(?) would barf on anything other than text/javascript that's why servers chose instead of using application/*. Doesn't mean they were right but the convos did happen from what I researched. Perhaps now is the perfect crossroads to rethink what the future looks like as far as "recommendation"?](https://www.microsoft.com/en-us/windowsforbusiness/end-of-ie-support)

Just a thought FWIW.

P.S. thanks for the clarification on text. In that case text/javascript is perhaps the "wrong" (historically) right (now) solution in retrospect. bug -> feature. I just know it's a touchy subject for the web since the bad old days.

[annevk]

LIMITED USE doesn't make sense since they're not private MIME types or intended for limited use. I also don't see why we need to reconsider anything as text/javascript seems fine.

OBSOLETE for the others still seems like a reasonable choice to me given that OBSOLETE was apparently a reasonable choice for text/javascript at some point.

[snuggs]

Copy that @annevk. I just know it was feeling like deja vu even down to the mime-type extensions, goal etc. And am dealing with a client now that has ancient apps with various media types (you would cry if you saw the screen). And much from good intent via conversations like this

On a bloomberg project I saw text/JavaScript1.2 fly across the network a few times on some of the more ancient apps.

To be clear I have no problem with text/javascript being COMMON for the sake of pain i've heard you all went through in the past with the topic. That being said I know the prose for this registration states the mime types it supersedes (moving forward) and the statement doesn't match with the diffs for the types it's actually making changes to. That was my initial point and more what this issue was about. That and an error we found but that's fixed now. Unless i'm wrong. I just know there was already an error found in the strategy which was corrected. Just measuring thrice to cut once.

Wish you woulda came up with that new mime type back in the day when you thought of it. :-|

[annevk]

New MIME type?

[snuggs]

@annevk in one of the historic links in my notes you stated about thinking of a new mime type previously in a discussion on an issue somewhat related to this topic. I believe the phrase you used verbatim was "That ship has sailed". I can find if you like but would rather not have to :-) Still trying to figure out how you all keep up.

[annevk]

Ah, for module JavaScript. Yeah, that's not doable now. That would still have left us with all these types for classic JavaScript though. (Using HTML Standard terms here.)