Design: Register .wasm as application/wasm in www.iana.org

[rongjiecomputer]

WebAssembly.{compile,instantiate}Streaming requires mime type of application/wasm. Many people use python -m http.server to serve and test WebAssembly locally but CPython does not know .wasm file extension (yet).

To add .wasm type to CPython's mimetypes module, CPython requires the extension to be registered in www.iana.org first (see mimetypes.py). Can someone from the WebAssembly group do the registration work?

[jfbastien]

I believe @flagxor did this last year: https://github.com/WebAssembly/meetings/blob/f6705a7fc135271700ff1fb5d1ca0637893723bf/2017/WG-10-23.md#mime-type-for-wasm

It was also discussed here: https://github.com/WebAssembly/spec/issues/583

[rongjiecomputer]

@jfbastien Thanks for the infomation. I did read that meeting note (and that particular section) when it was published on Github, but I totally forgot about it until you resurfaced it.

What is the current status of the registration?

[gergo-papp]

Hi! Any updates on adding .wasm files to IANA?

[binji]

I haven't followed this topic closely, but it seems like the current status is this:

application/wasm has been added to the provisional standard media type registry.

The process for provisional registrations is described in rfc6838 here. The w3 process is described here: Register an Internet Media Type for a W3C Spec.

It seems that to advance the process we'll have to proceed to Candidate Recommendation with the WebAssembly specification. @ericprud: is there more we need to do before this?

I'm unsure about where the Registration Section as described in step 2 of the w3 process is located. @flagxor do you have a copy of/link to this? I assume this was required to get provisional status.

[lukewagner]

FWIW, it's also in various other shared MIME dbs, including the one used by GitHub Pages.

[ericprud]

When we register, I'll send a PR to pull application/wasm out of mime-db's custom-types as it should then be redundant against iana-types. (I wonder if mime-db will detect that on its own.)

[ememisya]

Any updates on this? IANA Media Types were Last Updated 2019-07-11

[ericprud]

Now that we're on CR, we can do this any time. I'm on vacation for the next week. After that, I'll see when the next W3C/IESG meeting is.

Feel free to ping me if I forget.

[ememisya]

Any updates on this? IANA Media Types were Last Updated 2019-10-16

[verbessern]

What about WAT for text and WAB for binary?

[ericprud]

@plehegar, can we add this registration as an appendix to WebAPI so it will be where folks will look for it? I don't see it as changing the specification (the spec has prescribed application/wasm since Feb 2017); just putting stuff in predicable places.

@all, In the registration template below, I went with @verbessern's proposal for the .wab file extension (leaving room for a future .wat registration). Is there any legacy file extension we should conform to? Note that mime-db uses '.wasm'. @lukewagner, what's your suggestion?

Type name: application
Subtype name: wasm
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: N/A (this is a binary format)
Security and privacy considerations: see WebAssembly Core Security Considerations
Applications that use this MIME type: Web browsers
Additional information:
Magic number(s): N/A
File extension(s): .WAB
Macintosh file type code(s): WASM
Person & email address to contact for further information: Eric Prud'hommeaux \ Intended usage: COMMON
Restrictions on usage: none
Author: W3C's Web Assembly Working Group.
Change controller: W3C.

[ememisya]

Looks like emscripten also uses .wasm

[sunfishcode]

The WebAssembly spec says .wasm:

"The recommended extension for files containing WebAssembly modules in binary format is “.wasm”

And indeed, .wasm is used throughout the ecosystem:

• rustc
• wabt
• binaryen
• Emscripten
• walrus
• spec interpreter
• Wikipedia
• Webpack
• Parcel
• Rollup
• AssemblyScript
• MDN

(Edited - added more projects -- thanks @Pauan!)

[verbessern]

If that will be made properly, now is the time, later will be over. The .wasm obviously is dictated by the desire to extend the .asm files, but the binary forms there, are many (.exe, .dll, .so, ...). Mistakes must be fixed, not be used for a base. The standard should be corrected, and be proper. There will be many other implementations in the future, and uncountable files in the wild. I think that having .wasm and .wat file is far worse (they are even a different length), then .wab and .wat. I expect that they will be a very common file formats in the future. Three letters per extension is descriptive enough.

[verbessern]

How it will be served (MIME) is another topic. I find no excessive reason to be different from "application/wab", but It could be served as "application/web-assembly-binary" as is "application/java-archive" for example for .jar. In a similar way and for the text format. This abbreviation 'wa?' defines a common namespace for the extensions.

[verbessern]

The existance of .wasm, does not prevent to have an explicit "split" to .wab and .wat, that could enter in the subsequent versions of the specs. The .wasm extension does not clearly indicate the internal structure of the file, when the binary and the text format are defined to be equivalent.

[Macil]

@verbessern I don't think .wab is a good idea or realistic at this point. .wasm is already established in the ecosystem, it's very recognizable as related to WebAssembly, and WebAssembly text files are going to be very rare compared to the binary files since end-users never see them and most developers in the space will be working with tools that output straight to binary files, so it doesn't seem worth it to change .wasm for a closer parallel with .wat.

[verbessern]

That could be true, for the amount of end user files, but I think that this is not a reason, to mess up the extensions to .wasm and .wast (as its also already available around). This sounds like, because the .obj files used by some C++ compilers are not usually available for the end user, to call them .asmo. I don't think also that .wasm is "estabilished". That there are few implementations available, does not make it established. It will be established after years to come. The extension is not even yet registered (and so we are here).

[Pauan]

@sunfishcode In addition to that, .wasm is used by Webpack, Parcel, and Rollup. I would say it's definitely well established, and it would be quite difficult to change it at this point.

@verbessern You seem to think that .wasm was chosen because it "extends" the .asm extension... but that's not the case. It was chosen because "Wasm" is the official shorthand for "WebAssembly" (in speech).

That's it, that's the reason. It would be very strange to call it "Wasm" in speech but have the .wab file extension, rather than the very natural .wasm file extension.

In addition, .wasm always refers to the binary format, there is no ambiguity. The binary format is the idiomatic format. The text format is for debugging, and debuggers will automatically convert the .wasm file into the text format on the fly.

[verbessern]

It is the official shorthand, but it does have 2 different representations when serialized, that I think should be unified as stated above with a common prefix: .wa . I don't find a strong relation from the shorthand name and the extension(s?). I do think that the name is influenced by the assembly itself: https://en.wikipedia.org/wiki/Assembly_language, and then the extension is kept to clearly describe that relation: wasm.
I see no problem the support for web assembly to be called 'wasm support', neither some libraries to have wasm modules, that is correct, because that is how its shorthanded. I'm talking about the file extension itself, that its ambiguous, long, and does not incorporate well with the text format extension.
That few projects are loading one -not yet registered- extension, does not imply that it should be made worldwide. In a contrary, it should be made properly, even if that means to be .webasmbin / .webasmtxt.

[verbessern]

ps. I do think also, that the developers had to use something, because they worked on the implementations. It does not imply that all of them wanted to, or approve it. So this kind of an argument is a little foggy.

[Pauan]

@verbessern The extension is not ambiguous (as I already explained), 4 characters is not particularly long, it matches with the name of WebAssembly, it has always been the official recommendation (it's in the spec), and it is widely used by all tooling.

You seem to want to make the text format "equal" to the binary format, but they are not equal. The binary format is the standard format. It is what is used in production. It is what is used in 99+% of uses of wasm. The text format is a supplement used for debugging, teaching, etc. You should not be shipping .wat files. Also, having .wasm and .wat separated is a good thing, since it avoids confusion. Making them more similar causes more confusion, not less.

You also keep claiming that .wasm is somehow "improper", but you have provided no arguments for that. Registering .wab is not "more proper" than registering .wasm, that's just your own personal preference.

You also keep mentioning a .wa prefix, but we already have that, since .wasm and .wat both have a .wa prefix. And .wasm is a binary assembly format, and .wat is a textual format, so they work perfectly. So you will really need to provide some sort of strong argument for why .wab is superior to .wasm.

[ememisya]

The WebAssembly spec says .wasm:

"The recommended extension for files containing WebAssembly modules in binary format is “.wasm”

And indeed, .wasm is used throughout the ecosystem:

• rustc
• wabt
• binaryen
• Emscripten
• walrus
• spec interpreter
• Wikipedia

Not to stray off topic here, but most libraries in the ecosystem also mention how to configure the web server to serve the mimetype. Frameworks such as Spring tend to get their list of MIME types from web servers like Apache (albeit the ultimate authority is IANA). Apache on the other hand is waiting on this issue to be resolved https://bz.apache.org/bugzilla/show_bug.cgi?id=63162

[verbessern]

Alright. It seems you are not reading carefully.

• the "official" recommendation is there, because it had to be some. The topic is not yet resolved, and so we are here.
• 4 characters is too long, based on the most common 3 characters extensions.
• all "existing" tooling, does not constitute a standard, and as I have explained (if read carefully), that the "not yet registered" extension is used, is because some had to be, the developers just followed what the specs said, so that argument is not really that strong.
• the two serialization formats are equivalent by a definition, regardless that one will be used more often. Equal are for sure not.
• I don't really understand that one "You should not be shipping .wat files. Also, having .wasm and .wat separated is a good thing".
• I have provided many arguments to support .wab files (if read carefully): its shorter and the same length as the .wat extension (btw. in the web there are and .wast files, not only .wat, so it seems you kind of agree with the extension).
• I don't really have a personal preference, the power I have used to discuss this is more then to use a 5 characters extension for many years to come. I have just noticed the lack of consistency on that, so I have commented. What I do hope to have is logic, and a sense for consistency. And if more people have the same "personal preference" as to say, then fine, else fine as well.

I can agree that .wasm is more descriptive, but its questionable is that enough for a file extension, that breaks other "properties" as described above. And some purely cosmetic property: It is also harder to pronounce then .wab.

[conrad-watt]

The most important point, as made by @sunfishcode, is that all existing tools and documentation are using .wasm, and switching now will cause pain that would need to be appropriately justified with a strong argument that the alternative is significantly better.

@verbessern the people disagreeing with your position are not misreading your arguments. We just don't think they tip the scales. If the Web can survive .html being 4 characters then .wasm is fine for sure.

You talk of .wat and .wasm as being "two serialization formats", but this is _not_ the purpose of .wat, which exists essentially as a communication convenience for humans. Wasm _is_ a bytecode language. Shipping .wat would be analogous to shipping a Java program as a text file containing Java bytecode mnemonics. With the possible exception of engine conformance tests or simple tutorials, the .wa[s]t extensions should almost never be seen by anyone who did not produce the file themselves.

[verbessern]

Alright, I felt a desire to contribute to the issue with some arguments. Please decide what ever is best.

ps. is that the purpose or not does not change the fact that these are two serialization formats. After they are defined as equivalent, each of them could be used by an implementation.
ps. I will definitely refactor a code, when I understand that the current definitions are not appropriate. If not, in long term, everything will become "something like that" but not exactly.

[lukewagner]

@ericprud (Sorry for slow reply.) Definitely agreed with @sunfishcode @conrad-watt et al on sticking with .wasm as currently in mime-db and used throughout the ecosystem.

[sunfishcode]

@ericprud In addition to the file extension, here are a few other things we can fill in:

Applications that use this MIME type: Web browsers

WebAssembly is growing in non-Web spaces too, so it would nice to list runtime systems (in the sense described here) here as well.

Magic number(s): N/A

The binary format starts with the bytes 0x00 0x61 0x73 0x6D.

[ericprud]

With apologies to @verbessern, it does seem that consensus is that the deployed extension is .wasm so I'll submit a PR to go into web-api-1.1 (or 2? that's another conversation to be had).

@sunfishcode, I believe you intend this text:

Applications that use this MIME type: Web browsers and runtime systems

, and tx for the magic no.

[sunfishcode]

@ericprud Yes, that wording looks good, thanks!