[media-types] Re: +md as a text/markdown suffix

I thought a bit more about this, and I think it might be a bad idea to
use +md where we could be using a parameter.
I am also suspicious of the "text" type vs "application" type given the
yaml front matter.

I would love to see something helpful done for this problem space though,
it seems like an increasingly important building block.

Setting aside what I know about how we got the current media types, I would
probably attack the problem like this:

application/agent-context;profile=okf / obsidian / ... skills / other stuff

This feels like possibly creating a big tent that nobody asked for, so you
might consider:

application/okf (or whatever other flavors)

I have a feeling that using +md would lead to many subtypes needed to carry
semantics, instead of carrying application configuration types, which I
think is what all these things are.

That being said, if we think there will be a big enough pile of these sorts
of things where consistent processing of the suffix for rendering is
helpful, even if the specific structure in the yaml or markdown is not
actually checked in the context of the configuration type, it might be
worth it.

I would be extremely cautious about the cases where the markdown or yaml
failed to parse / display for +md ... Squashing 2 media types together
creates many error cases, and with one of those media types supporting many
flavors, that risk multiplies.

Potentially triggering, but given how important markdown is for this domain
(AI Agent Context Engineering), maybe it's best we start considering the
benefits of picking a winner.

If we did register a +md or +ctx (context?), I would want to see a regular
media type defined alongside it that reduces the risks related to supported
syntax and features and change control.



On Fri, Aug 21, 2026 at 2:19 AM Paul Libbrecht <paul=
[email protected]> wrote:

> Hello list,
>
> I think that what made the success of the many markdown flavours is their
> ability to “degrade gracefully” in the eyes of end-users by showing a text
> that seems human-readable. The YAML additions aimed at the same.
>
> Maybe that can be enough for a description of the encoding? At the end it
> seems much like plain-text but with a little chance of some automatic
> processing, which is probably expected to never fail when in a display
> process, even if the user needs more cognitive resources to interpret it.
>
> Paul
>
>
> On 21 Aug 2026, at 2:37, Mark Nottingham wrote:
>
> > Registering markdown as a suffix seems to invert that -- it says "here's
> a family of formats that share semantics, but they're spelled differently
> on the wire." That's assuming that you want to accommodate all of the
> various flavours and complications of modern markdown, and not choose a
> winner.
>
>
> On 21 Aug 2026, at 0:04, Orie wrote:
>
> > Aren't there lots of flavors of markdown?
>
> _______________________________________________
> 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]