Problem
OKF defines a bundle's structure but deliberately leaves serving and discovery out of scope. Discovery layers like the ARD AI Catalog let a publisher advertise a bundle by pointing an entry at the artefact — but a catalog entry is keyed by an IANA media type. There is no media type that identifies an artefact as an OKF bundle, so a consumer can find the artefact but cannot recognise it as OKF without sniffing the contents. Every publisher ends up inventing an interim type, and they won't agree.
Proposal
Define (and eventually register) media types for an OKF bundle artefact:
application/okf-bundle — an OKF bundle, packaging-agnostic.
application/okf-bundle+gzip — a gzipped tar of the bundle tree.
application/okf-bundle+zip — a zip of the bundle tree.
A consumer that recognises any of these knows the artefact is an OKF concept tree and can ingest it per the spec (index.md progressive disclosure, per-file type front matter, log.md, references/). The +gzip/+zip structured suffixes keep the compression explicit; fall back to application/okf-bundle when packaging is irrelevant.
Worked example (real, resolvable)
We publish The Website Specification as an OKF bundle generated from our content collection: 144 check concepts + a references/ concept per cited standard, with index.md/log.md. It's served browsably and as a single tarball, and advertised through an ARD AI Catalog entry.
Today that entry uses the interim, unregistered constant application/okf-bundle+gzip, declared in one place and documented as interim so adopting a blessed type is a one-line change. Happy to be the reference adopter for whatever gets blessed.
Problem
OKF defines a bundle's structure but deliberately leaves serving and discovery out of scope. Discovery layers like the ARD AI Catalog let a publisher advertise a bundle by pointing an entry at the artefact — but a catalog entry is keyed by an IANA media type. There is no media type that identifies an artefact as an OKF bundle, so a consumer can find the artefact but cannot recognise it as OKF without sniffing the contents. Every publisher ends up inventing an interim type, and they won't agree.
Proposal
Define (and eventually register) media types for an OKF bundle artefact:
application/okf-bundle— an OKF bundle, packaging-agnostic.application/okf-bundle+gzip— a gzipped tar of the bundle tree.application/okf-bundle+zip— a zip of the bundle tree.A consumer that recognises any of these knows the artefact is an OKF concept tree and can ingest it per the spec (
index.mdprogressive disclosure, per-filetypefront matter,log.md,references/). The+gzip/+zipstructured suffixes keep the compression explicit; fall back toapplication/okf-bundlewhen packaging is irrelevant.Worked example (real, resolvable)
We publish The Website Specification as an OKF bundle generated from our content collection: 144 check concepts + a
references/concept per cited standard, withindex.md/log.md. It's served browsably and as a single tarball, and advertised through an ARD AI Catalog entry.Today that entry uses the interim, unregistered constant
application/okf-bundle+gzip, declared in one place and documented as interim so adopting a blessed type is a one-line change. Happy to be the reference adopter for whatever gets blessed.