MIME update

[lexaknyazev]

As of now, IANA image/ktx record points here.
The registration information contains 12 "magic" bytes that include KTX1 version string.

Since KTX2 uses different "magic", we need to decide:

• whether to introduce a new file extension (like .ktx2) and a new MIME type (like image/ktx2)

or

• add KTX2 "magic" to IANA registration to keep file extension and MIME type intact.

[MarkCallow]

My plan is to make a new registration for image/ktx2 with new extension and "magic".

[dewilkinson]

I would like the option for a writer to create a file with a ‘.cttf’ suffix, even though it is a subset of KTX2. Would this require a mime type to be registered also?

Rationale:
I want for artists to recognize universal/supercompressed textures by inspecting/sorting just by file type. A ‘ktx2’ suffix could represent anything

[MarkCallow]

If you want browsers to be able to recognize the subset, another mime type will be required. If it's a different mime-type the underlying file may also a need different magic identifier. We should consult the IETF.

[lexaknyazev]

Browsers don't care much about unknown MIME types: they will treat image/ktx2 and image/cttf alike. I don't see a reason for a different magic value - an additional file extension should be enough for expected use cases.

[dewilkinson]

As long as .cttf aliases to ktx2, that's fine. I don't want to be adding extra MIME types if they're not required

[bghgary]

What is the reasoning behind adding a new extension for ktx2? I can understand maybe a separate extension as @dewilkinson points out specifically for supercompressed (though I'm not sure .cttf makes sense anymore since the glTF extension no longer calls anything cttf), but why ktx2? Is the version inside the header not enough?

[MarkCallow]

Because there are some platforms that rely entirely on file extensions to determine file type and because not every KTX loader can be relied on to support both KTX 1 and 2 given that 2 is not a superset of 1.

The .cttf idea was to identify KTX2 files that contained CTTF format data. We now have Basis Universal instead of CTTF but otherwise the idea is the same. I don't think this is necessary and would cause confusion as the MIME type would be the same as general KTX2 since there is no way to register 2 mime types with the same file signature (as far as I know).

[bghgary]

Because there are some platforms that rely entirely on file extensions to determine file type and because not every KTX loader can be relied on to support both KTX 1 and 2 given that 2 is not a superset of 1.

I think this line of reasoning is true for many files with a version in the header. Some thoughts:

• Loaders should be checking the version in the header and do appropriate things if it doesn't support it.
• File extensions with a number at the end to indicate the version doesn't seem very common.
• Coming from glTF, we have .glb for all versions (1 and 2 so far). Version 1 is not compatible with version 2 and likely neither will version 3.
• If a client supports both .ktx and .ktx2, this clients needs to register two similar extensions with the OS. If we ever have a 3rd version, will it be .ktx3?

The .cttf idea was to identify KTX2 files that contained CTTF format data. We now have Basis Universal instead of CTTF but otherwise the idea is the same. I don't think this is necessary and would cause confusion as the MIME type would be the same as general KTX2 since there is no way to register 2 mime types with the same file signature (as far as I know).

There is no rush for this as we can always add it later, but having a file extension that is more or less guaranteed to load on all platforms is much more compelling than a file extension that might or might not load depending on what is inside it.

[MarkCallow]

So @bghgary your recommendation is to use .ktx for both versions? And you would like a different extension for BasisU compressed .ktx files? If we do the latter will you want a third extension for UASTC compressed files when they appear?

I need to check the ramifications of these changes on the MIME-type registration. My concern over .ktx is that KTX2 has supercompression which will require an updated security statement vs KTX 1. I suppose we can update the existing registration but I need to verify that. My concern over additional extensions is whether it is permitted for one MIME type to have multiple extensions.

For glTF, isn't using the khr_texture_basisu extension sufficient indication that the texture will load, provided the extension is supported?

[bghgary]

your recommendation is to use .ktx for both versions?

I'm not sure I would say that's my recommendation yet. I want to know the pros and cons of each first.

And you would like a different extension for BasisU compressed .ktx files?

I don't have any specific need for this, but I can see the benefit of it.

If we do the latter will you want a third extension for UASTC compressed files when they appear?

Possibly. Or maybe we should wait until UASTC comes out to decide. I don't think we should do anything yet. Let's agree on .ktx vs .ktx2 first.

For glTF, isn't using the khr_texture_basisu extension sufficient indication that the texture will load, provided the extension is supported?

I'm not looking at this from a glTF perspective. I'm looking at this from a standalone .ktx (or .ktx2) file. If you try to open it in a file explorer of some kind, the question is whether it is better with (.ktx and .ktx2) or just .ktx

[emackey]

This issue is a little old, but there is now an official registration.

*.ktx2 is registered to image/ktx2

[MarkCallow]

Thanks for noticing this is fixed. Closing.