Register some more JavaScript MIME types

[annevk]

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

[bmeck]

Node etc. don't point to the HTML standard so unless that information gets moved to somewhere else an RFC seems like a sane place.

[annevk]

Why can't Node point to HTML?

[bmeck]

Some people see IANA as more authoritative on the matter. Could propose it to Node though.

[bmeck]

I would also note, some MIME databases are scraping IANA. None to my knowledge are scraping the HTML standard.

[annevk]

I'm not saying we shouldn't update IANA, I'm just saying that we don't need an RFC for that.

[bmeck]

Is HTML going to be adding .mjs somehow? That seems like it has no place in HTML.

[adamroach]

@annevk --

I'm not saying we shouldn't update IANA, I'm just saying that we don't need an RFC for that.

We do. I've had a discussion with the other ART ADs on exactly this topic. Since the original javascript MIME types were registered by an IETF-stream document, any updates to them need to be performed by an IETF-stream document.

If you want to add completely new types, that can be done by any recognized standards organization -- and there's some difference of opinion on the current IESG whether WHATWG qualifies, as the nature of "living standards" is incompatible with the notion of stable references.

But since there's likely going to be updates to text/javascript and application/javascript anyway, it adds very little work to roll any other additions you might think necessary into that document at the same time.

So, in my relatively well-informed opinion, pushing through a very small RFC is actually the easy path here.

[annevk]

ART?

I guess as long as this RFC references the HTML Standard for the processing requirements (how to get Unicode out of the bytes comes to mind) it's okay either way.

[bmeck]

@annevk the charset parameter is currently defined and has some notes things of interest from https://tools.ietf.org/html/rfc6657#section-3 . Is there something else that needs to be added / a thing we can link to that is not specific to HTML?

[adamroach]

@annevk --

ART?

Applications and Realtime. The area of the IETF that MIME usage falls under. See https://datatracker.ietf.org/group/art/about/

[annevk]

@bmeck I think you need to link to HTML since that defines the defaults, which encodings are valid, etc.

[adamroach]

@annevk -- I think you're conflating a couple of things here - there's ECMAScript as a syntax; and then there's how HTML uses that syntax. This is dealing with the former, while the HTML spec will deal with the latter.

For example, I wouldn't expect the HTML spec to bear on how node.js interacts with my filesystem when it uses a .js or .jsm file; that whole interaction is 100% HTML-free.

Put another way: I wouldn't expect to have to reference any W3C documents when registering MIME types for GIF, JPEG, or OGG formats, even though they do end up being used in HTML contexts. Why is JavaScript different?

[annevk]

@adamroach because JavaScript expects a stream of scalar values as input to its parser, not a byte sequence.

[adamroach]

@annevk -- Sure. In the general sense, that's what the MIME charset attribute communicates: how to map from a byte sequence to characters. For the domain that the HTML spec applies to, it has its own rules; but they're not applicable across all uses of ECMAScript.

[annevk]

Okay, then you'll need to say that it's host-dependent, just like ECMAScript defers a bunch of logic to hosts. You can't say it's charset because that's wrong.

[bmeck]

@annevk we can state that the charset may be ignored like in https://tools.ietf.org/html/rfc6657#section-3 ?

HTML doesn't seem to deal w/ charset from MIME that I can tell. I can send invalid charsets and it still won't seem to affect things.

[annevk]

It's not ignored, but an invalid value doesn't mean the script won't be parsed either. (Also, I would expect Node to want the same behavior as HTML does to some extent here. E.g., a BOM trumping any encoding declaration.)

[bmeck]

@annevk this is a good point; I would like to see if considerations for #!, BOM, and other preprocessing exceptions exist already. Searching around RFCs didn't bring up anything but hard to search for those concepts by term.

[bmeck]

BOM appears to be covered through https://tc39.github.io/ecma262/#sec-unicode-format-control-characters since it just states that it is treated as whitespace and does not affect the Source Text on ECMAScript spec. I don't see anything for #! in any of the https://iana.org/assignments/media-types i've been reading.

[annevk]

Yeah, except it's not treated as whitespace (it's in fact removed before being handed to ECMAScript in theory though I suspect that can't be observed one way or another).

[annevk]

See https://encoding.spec.whatwg.org/#decode for the algorithm that's eventually invoked to obtain the Source Text once there's an encoding (either through an attribute or from the charset parameter).

[bmeck]

stripping certainly changes character indexes in stack traces. It is observable in that sense. Still grepping around to see if those preprocessor considerations exist in other RFCs. I feel like they should...

[annevk]

Apparently the old JavaScript RFC had something very similar about BOMs too, but it did it too late: https://tools.ietf.org/html/rfc4329#section-4.2. (And it didn't cover script element / document encoding defaulting.)

[bmeck]

@annevk I have fixed the encoding to be host dependent. I am hesitant to register the other media types since they are still obsolete. Is this ok to close?

[annevk]

What do you mean with obsolete?

Note also that previous RFC registered text/javascript as obsolete, whereas the HTML Standard recommends using that MIME type exclusively.

[bmeck]

@annevk text/javascript is changed to COMMON in this. That RFC should not be the source of discussing text/javascript when its registration is being replaced.

I mean obsolete as in not even in the IANA. Though I see that application/ecmascript is present and should probably be added as well.

[annevk]

Not in IANA doesn't mean they're obsolete though. It just means nobody bothered to register them. And since the way to get them easily registered is to publish an RFC, the idea was to do that here. See also comments by @adamroach above.

[annevk]

Whether we then classify them as obsolete or not, I don't care strongly. I'd probably recommend against anything that isn't text/javascript.

[bmeck]

@annevk added in 9f52db7

[annevk]

And e9e47ca it seems. That commit on its own was rather confusing.

[annevk]

It seems like you listed all as COMMON, was that intended?

[bmeck]

@annevk yes, it at least gives consistent messaging with WHATWG list.

[annevk]

In https://html.spec.whatwg.org/#mime-types-2 we list everything but text/javascript as legacy type. But indeed we haven't really made any recommendations with respect to the server elsewhere. I think that's just a bug and we meant to encourage text/javascript everywhere.

[bmeck]

@annevk moved all except text/javascript to OBSOLETE in 063e5c6

[annevk]

Thanks @bmeck. I think this can be closed then, but I'll leave that up to you. I'll make sure we have some follow-up on the HTML Standard side to actually recommend text/javascript for resources.

[jabcreations]

There is no such thing as "text/javascript". The only anyone would so that specific random garble of text is because Internet Explorer 6 does not comprehend application/javascript.

Why is this even a thing? Why do there need to be more mimes? This seems like a complete waste of time and resources. Multiple mime types for the exact same thing (JavaScript) will only serve to confuse less experienced developers and only serve to undermine technology as a whole. If you break the standards we professionals will begin to ignore more than just the corrupted parts of them.

[bmeck]

@jabcreations for quite some time HTML spec has used text/javascript when preparing a script. I am not sure what

There is no such thing as "text/javascript".

means given that.

The existing MIMEs are marked as obsolete, they are not being removed. The additional MIMEs are added to reflect the reality of what is acceptable as a JS MIME.