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

--===============2128799237075465656==
Content-Type: multipart/alternative; boundary="000000000000d9557c06569fe91a"

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

Also, why "text" as the top level type?

"text" was always meant for "stuff humans read", as I recall (text/html,
text/markdown), and this isn't that.  "text" has since been used for source
code and other non-human things, but I think there's some wish that that
hadn't happened.  I wonder if the registrant has considered this.

-MSK

On Tue, Jul 14, 2026 at 10:47=E2=80=AFPM Murray S. Kucherawy <superuser@gma=
il.com>
wrote:

> 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 t=
he
> 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, previ=
ew,
>> 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, as=
set
>> 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 reference=
s,
>> or game logic. This media type does not provide confidentiality, integri=
ty
>> protection, authentication, signing, or encryption. These services shoul=
d
>> 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, permissio=
n,
>> sandboxing, and resource-limit policies appropriate to the environment i=
n
>> which the implementation runs.
>>
>> This media type does not employ compression and is not a container forma=
t.
>>
>> 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 behavio=
r.
>>
>> 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@S=
Y
>> 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
>>
>

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

<div dir=3D"ltr">Also, why &quot;text&quot; as the top level type?<div><br>=
</div><div>&quot;text&quot; was always meant for &quot;stuff humans read&qu=
ot;, as I recall (text/html, text/markdown), and this isn&#39;t that.=C2=A0=
 &quot;text&quot; has since been used for source code and other non-human t=
hings, but I think there&#39;s some wish that that hadn&#39;t happened.=C2=
=A0 I wonder if the registrant has considered this.</div><div><br></div><di=
v>-MSK</div></div><br><div class=3D"gmail_quote gmail_quote_container"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 14, 2026 at 10:47=E2=80=AFPM =
Murray S. Kucherawy &lt;<a href=3D"mailto:[email protected]">superuser@gm=
ail.com</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-lef=
t:1ex"><div dir=3D"ltr"><div><span style=3D"background-color:transparent">A=
 few questions, mostly about SHOULD.</span></div><div><span style=3D"backgr=
ound-color:transparent"><br></span></div><div><span style=3D"background-col=
or:transparent">-MSK</span></div><div dir=3D"ltr"><span style=3D"background=
-color:transparent"><br></span></div><div dir=3D"ltr"><span style=3D"backgr=
ound-color:transparent">On Thu, Jul 9, 2026 at 11:42=E2=80=AFPM Amanda Babe=
r via RT &lt;<a href=3D"mailto:[email protected]" target=3D"_blank=
">[email protected]</a>&gt; wrote:</span></div><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">Name: Joseph Raym=
ond 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>
</blockquote></div>

--000000000000d9557c06569fe91a--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWVkaWEtdHlw
ZXMgbWFpbGluZyBsaXN0IC0tIG1lZGlhLXR5cGVzQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNl
bmQgYW4gZW1haWwgdG8gbWVkaWEtdHlwZXMtbGVhdmVAaWV0Zi5vcmcK

--===============2128799237075465656==--