From 9c105762c1a36486906fefb467a5ceda813823e1 Mon Sep 17 00:00:00 2001 From: "Jonathan D.A. Jewell" <6759885+hyperpolymath@users.noreply.github.com> Date: Mon, 14 Sep 2026 18:30:45 +0100 Subject: [PATCH 1/2] docs(iana): prepare the application/vnd.deed media type registration MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit There was no registration document for the DEED media type anywhere in the estate — verified 2026-09-14 across standards, a2ml, deed-ecosystem and k9-ecosystem. application/vnd.a2ml and application/vnd.k9 both have one; deed, the format that supersedes a2ml, had none. Derived from those two. Nothing in it is invented: every normative claim is taken from deed/spec/DEED-GRAMMAR-SPEC.adoc or deed/spec/abnf/deed.abnf as they stand on main. Decisions and where they come from: - Subtype `vnd.deed`, no structured syntax suffix. Not a judgement call — DEED-GRAMMAR-SPEC.adoc:7 already declares `:media-type: application/vnd.deed` normatively, and it matches the reasoning application/vnd.k9 already records for dropping `+nickel` (RFC 6838 Section 4.2.8: unregistered suffixes SHOULD NOT be used). - Encoding `8bit`, not `binary` as vnd.a2ml uses. vnd.a2ml is binary because of its @opaque payload construct. DEED has no such construct: grep for opaque/include/eval across deed.abnf returns 0 against a positive control of 28 ABNF rules. - The four head forms, the filename dispatch table and the exact-stem-first rule are transcribed from deed.abnf rather than restated from memory, including the constraint that in repo-file MUST NOT be "estate". - Interoperability considerations lead on the "=" hazard because that is the one this estate actually has: a large population of files bearing the ecosystem extension were written TOML-style by tooling with no grammar to consult. The ABNF states it flatly — "The only bracket is '('. A file using '=' is not a deed." — so the registration says parsers MUST reject rather than accept leniently. Deliberately NOT included: the @trust_override / @adjust_override mechanism. It is designed, but "override" occurs 0 times in DEED-GRAMMAR-SPEC.adoc at v0.1.0. A registration must describe the grammar that exists, not the one intended, so it is recorded as an open item instead — flagged because overrides are security-relevant to any processor and would require a revision if they land. Three items are left open for the owner at the end of the file, none blocking: whether to submit against a v0.1.0 DRAFT spec; the dangling `format-registrations/iana/` canonical path that vnd.a2ml and vnd.k9 both declare and which exists in no repository (0 hits, positive controls of 126/7/47/139 paths matching "k9"); and whether vnd.a2ml was ever actually filed, since if it was, deed needs a change request rather than a fresh registration. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01QNjWX2B4FffG7zqMBMui6v --- .../application-vnd.deed-registration.txt | 254 ++++++++++++++++++ 1 file changed, 254 insertions(+) create mode 100644 deed/docs/iana/application-vnd.deed-registration.txt diff --git a/deed/docs/iana/application-vnd.deed-registration.txt b/deed/docs/iana/application-vnd.deed-registration.txt new file mode 100644 index 000000000..d3e263507 --- /dev/null +++ b/deed/docs/iana/application-vnd.deed-registration.txt @@ -0,0 +1,254 @@ +IANA Media Type Registration: application/vnd.deed +========================================================= +SPDX-License-Identifier: MPL-2.0 + +Canonical copy: format-registrations/iana/deed-media-type.txt +This file is a synchronised copy for co-location with the DEED spec. + +NOTE: No structured syntax suffix is used. Per RFC 6838 Section 4.2.8, +unregistered suffixes SHOULD NOT be used, and there is no registered +suffix corresponding to the DEED s-expression surface. This +registration uses "application/vnd.deed" as the base type, matching the +`:media-type:` attribute declared normatively in DEED-GRAMMAR-SPEC.adoc +and following the same reasoning already applied to application/vnd.k9. + +Submission Date: NOT YET SUBMITTED (Revision 1, prepared 2026-09-14) +Submitted By: Jonathan D.A. Jewell + +--- + +Type name: + application + +Subtype name: + vnd.deed + +Required parameters: + None + +Optional parameters: + charset + If specified, the value MUST be "utf-8" (case-insensitive). + DEED documents are UTF-8 text (RFC 3629). + + schema-version + The value of the REQUIRED :schema-version field carried by the + document's head form. Syntax: major.minor.patch (e.g. "0.1.0"). + This parameter is advisory; the authoritative version is the + :schema-version field inside the document itself. + +Encoding considerations: + 8bit + + DEED documents are UTF-8 text. Unlike application/vnd.a2ml, DEED has + no opaque binary payload construct, so the encoding is 8bit rather + than binary. + + Line endings are LF (U+000A) by convention; parsers MUST accept + CR+LF (U+000D U+000A) as well and normalise to LF internally. + +Security considerations: + DEED is a declarative s-expression format for repository and estate + identity, provenance and praxis declarations. It is not executable + and contains no active content: the grammar admits no code block, no + include directive, no evaluation form and no opaque payload. + + DEED documents are nevertheless consumed by automated agents to make + decisions about repositories, so the following apply: + + (a) Processors MUST treat a DEED document as untrusted input and MUST + NOT grant a repository any privilege merely because its deed + asserts one. Assertions in a deed are claims, not grants. + + (b) Identity fields (:canonical-name and the head form) determine + which policy set applies to a repository. A processor that + resolves identity from the filename alone can be misled by a + renamed file; identity MUST be resolved from the document's head + form and :canonical-name together, with the filename used only as + a dispatch hint. + + (c) DEED carries attestation blocks. Implementations that verify + attestations MUST validate signature correctness against the + stated public key, timestamp freshness, and public-key trust. + Documents without attestation SHOULD be treated as unverified. + + Privacy considerations: + - DEED documents routinely contain author and maintainer identifiers + and repository URLs. Publishers SHOULD assume a deed is public. + - Deeds are designed to be read by third-party agents visiting a + repository; they SHOULD NOT carry secrets, credentials or + endpoint tokens. + +Interoperability considerations: + DEED has exactly one bracket character: "(". A file using "=" as an + assignment form is NOT a deed, regardless of extension. This is + normative and is the primary interoperability hazard in practice: a + large population of files bearing an ecosystem extension were written + in a TOML-like "key = value" form by tooling that had no grammar to + consult. Parsers MUST reject such files rather than accept them + leniently, so that the divergence surfaces at the point of authoring. + + Every head form REQUIRES a :schema-version field. A document without + one is not a conforming deed, and processors MUST NOT infer a default + version. + + Character encoding is UTF-8 (RFC 3629). A leading Byte Order Mark + (U+FEFF) is permitted but not required; parsers MUST accept and + silently consume it. + + Head-form dispatch is exact-stem-first. The literal + "estate_chora.deed" also matches the general "_chora.deed" + repo-deed pattern, and a conforming implementation MUST resolve it as + estate-deed, never as repo-deed. + +Published specification: + Primary specification (v0.1.0, DRAFT): + https://github.com/hyperpolymath/standards/blob/main/deed/spec/DEED-GRAMMAR-SPEC.adoc + + Formal grammar (ABNF): + https://github.com/hyperpolymath/standards/blob/main/deed/spec/abnf/deed.abnf + +Applications which use this media type: + - DEED validators and CI gates (the validate-action composite action) + - Repository and estate scaffolding tools + - Automated agents that visit a repository and read its declared + identity, provenance and praxis before acting + - Attestation and conformance tooling pairing DEED (which attests) + with application/vnd.k9 (which enforces) + + Reference implementation: + https://github.com/hyperpolymath/standards/tree/main/deed + +Fragment identifier considerations: + None defined at this revision. DEED documents are whole-document + declarations; no fragment identifier syntax is specified. Processors + encountering a fragment SHOULD treat it as unresolvable rather than + as an error. + +Restrictions on usage: + None + +Additional information: + + Deprecated alias names for this type: + application/vnd.a2ml + + DEED is the renamed successor to A2ML. The two are distinct + registrations; application/vnd.a2ml describes the earlier format + and is retained for historical documents. + + Magic number(s): + None. + + DEED is text-based and is identified by file extension together + with content detection: a conforming document begins with one or + more SPDX header lines, followed by "(" and one of the four head + tokens "estate-deed", "repo-deed", "estate-atlas-deed" or + "praxis-deed". The absence of "=" as an assignment form is a + reliable negative signal. + + File extension(s): + .deed + + Conforming filenames are constrained by the grammar: + estate_chora.deed -> estate-deed + ATLAS.deed -> estate-atlas-deed + _praxis.deed -> praxis-deed + _chora.deed -> repo-deed + + Macintosh file type code(s): + None + + Object Identifier(s) or OID(s): + None + +Person & email address to contact for further information: + Jonathan D.A. Jewell + j.d.a.jewell@open.ac.uk + The Open University + Milton Keynes, MK7 6AA, United Kingdom + +Intended usage: + COMMON + +Author/Change controller: + Jonathan D.A. Jewell + The Open University + j.d.a.jewell@open.ac.uk + +Provisional registration: No (Vendor-tree registration.) + +--- + +Note: "deed" is used here in its ordinary legal-instrument sense — a +signed declaration of record — and is not an acronym. No expansion +should be supplied in the registration. + +--- + +References: + +[1] RFC 6838 - Media Type Specifications and Registration Procedures + https://www.rfc-editor.org/rfc/rfc6838.html + +[2] RFC 3629 - UTF-8, a transformation format of ISO 10646 + https://www.rfc-editor.org/rfc/rfc3629.html + +[3] DEED Grammar Specification (v0.1.0, DRAFT) + https://github.com/hyperpolymath/standards/blob/main/deed/spec/DEED-GRAMMAR-SPEC.adoc + +[4] DEED ABNF grammar + https://github.com/hyperpolymath/standards/blob/main/deed/spec/abnf/deed.abnf + +[5] application/vnd.k9 registration (companion enforcement format) + https://github.com/hyperpolymath/standards/blob/main/k9-svc/docs/iana/application-vnd.k9+nickel-registration.txt + +--- + +Change Log: + +2026-09-14: Revision 1 -- initial registration prepared, derived from + the application/vnd.a2ml and application/vnd.k9 + registrations. Subtype taken from the :media-type: + attribute declared normatively in DEED-GRAMMAR-SPEC.adoc. + No structured syntax suffix, per RFC 6838 Section 4.2.8 and + consistent with the vnd.k9 decision. Encoding is 8bit + rather than binary because DEED has no opaque payload + construct. + +--- + +OPEN BEFORE SUBMISSION (owner action, not blocking this file): + + 1. The spec is v0.1.0 DRAFT. RFC 6838 permits registering against a + published specification; confirm whether to submit now against the + draft or hold until the spec is marked Stable. + + 2. "Canonical copy: format-registrations/iana/deed-media-type.txt" + is written above to match the convention the vnd.a2ml and vnd.k9 + files already declare. That directory DOES NOT EXIST in any + estate repository — verified 2026-09-14 across standards, a2ml, + deed-ecosystem and k9-ecosystem (0 hits; positive controls of + 126/7/47/139 paths matching "k9"). Both existing registrations + therefore declare themselves synchronised copies of an original + that was never created. Either create format-registrations/ as + the real canonical home for all three, or drop the line from all + three. Do not leave one fixed and two dangling. + + 3. application/vnd.a2ml was prepared with "Submission Date: + 2026-04-03 (Revision 2)" but there is no evidence in the estate + that it was ever actually filed. If it WAS filed, DEED needs a + change request against it rather than a fresh registration, and + the "Deprecated alias names" field above becomes load-bearing. + Confirm the filing status before submitting. + + 4. An override mechanism (@trust_override / @adjust_override, narrow + + named + justified + expiring + countable, loosening only) has been + designed for this family but appears NOWHERE in + DEED-GRAMMAR-SPEC.adoc at v0.1.0 — verified 2026-09-14, 0 + occurrences of "override" in the spec against 28 ABNF rules. It is + therefore deliberately absent from the Security considerations + above, which describe only what the registered grammar actually + admits. If overrides land in the normative grammar, this + registration needs a revision, because an override construct is + security-relevant to any processor consuming a deed. From ea22876b632d7b20e1361c3be88bd9bcbfcbe093 Mon Sep 17 00:00:00 2001 From: "Jonathan D.A. Jewell" <6759885+hyperpolymath@users.noreply.github.com> Date: Mon, 14 Sep 2026 22:00:14 +0100 Subject: [PATCH 2/2] =?UTF-8?q?docs(iana):=20apply=20owner=20rulings=20?= =?UTF-8?q?=E2=80=94=20provisional=20filing,=20fresh=20registration,=20A2M?= =?UTF-8?q?L=20expansion?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Five rulings of 2026-09-14, applied across every media-type registration in this repository so that no two layers disagree. 1. FILE PROVISIONALLY, THEN RE-FILE. The spec is at v0.1.0 DRAFT and RFC 6838 permits registering against a published specification either way. The ruling is to claim the subtype name NOW with a provisional registration and re-file a full one once the grammar is marked Stable — the point of filing is to lock the name down, and an unclaimed vnd.deed is the risk being managed. "Provisional registration" changes from No to Yes and states what the re-filing is expected to change (specification reference and Security considerations only; name, encoding and fragment semantics are settled). 2. "A2ML" EXPANDS TO "Attestation Markup Language". Three repositories each carried a different expansion — Attested Agent Markup Language (deed-core), Attestation Markup Language (deed-ecosystem), Annotated Markup Language (standards). The deed-ecosystem reading is canonical for every historical reference: dropping "agent" makes the superseded format a general attestation format rather than an agent-specific one, which matches what DEED actually became. The expansion is now stated where the registration explains the earlier working name. 3. application/vnd.a2ml was NEVER filed with IANA. application/vnd.deed is therefore a FRESH registration, not a change request. The "Deprecated alias names" field is corrected: vnd.a2ml is NOT a registered alias, and the unregistered string is recorded only so implementors understand its origin (MAY accept on input, MUST NOT emit). 4. The "Canonical copy: format-registrations/iana/-media-type.txt" convention is DROPPED from every registration. That location exists nowhere: not as a directory (0 hits across standards, a2ml, deed-ecosystem and k9-ecosystem, against positive controls of 126/7/47/139 paths matching "k9"), and not as a repository (hyperpolymath/format-registrations and metadatastician/format-registrations both 404, with a live positive control and a 404 negative control; no local checkout, against a control that found three "standards" checkouts by the same method). Both earlier registrations described themselves as synchronised copies of an original that was never created. The document beside the specification is now the canonical one, with no second copy to drift. NOTE: rhodium-standard-repositories/spec/ and docs/proofs/ still cite format-registrations as a real T3 repo at /var/mnt/eclipse/repos/. Those claims are now known to be false and are left for a separate sweep. 5. application-vnd.k9+nickel-registration.txt is renamed to application-vnd.k9-registration.txt. Its filename contradicted its own body, which registers bare application/vnd.k9 and explains why, citing RFC 6838 Section 4.2.8. Exactly one reference to the old filename existed and is updated in the same commit. One item remains open before submission, and it is deliberately not guessed: the @trust_override / @adjust_override mechanism is designed for this family but appears NOWHERE in the v0.1.0 grammar (0 occurrences of "override" against 28 ABNF rules), so it is absent from Security considerations, which describe only what the registered grammar admits. If overrides land normatively, this registration needs a revision — an override construct is security-relevant to any processor consuming a deed. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01QNjWX2B4FffG7zqMBMui6v --- .../application-vnd.deed-registration.txt | 88 ++++++++++++------- ...xt => application-vnd.k9-registration.txt} | 4 +- 2 files changed, 59 insertions(+), 33 deletions(-) rename k9-svc/docs/iana/{application-vnd.k9+nickel-registration.txt => application-vnd.k9-registration.txt} (97%) diff --git a/deed/docs/iana/application-vnd.deed-registration.txt b/deed/docs/iana/application-vnd.deed-registration.txt index d3e263507..11ecd30a7 100644 --- a/deed/docs/iana/application-vnd.deed-registration.txt +++ b/deed/docs/iana/application-vnd.deed-registration.txt @@ -2,8 +2,8 @@ IANA Media Type Registration: application/vnd.deed ========================================================= SPDX-License-Identifier: MPL-2.0 -Canonical copy: format-registrations/iana/deed-media-type.txt -This file is a synchronised copy for co-location with the DEED spec. +This file is the canonical registration document for application/vnd.deed. +It lives beside the specification it registers; there is no second copy. NOTE: No structured syntax suffix is used. Per RFC 6838 Section 4.2.8, unregistered suffixes SHOULD NOT be used, and there is no registered @@ -131,11 +131,16 @@ Restrictions on usage: Additional information: Deprecated alias names for this type: - application/vnd.a2ml + None. - DEED is the renamed successor to A2ML. The two are distinct - registrations; application/vnd.a2ml describes the earlier format - and is retained for historical documents. + DEED was developed under the earlier working name "A2ML" + (Attestation Markup Language), and documents in the wild may + carry the unregistered media type string + "application/vnd.a2ml". That string was never submitted to IANA + and is NOT a registered alias of this type; it is recorded here + only so that implementors encountering it understand its origin. + Processors MAY accept it as a legacy synonym on input; they MUST + NOT emit it. Magic number(s): None. @@ -176,7 +181,16 @@ Author/Change controller: The Open University j.d.a.jewell@open.ac.uk -Provisional registration: No (Vendor-tree registration.) +Provisional registration: Yes + + Registered provisionally to establish the subtype name while the + grammar specification is at v0.1.0 DRAFT. A full registration will + be re-filed, superseding this one, once DEED-GRAMMAR-SPEC.adoc is + marked Stable. The re-filing is expected to change only the + specification reference and the Security considerations (see OPEN + item 2 below, on the override mechanism); the subtype name, encoding + and fragment semantics registered here are settled and are not + expected to change. --- @@ -201,7 +215,7 @@ References: https://github.com/hyperpolymath/standards/blob/main/deed/spec/abnf/deed.abnf [5] application/vnd.k9 registration (companion enforcement format) - https://github.com/hyperpolymath/standards/blob/main/k9-svc/docs/iana/application-vnd.k9+nickel-registration.txt + https://github.com/hyperpolymath/standards/blob/main/k9-svc/docs/iana/application-vnd.k9-registration.txt --- @@ -218,31 +232,43 @@ Change Log: --- +SETTLED BY OWNER RULING, 2026-09-14: + + * application/vnd.a2ml was NEVER filed with IANA. This is therefore + a FRESH registration, not a change request against an existing one, + and vnd.a2ml is not a registered alias. The "Deprecated alias + names" field above is written accordingly. + + * The "Canonical copy: format-registrations/iana/..." convention + declared by the vnd.a2ml and vnd.k9 files is DROPPED, in all three + files. That directory existed in no repository — verified + 2026-09-14 across standards, a2ml, deed-ecosystem and k9-ecosystem + (0 hits; positive controls of 126/7/47/139 paths matching "k9") — + so both earlier registrations described themselves as synchronised + copies of an original that was never created. The document beside + the specification is now the canonical one, with no second copy. + + * FILE PROVISIONALLY, THEN RE-FILE. The spec is v0.1.0 DRAFT, and + RFC 6838 permits registering against a published specification + either way. The ruling is to claim the subtype name NOW with a + provisional registration, and to re-file a full registration once + the grammar is marked Stable. Rationale: the point of filing is to + lock the name down, and an unclaimed vnd.deed is the risk being + managed. The "Provisional registration" field above is written + accordingly. + + * "A2ML" EXPANDS TO "Attestation Markup Language". Three repositories + each carried a different expansion — Attested Agent Markup Language + (deed-core), Attestation Markup Language (deed-ecosystem) and + Annotated Markup Language (standards). The deed-ecosystem reading + is canonical for all historical references: it drops "agent", + making the superseded format a general attestation format rather + than an agent-specific one, which matches what DEED actually became. + The other two expansions are to be corrected wherever they appear. + OPEN BEFORE SUBMISSION (owner action, not blocking this file): - 1. The spec is v0.1.0 DRAFT. RFC 6838 permits registering against a - published specification; confirm whether to submit now against the - draft or hold until the spec is marked Stable. - - 2. "Canonical copy: format-registrations/iana/deed-media-type.txt" - is written above to match the convention the vnd.a2ml and vnd.k9 - files already declare. That directory DOES NOT EXIST in any - estate repository — verified 2026-09-14 across standards, a2ml, - deed-ecosystem and k9-ecosystem (0 hits; positive controls of - 126/7/47/139 paths matching "k9"). Both existing registrations - therefore declare themselves synchronised copies of an original - that was never created. Either create format-registrations/ as - the real canonical home for all three, or drop the line from all - three. Do not leave one fixed and two dangling. - - 3. application/vnd.a2ml was prepared with "Submission Date: - 2026-04-03 (Revision 2)" but there is no evidence in the estate - that it was ever actually filed. If it WAS filed, DEED needs a - change request against it rather than a fresh registration, and - the "Deprecated alias names" field above becomes load-bearing. - Confirm the filing status before submitting. - - 4. An override mechanism (@trust_override / @adjust_override, narrow + + 1. An override mechanism (@trust_override / @adjust_override, narrow + named + justified + expiring + countable, loosening only) has been designed for this family but appears NOWHERE in DEED-GRAMMAR-SPEC.adoc at v0.1.0 — verified 2026-09-14, 0 diff --git a/k9-svc/docs/iana/application-vnd.k9+nickel-registration.txt b/k9-svc/docs/iana/application-vnd.k9-registration.txt similarity index 97% rename from k9-svc/docs/iana/application-vnd.k9+nickel-registration.txt rename to k9-svc/docs/iana/application-vnd.k9-registration.txt index 8121879d9..b9f88b488 100644 --- a/k9-svc/docs/iana/application-vnd.k9+nickel-registration.txt +++ b/k9-svc/docs/iana/application-vnd.k9-registration.txt @@ -2,8 +2,8 @@ IANA Media Type Registration: application/vnd.k9 ========================================================= SPDX-License-Identifier: MPL-2.0 -Canonical copy: format-registrations/iana/k9-media-type.txt -This file is a synchronised copy for co-location with the K9 spec. +This file is the canonical registration document for application/vnd.k9. +It lives beside the specification it registers; there is no second copy. NOTE: Earlier drafts used "application/vnd.k9+nickel" but the +nickel structured syntax suffix is not registered with IANA. Per RFC 6838