bmeck / I-D

Internet Drafts
4 stars 4 forks source link

Register some more JavaScript MIME types #2

Closed annevk closed 7 years ago

annevk commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Why can't Node point to HTML?

bmeck commented 7 years ago

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

bmeck commented 7 years ago

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

annevk commented 7 years ago

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

bmeck commented 7 years ago

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

adamroach commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@annevk --

ART?

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

annevk commented 7 years ago

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

adamroach commented 7 years ago

@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 commented 7 years ago

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

adamroach commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@annevk added in 9f52db7

annevk commented 7 years ago

And https://github.com/bmeck/I-D/commit/e9e47ca9269c5733d58a71d92b75d9e5b272da0b it seems. That commit on its own was rather confusing.

annevk commented 7 years ago

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

bmeck commented 7 years ago

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

annevk commented 7 years ago

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 commented 7 years ago

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

annevk commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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