Repository navigation
rephrase usage restriction #16
Description
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.
Activity
bmeck commentedon Nov 2, 2017
Maybe adding "when using this Media Type" would be sufficient?
annevk commentedon Nov 2, 2017
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.
bmeck commentedon Nov 2, 2017
@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.
annevk commentedon Nov 2, 2017
What it appears you're proposing to do instead violates how MIME types are supposed to work. That seems worse.
bmeck commentedon Nov 2, 2017
@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.
bmeck commentedon Nov 2, 2017
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
Also there appears to be a variety of things relying on transport context of usage that affects applications with many stating:
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
annevk commentedon Nov 2, 2017
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.
bmeck commentedon Nov 2, 2017
@annevk this is [partially] why I originally wanted a different mime. Adding
goal=moduleas mandatory for.mjssimply is not sufficient.annevk commentedon Nov 2, 2017
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.)bmeck commentedon Nov 2, 2017
@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 anyregard[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.annevk commentedon Nov 2, 2017
@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).bmeck commentedon Nov 2, 2017
@annevk If it is ignoring MIME types, how does the usage restriction cause it problems?
bmeck commentedon Nov 2, 2017
How does a rephrasing of:
The intended usage of .mjs relies on the message being parsed using the Module goal of ECMA262Sound? It adds the word
relieswhich I think might be enough of a compromise for me even if it allows consumers to be ambiguous about it.bmeck commentedon Nov 2, 2017
removing
intendedwould be ideal to me, but seems to be a blocker.annevk commentedon Nov 2, 2017
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.
bmeck commentedon Nov 2, 2017
@annevk
goal=Moduleis ignored by browsers, using that would effectively remove the intent for browsers.annevk commentedon Nov 2, 2017
So you're trying to make new requirements on browsers with this document? That's news to me...
bmeck commentedon Nov 2, 2017
@annevk no, I am trying to preserve intent.
annevk commentedon Nov 2, 2017
I don't know what that means.
bmeck commentedon Nov 2, 2017
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
bmeck commentedon Nov 2, 2017
To me, if browsers are not going to respect
goal=there isno[little] usefulness in trying to use it for Node. This is part of my reasoning for pushback against agoalparameter in #1annevk commentedon Nov 2, 2017
If neither Node.js nor browsers will use it then we should not add it.
bmeck commentedon Nov 2, 2017
@annevk See #1 comments about this.