docs(iana): apply owner rulings — provisional filing, fresh registration, A2ML expansion

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 <j.d.a.jewell@open.ac.uk>
+
+---
+
+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 "<stem>_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
+      <stem>_praxis.deed       -> praxis-deed
+      <stem>_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.

k9-svc/docs/iana/application-vnd.k9+nickel-registration.txt → 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