[media-types] Re: [IANA #1455548] application/vnd.ea sylang.bytecode+json registration request

--===============7713217111122730260==
Content-Type: multipart/alternative; boundary="0000000000009d2b4a0656a0008a"

--0000000000009d2b4a0656a0008a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Same issues with SHOULD as the other one.

-MSK

On Thu, Jul 9, 2026 at 11:47=E2=80=AFPM Amanda Baber via RT <
[email protected]> wrote:

> Hi Murray,
>
> This is #2 of 2.
>
> thanks,
> Amanda
>
> =3D=3D=3D=3D=3D
>
> Name: Joseph Raymond Francis Harrison
>
> Email: [email protected]
>
> Media type name: application
>
> Media subtype name: vnd.easylang.bytecode+json
>
> Required parameters: N/A
>
> Optional parameters: N/A
>
> Encoding considerations: binary
>
> E@SY compiled files are JSON documents encoded using UTF-8.
>
> The binary encoding consideration is selected for MIME transport purposes
> because JSON documents may contain lines longer than 998 octets. This med=
ia
> type uses the +json structured syntax suffix.
>
> No charset parameter is defined for this media type.
>
> Security considerations: E@SY compiled files contain active executable
> game bytecode or a compiled game package for execution by an E@SY
> runtime. Implementations MUST treat this media type as untrusted executab=
le
> content unless it has been obtained from a trusted source and verified by
> an external trust mechanism.
>
> An E@SY runtime MUST NOT execute an .easyc file merely because it has
> this media type or the .easyc filename extension. Before execution, the
> runtime SHOULD validate that the content is valid JSON, that the top-leve=
l
> value is an object, that the object contains the expected E@SY magic
> member with value "EASYBC", that the bytecode version is supported, and
> that all required bytecode/package fields are present and well formed.
>
> Implementations SHOULD validate all opcodes, operands, constants, functio=
n
> tables, asset references, entry points, metadata, and version information
> before execution. Unknown or unsupported bytecode instructions SHOULD be
> rejected unless the E@SY bytecode specification explicitly defines a safe
> forward-compatibility rule.
>

Copied text from my previous reply:

--
BCP 14 "SHOULD" presents implementers with a choice, and they need to be
enabled to make an educated one.  Here, for instance, I don't know what the
impact of not following this SHOULD is.

"SHOULD" isn't valid simply because we are shy about saying "MUST".

I suggest applying that test to each SHOULD (you have several) and see if
you really want SHOULD (with some supporting prose about the choice) or
actually want MUST or just "should".  And if there are any SHOULDs left,
you probably need to refer the reader to BCP 14.
--

This last SHOULD is better than the others because it educates users on the
choice being made, i.e., we have some guidance on when one might disregard
the SHOULD.

Malicious E@SY compiled files could attempt to consume excessive CPU time,
> memory, graphics resources, storage, or other local resources. Runtimes
> SHOULD enforce limits on execution time, memory use, recursion depth,
> instruction count, asset loading, graphics resource use, filesystem acces=
s,
> network access, and other host capabilities.
>

I suggest, for example:

"Malicious E@SY compiled files could attempt to consume excessive CPU time,
memory, graphics resources, storage, or other local resources. Runtimes
should defend themselves against such abuse."

You don't need to make the choice explicit when what you really want the
implementer to do is obvious.

E@SY compiled files may contain source-line information, filenames, asset
> paths, URLs, debug information, game metadata, or other information that
> may be sensitive. This media type does not provide confidentiality,
> integrity protection, authentication, signing, or encryption. These
> services should be provided externally, for example by TLS during
> transport, file permissions at rest, digital signatures, checksums,
> package-manager verification, or another application-level trust mechanis=
m.
>
> Because this media type is JSON-based, implementations should also
> consider JSON-specific risks, including very large documents, deeply nest=
ed
> structures, duplicate member names, unexpected number ranges, parser
> differences, and resource exhaustion during parsing. Implementations shou=
ld
> use a JSON parser rather than evaluating JSON text as executable script.
>
> This media type does not itself employ compression. If future versions of
> the E@SY compiled format support compression, archives, embedded assets,
> or container structures, the security considerations for decompression
> limits, archive traversal, embedded-resource validation, and resource
> exhaustion will need to be addressed.
>
> Interoperability considerations: E@SY compiled files are JSON documents
> containing compiled E@SY game bytecode or package data.
>
> Implementations MUST parse the file as JSON and SHOULD require a top-leve=
l
> JSON object. The object is expected to contain a top-level "magic" member
> with value "EASYBC" and a "version" member identifying the E@SY bytecode
> format version.
>

Here, why would you give the implementation an out?  Is it even in a format
you'd recognize without this top-level object with the magic number?


> Implementations SHOULD reject unsupported bytecode versions rather than
> attempting unsafe execution. Implementations SHOULD NOT assign semantic
> meaning to JSON object member ordering. Implementations SHOULD define how
> duplicate JSON object member names are handled; rejecting duplicate membe=
r
> names is recommended for interoperability.
>

What's the impact of disregarding the latter two of these?


> Numeric values, opcodes, constants, asset references, and runtime metadat=
a
> should be constrained by the published E@SY bytecode specification so
> that different E@SY runtimes execute the same compiled file consistently.
>
> JSON text exchanged between systems that are not part of a closed
> ecosystem is expected to be encoded using UTF-8.
>
> The common filename extension is .easyc.
>
> Published specification: E@SY Compiled Bytecode/Package Format
> Specification, version 0.1.
>
> Specification URL:
> https://github.com/Coolythecoder/EASY/blob/main/docs/file-types.md
>
> Applications which use this media: E@SY compiled files are used by the
> E@SY compiler, E@SY runtime, E@SY game launcher, local development tools,
> game preview tools, package managers, build systems, and game-distributio=
n
> workflows.
>
> The media type may also be used by web servers, CDNs, package registries,
> game stores, documentation sites, and development environments when
> distributing compiled E@SY games intended to run on local hardware
> through an installed E@SY runtime.
>
> Fragment identifier considerations: This media type uses the +json
> structured syntax suffix.
>
> No E@SY-specific fragment identifier syntax is defined for this media
> type. Fragment identifiers should be processed according to generic +json
> rules where applicable. Otherwise, no fragment semantics are defined for
> this media type.
>
> Restrictions on usage: No restrictions on interchange.
>
> This media type is intended for distribution and storage of compiled E@SY
> games or bytecode packages. It is not intended to cause automatic executi=
on
> by generic user agents. Execution should only be performed by E@SY-aware
> runtimes after validation.
>
> Provisional registration? (standards tree only): No
>
> Additional information:
>
> 1. Deprecated alias names for this type: N/A
> 2. Magic number(s): No fixed byte sequence magic number. E@SY compiled
> files are JSON documents. The top-level JSON value MUST be an object
> containing a member named "magic" with the string value "EASYBC".
> 3. File extension(s): .easyc
> 4. Macintosh file type code: N/A
> 5. Object Identifiers: N/A
>
> General Comments: The public display name of the language is E@SY.
> Technical identifiers use "easylang" because MIME/media type names and
> related identifiers should not contain the "@" character.
>
> The usual filename extension is .easyc.
>
> This media type uses the +json structured syntax suffix because the
> current E@SY compiled format is JSON-based.
>
> Person to contact for further information:
>
> 1. Name: Joseph Raymond Francis Harrison
> 2. Email: [email protected]
>
> Intended usage: COMMON
>
> This media type is intended for general interchange of compiled E@SY
> games or bytecode packages between E@SY compilers, E@SY runtimes, game
> launchers, local development tools, game preview tools, package registrie=
s,
> web servers, CDNs, game stores, and development environments.
>
> Author/Change controller: Joseph Raymond Francis Harrison
>

-MSK

--0000000000009d2b4a0656a0008a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Same issues with SHOULD =
as the other one.<div><br></div><div>-MSK</div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 9, 2026 at 11:47=
=E2=80=AFPM Amanda Baber via RT &lt;<a href=3D"mailto:iana-mime-comment@ian=
a.org" target=3D"_blank">[email protected]</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Murray,<br>
<br>
This is #2 of 2.<br>
<br>
thanks,<br>
Amanda<br>
<br>
=3D=3D=3D=3D=3D<br>
<br>
Name: Joseph Raymond Francis Harrison<br>
<br>
Email: <a href=3D"mailto:[email protected]" target=3D"_blank">jose=
[email protected]</a><br>
<br>
Media type name: application<br>
<br>
Media subtype name: vnd.easylang.bytecode+json<br>
<br>
Required parameters: N/A<br>
<br>
Optional parameters: N/A<br>
<br>
Encoding considerations: binary<br>
<br>
E@SY compiled files are JSON documents encoded using UTF-8.<br>
<br>
The binary encoding consideration is selected for MIME transport purposes b=
ecause JSON documents may contain lines longer than 998 octets. This media =
type uses the +json structured syntax suffix.<br>
<br>
No charset parameter is defined for this media type.<br>
<br>
Security considerations: E@SY compiled files contain active executable game=
 bytecode or a compiled game package for execution by an E@SY runtime. Impl=
ementations MUST treat this media type as untrusted executable content unle=
ss it has been obtained from a trusted source and verified by an external t=
rust mechanism.<br>
<br>
An E@SY runtime MUST NOT execute an .easyc file merely because it has this =
media type or the .easyc filename extension. Before execution, the runtime =
SHOULD validate that the content is valid JSON, that the top-level value is=
 an object, that the object contains the expected E@SY magic member with va=
lue &quot;EASYBC&quot;, that the bytecode version is supported, and that al=
l required bytecode/package fields are present and well formed.<br>
<br>
Implementations SHOULD validate all opcodes, operands, constants, function =
tables, asset references, entry points, metadata, and version information b=
efore execution. Unknown or unsupported bytecode instructions SHOULD be rej=
ected unless the E@SY bytecode specification explicitly defines a safe forw=
ard-compatibility rule.<br></blockquote><div><br></div><div>Copied text fro=
m my previous reply:</div><div><br></div><div>--</div><div><div>BCP 14 &quo=
t;SHOULD&quot; presents implementers with a choice, and they need to be ena=
bled to make an educated one.=C2=A0 Here, for instance, I don&#39;t know wh=
at the impact of not following this SHOULD is.</div><div><br></div><div>&qu=
ot;SHOULD&quot; isn&#39;t valid simply because we are shy about saying &quo=
t;MUST&quot;.</div><div><br></div><div>I suggest applying that test to each=
 SHOULD (you have several) and see if you really want SHOULD (with some sup=
porting prose about the choice) or actually want MUST or just &quot;should&=
quot;.=C2=A0 And if there are any SHOULDs left, you probably need to refer =
the reader to BCP 14.</div></div><div>--</div><div><br></div><div>This last=
 SHOULD is better than the others because it educates users on the choice b=
eing made, i.e., we have some guidance on when one might disregard the SHOU=
LD.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">M=
alicious E@SY compiled files could attempt to consume excessive CPU time, m=
emory, graphics resources, storage, or other local resources. Runtimes SHOU=
LD enforce limits on execution time, memory use, recursion depth, instructi=
on count, asset loading, graphics resource use, filesystem access, network =
access, and other host capabilities.<br></blockquote><div><br></div><div>I =
suggest, for example:</div><div><br></div><div><span style=3D"background-co=
lor:transparent">&quot;Malicious E@SY compiled files could attempt to consu=
me excessive CPU time, memory, graphics resources, storage, or other local =
resources. Runtimes should defend themselves against such abuse.&quot;</spa=
n></div><div><span style=3D"background-color:transparent"><br></span></div>=
<div>You don&#39;t need to make the choice explicit when what you really wa=
nt the implementer to do is obvious.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">E@SY compiled files may contain source-lin=
e information, filenames, asset paths, URLs, debug information, game metada=
ta, or other information that may be sensitive. This media type does not pr=
ovide confidentiality, integrity protection, authentication, signing, or en=
cryption. These services should be provided externally, for example by TLS =
during transport, file permissions at rest, digital signatures, checksums, =
package-manager verification, or another application-level trust mechanism.=
<br>
<br>
Because this media type is JSON-based, implementations should also consider=
 JSON-specific risks, including very large documents, deeply nested structu=
res, duplicate member names, unexpected number ranges, parser differences, =
and resource exhaustion during parsing. Implementations should use a JSON p=
arser rather than evaluating JSON text as executable script.<br>
<br>
This media type does not itself employ compression. If future versions of t=
he E@SY compiled format support compression, archives, embedded assets, or =
container structures, the security considerations for decompression limits,=
 archive traversal, embedded-resource validation, and resource exhaustion w=
ill need to be addressed.<br>
<br>
Interoperability considerations: E@SY compiled files are JSON documents con=
taining compiled E@SY game bytecode or package data.<br>
<br>
Implementations MUST parse the file as JSON and SHOULD require a top-level =
JSON object. The object is expected to contain a top-level &quot;magic&quot=
; member with value &quot;EASYBC&quot; and a &quot;version&quot; member ide=
ntifying the E@SY bytecode format version.<br></blockquote><div><br></div><=
div>Here, why would you give the implementation an out?=C2=A0 Is it even in=
 a format you&#39;d recognize without this top-level object with the magic =
number?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">Implementations SHOULD reject unsupported bytecode versions rather tha=
n attempting unsafe execution. Implementations SHOULD NOT assign semantic m=
eaning to JSON object member ordering. Implementations SHOULD define how du=
plicate JSON object member names are handled; rejecting duplicate member na=
mes is recommended for interoperability.<br></blockquote><div><br></div><di=
v>What&#39;s the impact of disregarding the latter two of these?</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Numeric value=
s, opcodes, constants, asset references, and runtime metadata should be con=
strained by the published E@SY bytecode specification so that different E@S=
Y runtimes execute the same compiled file consistently.<br>
<br>
JSON text exchanged between systems that are not part of a closed ecosystem=
 is expected to be encoded using UTF-8.<br>
<br>
The common filename extension is .easyc.<br>
<br>
Published specification: E@SY Compiled Bytecode/Package Format Specificatio=
n, version 0.1.<br>
<br>
Specification URL:<br>
<a href=3D"https://github.com/Coolythecoder/EASY/blob/main/docs/file-types.=
md" rel=3D"noreferrer" target=3D"_blank">https://github.com/Coolythecoder/E=
ASY/blob/main/docs/file-types.md</a><br>
<br>
Applications which use this media: E@SY compiled files are used by the E@SY=
 compiler, E@SY runtime, E@SY game launcher, local development tools, game =
preview tools, package managers, build systems, and game-distribution workf=
lows.<br>
<br>
The media type may also be used by web servers, CDNs, package registries, g=
ame stores, documentation sites, and development environments when distribu=
ting compiled E@SY games intended to run on local hardware through an insta=
lled E@SY runtime.<br>
<br>
Fragment identifier considerations: This media type uses the +json structur=
ed syntax suffix.<br>
<br>
No E@SY-specific fragment identifier syntax is defined for this media type.=
 Fragment identifiers should be processed according to generic +json rules =
where applicable. Otherwise, no fragment semantics are defined for this med=
ia type.<br>
<br>
Restrictions on usage: No restrictions on interchange.<br>
<br>
This media type is intended for distribution and storage of compiled E@SY g=
ames or bytecode packages. It is not intended to cause automatic execution =
by generic user agents. Execution should only be performed by E@SY-aware ru=
ntimes after validation.<br>
<br>
Provisional registration? (standards tree only): No<br>
<br>
Additional information:<br>
<br>
1. Deprecated alias names for this type: N/A<br>
2. Magic number(s): No fixed byte sequence magic number. E@SY compiled file=
s are JSON documents. The top-level JSON value MUST be an object containing=
 a member named &quot;magic&quot; with the string value &quot;EASYBC&quot;.=
<br>
3. File extension(s): .easyc<br>
4. Macintosh file type code: N/A<br>
5. Object Identifiers: N/A<br>
<br>
General Comments: The public display name of the language is E@SY. Technica=
l identifiers use &quot;easylang&quot; because MIME/media type names and re=
lated identifiers should not contain the &quot;@&quot; character.<br>
<br>
The usual filename extension is .easyc.<br>
<br>
This media type uses the +json structured syntax suffix because the current=
 E@SY compiled format is JSON-based.<br>
<br>
Person to contact for further information:<br>
<br>
1. Name: Joseph Raymond Francis Harrison<br>
2. Email: <a href=3D"mailto:[email protected]" target=3D"_blank">j=
[email protected]</a><br>
<br>
Intended usage: COMMON<br>
<br>
This media type is intended for general interchange of compiled E@SY games =
or bytecode packages between E@SY compilers, E@SY runtimes, game launchers,=
 local development tools, game preview tools, package registries, web serve=
rs, CDNs, game stores, and development environments.<br>
<br>
Author/Change controller: Joseph Raymond Francis Harrison<br></blockquote><=
div><br></div><div>-MSK</div><div>=C2=A0</div></div></div>
</div>

--0000000000009d2b4a0656a0008a--


--===============7713217111122730260==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWVkaWEtdHlw
ZXMgbWFpbGluZyBsaXN0IC0tIG1lZGlhLXR5cGVzQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNl
bmQgYW4gZW1haWwgdG8gbWVkaWEtdHlwZXMtbGVhdmVAaWV0Zi5vcmcK

--===============7713217111122730260==--