[media-types] [IANA #1449861] text/vnd.longform regist ration request

Hi Murray,

Response from the applicant:

===

Yes there is a product. It is not described in my README yet but I have an open source project https://codeberg.org/occultist/octiron, still pre-alpha,
which server renders and picks up the pieces of rendered Longform.
It is a concrete implementation of the theoretical application described in my Longform spec document.

This is part of a larger open source project I'm calling Occultist.dev that the code-bases here https://codeberg.org/occultist all support,
Octiron and Longform are primary components.

If things work out this would compete with the likes of Next.JS and other server rendereable Javascript frameworks.

Both Octiron and Occultist.dev could be considered opensource products. They are not well documented yet as content negotiation is a large part of how they work
and I wanted to lock down Longform's media type before I started documenting and promoting the solution.

Given this I think "text/vnd.longform" might be more suitable given I plan to foster a adoption around the wider project and that Octiron is publicly available, albeit not production ready.

===

Which prefix should be used here?

If vendor tree is OK, does it need any other changes?

thanks,
Amanda

On Tue Apr 14 16:03:46 2026, [email protected] wrote:
> On Mon, Apr 13, 2026 at 4:00 PM Amanda Baber via RT <
> [email protected]> wrote:
> 
> > He initially submitted this as text/longform, but it isn't associated
> > with
> > a standards organization, and he didn't think it should be
> > grandfathered.
> > He writes, "I'm a solo developer and this is all quite new to me. I'm
> > interested in what feedback I might receive on the media type but can
> > understand the vendor tree option might be the best until my ideas
> > have
> > matured and proved out a bit. Can you update to text/vnd.longform for
> > now.
> > I'll apply that change to the specification at
> > https://longform.occultist.dev."
> >
> 
> For a solo developer, perhaps the "prs" (personal) tree would be more
> appropriate?  The primary distinction between the vendor and
> personal/vanity trees appears to be that the latter registrations are
> associated with "products", though RFC 6838 doesn't strictly say they
> need
> to be commercial products.
> 
> So let's say: If the applicant is OK with the personal/vanity tree,
> this is
> approved as "text/prs.longform".  If he really wants the vendor tree,
> does
> he want to argue that there are "products" out there that use this
> media
> type?
> 
> -MSK
> 
> =====
> >
> > Name: Matthew Quinn
> >
> > Email: [email protected]
> >
> > Media type name: text
> >
> > Media subtype name: vnd.longform
> >
> > Required parameters: charset parameter is optional, UTF-8 charset is
> > the
> > default.
> >
> > Optional parameters: N/A
> >
> > Encoding considerations: 8bit
> >
> > Security considerations: Longform is used like Markdown and has all
> > the
> > security considerations of the text/markdown media type, however it
> > has a
> > broader feature set that should be considered. The following is taken
> > from
> > here: https://longform.occultist.dev/#security-considerations
> >
> > Longform is typically rendered into a HTML document, or parsed client
> > side
> > and rendered into a DOM environment. It is possible to mix untrusted
> > user
> > defined content with the original Longform markup creating the
> > possibility
> > of content injection attacks. Longform provides sanitization APIs
> > that can
> > be configured with allow lists to only allow intended markup to be
> > rendered
> > at the location the untrusted content is being embedded. Where the
> > markup
> > is in the Longform form, the Longform parser should apply the
> > sanitization
> > rules to the markup. Where HTML markup is used the parser should
> > expose
> > APIs so the sanitization rules can be enforced using the Sanitizer
> > API and
> > / or the Trusted Types API. These APIs work in a DOM environment on
> > modern
> > browsers. For server side sanitization or older browser support the
> > parser
> > would need to integrate with a sanitization library such as
> > DOMPurify.
> > Users of a Longform parser should familiarize themselves with how to
> > configure their parser to sanitize HT
> > ML content correctly in any environment the content is parsed.
> >
> 
> There's an errant line break here.
> 
> 
> > The Longform serialization rules assume the Longform document itself
> > is
> > not comprised of untrusted content. Parsers should consider exposing
> > APIs
> > to allow the same sanitization rules be applied document wide so
> > documents
> > can be constructed from multiple sources before being parsed.
> >
> > It is important for parser implementers to consider that any user
> > content
> > that is rendered into the HTML page as HTML could use the same HTML
> > ids or
> > data attributes as the ones used by the parser and could be picked up
> > by
> > the client application instead of the intended Longform fragment. So
> > it is
> > important that a parsers takes steps to ensure the data attribute
> > names
> > used are unique, maybe using values generated at the time of render.
> > Parsers are encouraged to export CSS selector strings that client
> > applications can use to rebuild the Longform documents, instead of
> > fixed
> > data-attribute naming conventions. For this reason it is also
> > preferred
> > that data attributes are used over HTML ids where user content might
> > be
> > rendered to the page even if the fragment has an embedded id.
> >
> > Application developers using Longform in the client should consider
> > the
> > affects external scripts might have on a Longform fragment if it is
> > re-attached to the DOM after state changes. Browser extensions could
> > modify
> > the fragment if it is attached to the DOM so consider performing a
> > deep
> > clone on a pristine in memory copy of the fragment instead of re-
> > using
> > previously attached fragments.
> >
> > Interoperability considerations: Longform is in development and the
> > final
> > formal syntax is not yet complete. The base media type is intended to
> > be a
> > narrow feature set intended for the purposes described in
> > https://longform.occultist.dev/#fragments. It is intended that the
> > syntax
> > and directives could be built upon by other formats and
> > considerations are
> > being made for that now.
> >
> > Published specification: https://longform.occultist.dev
> >
> > Applications which use this media: Applications that render HTML
> > documents, handle DOM state changes and maybe also render to XML and
> > MathML.
> >
> > Fragment identifier considerations: The fragment identifier is used
> > to
> > select from the available Longform fragments outputted by parsing a
> > Longform document. Fragment identifiers are currently loosely
> > described
> > here https://longform.occultist.dev/#fragments.
> >
> > Longform also supports simple templating. A fragment identifier can
> > be
> > used to apply parameters to a template using the query string format
> > following the Longform fragment's identifier.
> >
> > Restrictions on usage: None.
> >
> > Provisional registration? (standards tree only): No
> >
> > Additional information:
> >
> > 1. Deprecated alias names for this type: None
> > 2. Magic number(s): None
> > 3. File extension(s): .lf, .longform
> > 4. Macintosh file type code: TBD
> > 5. Object Identifiers: Unsure
> >
> > General Comments:
> >
> > Person to contact for further information:
> >
> > 1. Name: Matthew Quinn
> > 2. Email: [email protected]
> >
> > Intended usage: COMMON
> >
> > Author/Change controller: Matthew Quinn, [email protected]
> >

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