[media-types] Request feedback for proposed media-type registration

[Mark Callow <[e-mail]>]

Greetings Media-Type Experts

I write to you as the point of contact for an existing media type in the standards tree, image/ktx which is promulgated by the Khronos Group.

Khronos has almost completed a new version of the specification known formally as The KTX File Format Version 2 <http://github.khronos.org/KTX-Specification/> and wishes to ensure this can be used within the Media-Type framework. Version 2 is significantly different from the existing version to the point where software that knows only about Version 1 will not be able to do anything useful with a Version 2 file. The purpose of both formats is the same, to be a container for texture data for 3D APIs. We expect Version 2 to have significant uptake due to its powerful features, including jpeg-levels of compression for transmitting texture data with transcoding to GPU block-compressed formats for use after receipt. It is likely to supplant version 1.

I should point out that both versions differs from a traditional image file in that the payload can consist of multiple possibly disparate images for cases such as mipmaps, array textures, cube maps or 3d textures.

The most likely course seems to be to register a new Media-Type image/ktx2. A putative registration application is attached. However I want to consult the experts here as to whether there are any alternative approaches that would be better such as using the tree or facets. For example creating a new tree image/texture/{ktx1,ktx2} or, using facets instead, image/texture.{ktx1,ktx2} or something else entirely. Maybe even just adding a new magic number to the existing registration.

Please advise. If a new Media-Type is the right way to go, then please review the attached draft registration.

Regards

    -Mark