Standards tree image/ktx mime registration for review

[Ned Freed]

> I sent the following messages on July 26th and July 22nd.

AFAICT neither message made it to the list.

> I have had no response.

That's hardly surprising.

> I am going to assume this to mean the IETF has no objections
> to the proposed registration.

The people on this list do not speak for the IETF in this way.

> If I do not hear anything to the contrary
> by Mon. August 23rd 2PM PDT, I am going to submit the registration to
> the IESG.

Which is where the actual review and approval (or rejection) of the
registration will occur. This list provides a means to get preliminary reviews
only.

As for your actual registration:

> Type name: Image

> Subtype name: ktx

Given that this is a standards tree registration, the IESG is going to ask if
this comes from a recognized standards body. It sounds to me like The Khronos
Group qualifies, but this will be for the IESG to determine.

> Required parameters: none

> Optional parameters: none

> Encoding considerations: binary

> Security considerations:

> The ktx type is a binary data stream which contains no executable code that
> could disrupt a client processor. There is no provision in the type
> specification that would allow authors to insert executable code that would
> present any security risk to a client machine. 

IMO these security considerations are nowhere near sufficient for a standards
tree type. At an absolute minimum you need to add a discussion of possible
integrity/confidentiality concerns: Does data of this type require such
protection, and if it does, does the type provide it internally (and if so,
how) or must it be provided externally (and again, how)?

> Interoperability considerations:

> ktx data includes a field identifying the endianness of the machine which
> created the data. Applications reading the data are expected to check this
> field and convert the endianness of the data, if necessary. The texture data
> payload may be compressed using an OpenGL-vendor-specific scheme. In this
> case, only devices or applications having a way of decompressing that data
> will be able to display it.

> Published specification:

> The KTX file format specification can be found at

>     http://www.khronos.org/opengles/sdk/sdk/tools/KTX.

> This is a temporary location. The spec. will be announced next week 7/28
> and the permanent location will settled then.

A stable specification location is very important for types in the standards
tree. This will need to be updated once a permanent location is decided on.

> Applications that use this media type :

> Currently none. It is anticipated it will be widely used by applications built
> on top of the OpenGL family of standards, OpenGL, OpenGL ES and WebGL, as
> the means of delivering texture data. WebGL is likely to support this
> media type as a first class citizen.

> Additional information:

>     Magic number(s): 12 octets
				 { 0xAB,0x4B,0x54,0x58,0x20,0x31,0x31,0xBB,0x0D,0x0A,0x1A,0x0A }
>     File extension(s): .ktx
>     Macintosh file type code(s):

> Person & email address to contact for further information:

>    Mark Callow (callow_mark at hicorp.co.jp)

> Intended usage: COMMON

> Restrictions on usage: none

> Authors: Mark Callow, Georg Kolling, Jacob Ström

> Change controller:

> The Khronos Group, an industry consortium, which is responsible for such
> standards as OpenGL, OpenGL ES, WebGL and OpenCL.

				Ned