Re: Standards tree image/ktx mime registration for review

To: Whom It May Concern: I sent the following messages on July 26th and July 22nd. I have had no response. I am going to assume this to mean the IETF has no objections to the proposed registration. 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. Regards -Mark On 2010/07/26 20:58, Mark Callow wrote:
To Whom It May Concern:
I sent the following message on July 22nd. The only response I have received is an automated message telling me my message was awaiting the moderator's review because I am not a list member.
How long does a review typically take?
Note the KTX home page listed in the registration template will change during the next 24 hours to
http://www.khronos.org/opengles/sdk/tools/KTX
and the specification will be at
http://www.khronos.org/opengles/sdk/tools/KTX/file-format-spec/
Regards
-Mark
On 2010/07/22 2:17, Mark Callow wrote:
To Whom It May Concern:
Attached is a registration template for a new image/ktx mime-type sent on behalf of the Khronos Group <http://www.khronos.org>. I understand the procedure is first for this list to review the template and, after it is final, to send it to iesg@ietf.org.
Regards
-Mark

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
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

Hi Ned, Thank you for your reply. First let me apologize for a typo in the registration request. The URL of the spec. was incorrect. A corrected registration template is attached. Other changes to this version are: * Added URL of the main Khronos Group web site under "Change Controller." * Added the name of an application that uses (reads) this file format. * Added additional info. to Security Considerations. * Fixed some typos. See below for other comments. On 27/08/2010 05:27, Ned Freed wrote:
... As for your actual registration:
... 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. I could find no information on the IANA web site that provides a definitive definition of "recognized" in this context. However I believe Khronos should qualify as it is a widely supported industry consortium with responsibility for several well known standards. ...
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)? It is not clear to me exactly what you are asking for. I looked at Security Considerations (Section 8.5) in the image/png registration (RFC 2083 <http://tools.ietf.org/html/rfc2083>) and could see nothing along the lines you seem to be suggesting. Since this is an image format, naturally any image could be sent including images which one may wish to keep confidential. There is no encryption in the format so users wishing to keep their images confidential should overlay their own encryption. Is this the kind of discussion you are requesting? ... 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. It is stable. The specification was ratified and a permanent home created during the more than a month that has passed since I wrote the above for my initial message to ietf-types. The permanent home is
http://www.khronos.org/opengles/sdk/tools/KTX/file_format_spec/ as noted in the revised registration that I have attached. Regards -Mark

Hi Ned,
Thank you for your reply.
First let me apologize for a typo in the registration request. The URL of the spec. was incorrect. A corrected registration template is attached. Other changes to this version are:
* Added URL of the main Khronos Group web site under "Change Controller." * Added the name of an application that uses (reads) this file format. * Added additional info. to Security Considerations. * Fixed some typos.
See below for other comments.
On 27/08/2010 05:27, Ned Freed wrote:
... As for your actual registration:
... 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.
I could find no information on the IANA web site that provides a definitive definition of "recognized" in this context.
Um, exactly what part of "the IESG makes the determination" did you fail to understand? IANA != IESG. It would be frankly astonishing if the rules for how the IESG determines standards body status could be found on the IANA site. Having served on the IESG in the past, I also doubt very much the IESG has bothered to create formalized rules for what consistitutes a recognized standards body - maybe they should, but I doubt they have. So IMO it's also pretty unlikely you'll find such rules on the IESG's site either, but at least you'd be looking in the right place...
However I believe Khronos should qualify as it is a widely supported industry consortium with responsibility for several well known standards.
That's my reading as well, but again, this is up to the IESG to determine.
...
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)? It is not clear to me exactly what you are asking for. I looked at Security Considerations (Section 8.5) in the image/png registration (RFC 2083 <http://tools.ietf.org/html/rfc2083>) and could see nothing along the lines you seem to be suggesting.
RFC 2083 was published in March 1997. The current security requirement rules for media types first appeared in a slightly different form in RFC 2048, which was published in November 1996 - only four months before. This means that the image/png specification was mostly developed under the previous set of rules laid out in RFC 1590, which impose almost no requirements on what needs to be discussed in the security considerations. (It's also clear from the failure to use RFC 2048 terminology and the proper registration template that RFC 2083 was only cursorily updated to refer to RFC 2048 and not RFC 1590.) In other words, the failure of RFC 2083 to meet our current requirements means almost nothing. Indeed, there was a period in the 90s where IANA cheerfully registered anything anybody sent to them, no matter how sketchy. The fact that IANA wasn't even managing to follow RFC 1521/RFC 1590 rules doesn't give you license not to follow the current rules now. RFC 2083 actually ends up doing a pretty good job of listing various type-specific security issues, especially considering how lax RFC 1590 was about this stuff. In any case, RFC 4288 is the current specification for media type registration procedures, and bullet point 4 in section 4.6 specifically notes that unintentional information disclosure is a concern that should be covered. My interpretation of that is that, as a practical matter, the simplest way to address this is to note if encryption is ever needed and if it is, whether the type provides the necesary protection or if it has to be done externally.
Since this is an image format, naturally any image could be sent including images which one may wish to keep confidential.
That may be the case for a general image format, but there are many highly specialized formats, including image formats, that are intended for specific purposes where confidentiality is a complete nonissue. And at the opposite extreme, there are formats where confidentiality are absolute requirements for any sort of usage.
There is no encryption in the format so users wishing to keep their images confidential should overlay their own encryption. Is this the kind of discussion you are requesting?
Yes, if correct, that's the sort of statement that needs to be made for a general-purpose image type. Really, this is not a big deal.
...
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. It is stable. The specification was ratified and a permanent home created during the more than a month that has passed since I wrote the above for my initial message to ietf-types. The permanent home is
http://www.khronos.org/opengles/sdk/tools/KTX/file_format_spec/
as noted in the revised registration that I have attached.
First, I was talking about the stability of the specification's *location*, in response to you having said the location was temporary. Having a stable location now addresses this concern. Second, it actually isn't a requirement that the specification be stable. Features and capabilities are added to and removed from media types all the time. text/html is an especially good example of this, but there are plenty of others. And yes, this means that the boundary between when you're modifying an existing type and creating a new one is hard tp nail down, but when you get down to specifics it's usually pretty clear what the right answer is. Ned

Hi Ned, Thank you for the useful information buried in the unnecessary lecture. I am well aware that IANA != IESG. I began my search there because they have documents and instructions related to MIME type registration. I did search more widely without result. I was not looking for a license to not follow current rules, merely an explanation of your request related to security and a major image file format seemed like a good place to start. I read RFC4288 as I was preparing the registration template but I did not fully understand the import of the *fifth* bullet in Section 4.6. I will revise the section on security then submit my registration to the IESG. Regards -Mark On 07/09/2010 09:24, Ned Freed wrote:
I could find no information on the IANA web site that provides a definitive definition of "recognized" in this context. Um, exactly what part of "the IESG makes the determination" did you fail to understand? IANA != IESG. It would be frankly astonishing if the rules for how the IESG determines standards body status could be found on the IANA site.
Having served on the IESG in the past, I also doubt very much the IESG has bothered to create formalized rules for what consistitutes a recognized standards body - maybe they should, but I doubt they have. So IMO it's also pretty unlikely you'll find such rules on the IESG's site either, but at least you'd be looking in the right place...
However I believe Khronos should qualify as it is a widely supported industry consortium with responsibility for several well known standards. That's my reading as well, but again, this is up to the IESG to determine.
....

Hi Ned, In my reply to your original message I wrote the following on 8/31.
On 27/08/2010 05:27, Ned Freed wrote:
...
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)? It is not clear to me exactly what you are asking for. I looked at Security Considerations (Section 8.5) in the image/png registration (RFC 2083 <http://tools.ietf.org/html/rfc2083>) and could see nothing along the lines you seem to be suggesting. Since this is an image format, naturally any image could be sent including images which one may wish to keep confidential. There is no encryption in the format so users wishing to keep their images confidential should overlay their own encryption. Is this the kind of discussion you are requesting.
I no clearer to understanding your request. Please answer my question so I can proceed with the registration. Regards -Mark
participants (2)
-
Mark Callow
-
Ned Freed