Open bmeck opened 6 years ago
Maybe adding "when using this Media Type" would be sufficient?
I don't understand how that makes sense. You use a file extension in certain contexts to get a MIME type. If you have a MIME type, there's no need for file extensions.
@annevk If converting to the mime introduces ambiguity it isn't sufficient. that was part of the original issue asking for a new MIME.
Since parameters can be ignored they are not sufficient.
What it appears you're proposing to do instead violates how MIME types are supposed to work. That seems worse.
@annevk I don't see how it violates them. I spent some time rereading stuff yesterday but might have missed some text in RFCs. If you can point to that or a phrasing that works I'd be happy to figure out how to rephrase this.
As for existing registrations; there do appear to be some standards track registrations which restrict clients:
https://www.iana.org/assignments/media-types/application/coap-payload
Restrictions on usage:
An application (or user) can only use this media type if it has to represent a CoAP payload of which the specified CoAP Content-Format is an unrecognized number, such that a proper translation directly to the equivalent HTTP media type is not possible.
Also there appears to be a variety of things relying on transport context of usage that affects applications with many stating:
This media type depends on RTP framing ...
Which it seems to affect both clients and servers as well.
One even calls out that it has a specific producer and consumer (not standards track):
https://www.iana.org/assignments/media-types/application/vnd.blink-idb-value-wrapper
Restrictions on usage: Data of this media type is intended to be consumed and produced solely by Blink, the rendering engine in Chromium's browser.
The whole point of a MIME type is to indicate the type of the resource. And as per https://tools.ietf.org/html/rfc6838#section-4.12 the point of file extensions in this context is to get to the corresponding MIME type.
Perhaps it's not expressly forbidden to give authority to file extensions in a MIME type context, but it does seem rather wrong.
I already suggested an alternative phrasing that I might be appropriate here: ".mjs must only be used for resources intended to be parsed as module scripts".
The examples you cite are all about the MIME type itself, not a particular file extension (which again is just used to inform a mapping from the resource to a MIME type). They also don't require that a consumer acts in a certain manner.
@annevk this is [partially] why I originally wanted a different mime. Adding goal=module
as mandatory for .mjs
simply is not sufficient.
In isolation it shouldn't really matter which way you go (new MIME type or new MIME type parameter). Elsewhere you indicated you already admitted defeat when it comes to <script>
, so this new MIME type parameter is only relevant for Node.js. If Node.js gives the goal parameter authority there's no reason this couldn't work for your use case.
(I agree it's a shame we don't have something that works across browsers and Node.js. I suspect nobody really realized that this new top-level grammar forked the language in significant ways. It was pointed out as you say; I've said it as well, but the resistance to do anything beyond <script type=module>
, including even as much as requiring MIME type enforcement at all, was quite strong.)
@annevk we can't use a new MIME since web. I don't see how the usage restriction is problematic to the web though.
I absolutely do not concede that <script>
has any regard[relevance] for MIME. I am not convinced of it since it accepts non-JS MIMEs and treats them as JS. You will need to convince me that even when using non-JS MIMEs it respects the JS MIME.
@bmeck right, <script>
mostly ignoring MIME types is what I meant, meaning that a new MIME type (parameter) would not solve anything there (unless you changed the processing model and got everyone on board with that).
@annevk If it is ignoring MIME types, how does the usage restriction cause it problems?
How does a rephrasing of:
The intended usage of .mjs relies on the message being parsed using the Module goal of ECMA262
Sound? It adds the word relies
which I think might be enough of a compromise for me even if it allows consumers to be ambiguous about it.
removing intended
would be ideal to me, but seems to be a blocker.
Can't you just say that .mjs is restricted to mapping to MIME type + goal=Module? Nowhere else do you detail processing requirements as we've mostly deferred those to hosts. I'm not sure why this is different.
@annevk goal=Module
is ignored by browsers, using that would effectively remove the intent for browsers.
So you're trying to make new requirements on browsers with this document? That's news to me...
@annevk no, I am trying to preserve intent.
I don't know what that means.
I can't preserve it using parameters so I was making a usage restriction on the file extension. That seems to be a blocker due to statements I disagree with, so I am attempting to rephrase it. You seem to be against any preservation of this being enforced by browsers under an argument about <script>
which doesn't seem to respect MIME.
I will continue to try and rephrase this to a point that is sufficient both for your needs of browsers not respecting MIME and my needs of the intent being preserved across applications.
[edit]: above is poorly phrased but I can't think of a clear way to phrase it
To me, if browsers are not going to respect goal=
there is no[little] usefulness in trying to use it for Node. This is part of my reasoning for pushback against a goal
parameter in https://github.com/bmeck/I-D/issues/1
If neither Node.js nor browsers will use it then we should not add it.
@annevk See #1 comments about this.
Given https://github.com/whatwg/html/issues/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.