[media-types] Re: [IANA #1455032] application/vnd.go dot.resource registration request

Alexey Melnikov <[email protected]>
Newsgroups gmane.ietf.types
Message-ID <[email protected]>
Hi David,

On 06/08/2026 18:52, David Dong via RT wrote:
> Hi Alexey,
>
> Following up on the godot requests; please see the below responses from the requester (it looks like he responded to all comments from the five requests together).
>
> --
>
>>>> Optional parameters:
>>>> Text-based Godot resources, `*.tres` files: `format=text`
>>>> Binary Godot resources, `*.res` files: `format=binary`
>> This looks like 2 different formats, but if they are similar enough,
>> reuse of the same media type is Ok.
> They are identical except for their final encoding. They can be converted 1:1 to each other in a way that they are considered to contain the exact same data when loaded. So yes, the intention is to use the same media type, because the processing and loading of these sub-types is identical beyond the very first step. However, if it fits in better with IANA's conventions and standards for media types, it would also be acceptable to have `application/vnd.godot.resource.text` and `application/vnd.godot.resource.binary`. These proposed media type names are not in use yet, so we can make this change without breaking compatibility with anything.
Yes, I think this would be the best (+ delete optional parameter 
"format" from each registration).
> The exact same response applies equally to Godot resources (vnd.godot.resource), Godot scenes (vnd.godot.scene), and Godot projects (vnd.godot.project). We should make the same decision for all of them: either keep as proposed, or make ".text" and ".binary" suffixed versions. I assume that IANA can add these without me submitting two nearly-identical registration requests? Or, let me know if action is required on my part.

If IANA is happy to do that, that would be fine with me. I can sanity 
check a pair or registrations before the same changes would be applied 
to the others?


The rest of the responses (below) are satisfactory to me.

>>>> Godot resource files do not require privacy or integrity services.
>> I question the statement about integrity, considering the statement
>> above about executable scripts. But Ok.
> Perhaps it would be better wording to say that if integrity services are required, they must be provided externally, i.e. the format does not provide any integrity services. Even a single bit flip may result in another valid file, with different contents. I'm also not sure what privacy services are, but the format doesn't have those either. The same applies to all Godot formats.
>
>>>> Interoperability considerations: Godot resource is a vendor-specific
>>>> general-purpose data format, designed for Godot Engine. Godot
>>>> resource files are not designed for interoperability with other software.
>> This section is about backward compatibility with earlier version of
>> the format. So I think the above text doesn't quite fit that and thus is not
>> needed.
>>
>> (The template already has a similar text in the "Restrictions on
>> usage", which is fine.)
> I see, I was not aware that "Interoperability considerations" refers to different versions of the file format. We can eliminate this text, consolidating into "Restrictions on usage".
>
>>>> Media subtype name: vnd.godot.gdscript
>> For textual media types it would be good to mention the default charset,
>> which seems to be UTF-8. If that is correct, adding this information to
>> the registration template would be good.
> Yes, the default and recommended charset is UTF-8. This information can be added to all of these Godot format registrations for the text versions of each format.
>
>>>> 2. Magic number(s): None
>> "N/A" instead of "None"?
> Sure, swap out "None" for "N/A".
>
> --
>
> Best regards,
>
> David Dong
> IANA Services Sr. Specialist
>
> On Tue Jul 28 17:02:46 2026, david.dong wrote:
>> Hi Alexey (filling in for Amanda),
>>
>> Following up on this; please see the below responses from the
>> requester (it looks like he responded to all comments from the five
>> requests together).
>>
>> --
>>
>>>>> Optional parameters:
>>>>> Text-based Godot resources, `*.tres` files: `format=text`
>>>>> Binary Godot resources, `*.res` files: `format=binary`
>>> This looks like 2 different formats, but if they are similar enough,
>>> reuse of the same media type is Ok.
>> They are identical except for their final encoding. They can be
>> converted 1:1 to each other in a way that they are considered to
>> contain the exact same data when loaded. So yes, the intention is to
>> use the same media type, because the processing and loading of these
>> sub-types is identical beyond the very first step. However, if it fits
>> in better with IANA's conventions and standards for media types, it
>> would also be acceptable to have `application/vnd.godot.resource.text`
>> and `application/vnd.godot.resource.binary`. These proposed media type
>> names are not in use yet, so we can make this change without breaking
>> compatibility with anything.
>>
>> The exact same response applies equally to Godot resources
>> (vnd.godot.resource), Godot scenes (vnd.godot.scene), and Godot
>> projects (vnd.godot.project). We should make the same decision for all
>> of them: either keep as proposed, or make ".text" and ".binary"
>> suffixed versions. I assume that IANA can add these without me
>> submitting two nearly-identical registration requests? Or, let me know
>> if action is required on my part.
>>
>>>>> Godot resource files do not require privacy or integrity services.
>>> I question the statement about integrity, considering the statement
>>> above about executable scripts. But Ok.
>> Perhaps it would be better wording to say that if integrity services
>> are required, they must be provided externally, i.e. the format does
>> not provide any integrity services. Even a single bit flip may result
>> in another valid file, with different contents. I'm also not sure what
>> privacy services are, but the format doesn't have those either. The
>> same applies to all Godot formats.
>>
>>>>> Interoperability considerations: Godot resource is a vendor-
>>>>> specific
>>>>> general-purpose data format, designed for Godot Engine. Godot
>>>>> resource files are not designed for interoperability with other
>>>>> software.
>>> This section is about backward compatibility with earlier version of
>>> the format. So I think the above text doesn't quite fit that and thus
>>> is not
>>> needed.
>>>
>>> (The template already has a similar text in the "Restrictions on
>>> usage", which is fine.)
>> I see, I was not aware that "Interoperability considerations" refers
>> to different versions of the file format. We can eliminate this text,
>> consolidating into "Restrictions on usage".
>>
>>>>> Media subtype name: vnd.godot.gdscript
>>> For textual media types it would be good to mention the default
>>> charset,
>>> which seems to be UTF-8. If that is correct, adding this information
>>> to
>>> the registration template would be good.
>> Yes, the default and recommended charset is UTF-8. This information
>> can be added to all of these Godot format registrations for the text
>> versions of each format.
>>
>>>>> 2. Magic number(s): None
>>> "N/A" instead of "None"?
>> Sure, swap out "None" for "N/A".
>>
>> --
>>
>> Best regards,
>>
>> David Dong
>> IANA Services Sr. Specialist
>>
>> On Sat Jul 18 03:03:08 2026, david.dong wrote:
>>> Hi Alexey (filling in for Amanda),
>>>
>>> Please see the below responses from the requester (it looks like he
>>> responded to all comments from the five requests together).
>>>
>>> --
>>>
>>>>>> Optional parameters:
>>>>>> Text-based Godot resources, `*.tres` files: `format=text`
>>>>>> Binary Godot resources, `*.res` files: `format=binary`
>>>> This looks like 2 different formats, but if they are similar
>>>> enough,
>>>> reuse of the same media type is Ok.
>>> They are identical except for their final encoding. They can be
>>> converted 1:1 to each other in a way that they are considered to
>>> contain the exact same data when loaded. So yes, the intention is to
>>> use the same media type, because the processing and loading of these
>>> sub-types is identical beyond the very first step. However, if it
>>> fits
>>> in better with IANA's conventions and standards for media types, it
>>> would also be acceptable to have
>>> `application/vnd.godot.resource.text`
>>> and `application/vnd.godot.resource.binary`. These proposed media
>>> type
>>> names are not in use yet, so we can make this change without breaking
>>> compatibility with anything.
>>>
>>> The exact same response applies equally to Godot resources
>>> (vnd.godot.resource), Godot scenes (vnd.godot.scene), and Godot
>>> projects (vnd.godot.project). We should make the same decision for
>>> all
>>> of them: either keep as proposed, or make ".text" and ".binary"
>>> suffixed versions. I assume that IANA can add these without me
>>> submitting two nearly-identical registration requests? Or, let me
>>> know
>>> if action is required on my part.
>>>
>>>>>> Godot resource files do not require privacy or integrity
>>>>>> services.
>>>> I question the statement about integrity, considering the statement
>>>> above about executable scripts. But Ok.
>>> Perhaps it would be better wording to say that if integrity services
>>> are required, they must be provided externally, i.e. the format does
>>> not provide any integrity services. Even a single bit flip may result
>>> in another valid file, with different contents. I'm also not sure
>>> what
>>> privacy services are, but the format doesn't have those either. The
>>> same applies to all Godot formats.
>>>
>>>>>> Interoperability considerations: Godot resource is a vendor-
>>>>>> specific
>>>>>> general-purpose data format, designed for Godot Engine. Godot
>>>>>> resource files are not designed for interoperability with other
>>>>>> software.
>>>> This section is about backward compatibility with earlier version
>>>> of
>>>> the format. So I think the above text doesn't quite fit that and
>>>> thus
>>>> is not
>>>> needed.
>>>>
>>>> (The template already has a similar text in the "Restrictions on
>>>> usage", which is fine.)
>>> I see, I was not aware that "Interoperability considerations" refers
>>> to different versions of the file format. We can eliminate this text,
>>> consolidating into "Restrictions on usage".
>>>
>>>>>> Media subtype name: vnd.godot.gdscript
>>>> For textual media types it would be good to mention the default
>>>> charset,
>>>> which seems to be UTF-8. If that is correct, adding this
>>>> information
>>>> to
>>>> the registration template would be good.
>>> Yes, the default and recommended charset is UTF-8. This information
>>> can be added to all of these Godot format registrations for the text
>>> versions of each format.
>>>
>>>>>> 2. Magic number(s): None
>>>> "N/A" instead of "None"?
>>> Sure, swap out "None" for "N/A".
>>>
>>> --
>>>
>>> Best regards,
>>>
>>> David Dong
>>> IANA Services Sr. Specialist
>>>
>>> On Wed Jul 15 11:15:59 2026, [email protected] wrote:
>>>> Hi Amanda,
>>>>
>>>> This is mostly Ok to register. Some questions/comments below:
>>>>
>>>> On 07/07/2026 03:52, Amanda Baber via RT wrote:
>>>>> Hi Alexey,
>>>>>
>>>>> Resending #2 of 5 from June 29th. (Sorry, I accidentally labeled
>>>>> the
>>>>> last one "#1 of 1.")
>>>>>
>>>>> thanks,
>>>>> Amanda
>>>>>
>>>>> On Mon Jun 29 23:37:10 2026, amanda.baber wrote:
>>>>>> Hi Alexey,
>>>>>>
>>>>>> This is #2 of 5.
>>>>>>
>>>>>> thanks,
>>>>>> Amanda
>>>>>>
>>>>>> =====
>>>>>>
>>>>>> Name: Aaron Franke
>>>>>>
>>>>>> Email:[email protected]
>>>>>>
>>>>>> Media type name: application
>>>>>>
>>>>>> Media subtype name: vnd.godot.resource
>>>>>>
>>>>>> Required parameters: N/A
>>>>>>
>>>>>> Optional parameters: Text-based Godot resources, `*.tres` files:
>>>>>> `format=text`
>>>>>> Binary Godot resources, `*.res` files: `format=binary`
>>>> This looks like 2 different formats, but if they are similar
>>>> enough,
>>>> reuse of the same media type is Ok.
>>>>>> Encoding considerations: binary
>>>>>>
>>>>>> The binary format is entirely binary. The text-based format is
>>>>>> usually
>>>>>> 8-bit text, but MAY have lines longer than 998 octets, which
>>>>>> qualifies
>>>>>> as binary per RFC 2045 section 2.8.
>>>>>>
>>>>>> Security considerations: Godot resource files may contain
>>>>>> arbitrarily
>>>>>> many levels of nested content. The types of nested content
>>>>>> include
>>>>>> executable GDScript code, or possibly other executable content.
>>>>>> It
>>>>>> is
>>>>>> trivial to craft a malicious file which can be loaded by Godot
>>>>>> and
>>>>>> escape into the operating system. Therefore, sandboxing is
>>>>>> required
>>>>>> when loading untrusted files.
>>>>>>
>>>>>> Godot resource files do not require privacy or integrity
>>>>>> services.
>>>> I question the statement about integrity, considering the statement
>>>> above about executable scripts. But Ok.
>>>>>> Godot resource files are based on the INI-style Godot ConfigFile
>>>>>> format as the common structure, which also underlies most Godot
>>>>>> formats. This has the same security considerations generally,
>>>>>> with
>>>>>> the
>>>>>> same ability to contain arbitrary executable content.
>>>>>>
>>>>>> Godot resource files may link to other Godot files, such as
>>>>>> Godot
>>>>>> scenes, Godot resources, GDScript files, GDShader files, and
>>>>>> more.
>>>>>> This is done through Godot referencing syntaxes, such as
>>>>>> project-
>>>>>> relative path, project-wide unique ID, or class name.
>>>>>>
>>>>>> Interoperability considerations: Godot resource is a vendor-
>>>>>> specific
>>>>>> general-purpose data format, designed for Godot Engine. Godot
>>>>>> resource
>>>>>> files are not designed for interoperability with other software.
>>>> This section is about backward compatibility with earlier version
>>>> of
>>>> the
>>>> format. So I think the above text doesn't quite fit that and thus
>>>> is
>>>> not
>>>> needed.
>>>>
>>>> (The template already has a similar text in the "Restrictions on
>>>> usage",
>>>> which is fine.)
>>>>
>>>>>> Published specification:
>>>>>> https://docs.godotengine.org/en/stable/engine_details/file_formats/tscn.html
>>>>>>
>>>>>> Applications which use this media: Godot Engine, an open source
>>>>>> 2D
>>>>>> and
>>>>>> 3D game engine.
>>>>>>
>>>>>> Fragment identifier considerations: N/A
>>>>>>
>>>>>> Restrictions on usage: Godot resource files may be useful for
>>>>>> other
>>>>>> software to load, but implementations attempting to load them
>>>>>> are
>>>>>> not
>>>>>> guaranteed to keep working over time. Other software may choose
>>>>>> to
>>>>>> implement support for loading Godot resources, but this is not
>>>>>> encouraged.
>>>>>>
>>>>>> Provisional registration? (standards tree only): No
>>>>>>
>>>>>> Additional information:
>>>>>>
>>>>>> 1. Deprecated alias names for this type: application/x-godot-
>>>>>> resource
>>>>>> 2. Magic number(s): RSCC for *.res only
>>>>>> 3. File extension(s): *.tres *.res
>>>>>> 4. Macintosh file type code: N/A
>>>>>> 5. Object Identifiers: N/A
>>>>>>
>>>>>> General Comments: The primary purpose of registering Godot-
>>>>>> specific
>>>>>> formats is to define them, providing documentation of their
>>>>>> characteristics to non-Godot software, and provide a stable
>>>>>> vendor-
>>>>>> scoped MIME type going forward, that being
>>>>>> `application/vnd.godot.resource` in this case. However, there is
>>>>>> no
>>>>>> expectation of other software adopting Godot-specific formats or
>>>>>> adding support for loading them.
>>>>>>
>>>>>> Person to contact for further information:
>>>>>>
>>>>>> 1. Name: Godot IANA Inbox
>>>>>> 2. Email:[email protected]
>>>>>>
>>>>>> Intended usage: LIMITED USE
>>>>>>
>>>>>> Godot resource files may be useful for other software to load,
>>>>>> but
>>>>>> implementations attempting to load them are not guaranteed to
>>>>>> keep
>>>>>> working over time. Other software may choose to implement
>>>>>> support
>>>>>> for
>>>>>> loading Godot resources, but this is not encouraged.
>>>>>>
>>>>>> Author/Change controller: Godot Foundation

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.