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..11ecd30a7 --- /dev/null +++ b/deed/docs/iana/application-vnd.deed-registration.txt @@ -0,0 +1,280 @@ +IANA Media Type Registration: application/vnd.deed +========================================================= +SPDX-License-Identifier: MPL-2.0 + +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 +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: + None. + + 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. + + 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: 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. + +--- + +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-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. + +--- + +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. 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. 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