What's the correct way to determine content type?

[OmarShehata]

The spec says:

Explicit file extensions are optional. Valid implementations may ignore it and identify a content's format by the magic field in its header.

https://github.com/AnalyticalGraphicsInc/3d-tiles/tree/master/specification#file-extensions-and-mime-types

These two sentences seem contradictory to me. If the file extension is option, then a valid implementation must use the magic field, right?

[ptrgags]

This question came up again when working on some internal details of the ion platform. I had a case where I wanted to download files from a tileset for comparison, following external tileset links. This leads to questionable code since I either make assumptions about filenames or have to download large files just to check the first couple of bytes.

@mramato suggested this solution in another issue:

One possible solution is for there to be a mimeType or similar property that lives next to the uri. So "mimeType": "application/json" would tell you what uri is.

[lilleyse]

Other thoughts:

• If requiring a mimeType in each content is too verbose we could consider defining a top-level default that can be overriden. This isn't as big a concern for implicit tiling.
• glTF requires a mime type for images stored in buffer views (for reference): https://www.khronos.org/registry/glTF/specs/2.0/glTF-2.0.html#images

CC #341 and #555

[javagl]

Sticking to the word from the quote of this issue (that is still in the specs now, 4 years later), the sentence

Valid implementations may ignore it and identify a content's format by the magic field in its header.

should probably have been reworded.

On a technical level, there are different options for determining the content type, roughly:

• The file extension: That's simple. But as most simple solutions, it's broken. Don't do this.
• Something that hasn't been mentioned here: The transport layer. One could rely on the Content-Type of some HTTP header. But this is only an option, and requires the MIME types to be registered, configured properly, and ... does not work when working on the file system. So it cannot be part of the 'format specification'
• An explicit content.mimeType property: This is not part of 3D Tiles 1.1, and could therefore only be added in 3D Tiles 2.0.
• The magic header (or file content in general): That' works ... until you have to differentiate between a content.gltf file, a tileset.json, and a shape.geojson. If we ever publish 3D Tiles 2.0, then every valid 3D Tiles 2.0 tileset file will also be a valid glTF 2.0 asset 😕

So the options are

• consider one source of information as the truth. This could only be the file content itself
• consider multiple sources of information: What to do when these sources disagree?

A related discussion is in KhronosGroup/glTF#1966 , and the conclusion is that a specification can make recommendations or suggestions, but it's nearly impossible to specify a certain runtime behavior.

OK to close this?