MIME Type & File Extension For Binary Buffers

[lexaknyazev]

glTF 2.0 spec states that buffers with binary data must have .bin file extension and application/octet-stream MIME Type.

The latter applies both to external files (e.g., when they're served over HTTP) and Data URI-embedded buffers (because Data URI syntax requires specifying MIME type when it isn't text/plain).

Despite that glTF binary buffer is useless without JSON description, usage of such generic MIME Type (application/octet-stream) and file extension (.bin) could be sub-optimal:

• lack of specific MIME Type complicates network data transfer, e.g., in cases when server wants to use transport-level compression (gzip-over-HTTP);
• lack of specific file extension complicates server's configuration for such cases;
• lack of specific file extension prevents desktop environments from recognizing such files (e.g., to show non-generic icon) because glTF buffers don't have any magic value at the beginning.

Proposal: register a new MIME Type for glTF binary buffers and use it instead of application/octet-stream. Also, optionally replace .bin file extension with a new one.

According to RFC 6838, Section 4.2.5, application/ top-level type seems to be the right place:

4.2.5. Application Media Types

The "application" top-level type is to be used for discrete data that
do not fit under any of the other type names, and particularly for
data to be processed by some type of application program. This is
information that must be processed by an application before it is
viewable or usable by a user.
...
The subtype of "application" will often either be the name or include
part of the name of the application for which the data are intended.

I think that it seems quite consistent to propose application/gltf-buffer.

Thoughts?

CC @pjcozzi @sbtron @bghgary

[pjcozzi]

CC #943

[pjcozzi]

@sbtron OK to close this?

[lexaknyazev]

As far as I can see, this isn't registered yet.

[pjcozzi]

Ah, yes, of course, I was thinking of gltf-binary for .glb.

[sbtron]

nope this is still pending just the gltf-binary is done and closed.

[lexaknyazev]

@sbtron any update on this one?

[lexaknyazev]

@sbtron Any updates?

[emackey]

https://www.iana.org/assignments/media-types/media-types.xhtml

https://www.iana.org/assignments/media-types/application/gltf-buffer

It looks like this is officially registered!

Additional information:

   1. Deprecated alias names for this type: N/A 
   2. Magic number(s): N/A 
   3. File extension(s): .bin, glbin, glbuf 
   4. Macintosh file type code: N/A 
   5. Object Identifiers: N/A

The registered file extensions are .bin, .glbin, and .glbuf.

I'd like to caution once more about using .bin with anything other than application/octet-stream, first mentioned in #1180 (comment).

Most web servers are capable of serving "static files" by mapping file extensions to MIME types, typically with some factory-supplied mapping table that can optionally be extended by the server's administrator. All of the major servers already include a factory mapping from .bin to application/octet-stream, and this mapping is expected by many users, administrators, and pieces of software. It would not be appropriate for Khronos to ask anyone to map .bin to application/gltf-buffer, because that could have unknown consequences for pre-existing 3rd-party applications on many servers, un-related to glTF.

So, if we want to encourage usage of the new MIME type, we should use one of the newly registered file extensions (glbin or glbuf) to go with it.

[lexaknyazev]

Sounds great! Why did we ask for two new file extensions?

[javagl]

I'm not entirely sure how to respond to KhronosGroup/glTF-Tutorials#21 (comment) at the moment (and #1323 was closed as a duplicate of this one, so I'm asking here) :

To my understanding, the gltf-buffer MIME type applies to the network communication for full GLB files. Does this have any implications for the MIME type that is used internally, in data URIs?

More specifically: What is the MIME type that data URIs should have? (Of course, only referring to the ones that do not store images, but only the ones that store, e.g. animation data)

The spec doesn't seem to say anything about that right now. I think it could and probably should be mentioned there.

[emackey]

Why did we ask for two new file extensions?

I don't think we came to a consensus which one was better, unfortunately. I didn't have a strong opinion when I was asked, so apparently we registered both. The spec should probably be updated to use just one. glbin is closer to what everyone is using already, maybe we use that.

To my understanding, the gltf-buffer MIME type applies to the network communication for full GLB files.

Ah no, a full .GLB file is registered to model/gltf-binary.

A text-based .gltf file is registered to model/gltf+json. The +json part is part of a known subtype scheme within MIME, but there is no corresponding one for binary because "everything" is binary, so it gets a minus sign instead of a plus sign. Awesome, right?

So a JSON-based .gltf file can pull in a binary-only buffer of accessor data. Typically this buffer, when stored on disk, bears the .bin file extension, and is transmitted over HTTP (or packed into a Data-URI) using the application/octet-stream MIME type. But there are various reasons, some listed in the OP above, why this is sub-optimal. So the corresponding PR seeks to rename the MIME type to this new application/gltf-buffer type. For most web servers, serving *.gltf and *.bin files as static files from a filesystem, it will not be reasonable for most server administrators to edit the factory-supplied mapping of .bin files on their systems. Thus I proposed using a different file extension, that could have a custom mapping applied.

I don't feel like I've written this very clearly... Please ask for any clarifications 😄

[emackey]

Also, question for the group: How much of a breaking change is it, if we ask everyone to change their .gltf files to use a new file extension on the buffer data? Will sections of the reader ecosystem break?

[sbtron]

Sorry seems to have dropped through the cracks since the registration took a while. We got the additional extensions as alternative to the .bin so if your particular server config could not use the .bin extension you had some alternatives.

Rather than getting everyone to update all files to use a alternate extension I was looking at the alternate extensions as more of a opt in if you have a server config that doesn't let you override the .bin. This does mean loaders need to work with all "allowed" file extensions and not just .bin. A few of the loaders I am aware of just look at the uri and don't necessarily mandate the extension. So this might be a good middle ground to maintain compat.

[akien-mga]

I landed here while debugging why Godot Engine fails to import some of the models from https://github.com/KhronosGroup/glTF-Sample-Models (godotengine/godot#33796), which seem to use data:application/gltf-buffer;base64 already instead of the until now expected data:application/octet-stream;base64.

I'll fix this in Godot's glTF 2.0 importer, but shouldn't this be updated in the specification?
https://github.com/KhronosGroup/glTF/blob/dcf4f5938f1338ad456a7130e25903e090c1770e/specification/2.0/README.md#file-extensions-and-mime-types

I only found a reference to this issue this through search engines, not in the spec.