[web] Register application/wasm MIME type

[lukewagner]

We should follow the procedure to register 'application/wasm' as an official MIME type.

(Incidentally, lack of official registration blocks WebAssembly.compileStreaming from consuming .wasm files served by GH Pages.)

[dschuff]

I believe @flagxor actually just started this process.

[lukewagner]

Nice! Maybe he can just close this issue once it's done?

[littledan]

Should we register a mimetype for Wasm text format?

[jfbastien]

We don't expect browsers to consume the text format except to display it as-is, no?

[littledan]

I didn't mean for it to be interpreted by browsers. Maybe it doesn't make sense. Mimetypes aren't just for browsers, but they're also not for entirely arbitrary things with a file extension. I was just thinking about the appropriate way to note the extension in the standards universe. (There was a recent update to the JavaScript mimetype to support .mjs, FWIW.)

[jfbastien]

IIUC .mjs changes how you parse the file (because modules don't parse the same as .js), whereas for the WebAssembly text format it seems like text/plain is what's needed?

[littledan]

This is a tangent, but .mjs doesn't change anything for browsers and doesn't have its own mimetype; it's just included in the JS mimetype.

[lukewagner]

As an update, .wasm is now a registered extension in mime-db which is the database used by GitHub Pages. Here's a test I just made which shows the change is live. Even better, .wasm files are marked as compressible so they are served with gzip compression.

[ericprud]

This should be handled by W3C-IETF registration process

[djc]

@ericprud so is there any progress on this? Otherwise maybe I'll just fill out the IANA application form to register application/wasm -- it seems rather straightforward. Maybe we should also get text/wasm for .wat?

[DesWurstes]

Any news from ietf-types at iana.org ? It shouldn't take more than one e-mail. 😔

They can't reject a MIME type even Google uses:

curl 'https://earth.google.com/static/wasm/9.3.113.2/earthwasm.wasm' -I | grep "wasm"

prints

Content-Type: application/wasm

[djc]

I propose sending the following data to IANA:

Type Name: application
Subtype Name: wasm
Required parameters: none
Optional parameters: none
Encoding considerations: binary, no additional notes
Security considerations: copy the relevant section from the spec:

"WebAssembly provides no ambient access to the computing environment in which code is executed. Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module. An embedder can establish security policies suitable for a respective environment by controlling or limiting which functional capabilities it makes available for import. Such considerations are an embedder’s responsibility and the subject of API definitions for a specific environment.

Because WebAssembly is designed to be translated into machine code running directly on the host’s hardware, it is potentially vulnerable to side channel attacks on the hardware level. In environments where this is a concern, an embedder may have to put suitable mitigations into place to isolate WebAssembly computations."

Interoperability considerations: WebAssembly has been carefully specified, and several interoperable implementations exist and are widely deployed.

Published specification: https://webassembly.github.io/spec/core/index.html

Application usage: The application/wasm media type is already in use as the type used to describe WebAssembly files when sent over HTTP to be executed by browsers, which is a common scenario. Additionally, several WebAssembly runtimes that take advantage of the safety and portability while targeting efficient execution and compact representation.

Fragment identifier considerations: N/A

Restrictions on usage: N/A

Deprecated alias names: N/A
Magic number(s): \0asm
File extension(s): wasm
Macintosh File Type Code(s): N/A
Object Identifier(s) or OID(s): N/A

Intended Usage: Common

Contact Person: ???
Contact Email Address: ???
Author/Change Controller: the WACG

In a pinch, I'd be okay being the contact person, but that seems suboptimal. Maybe @rossberg as editor?

[djc]

Last call: if there's no further feedback, I'm going to submit this to IANA with myself as contact person in ~48 hours.

[tlively]

It might be worth bringing this up at a CG video meeting, since I'm sure not everyone is paying close attention to this thread. @ericprud suggested above that there might be some special W3C process, and I would want to make sure we are following that as well.

[djc]

Thanks for the feedback! I found that CG means Community Group, but the page at https://www.w3.org/community/webassembly/ has one post from 2015 and doesn't seem to mention any video meetings that I can see, so I'm not sure how I'd participate in that. I pinged ericprud already a month ago and have seen no response.

[Ms2ger]

See https://github.com/WebAssembly/meetings/

[binji]

I'm not sure how often Eric checks his github mentions, I'll ping him directly.

[djc]

I've submitted a PR for the next meeting's agenda. Unfortunately I won't be able to attend, but hopefully who does can lead the discussion. It honestly seems fairly straightforward and non-controversial to me.

[ericprud]

W3C specs typically include a media type registration which is mirrored at iana.org. For example, Turtle has a registration in the spec and at iana. The Web API spec includes a media type. Diffing the two (normalizing to https://www.iana.org/form/media-types), I see five diffs:

 Optional Parameters: None
 Encoding Considerations: binary, no additional notes
 Security Considerations:
-"WebAssembly provides no ambient access to the computing environment in which code is executed. Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module. An embedder can establish security policies suitable for a respective environment by controlling or limiting which functional capabilities it makes available for import. Such considerations are an embedder’s responsibility and the subject of API definitions for a specific environment.
-
-Because WebAssembly is designed to be translated into machine code running directly on the host’s hardware, it is potentially vulnerable to side channel attacks on the hardware level. In environments where this is a concern, an embedder may have to put suitable mitigations into place to isolate WebAssembly computations."
+See see WebAssembly Core Security Considerations
+https://www.w3.org/TR/wasm-core/#security-considerations%E2%91%A0
 
 Interoperability Considerations:
-WebAssembly has been carefully specified, and several interoperable implementations exist and are widely deployed.
+See see WebAssembly Core Conformance
+https://www.w3.org/TR/wasm-core/#conformance
 
 Published specification:
-https://webassembly.github.io/spec/core/index.html
+https://www.w3.org/TR/wasm-core-1/ https://www.w3.org/TR/wasm-js-api-1/ https://www.w3.org/TR/wasm-web-api-1/
 
 Application Usage:
-  The application/wasm media type is already in use as the type used to describe WebAssembly files when sent over HTTP to be executed by browsers, which is a common scenario. Additionally, several WebAssembly runtimes that take advantage of the safety and portability while targeting efficient execution and compact representation.
+  Web browsers and runtime systems
 
 Fragment Identifier Considerations: N/A
 
 Restrictions on usage: N/A
 
 Deprecated alias names: N/A
-Magic number(s): \0asm
+Magic number(s): 0x00 0x61 0x73 0x6D
 File extension(s): wasm
 Macintosh File Type Code(s): N/A

For Security Considerations and Interoperability Considerations, I propose to go with the dereference to core's security considerations and conformance.

For Published Specification, I propose the W3C latest spec links for the three specs.

For Application Usage, @djc's text is more descriptive.

For Magic Number, my instinct is that the hex is harder to misinterpret.

Huh, Published specification has inconsistent capitalization in https://www.iana.org/form/media-types.

I created a PR to this end. I will update to reflect consensus here and in the CG meeting.

[djc]

@ericprud thanks for pushing this forward. So is there anything left to do to push this into the IANA registry?

[ericprud]

If folks agree on the CG call, I'll send this to the ietf-types list, wait a couple weeks, submit the form. I can also raise it in an IETF-liason call if it stalls somewhere.

[binji]

We can bring this up at the CG meeting, but looking at the PR, it seems like there isn't much to discuss there. Is there something in particular you'd like to get feedback on? If not, I'd say we should merge the PR and push forward with the rest of the process, since the document has already landed in the spec repo and hasn't changed much.

[djc]

BTW, should we also submit a registration for WAT?

[binji]

@djc There was a brief discussion about that at the top of the thread. I don't think we need to, since it's not consumed or produced except by offline tools, generally. But I don't think it would hurt to do it.

[djc]

One important usage of media types is to allow tools to interoperably identify file types from extensions -- in other words, I don't think media types are only useful when exchanging files across the network. It seems like this would be useful for .wat files, too, so yeah, I think it would be useful to have that.

[djc]

@ericprud any progress on getting this done?

[djc]

@plehegar, would you be able to help move this forward?

[ericprud]

I get weekly email from a kind person in charge of shepherding requests saying that it's still pending review by the IESG. I've offered to help or discuss it with them but I'm basically waiting for them to get around to it. It's probable that @plehegar or @ylafon can bump up our priority, though that basically means we're cutting in line. I don't know if there's any expectation that this process will improve so I wonder if it's time for a meta-discussion with the IESG.

[djc]

Ah, I didn't know it was stuck in the IESG review queue. Thanks for the update! For how long has it been waiting there?

[ericprud]

couple months, at least. just got another please-don't-be-mad-at-me email:

I'm writing to confirm again that both your requests are with the experts.
We're sending reminders to them and the Area Director that oversees media types.
Our experts are volunteers and have to balance their day jobs with providing this service for reviewing media types.

Thank you for your patience.

In the olde days, reaching apparent consensus on ietf-types basically meant you were done. I wonder if a lack of participation has forced the process to evolve.
I hope we can streamline this.

[ericprud]

BTW, Brad Nelson applied for a provisional registration a long time ago
https://www.iana.org/assignments/provisional-standard-media-types/provisional-standard-media-types.xhtml

I guessing that if the formal registration happens tomorrow or next year, it won't change anyone's deployment. Agree/disagree?

[ericprud]

We got feedback on the registration with some proposed changes.

Proposal: accept all reviewer's proposals and proceed.

Here are the changes in question by section:

Security Considerations:

orig text of registration request:

Security considerations:
See see WebAssembly Core Security Considerations
https://www.w3.org/TR/wasm-core/#security-considerations①

reviewer's comments

This covers the active/executable content issues. However, it fails to
cover possible privacy or integrity issues. I don't think there's anything
in the format itself that provides these sorts of protections. If this is
the case, I suggest something like:

reviewer's propsal

WebAssembly is a standard, a safe, portable, low-level code format. The
security considerations associated with executing WebAssembly code are
described in https://www.w3.org/TR/wasm-core/#security-considerations.

The WebAssembly format includes no integrity or privacy protection. If
such protection is needed it must be provided externally, e.g., through
the use of HTTPS.

Applications which use this media:

orig text of registration request:

The application/wasm media type is already in use as the type used to
describe WebAssembly files when sent over HTTP to be executed by browsers,
which is a common scenario. Additionally, several WebAssembly runtimes that
take advantage of the safety and portability while targeting efficient
execution and compact representation.

reviewer's comments

Saying something is "already in use" really isn't appropriate for a
registration. I suggest something like:

reviewer's propsal

The application/wasm media type is intended for use as the type used to
describe WebAssembly files when sent over HTTP to be executed by browsers,
which is a common scenario. Additionally, the type is used by several
WebAssembly runtimes that take advantage of the safety and portability
while targeting efficient execution and compact representation.

Meta: if asked, I'll split this out into two separate issues.

[edited to fix type: s/bu/by/]

[Ms2ger]

"used bu" → "used by".

Do you want to make a PR or should I?

[ericprud]

I'm happy for you to do it if you don't mind (saves me fixing bikeshed on my machine). Were you planning on a PR to add the Media Type registration to WebAPI?

IANA has no requirement that the registration be safely ensconced in a specification so the PR can happen asynchronously.

[Ms2ger]

@ericprud updated in #1279; also fixed "see see".

[ericprud]

done -- application/wasm registered 2021-04-20

[Ms2ger]

Thanks for dealing with this, @ericprud!