[media-types] Re: [IANA #1422745] application/vnd.si rtx.vmv0 registration request

Minor typo:  "Independent on such restrictions" should probably be "Independent of such restrictions"

Otherwise, registration looks good.

Darrel

________________________________
From: David Dong via RT <[email protected]>
Sent: Wednesday, July 30, 2025 8:21 PM
Cc: [email protected] <[email protected]>; Darrel Miller <[email protected]>
Subject: [IANA #1422745] application/vnd.sirtx.vmv0 registration request

Hi Darrel,

Just a reminder for this request from July 7th as well.

Thank you.

Best regards,

David Dong
IANA Services Sr. Specialist

On Tue Jul 22 14:59:59 2025, amanda.baber wrote:
> Hi Darrel,
>
> Sending a reminder for this request from July 7th.
>
> thanks,
> Amanda
>
> On Mon Jul 07 19:01:43 2025, amanda.baber wrote:
> > Hi Darrel,
> >
> > Would it be possible to review this one by July 21st?
> >
> > thanks,
> > Amanda
> >
> > =====
> >
> > Name: Philipp Schafft
> >
> > Email: [email protected]
> >
> > Media type name: application
> >
> > Media subtype name: vnd.sirtx.vmv0
> >
> > Required parameters: N/A
> >
> > Optional parameters: N/A
> >
> > Encoding considerations: binary
> >
> > Security considerations: The format contains code that is to be
> > executed as well as data structures that are not for execution. The
> > code is stored in a byte code format that is not native to any
> > physical CPU. Therefore a virtual machine is used to execute the code.
> > This virtual machine, as well as the used operating system (if any)
> > should implement restrictions on resources as required. Such resources
> > include physical and virtual devices, filesystems, other processes,
> > memory and computation power.
> >
> > Independent on such restrictions, care should be taken to not execute
> > malicious code. The origin of the code as well as potential
> > modification in transit or on storage should be considered. Code from
> > untrusted origins or that might have been altered should not be
> > executed.
> >
> > Any runtime should ensure a clear user intention before running any
> > code by designing user interfaces in a way that minimises accidental
> > execution.
> >
> > The format provides rudimentary checks for file integrity. Those
> > checks are optional. While any executing environment should implement
> > those, they will not block any intentional attack. Protecting the code
> > on storage (such as by file permissions), and in transit (such as by
> > using cryptographically signed transports) is therefore strongly
> > recommended.
> >
> > It is unlikely but not impossible that secret information is
> > contained. Unless otherwise defined administrative policy the same
> > rules as for protecting file integrity and the commonly used methods
> > seem sufficient.
> >
> > The format itself does at this point not support compression. However
> > it could be used e.g. to construct self-decompressing executables.
> >
> > Interoperability considerations: The format is designed specifically
> > to overcome portability of any specific hardware or operating system.
> > It does not depend on any specific CPU type, address space layout, or
> > other properties. It is however optimised for platforms that operate
> > with data units that are a multiple of 8 bit and 16 bit (or more)
> > addressing of all kinds of memories.
> >
> > Published specification: https://sirtx.keep-cool.org/vm.html
> >
> > Applications which use this media: The format developed along with the
> > SIRTX operating system, but can be used outside of it.
> >
> > Fragment identifier considerations: No fragment identifiers are
> > currently defined for the format.
> >
> > Restrictions on usage: No restrictions.
> >
> > Provisional registration? (standards tree only): No
> >
> > Additional information:
> >
> > 1. Deprecated alias names for this type: N/A
> > 2. Magic number(s): 0x00 0b00###111 0x56 0x4d 0x0d 0x0a 0xc0 0x0a
> > 3. File extension(s): vmv0
> > 4. Macintosh file type code: N/A
> > 5. Object Identifiers: N/A
> >
> > Person to contact for further information:
> >
> > 1. Name: Philipp Schafft
> > 2. Email: [email protected]
> >
> > Intended usage: COMMON
> >
> > Author/Change controller: Philipp Schafft

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]