Standards tree image/ktx mime registration for review

[Mark Callow]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/ietf-types/attachments/20100831/df8a3724/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ktx-mime-registration.txt
URL: <http://www.alvestrand.no/pipermail/ietf-types/attachments/20100831/df8a3724/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: callow_mark.vcf
Type: text/x-vcard
Size: 398 bytes
Desc: not available
URL: <http://www.alvestrand.no/pipermail/ietf-types/attachments/20100831/df8a3724/attachment.vcf>