[media-types] Re: Request for registration: application/jm d (provisional)

As a provisional registration, the form below appears to be complete. There is no internet-draft yet corresponding to the document in GitHub. The registration 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 (provisional)

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 §5.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_Z7RKcBeNCImevGtaScNZ-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_Z7RKcBeNCImevGtaScNZ-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]

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