-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rephrase usage restriction #16
Comments
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
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
|
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 |
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 (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 |
@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 |
@bmeck right, |
@annevk If it is ignoring MIME types, how does the usage restriction cause it problems? |
How does a rephrasing of:
Sound? It adds the word |
removing |
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 |
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 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 |
If neither Node.js nor browsers will use it then we should not add it. |
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.The text was updated successfully, but these errors were encountered: