[media-types] Re: Request for registration: application/jm d (provisional)
Andreas Ostermeyer <[email protected]> Sun, 05 Jul 2026 11:46:38 +0000
| Newsgroups | gmane.ietf.types |
|---|---|
| Message-ID | <[email protected]> |
--===============0369719569351588888==
Content-Type: multipart/alternative;
boundary="===============4986018940930852947=="
--===============4986018940930852947==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Dear Tony,
Thank you for the review and for the three points you raised. In order:
1. "Could text/markdown be used in its place?" -- No, for two
independent reasons.
First, the RFC 6838 category. Section 4.2.1 defines text/* for content
that is "principally textual in form" and usefully readable without
software interpreting it; Section 4.2.5 defines application/* for data
to be processed by an application program before it is usable. JMD is a
structured data format whose primary consumers are programs and LLM
agents; its specification is explicit that Markdown syntax was chosen
for model affinity, not for human readability. This matches the
precedent of application/json (RFC 8259) and, more recently,
application/yaml (RFC 9512) -- both human-readable plain-text formats
registered under application/* for exactly this reason. RFC 7763 frames
text/markdown as a writing format for prose that may be converted to
HTML; that would set the wrong consumer expectation for a data
interchange format.
Second, and more decisively: JMD documents are not in general valid
CommonMark. Three of JMD's four root markers ("#!" schema, "#?" query,
"#-" delete) are not ATX headings under CommonMark 4.2 (no space after
the "#" sequence), and heading depth beyond six exceeds CommonMark's
ATX range. A text/markdown consumer would therefore legitimately render
substantial classes of JMD documents as plain prose -- precisely the
content-confusion scenario our security considerations warn against.
Labeling JMD text/markdown would invite that misinterpretation;
labeling it application/jmd prevents it. The specification now states
this non-conformance explicitly.
2. Duplication of the registration template in jmd-over-http.md --
acknowledged and fixed. The template is now maintained in exactly one
place in the repository (iana/application-jmd.md); jmd-over-http.md
section 2 has been reduced to a non-normative reference that explicitly
yields to the template. The "+jmd" structured syntax suffix discussed
there is now clearly marked as a separate, later registration step
(RFC 6839), not part of this request.
3. Internet-Draft: this gap is now closed. draft-ostermeyer-jmd-00 has
been submitted to the IETF Datatracker and is available at:
https://datatracker.ietf.org/doc/draft-ostermeyer-jmd/
It specifies the core grammar in ABNF, the canonical parse result, the
four document modes, the streaming event model, security
considerations, and inlines the registration template.
One further update: the referenced specification has just undergone a
consolidation release (v0.3.5), which among other things adds a
normative Security Considerations section and a normative treatment of
line endings and whitespace. A revised registration template follows
below. Two substantive changes relative to the May submission, both
following the precedent of RFC 8259 / RFC 9512: the optional "charset"
and "version" parameters have been removed (the encoding is fixed by
the format, and no implementation consumed a version parameter), and
the security considerations now summarize the specification's
normative section.
Revised registration template (against Specification v0.3.5):
Type name:
application
Subtype name:
jmd
Required parameters:
None
Optional parameters:
None
Encoding considerations:
JMD is a text format and MUST be encoded as UTF-8 (RFC 3629).
Documents consisting entirely of ASCII characters are 7-bit safe;
documents containing non-ASCII UTF-8 byte sequences require 8-bit
transport. Content-Transfer-Encoding values such as "base64" or
"quoted-printable" are permitted for transport systems that require
7-bit encoding (such as historical e-mail), but are neither
necessary nor recommended for modern HTTP or MCP transport.
Security considerations:
The normative treatment is Section 24 of the JMD Specification;
this template summarizes it. JMD inherits the security posture of
"application/json", with one format-specific addition (item 1).
1. Structure injection in naive generation. JMD assigns
structural meaning to line starts (headings, mode markers,
list items, frontmatter position). A generator MUST emit
untrusted content as quoted strings (RFC 8259 escaping) and
MUST NOT interpolate untrusted text into bare-value, key,
label, or frontmatter position (Specification Section 24.1).
A JMD byte sequence contains exactly one document
(Specification Section 18.0); an injected root heading or
mode marker mid-document therefore produces a parse error
rather than a second, potentially destructive document.
2. Injection into downstream rendering contexts. JMD string
content is literal data, but documents may contain characters
that are structurally significant in downstream contexts
(HTML, SQL, shell). Receivers that render JMD content into
such contexts MUST apply the appropriate escaping. This is
identical to the JSON situation and is not specific to JMD.
3. Parser resource consumption. A conforming JMD parser processes
documents in O(n) time and O(d) stack depth, where n is the
document length in bytes and d is the maximum heading depth.
The grammar itself places no bound on depth, line length,
blockquote length, or field count; implementations SHOULD
enforce practical, configurable bounds (a reasonable default
depth bound is 32) to prevent stack exhaustion and memory
abuse from adversarial inputs. Rejecting a document that
exceeds a resource bound is a resource-limit error, not a
conformance violation (Specification Section 24.3).
4. Content confusion with Markdown. JMD and conventional Markdown
share surface syntax, but JMD is not guaranteed to be valid
CommonMark: heading depth beyond six and the mode markers
"#!", "#?", "#-" are not ATX headings. A receiver that
renders a JMD document as Markdown will produce misleading
output. Implementations MUST dispatch on the declared
Content-Type and not on file content sniffing.
5. No active content. JMD has no scripting, no template
expansion, no external reference resolution, no schema
validation directives, and no anchor/alias mechanism. Parsing
a JMD document does not trigger network access, code
execution, or arbitrary I/O. This is identical to the JSON
security model.
6. Privacy. JMD documents are opaque structured data. They do not
carry fragment identifiers, external references, or embedded
URIs that are interpreted implicitly by a conforming parser.
Any URI-valued fields are application-level data; no JMD
parser is required to follow them.
7. Streaming parse semantics. JMD is line-oriented and every
completed line is independently parseable, and each framing
unit carries exactly one document (Specification Section
18.0). A partial JMD document may be partially processed by a
receiver before the full document has arrived. Implementations
that act on streaming data before the document is complete
MUST ensure that such actions are safe under truncation (for
example, a database write that commits only when the framing
unit terminates cleanly).
Interoperability considerations:
JMD is defined such that every valid data document is in bijection
with a JSON value: parsing JMD yields a JSON value; serializing a
JSON value yields a JMD document; and the roundtrip
JMD -> JSON -> JMD preserves the value up to canonical
normalization (key ordering and number formatting variations
permitted by RFC 8259).
Multiple valid JMD representations may exist for the same JSON
value. This is by design and matches JSON's own freedom in object
key ordering. Interoperability between JMD implementations
requires only that each agrees on the value, not on the byte
sequence that represents it.
JMD defines four document modes (data, query, schema, delete)
distinguished by the root heading marker. Only data documents are
in bijection with JSON values; query, schema, and delete documents
carry application-interpreted expressions as string field values
and are intended for use by consuming applications that understand
those conventions.
Line-ending handling (Specification Section 11.2): canonical form
uses "\n" (LF). A conforming parser accepts "\r\n" by consuming the
"\r" as part of the line terminator; a "\r" not followed by "\n" is
a parse error. A single leading U+FEFF (byte order mark) is
consumed and ignored; generators never emit one.
Published specification:
JMD Specification v0.3.5, available at:
https://github.com/ostermeyer/jmd-spec/blob/main/jmd-spec-v0_3.md
A companion proposal for HTTP integration is available at:
https://github.com/ostermeyer/jmd-spec/blob/main/jmd-over-http.md
An Internet-Draft describing JMD is available in the IETF
Datatracker:
draft-ostermeyer-jmd-00
https://datatracker.ietf.org/doc/draft-ostermeyer-jmd/
This registration request should be treated as provisional until
the Internet-Draft is published as an RFC, at which point the
registration can be promoted under the Specification Required or
Standards Action procedures.
Applications that use this media type:
- MCP (Model Context Protocol) servers for LLM tool integration
- REST APIs with LLM agent clients
- Streaming data pipelines with line-level event processing
- LLM-generated structured output in agentic workflows
- Service-to-service data exchange as a JSON alternative
- Configuration files for LLM-native tooling
Fragment identifier considerations:
None defined by this specification. A future revision of the JMD
specification may define fragment identifiers for addressing
specific elements within a JMD document (field paths, heading
identifiers, or similar).
Additional information:
Deprecated alias names for this type: None
Magic number(s): None
File extension(s): .jmd
Macintosh file type code(s): TEXT
Person & email address to contact for further information:
Andreas Ostermeyer <[email protected]>
Intended usage:
COMMON
Restrictions on usage:
None
Author:
Andreas Ostermeyer <[email protected]>
Change controller:
Andreas Ostermeyer <[email protected]>
Upon publication of a Standards-Track Internet-Draft for JMD, the
change controller will become the IETF.
Provisional registration?
Yes
Thank you again for the careful review.
Best regards,
Andreas Ostermeyer
[email protected]
On Mon, 29 Jun 2026 13:19 (+0000), HANSEN, TONY L <[email protected]> wrote:
> As a provisional registration, the form below appears to be complete. There=
is no internet-draft yet corresponding to the document in GitHub. The regist=
ration template is also partially replicated in https://github.com/ostermeyer=
/jmd-spec/blob/main/jmd-over-http.md.
>
> Question: could text/markdown be used in its place?
>
>
>
> *
> Tony
>
> From: Andreas Ostermeyer <[email protected]>
> Date: Monday, May 11, 2026 at 12:17 PM
> To: [email protected] <[email protected]>
> Subject: [media-types] Request for registration: application/jmd (provision=
al)
>
> This Message is From an Unknown Sender
> The message sender does not frequently correspond with AT&T.
>
>
> To: [email protected]
> Subject: Request for registration: application/jmd (provisional)
>
> Dear IANA Media Types Reviewers,
>
> I am requesting the provisional registration of the media type
> "application/jmd" for JMD (JSON Markdown), a text-based structured data
> format. The registration template follows below, per RFC 6838 =C2=A75.6.
>
> Type name:
> application
>
> Subtype name:
> jmd
>
> Required parameters:
> None
>
> Optional parameters:
> charset:
> A charset parameter indicating the character encoding of the
> document. The only supported charset is "utf-8"; this is also
> the default when the parameter is omitted. Receivers MAY reject
> any other value with a 415 Unsupported Media Type response (for
> HTTP transport) or an equivalent error condition.
>
> version:
> An optional parameter carrying the JMD Specification version
> targeted by the document (e.g., "0.3.2"). When omitted, the
> receiver SHOULD assume the latest stable JMD specification
> version it supports.
>
> Encoding considerations:
> JMD is a text format and MUST be encoded as UTF-8 (RFC 3629).
> Documents consisting entirely of ASCII characters are 7-bit safe;
> documents containing non-ASCII UTF-8 byte sequences require 8-bit
> transport. Content-Transfer-Encoding values such as "base64" or
> "quoted-printable" are permitted for transport systems that require
> 7-bit encoding (such as historical e-mail), but are neither
> necessary nor recommended for modern HTTP or MCP transport.
>
> Security considerations:
> JMD inherits the security posture of "application/json". Specific
> considerations:
>
> 1. Injection into downstream rendering contexts. JMD string
> content is literal data, but documents may contain characters
> that are structurally significant in downstream contexts
> (HTML, SQL, shell). Receivers that render JMD content into
> such contexts MUST apply the appropriate escaping. This is
> identical to the JSON situation and is not specific to JMD.
>
> 2. Parser resource consumption. A conforming JMD parser processes
> documents in O(n) time and O(d) stack depth, where n is the
> document length in bytes and d is the maximum heading depth.
> Implementations SHOULD enforce a practical bound on d (a
> reasonable default is 32) to prevent stack exhaustion from
> adversarial inputs. Line length, blockquote length, and field
> count have no inherent bound in the grammar, and
> implementations SHOULD impose application-specific limits
> consistent with their memory budget.
>
> 3. Content confusion with Markdown. JMD and conventional Markdown
> share a syntactic subset (headings, bullets, blockquotes).
> A receiver that renders a JMD document as Markdown will produce
> a document that is technically well-formed but semantically
> nonsensical (data fields become apparent section headings and
> bullet lists). Implementations MUST dispatch on the declared
> Content-Type and not on file content sniffing.
>
> 4. No active content. JMD has no scripting, no template
> expansion, no external reference resolution, no schema
> validation directives, and no anchor/alias mechanism. Parsing
> a JMD document does not trigger network access, code
> execution, or arbitrary I/O. This is identical to the JSON
> security model.
>
> 5. Privacy. JMD documents are opaque structured data. They do not
> carry fragment identifiers, external references, or embedded
> URIs that are interpreted implicitly by a conforming parser.
> Any URI-valued fields are application-level data; no JMD
> parser is required to follow them.
>
> 6. Streaming parse semantics. JMD is line-oriented and every
> completed line is independently parseable. This means that a
> partial JMD document may be partially processed by a receiver
> before the full document has arrived. Implementations that act
> on streaming data before the document is complete MUST ensure
> that such actions are safe under truncation (for example, a
> database write that commits only when the document terminator
> is observed).
>
> Interoperability considerations:
> JMD is defined such that every valid data document is in bijection
> with a JSON value: parsing JMD yields a JSON value; serializing a
> JSON value yields a JMD document; and the roundtrip
> JMD -> JSON -> JMD preserves the value up to canonical
> normalization (key ordering and number formatting variations
> permitted by RFC 8259).
>
> Multiple valid JMD representations may exist for the same JSON
> value. This is by design and matches JSON's own freedom in object
> key ordering. Interoperability between JMD implementations
> requires only that each agrees on the value, not on the byte
> sequence that represents it.
>
> JMD defines four document modes (data, query, schema, delete)
> distinguished by the root heading marker. Only data documents are
> in bijection with JSON values; query, schema, and delete documents
> carry application-interpreted expressions as string field values
> and are intended for use by consuming applications that understand
> those conventions.
>
> Line-ending handling: a conforming parser accepts "\n", "\r\n",
> and "\r" as line terminators. Canonical form uses "\n".
>
> Published specification:
> JMD Specification v0.3.2, available at:
> https://urldefense.com/v3/__https://github.com/ostermeyer/jmd-spec/=
blob/main/jmd-spec-v0_3.md__;!!BhdT!nmhxgfWlg3uMy-DbrfrJHUmZQORi_Z7RKcBeNCIme=
vGtaScNZ-Tdew-DyhK155A3Qgg0EPAK81bOHKs$
>
> A companion proposal for HTTP integration is available at:
> https://urldefense.com/v3/__https://github.com/ostermeyer/jmd-spec/=
blob/main/jmd-over-http.md__;!!BhdT!nmhxgfWlg3uMy-DbrfrJHUmZQORi_Z7RKcBeNCIme=
vGtaScNZ-Tdew-DyhK155A3Qgg0EPAKhNr-Uwk$
>
> An Internet-Draft describing JMD is in preparation and will be
> submitted to the IETF Datatracker. This registration request
> should be treated as provisional until the Internet-Draft is
> published, at which point the registration can be promoted under
> the Specification Required or Standards Action procedures.
>
> Applications that use this media type:
> - MCP (Model Context Protocol) servers for LLM tool integration
> - REST APIs with LLM agent clients
> - Streaming data pipelines with line-level event processing
> - LLM-generated structured output in agentic workflows
> - Service-to-service data exchange as a JSON alternative
> - Configuration files for LLM-native tooling
>
> Fragment identifier considerations:
> None defined by this specification. A future revision of the JMD
> specification may define fragment identifiers for addressing
> specific elements within a JMD document (field paths, heading
> identifiers, or similar).
>
> Additional information:
> Deprecated alias names for this type: None
> Magic number(s): None
> File extension(s): .jmd
> Macintosh file type code(s): TEXT
>
> Person & email address to contact for further information:
> Andreas Ostermeyer <[email protected]>
>
> Intended usage:
> COMMON
>
> Restrictions on usage:
> None
>
> Author:
> Andreas Ostermeyer <[email protected]>
>
> Change controller:
> Andreas Ostermeyer <[email protected]>
>
> Upon publication of a Standards-Track Internet-Draft for JMD, the
> change controller will become the IETF.
>
> Provisional registration?
> Yes
>
> Thank you for your consideration.
>
> Best regards,
> Andreas Ostermeyer
> [email protected]
>
> _______________________________________________
> media-types mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
---
*This email was sent by an AI assistant using [jmd-mcp-mail](https://github.c=
om/ostermeyer/jmd-mcp-mail).*
--===============4986018940930852947==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
<p>Dear Tony,</p>
<p>Thank you for the review and for the three points you raised. In order:</p>
<ol>
<li>"Could text/markdown be used in its place?" -- No, for two<br />
independent reasons.</li>
</ol>
<p>First, the RFC 6838 category. Section 4.2.1 defines text/<em> for content<=
br />
that is "principally textual in form" and usefully readable without<br />
software interpreting it; Section 4.2.5 defines application/</em> for data<br=
/>
to be processed by an application program before it is usable. JMD is a<br />
structured data format whose primary consumers are programs and LLM<br />
agents; its specification is explicit that Markdown syntax was chosen<br />
for model affinity, not for human readability. This matches the<br />
precedent of application/json (RFC 8259) and, more recently,<br />
application/yaml (RFC 9512) -- both human-readable plain-text formats<br />
registered under application/* for exactly this reason. RFC 7763 frames<br />
text/markdown as a writing format for prose that may be converted to<br />
HTML; that would set the wrong consumer expectation for a data<br />
interchange format.</p>
<p>Second, and more decisively: JMD documents are not in general valid<br />
CommonMark. Three of JMD's four root markers ("#!" schema, "#?" query,<br />
"#-" delete) are not ATX headings under CommonMark 4.2 (no space after<br />
the "#" sequence), and heading depth beyond six exceeds CommonMark's<br />
ATX range. A text/markdown consumer would therefore legitimately render<br />
substantial classes of JMD documents as plain prose -- precisely the<br />
content-confusion scenario our security considerations warn against.<br />
Labeling JMD text/markdown would invite that misinterpretation;<br />
labeling it application/jmd prevents it. The specification now states<br />
this non-conformance explicitly.</p>
<ol start=3D"2">
<li>
<p>Duplication of the registration template in jmd-over-http.md --<br />
acknowledged and fixed. The template is now maintained in exactly one<br />
place in the repository (iana/application-jmd.md); jmd-over-http.md<br />
section 2 has been reduced to a non-normative reference that explicitly<br />
yields to the template. The "+jmd" structured syntax suffix discussed<br />
there is now clearly marked as a separate, later registration step<br />
(RFC 6839), not part of this request.</p>
</li>
<li>
<p>Internet-Draft: this gap is now closed. draft-ostermeyer-jmd-00 has<br />
been submitted to the IETF Datatracker and is available at:</p>
<p>https://datatracker.ietf.org/doc/draft-ostermeyer-jmd/</p>
</li>
</ol>
<p>It specifies the core grammar in ABNF, the canonical parse result, the<br =
/>
four document modes, the streaming event model, security<br />
considerations, and inlines the registration template.</p>
<p>One further update: the referenced specification has just undergone a<br />
consolidation release (v0.3.5), which among other things adds a<br />
normative Security Considerations section and a normative treatment of<br />
line endings and whitespace. A revised registration template follows<br />
below. Two substantive changes relative to the May submission, both<br />
following the precedent of RFC 8259 / RFC 9512: the optional "charset"<br />
and "version" parameters have been removed (the encoding is fixed by<br />
the format, and no implementation consumed a version parameter), and<br />
the security considerations now summarize the specification's<br />
normative section.</p>
<p>Revised registration template (against Specification v0.3.5):</p>
<p>Type name:<br />
application</p>
<p>Subtype name:<br />
jmd</p>
<p>Required parameters:<br />
None</p>
<p>Optional parameters:<br />
None</p>
<p>Encoding considerations:<br />
JMD is a text format and MUST be encoded as UTF-8 (RFC 3629).<br />
Documents consisting entirely of ASCII characters are 7-bit safe;<br />
documents containing non-ASCII UTF-8 byte sequences require 8-bit<br />
transport. Content-Transfer-Encoding values such as "base64" or<br />
"quoted-printable" are permitted for transport systems that require<br />
7-bit encoding (such as historical e-mail), but are neither<br />
necessary nor recommended for modern HTTP or MCP transport.</p>
<p>Security considerations:<br />
The normative treatment is Section 24 of the JMD Specification;<br />
this template summarizes it. JMD inherits the security posture of<br />
"application/json", with one format-specific addition (item 1).</p>
<pre><code>1. Structure injection in naive generation. JMD assigns
structural meaning to line starts (headings, mode markers,
list items, frontmatter position). A generator MUST emit
untrusted content as quoted strings (RFC 8259 escaping) and
MUST NOT interpolate untrusted text into bare-value, key,
label, or frontmatter position (Specification Section 24.1).
A JMD byte sequence contains exactly one document
(Specification Section 18.0); an injected root heading or
mode marker mid-document therefore produces a parse error
rather than a second, potentially destructive document.
2. Injection into downstream rendering contexts. JMD string
content is literal data, but documents may contain characters
that are structurally significant in downstream contexts
(HTML, SQL, shell). Receivers that render JMD content into
such contexts MUST apply the appropriate escaping. This is
identical to the JSON situation and is not specific to JMD.
3. Parser resource consumption. A conforming JMD parser processes
documents in O(n) time and O(d) stack depth, where n is the
document length in bytes and d is the maximum heading depth.
The grammar itself places no bound on depth, line length,
blockquote length, or field count; implementations SHOULD
enforce practical, configurable bounds (a reasonable default
depth bound is 32) to prevent stack exhaustion and memory
abuse from adversarial inputs. Rejecting a document that
exceeds a resource bound is a resource-limit error, not a
conformance violation (Specification Section 24.3).
4. Content confusion with Markdown. JMD and conventional Markdown
share surface syntax, but JMD is not guaranteed to be valid
CommonMark: heading depth beyond six and the mode markers
"#!", "#?", "#-" are not ATX headings. A receiver that
renders a JMD document as Markdown will produce misleading
output. Implementations MUST dispatch on the declared
Content-Type and not on file content sniffing.
5. No active content. JMD has no scripting, no template
expansion, no external reference resolution, no schema
validation directives, and no anchor/alias mechanism. Parsing
a JMD document does not trigger network access, code
execution, or arbitrary I/O. This is identical to the JSON
security model.
6. Privacy. JMD documents are opaque structured data. They do not
carry fragment identifiers, external references, or embedded
URIs that are interpreted implicitly by a conforming parser.
Any URI-valued fields are application-level data; no JMD
parser is required to follow them.
7. Streaming parse semantics. JMD is line-oriented and every
completed line is independently parseable, and each framing
unit carries exactly one document (Specification Section
18.0). A partial JMD document may be partially processed by a
receiver before the full document has arrived. Implementations
that act on streaming data before the document is complete
MUST ensure that such actions are safe under truncation (for
example, a database write that commits only when the framing
unit terminates cleanly).
</code></pre>
<p>Interoperability considerations:<br />
JMD is defined such that every valid data document is in bijection<br />
with a JSON value: parsing JMD yields a JSON value; serializing a<br />
JSON value yields a JMD document; and the roundtrip<br />
JMD -> JSON -> JMD preserves the value up to canonical<br />
normalization (key ordering and number formatting variations<br />
permitted by RFC 8259).</p>
<pre><code>Multiple valid JMD representations may exist for the same JSON
value. This is by design and matches JSON's own freedom in object
key ordering. Interoperability between JMD implementations
requires only that each agrees on the value, not on the byte
sequence that represents it.
JMD defines four document modes (data, query, schema, delete)
distinguished by the root heading marker. Only data documents are
in bijection with JSON values; query, schema, and delete documents
carry application-interpreted expressions as string field values
and are intended for use by consuming applications that understand
those conventions.
Line-ending handling (Specification Section 11.2): canonical form
uses "\n" (LF). A conforming parser accepts "\r\n" by consuming the
"\r" as part of the line terminator; a "\r" not followed by "\n" is
a parse error. A single leading U+FEFF (byte order mark) is
consumed and ignored; generators never emit one.
</code></pre>
<p>Published specification:<br />
JMD Specification v0.3.5, available at:<br />
https://github.com/ostermeyer/jmd-spec/blob/main/jmd-spec-v0_3.md</p>
<pre><code>A companion proposal for HTTP integration is available at:
https://github.com/ostermeyer/jmd-spec/blob/main/jmd-over-http.md
An Internet-Draft describing JMD is available in the IETF
Datatracker:
draft-ostermeyer-jmd-00
https://datatracker.ietf.org/doc/draft-ostermeyer-jmd/
This registration request should be treated as provisional until
the Internet-Draft is published as an RFC, at which point the
registration can be promoted under the Specification Required or
Standards Action procedures.
</code></pre>
<p>Applications that use this media type:<br />
- MCP (Model Context Protocol) servers for LLM tool integration<br />
- REST APIs with LLM agent clients<br />
- Streaming data pipelines with line-level event processing<br />
- LLM-generated structured output in agentic workflows<br />
- Service-to-service data exchange as a JSON alternative<br />
- Configuration files for LLM-native tooling</p>
<p>Fragment identifier considerations:<br />
None defined by this specification. A future revision of the JMD<br />
specification may define fragment identifiers for addressing<br />
specific elements within a JMD document (field paths, heading<br />
identifiers, or similar).</p>
<p>Additional information:<br />
Deprecated alias names for this type: None<br />
Magic number(s): None<br />
File extension(s): .jmd<br />
Macintosh file type code(s): TEXT</p>
<p>Person & email address to contact for further information:<br />
Andreas Ostermeyer <a href=3D"mailto:	=
7;ndreas@osterm=
;eyer.de">andrea=
;s@ostermeyer.=
de</a></p>
<p>Intended usage:<br />
COMMON</p>
<p>Restrictions on usage:<br />
None</p>
<p>Author:<br />
Andreas Ostermeyer <a href=3D"mailto:	=
7;ndreas@osterm=
;eyer.de">andrea=
;s@ostermeyer.=
de</a></p>
<p>Change controller:<br />
Andreas Ostermeyer <a href=3D"mailto:	=
7;ndreas@osterm=
;eyer.de">andrea=
;s@ostermeyer.=
de</a></p>
<pre><code>Upon publication of a Standards-Track Internet-Draft for JMD, the
change controller will become the IETF.
</code></pre>
<p>Provisional registration?<br />
Yes</p>
<p>Thank you again for the careful review.</p>
<p>Best regards,<br />
Andreas Ostermeyer<br />
[email protected]</p>
<p>On Mon, 29 Jun 2026 13:19 (+0000), HANSEN, TONY L <a href=3D"ma&#=
105;lto:tony@att.=
;com">tony@att.c&=
#111;m</a> wrote:</p>
<blockquote>
<p>As a provisional registration, the form below appears to be complete. Ther=
e is no internet-draft yet corresponding to the document in GitHub. The regis=
tration template is also partially replicated in https://github.com/ostermeye=
r/jmd-spec/blob/main/jmd-over-http.md.</p>
<p>Question: could text/markdown be used in its place?</p>
<p>*<br />
Tony</p>
<p>From: Andreas Ostermeyer <a href=3D"mailto=
8;andreas@oster=
meyer.de">andre=
;as@ostermeyer=
.de</a><br />
Date: Monday, May 11, 2026 at 12:17 PM<br />
To: [email protected] <a href=3D"mailto:&=
#109;edia-types@i	=
7;na.org">media-t=
;ypes@iana.org</=
a><br />
Subject: [media-types] Request for registration: application/jmd (provisional=
)</p>
<p>This Message is From an Unknown Sender<br />
The message sender does not frequently correspond with AT&T.</p>
<p>To: [email protected]<br />
Subject: Request for registration: application/jmd (provisional)</p>
<p>Dear IANA Media Types Reviewers,</p>
<p>I am requesting the provisional registration of the media type<br />
"application/jmd" for JMD (JSON Markdown), a text-based structured data<br />
format. The registration template follows below, per RFC 6838 =C2=A75.6.</p>
<p>Type name:<br />
application</p>
<p>Subtype name:<br />
jmd</p>
<p>Required parameters:<br />
None</p>
<p>Optional parameters:<br />
charset:<br />
A charset parameter indicating the character encoding of the<br />
document. The only supported charset is "utf-8"; this is also<br />
the default when the parameter is omitted. Receivers MAY reject<br />
any other value with a 415 Unsupported Media Type response (for<br />
HTTP transport) or an equivalent error condition.</p>
<pre><code>version:
An optional parameter carrying the JMD Specification version
targeted by the document (e.g., "0.3.2"). When omitted, the
receiver SHOULD assume the latest stable JMD specification
version it supports.
</code></pre>
<p>Encoding considerations:<br />
JMD is a text format and MUST be encoded as UTF-8 (RFC 3629).<br />
Documents consisting entirely of ASCII characters are 7-bit safe;<br />
documents containing non-ASCII UTF-8 byte sequences require 8-bit<br />
transport. Content-Transfer-Encoding values such as "base64" or<br />
"quoted-printable" are permitted for transport systems that require<br />
7-bit encoding (such as historical e-mail), but are neither<br />
necessary nor recommended for modern HTTP or MCP transport.</p>
<p>Security considerations:<br />
JMD inherits the security posture of "application/json". Specific<br />
considerations:</p>
<pre><code>1. Injection into downstream rendering contexts. JMD string
content is literal data, but documents may contain characters
that are structurally significant in downstream contexts
(HTML, SQL, shell). Receivers that render JMD content into
such contexts MUST apply the appropriate escaping. This is
identical to the JSON situation and is not specific to JMD.
2. Parser resource consumption. A conforming JMD parser processes
documents in O(n) time and O(d) stack depth, where n is the
document length in bytes and d is the maximum heading depth.
Implementations SHOULD enforce a practical bound on d (a
reasonable default is 32) to prevent stack exhaustion from
adversarial inputs. Line length, blockquote length, and field
count have no inherent bound in the grammar, and
implementations SHOULD impose application-specific limits
consistent with their memory budget.
3. Content confusion with Markdown. JMD and conventional Markdown
share a syntactic subset (headings, bullets, blockquotes).
A receiver that renders a JMD document as Markdown will produce
a document that is technically well-formed but semantically
nonsensical (data fields become apparent section headings and
bullet lists). Implementations MUST dispatch on the declared
Content-Type and not on file content sniffing.
4. No active content. JMD has no scripting, no template
expansion, no external reference resolution, no schema
validation directives, and no anchor/alias mechanism. Parsing
a JMD document does not trigger network access, code
execution, or arbitrary I/O. This is identical to the JSON
security model.
5. Privacy. JMD documents are opaque structured data. They do not
carry fragment identifiers, external references, or embedded
URIs that are interpreted implicitly by a conforming parser.
Any URI-valued fields are application-level data; no JMD
parser is required to follow them.
6. Streaming parse semantics. JMD is line-oriented and every
completed line is independently parseable. This means that a
partial JMD document may be partially processed by a receiver
before the full document has arrived. Implementations that act
on streaming data before the document is complete MUST ensure
that such actions are safe under truncation (for example, a
database write that commits only when the document terminator
is observed).
</code></pre>
<p>Interoperability considerations:<br />
JMD is defined such that every valid data document is in bijection<br />
with a JSON value: parsing JMD yields a JSON value; serializing a<br />
JSON value yields a JMD document; and the roundtrip<br />
JMD -> JSON -> JMD preserves the value up to canonical<br />
normalization (key ordering and number formatting variations<br />
permitted by RFC 8259).</p>
<pre><code>Multiple valid JMD representations may exist for the same JSON
value. This is by design and matches JSON's own freedom in object
key ordering. Interoperability between JMD implementations
requires only that each agrees on the value, not on the byte
sequence that represents it.
JMD defines four document modes (data, query, schema, delete)
distinguished by the root heading marker. Only data documents are
in bijection with JSON values; query, schema, and delete documents
carry application-interpreted expressions as string field values
and are intended for use by consuming applications that understand
those conventions.
Line-ending handling: a conforming parser accepts "\n", "\r\n",
and "\r" as line terminators. Canonical form uses "\n".
</code></pre>
<p>Published specification:<br />
JMD Specification v0.3.2, available at:<br />
https://urldefense.com/v3/<strong>https://github.com/ostermeyer/jmd-s=
pec/blob/main/jmd-spec-v0_3.md</strong>;!!BhdT!nmhxgfWlg3uMy-DbrfrJHUmZQORi_Z=
7RKcBeNCImevGtaScNZ-Tdew-DyhK155A3Qgg0EPAK81bOHKs$</p>
<pre><code>A companion proposal for HTTP integration is available at:
https://urldefense.com/v3/__https://github.com/ostermeyer/jmd-spec/blob/m=
ain/jmd-over-http.md__;!!BhdT!nmhxgfWlg3uMy-DbrfrJHUmZQORi_Z7RKcBeNCImevGtaSc=
NZ-Tdew-DyhK155A3Qgg0EPAKhNr-Uwk$
An Internet-Draft describing JMD is in preparation and will be
submitted to the IETF Datatracker. This registration request
should be treated as provisional until the Internet-Draft is
published, at which point the registration can be promoted under
the Specification Required or Standards Action procedures.
</code></pre>
<p>Applications that use this media type:<br />
- MCP (Model Context Protocol) servers for LLM tool integration<br />
- REST APIs with LLM agent clients<br />
- Streaming data pipelines with line-level event processing<br />
- LLM-generated structured output in agentic workflows<br />
- Service-to-service data exchange as a JSON alternative<br />
- Configuration files for LLM-native tooling</p>
<p>Fragment identifier considerations:<br />
None defined by this specification. A future revision of the JMD<br />
specification may define fragment identifiers for addressing<br />
specific elements within a JMD document (field paths, heading<br />
identifiers, or similar).</p>
<p>Additional information:<br />
Deprecated alias names for this type: None<br />
Magic number(s): None<br />
File extension(s): .jmd<br />
Macintosh file type code(s): TEXT</p>
<p>Person & email address to contact for further information:<br />
Andreas Ostermeyer <a href=3D"mailto:	=
7;ndreas@osterm=
;eyer.de">andrea=
;s@ostermeyer.=
de</a></p>
<p>Intended usage:<br />
COMMON</p>
<p>Restrictions on usage:<br />
None</p>
<p>Author:<br />
Andreas Ostermeyer <a href=3D"mailto:	=
7;ndreas@osterm=
;eyer.de">andrea=
;s@ostermeyer.=
de</a></p>
<p>Change controller:<br />
Andreas Ostermeyer <a href=3D"mailto:	=
7;ndreas@osterm=
;eyer.de">andrea=
;s@ostermeyer.=
de</a></p>
<pre><code>Upon publication of a Standards-Track Internet-Draft for JMD, the
change controller will become the IETF.
</code></pre>
<p>Provisional registration?<br />
Yes</p>
<p>Thank you for your consideration.</p>
<p>Best regards,<br />
Andreas Ostermeyer<br />
[email protected]</p>
<hr />
<p>media-types mailing list -- [email protected]<br />
To unsubscribe send an email to [email protected]</p>
</blockquote>
<hr />
<p><em>This email was sent by an AI assistant using <a href=3D"https://github=
.com/ostermeyer/jmd-mcp-mail">jmd-mcp-mail</a>.</em></p>
--===============4986018940930852947==--
--===============0369719569351588888==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWVkaWEtdHlw
ZXMgbWFpbGluZyBsaXN0IC0tIG1lZGlhLXR5cGVzQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNl
bmQgYW4gZW1haWwgdG8gbWVkaWEtdHlwZXMtbGVhdmVAaWV0Zi5vcmcK
--===============0369719569351588888==--