rephrase usage restriction

[bmeck]

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.

[bmeck]

Maybe adding "when using this Media Type" would be sufficient?

[annevk]

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]

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

What it appears you're proposing to do instead violates how MIME types are supposed to work. That seems worse.

[bmeck]

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

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.

[annevk]

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]

@annevk this is [partially] why I originally wanted a different mime. Adding goal=module as mandatory for .mjs simply is not sufficient.

[annevk]

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]

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

[annevk]

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

@annevk If it is ignoring MIME types, how does the usage restriction cause it problems?

[bmeck]

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.

[bmeck]

removing intended would be ideal to me, but seems to be a blocker.

[annevk]

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]

@annevk goal=Module is ignored by browsers, using that would effectively remove the intent for browsers.

[annevk]

So you're trying to make new requirements on browsers with this document? That's news to me...

[bmeck]

@annevk no, I am trying to preserve intent.

[annevk]

I don't know what that means.

[bmeck]

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]

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

[annevk]

If neither Node.js nor browsers will use it then we should not add it.

[bmeck]

@annevk See #1 comments about this.