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.

NOTE: Earlier drafts used "application/vnd.k9+nickel" but the +nickel
structured syntax suffix is not registered with IANA.  Per RFC 6838
Section 4.2.8, unregistered suffixes SHOULD NOT be used.  This
registration uses "application/vnd.k9" as the base type.

Submission Date: 2026-04-03 (Revision 2)
Submitted By: Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>

---

Type name:
  application

Subtype name:
  vnd.k9

Required parameters:
  None

Optional parameters:
  security-level
    One of "kennel", "yard", or "hunt" (case-insensitive).
    Indicates the maximum execution privilege the component requests.
    Defaults to "kennel" if absent.  This parameter is advisory; the
    authoritative security level is declared in the pedigree metadata.

  version
    K9 specification version.  Syntax: major.minor.patch (e.g., "1.0.0").

Encoding considerations:
  8bit

  K9 files are UTF-8 text using Nickel configuration language syntax.
  They begin with the ASCII magic bytes "K9!" (0x4B 0x39 0x21) at
  byte offset 0.  Line endings are LF by convention; parsers MUST
  accept CR+LF and normalise to LF.

Security considerations:
  K9 implements a tiered Leash System with three security levels:

  - Kennel (Pure Data): No execution.  Read-only.  Safe anywhere.
  - Yard (Validation Only): Nickel contract evaluation in a sandboxed
    context.  Nickel is functionally pure -- no side effects, no
    filesystem access, no network access.  Resource limits MUST be
    enforced.
  - Hunt (Full Execution): Complete must-just-nickel triad.  REQUIRES
    Ed25519 signature verification, explicit user consent, and
    containerised execution (Podman-first) where available.

  Unsigned or improperly signed Hunt-level components MUST be rejected.

  Threat mitigations: signature-gated execution, contract isolation,
  bounded Nickel evaluation, replay prevention via timestamped
  signatures, tiered privilege escalation to prevent dependability
  collapse.

  Privacy: pedigree metadata may contain author information and
  deployment targets.  Implementations SHOULD strip metadata before
  sharing across trust boundaries.

  See K9 security documentation for complete details.

Interoperability considerations:
  K9 targets multi-architecture permanence (Linux, Minix, macOS,
  Android, embedded/ASIC at Kennel level).  The must-just-nickel triad
  provides environment detection (POSIX shell), task orchestration
  (Just), and typed validation (Nickel).

  Kennel-level interop requires only magic-byte detection and metadata
  extraction.  Yard requires a Nickel evaluator.  Hunt requires Nickel,
  Just, and Ed25519 verification.

  The format is self-describing via pedigree metadata blocks.  The
  underlying syntax is Nickel (https://nickel-lang.org).

Published specification:
  K9 SVC Specification (v1.0.0-alpha):
  https://github.com/hyperpolymath/standards/blob/main/k9-svc/SPEC.adoc

  Nickel: https://nickel-lang.org/
  Just: https://just.systems/

Applications which use this media type:
  - K9 component validators and deployers (k9-scan, k9-sign)
  - CI/CD pipelines with self-validating configuration
  - Container orchestration systems (Podman-first)
  - Multi-architecture deployment tools
  - Configuration management with typed contracts
  - Edge and ASIC deployment (Kennel-level data components)
  - The Contractile CLI system (must/trust/dust/intend/k9)

  Reference implementation:
  https://github.com/hyperpolymath/standards/tree/main/k9-svc

Fragment identifier considerations:
  Dot-separated paths into the component's data structure.

  Syntax:  #<path>  where <path> is key *( "." key ),
           key = 1*( ALPHA / DIGIT / "_" / "-" )

  Examples:
    #pedigree.name       -- component name
    #config.server.port  -- nested config value

  If no key matches, user agent SHOULD treat as unresolvable (no error).

Restrictions on usage:
  None, subject to Leash System enforcement.  Hunt-level files MUST
  NOT be executed without cryptographic verification and user consent.

Additional information:

  Deprecated alias names for this type:  None
  Magic number(s):  "K9!" (0x4B 0x39 0x21) at byte offset 0
  File extension(s):  .k9, .k9.ncl
  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.)

---

References:

[1] RFC 6838 - Media Type Specifications and Registration Procedures
    https://www.rfc-editor.org/rfc/rfc6838.html

[2] RFC 8032 - Edwards-Curve Digital Signature Algorithm (EdDSA)
    https://www.rfc-editor.org/rfc/rfc8032.html

[3] K9 SVC Specification (v1.0.0-alpha)
    https://github.com/hyperpolymath/standards/blob/main/k9-svc/SPEC.adoc

[4] Nickel Configuration Language
    https://nickel-lang.org

[5] Just Command Runner
    https://just.systems

---

Change Log:

2026-01-30: Initial draft (as application/vnd.k9+nickel)
2026-03-16: Expanded security, interoperability, added vnd.k9 base type
2026-04-03: Revision 2 -- consolidated to vnd.k9 (removed unregistered
            +nickel suffix per RFC 6838 Section 4.2.8), added RFC 8032,
            corrected encoding to "8bit", added resource bounding,
            replay prevention, Podman-first, web form submission
