[media-types] Re: [IANA #1455544] text/vnd.easylang .source registration request

--===============2789877887618880941==
Content-Type: multipart/alternative; boundary="000000000000960dbc06569fdd9c"

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

A few questions, mostly about SHOULD.

-MSK

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

> Name: Joseph Raymond Francis Harrison
>
> Email: [email protected]
>
> Media type name: text
>
> Media subtype name: vnd.easylang.source
>
> Required parameters: charset
>
> The charset parameter is required. Its value MUST be UTF-8.
>
> E@SY source files are encoded as UTF-8 text. Other charset values are not
> defined for this media type.
>
> Optional parameters: N/A
>
> Encoding considerations: binary
>
> E@SY source files are UTF-8 encoded text.
>
> The binary encoding consideration is used for MIME transport purposes
> because E@SY source files may use platform-native line endings and may
> contain lines longer than 998 octets. NUL octets are not valid in E@SY
> source files.
>
> Implementations MUST decode E@SY source files as UTF-8 and SHOULD
> normalize line endings before parsing.
>

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.

Security considerations: E@SY source files contain active program text when
> processed by an E@SY compiler, interpreter, runtime, editor preview
> feature, build tool, or launcher. Merely storing or displaying an E@SY
> source file does not execute it, but implementations that compile, previe=
w,
> or run it MUST treat the file as untrusted input.
>
> Implementations SHOULD validate the source before execution, reject
> malformed programs, and avoid executing partially parsed or partially
> compiled input. Implementations SHOULD run E@SY programs inside a
> restricted runtime environment that exposes only the intended E@SY game
> API, rather than direct unrestricted access to the host operating system.
>
> Malicious E@SY source code 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, ass=
et
> loading, filesystem access, network access, and other host capabilities.
>
> E@SY source files may contain sensitive information such as developer
> comments, file paths, asset names, URLs, server addresses, API references=
,
> or game logic. This media type does not provide confidentiality, integrit=
y
> protection, authentication, signing, or encryption. These services should
> be provided externally, for example by TLS during transport, file
> permissions at rest, package signatures, checksums, or another
> application-level trust mechanism.
>
> If an E@SY implementation supports loading external assets or resources
> referenced from source files, it should apply the same-origin, permission=
,
> sandboxing, and resource-limit policies appropriate to the environment in
> which the implementation runs.
>
> This media type does not employ compression and is not a container format=
.
>
> Interoperability considerations: E@SY source files are UTF-8 text files
> containing source code for the E@SY game programming language.
>

This is a little redundant to text above and could be removed.  Instead,
perhaps mention whether any prior incompatible versions of this payload
were in circulation.


> Implementations SHOULD identify the language version supported by the
> implementation and SHOULD reject or clearly report source files that
> require unsupported language features.
>
> Implementations SHOULD accept common platform line endings and normalize
> them before parsing. Implementations MUST NOT rely only on the filename
> extension to determine validity; the file contents should be parsed
> according to the E@SY language grammar.
>
> Generic text editors may display E@SY source files, but only E@SY-aware
> tools are expected to compile, run, or provide language-specific behavior=
.
>
> The common filename extension is .easy.
>
> Published specification: E@SY Language and Source File 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 source files are used by E@SY
> editors, compilers, interpreters, game-development tools, build tools,
> syntax highlighters, project templates, educational tools, and local E@SY
> runtimes.
>
> The media type may also be used by web servers, source-code hosting
> services, package registries, documentation sites, and development
> environments when distributing or displaying E@SY source code.
>
> Fragment identifier considerations: No E@SY-specific fragment identifier
> syntax is defined for this media type.
>
> Fragment identifiers, if present, are not interpreted by this media type
> unless defined by a future version of the E@SY source file format
> specification.
>
> Restrictions on usage: N/A
>
> 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 source
> files are UTF-8 text files parsed according to the E@SY language grammar.
> Implementations should not rely only on the filename extension or media
> type to determine validity.
> 3. File extension(s): .easy
> 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 .easy.
>
> 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 E@SY source code
> between E@SY editors, compilers, interpreters, development tools,
> source-code hosting services, package registries, web servers, and local
> E@SY runtimes.
>
> Author/Change controller: Joseph Raymond Francis Harrison
>

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

<div dir=3D"ltr"><div><span style=3D"background-color:transparent">A few qu=
estions, mostly about SHOULD.</span></div><div><span style=3D"background-co=
lor:transparent"><br></span></div><div><span style=3D"background-color:tran=
sparent">-MSK</span></div><div dir=3D"ltr"><span style=3D"background-color:=
transparent"><br></span></div><div dir=3D"ltr"><span style=3D"background-co=
lor:transparent">On Thu, Jul 9, 2026 at 11:42=E2=80=AFPM Amanda Baber via R=
T &lt;<a href=3D"mailto:[email protected]">iana-mime-comment@iana.=
org</a>&gt; wrote:</span></div><div class=3D"gmail_quote gmail_quote_contai=
ner"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">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: text<br>
<br>
Media subtype name: vnd.easylang.source<br>
<br>
Required parameters: charset<br>
<br>
The charset parameter is required. Its value MUST be UTF-8.<br>
<br>
E@SY source files are encoded as UTF-8 text. Other charset values are not d=
efined for this media type.<br>
<br>
Optional parameters: N/A<br>
<br>
Encoding considerations: binary<br>
<br>
E@SY source files are UTF-8 encoded text.<br>
<br>
The binary encoding consideration is used for MIME transport purposes becau=
se E@SY source files may use platform-native line endings and may contain l=
ines longer than 998 octets. NUL octets are not valid in E@SY source files.=
<br>
<br>
Implementations MUST decode E@SY source files as UTF-8 and SHOULD normalize=
 line endings before parsing.<br></blockquote><div><br></div><div>BCP 14 &q=
uot;SHOULD&quot; presents implementers with a choice, and they need to be e=
nabled to make an educated one.=C2=A0 Here, for instance, I don&#39;t know =
what the impact of not following this SHOULD is.</div><div><br></div><div>&=
quot;SHOULD&quot; isn&#39;t valid simply because we are shy about saying &q=
uot;MUST&quot;.</div><div><br></div><div>I suggest applying that test to ea=
ch SHOULD (you have several) and see if you really want SHOULD (with some s=
upporting prose about the choice) or actually want MUST or just &quot;shoul=
d&quot;.=C2=A0 And if there are any SHOULDs left, you probably need to refe=
r the reader to BCP 14.</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">Security considerations: E@SY source files contain activ=
e program text when processed by an E@SY compiler, interpreter, runtime, ed=
itor preview feature, build tool, or launcher. Merely storing or displaying=
 an E@SY source file does not execute it, but implementations that compile,=
 preview, or run it MUST treat the file as untrusted input.<br>
<br>
Implementations SHOULD validate the source before execution, reject malform=
ed programs, and avoid executing partially parsed or partially compiled inp=
ut. Implementations SHOULD run E@SY programs inside a restricted runtime en=
vironment that exposes only the intended E@SY game API, rather than direct =
unrestricted access to the host operating system.<br>
<br>
Malicious E@SY source code could attempt to consume excessive CPU time, mem=
ory, graphics resources, storage, or other local resources. Runtimes SHOULD=
 enforce limits on execution time, memory use, recursion depth, asset loadi=
ng, filesystem access, network access, and other host capabilities.<br>
<br>
E@SY source files may contain sensitive information such as developer comme=
nts, file paths, asset names, URLs, server addresses, API references, or ga=
me logic. This media type does not provide confidentiality, integrity prote=
ction, authentication, signing, or encryption. These services should be pro=
vided externally, for example by TLS during transport, file permissions at =
rest, package signatures, checksums, or another application-level trust mec=
hanism.<br>
<br>
If an E@SY implementation supports loading external assets or resources ref=
erenced from source files, it should apply the same-origin, permission, san=
dboxing, and resource-limit policies appropriate to the environment in whic=
h the implementation runs.<br>
<br>
This media type does not employ compression and is not a container format.<=
br>
<br>
Interoperability considerations: E@SY source files are UTF-8 text files con=
taining source code for the E@SY game programming language.<br></blockquote=
><div><br></div><div>This is a little redundant to text above and could be =
removed.=C2=A0 Instead, perhaps mention whether any prior incompatible vers=
ions of this payload were in circulation.</div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">Implementations SHOULD identify the =
language version supported by the implementation and SHOULD reject or clear=
ly report source files that require unsupported language features.<br>
<br>
Implementations SHOULD accept common platform line endings and normalize th=
em before parsing. Implementations MUST NOT rely only on the filename exten=
sion to determine validity; the file contents should be parsed according to=
 the E@SY language grammar.<br>
<br>
Generic text editors may display E@SY source files, but only E@SY-aware too=
ls are expected to compile, run, or provide language-specific behavior.<br>
<br>
The common filename extension is .easy.<br>
<br>
Published specification: E@SY Language and Source File Format Specification=
, 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 source files are used by E@SY edito=
rs, compilers, interpreters, game-development tools, build tools, syntax hi=
ghlighters, project templates, educational tools, and local E@SY runtimes.<=
br>
<br>
The media type may also be used by web servers, source-code hosting service=
s, package registries, documentation sites, and development environments wh=
en distributing or displaying E@SY source code.<br>
<br>
Fragment identifier considerations: No E@SY-specific fragment identifier sy=
ntax is defined for this media type.<br>
<br>
Fragment identifiers, if present, are not interpreted by this media type un=
less defined by a future version of the E@SY source file format specificati=
on.<br>
<br>
Restrictions on usage: N/A<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 source files =
are UTF-8 text files parsed according to the E@SY language grammar. Impleme=
ntations should not rely only on the filename extension or media type to de=
termine validity.<br>
3. File extension(s): .easy<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 .easy.<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 E@SY source code bet=
ween E@SY editors, compilers, interpreters, development tools, source-code =
hosting services, package registries, web servers, and local E@SY runtimes.=
<br>
<br>
Author/Change controller: Joseph Raymond Francis Harrison<br>
</blockquote></div></div>

--000000000000960dbc06569fdd9c--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWVkaWEtdHlw
ZXMgbWFpbGluZyBsaXN0IC0tIG1lZGlhLXR5cGVzQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNl
bmQgYW4gZW1haWwgdG8gbWVkaWEtdHlwZXMtbGVhdmVAaWV0Zi5vcmcK

--===============2789877887618880941==--