open-standards/wai/ietf/draft-charlot-moq-wai-packaging-00.txt

Media Over QUIC                                               D. Charlot
Internet-Draft                                       Transaction Science
Intended status: Informational                           21 October 2026
Expires: 24 April 2027


              WAI Packaging for the MOQT Streaming Format
                   draft-charlot-moq-wai-packaging-00

Abstract

   This document specifies how WAI envelopes are carried as a packaging
   of the MOQT Streaming Format (MSF) over Media over QUIC Transport
   (MOQT).  A WAI envelope names the decoding capability its payload
   needs and a fallback, and can name, by SHA-256 digest, the parameter
   set a learned decoder must hold to decode it.  This document defines
   the MSF packaging value "wai", in which every MOQT object is exactly
   one WAI envelope.  It defines track-level catalog fields that declare
   a track's capabilities, the parameter sets its objects pin, by
   digest, and the reproducibility tier of each.  It defines a staged
   form in which a base and its refinement layers travel on separate
   tracks.  It defines a receipts track that carries an Ed25519-signed
   Merkle commitment to each MOQT group's objects, and an object
   property that carries an object's receipt commitment.  It also
   registers the media type application/wai.

About This Document

   This note is to be removed before publishing as an RFC.

   The source of this document is kept with the WAI specification it
   draws on, in the directory wai/ietf of
   https://git.transaction.science/Transaction-Science/open-standards.
   The WAI extension texts it restates are cited as informative
   references in Appendix C.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.






Charlot                   Expires 24 April 2027                 [Page 1]

Internet-Draft            WAI Packaging for MSF             October 2026


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 April 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  MSF Extension . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  The WAI Envelope  . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Layout  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Manifest  . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Capability Dispatch . . . . . . . . . . . . . . . . . . .   6
     4.4.  Parameter-Set Pins  . . . . . . . . . . . . . . . . . . .   7
     4.5.  Determinism Tiers . . . . . . . . . . . . . . . . . . . .   9
   5.  Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Packaging Values  . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Track Fields  . . . . . . . . . . . . . . . . . . . . . .  11
       5.2.1.  Capabilities  . . . . . . . . . . . . . . . . . . . .  12
       5.2.2.  Determinism . . . . . . . . . . . . . . . . . . . . .  12
       5.2.3.  Receipts Fields . . . . . . . . . . . . . . . . . . .  13
     5.3.  Pinned Parameter Sets . . . . . . . . . . . . . . . . . .  13
     5.4.  Staged Tracks . . . . . . . . . . . . . . . . . . . . . .  15
   6.  Receipts  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
     6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  18
     6.2.  Content Hash  . . . . . . . . . . . . . . . . . . . . . .  18
     6.3.  Merkle Tree . . . . . . . . . . . . . . . . . . . . . . .  18
     6.4.  Energy Class Encoding . . . . . . . . . . . . . . . . . .  19
     6.5.  Group Signature . . . . . . . . . . . . . . . . . . . . .  19
       6.5.1.  Link Hash . . . . . . . . . . . . . . . . . . . . . .  20
     6.6.  Binary Forms  . . . . . . . . . . . . . . . . . . . . . .  21



Charlot                   Expires 24 April 2027                 [Page 2]

Internet-Draft            WAI Packaging for MSF             October 2026


     6.7.  The Receipts Track  . . . . . . . . . . . . . . . . . . .  21
     6.8.  Verification  . . . . . . . . . . . . . . . . . . . . . .  22
     6.9.  The WAI_RECEIPT Object Property . . . . . . . . . . . . .  24
     6.10. Relays  . . . . . . . . . . . . . . . . . . . . . . . . .  25
   7.  The codecs Parameter  . . . . . . . . . . . . . . . . . . . .  25
   8.  Implementation Status . . . . . . . . . . . . . . . . . . . .  26
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
     9.1.  Receipt Keys  . . . . . . . . . . . . . . . . . . . . . .  27
     9.2.  Replay  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     9.3.  Relay Transparency  . . . . . . . . . . . . . . . . . . .  27
     9.4.  Catalog Integrity . . . . . . . . . . . . . . . . . . . .  28
     9.5.  Parameter Sets  . . . . . . . . . . . . . . . . . . . . .  28
     9.6.  Resource Consumption  . . . . . . . . . . . . . . . . . .  28
     9.7.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  28
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29
     10.1.  MSF Packaging Values . . . . . . . . . . . . . . . . . .  29
     10.2.  MOQ Properties . . . . . . . . . . . . . . . . . . . . .  29
     10.3.  Media Type application/wai . . . . . . . . . . . . . . .  29
     10.4.  Capability Strings . . . . . . . . . . . . . . . . . . .  30
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  30
     11.2.  Informative References . . . . . . . . . . . . . . . . .  32
   Appendix A.  Catalog Example  . . . . . . . . . . . . . . . . . .  33
   Appendix B.  Refusal Reasons  . . . . . . . . . . . . . . . . . .  35
   Appendix C.  Correspondence with the WAI Texts  . . . . . . . . .  35
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  36

1.  Introduction

   MOQT [MOQT] moves objects, in groups, on tracks, and orders them by
   priority; it does not say what an object means.  MSF [MSF] says what
   objects mean: its catalog names, for each track, a "packaging" that
   fixes how the track's objects are encapsulated, and a sibling
   document can add a packaging value together with the catalog fields
   it needs [CMSF].

   WAI [WAI] is a container and capability-dispatch format.  A WAI
   envelope carries a manifest and a payload.  The manifest names the
   capability a receiver needs to decode the payload, a fallback
   capability for a receiver that lacks it, and, for a capability that
   decodes against a parameter set (for example the weights of a learned
   decoder), a pin: the SHA-256 digest of that set.  A receiver that
   cannot verify the pin does not decode the payload against another
   set.  WAI defines no transport.

   This document defines how WAI envelopes are carried as MSF objects.
   Its aims are:




Charlot                   Expires 24 April 2027                 [Page 3]

Internet-Draft            WAI Packaging for MSF             October 2026


   *  A receiver can decide before it subscribes whether it can decode a
      track: which capabilities the track's objects use, which parameter
      sets they pin, by digest, and which reproducibility tier each is
      offered at (Section 5).

   *  A receiver can establish that each object it received is the one
      the publisher's key committed to, at that MOQT group and object,
      and can account for an object it did not receive (Section 6).

   *  A relay needs no knowledge of WAI.  Every rule here uses MOQT's
      own objects, groups, priorities, properties and delivery timeouts,
      and a relay treats every payload as opaque, as Section 7.8 of
      [MOQT] requires.

   This document changes nothing in MOQT or MSF.  It defines no
   transport and no codec.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Section numbers of [MOQT] and [MSF] are those of the revisions
   referenced.  Where a later revision of either moves or changes what
   is cited, that revision governs and the citation is what changes.

   Envelope:  A WAI container in the form of Section 4.1, beginning with
      the four bytes "WAI1".

   Capability:  A string naming how a payload is decoded, such as
      "wai.image.png" or "wai.neural.int_hyper".  Capabilities are
      registered by [WAI], Section 5.

   Parameter set:  Every byte, other than the payload, that a
      capability's decode reads and that its output depends on:
      networks, entropy tables, normative constants.  A receiver holds
      it; an envelope never carries it.

   Pin:  A manifest member that names a parameter set by the SHA-256
      digest of its bytes (Section 4.4).

   Tier:  A reproducibility guarantee of a decode (Section 4.5).

   Publisher, receiver, relay:  The MOQT original publisher of a track;




Charlot                   Expires 24 April 2027                 [Page 4]

Internet-Draft            WAI Packaging for MSF             October 2026


      an endpoint that subscribes to a track and decodes its objects;
      and an MOQT relay.

   Stage set:  A base and the refinement layers that improve it,
      delivered as staged delivery (Section 5.4).

   Link hash:  The identity of a group receipt (Section 6.5.1).

   In byte layouts, "||" is concatenation; u8, u32_be and u64_be are
   unsigned integers of 1, 4 and 8 bytes in network byte order; u32_le
   is a 4-byte unsigned integer in little-endian order; a string is
   u32_be(length) || its UTF-8 bytes; and a quoted domain string such as
   "moq-jwp:object\x01" is its ASCII bytes followed by the single byte
   that \x01 denotes.  BLAKE3 is the 32-byte output of the BLAKE3 hash
   [BLAKE3], and SHA-256 is that of [SHS].  Digests written in JSON are
   64 lowercase hexadecimal digits.

3.  MSF Extension

   All of the specifications, requirements and terminology defined in
   [MSF] apply to implementations of this extension unless explicitly
   noted otherwise in this document.  Tracks of the packaging defined
   here can share a catalog, and a render group, with tracks of any
   other packaging.

4.  The WAI Envelope

4.1.  Layout

   +--------+---------+---------------+-------------+---------+
   | "WAI1" | man_len | manifest      | payload_len | payload |
   | 4 B    | u32_le  | man_len bytes | u32_le      |         |
   +--------+---------+---------------+-------------+---------+

   *  A reader MUST refuse bytes whose first four are not "WAI1" (0x57
      0x41 0x49 0x31).

   *  The manifest is a JSON object [RFC8259] in UTF-8, serialized with
      no insignificant whitespace.  No member name occurs twice in one
      object, at any depth.  A member that must be an integer is written
      as one: digits, with a minus sign only before a non-zero value,
      and no fraction or exponent.

   *  The payload's interpretation is fixed by the capability that
      decodes it (Section 4.3) and, for a capability that decodes
      against a parameter set, by that set.





Charlot                   Expires 24 April 2027                 [Page 5]

Internet-Draft            WAI Packaging for MSF             October 2026


   *  A reader MUST NOT refuse a manifest for its size while it is at
      most 2^27 bytes long, nests arrays and objects at most 127 deep
      (the manifest object counting as one), and holds at most 2^22 JSON
      values.  It MAY refuse a larger one, from man_len alone for its
      length, before it reads it.

   [WAI] Section 7.1 also defines a multi-rendition container, "WAI2".
   This document carries "WAI1" envelopes only.

4.2.  Manifest

   The members this document reads are:

   wai:
      The version, "1.0".  A reader refuses an unknown major version and
      accepts an unknown minor one.  A reader ignores a member it does
      not understand.

   model_requirement.capability:
      The capability that decodes the payload.

   model_requirement.fallback:
      A capability a receiver MAY decode the payload with if it lacks
      the first, or if the pin does not resolve for the first; or null,
      in which case the envelope is inert without the first.

   conditioning.prior:
      OPTIONAL.  The pin (Section 4.4) of the parameter set the payload
      was coded against.  It applies to whichever of the capability and
      the fallback decodes the payload.

   intent:
      "replicate" states that every conforming receiver reconstructs the
      source as the capability's tier promises (Section 4.5).

   refines:
      Present exactly when the capability is refinement-only: what the
      payload refines (Section 5.4).

   security:
      OPTIONAL.  Whether the payload is encrypted, as [WAI] Section 6
      defines.  The capability and the pin always describe the
      plaintext.

4.3.  Capability Dispatch

   A receiver dispatches an envelope as follows:




Charlot                   Expires 24 April 2027                 [Page 6]

Internet-Draft            WAI Packaging for MSF             October 2026


   1.  If the major version in "wai" is unknown, refuse the envelope.

   2.  Let cap be the capability.  If the receiver can decode cap, cap
       is dispatchable, and either no pin applies to cap or the pin
       resolves for cap (Section 4.4), decode the payload with cap,
       against the verified parameter set, and stop.  A pin that does
       not resolve makes cap unsupported for this envelope; keep its
       reason.

   3.  Otherwise, if the fallback is not null and step 2's conditions
       hold for it, decode with the fallback and stop; keep a pin's
       reason if it does not resolve.

   4.  Otherwise the envelope is inert at this receiver.  Report the
       reason kept at step 2, else the one kept at step 3, else
       "missing_capability".

   A capability is dispatchable unless [WAI] Section 4 registers it as
   something a receiver does not decode on its own: a candidate, a
   companion-only, a refinement-only, a record or a derivation string.
   A string [WAI] does not register is dispatchable by a receiver that
   has a decoder for it.  A pin that does not resolve is never a reason
   to decode against another parameter set: a learned decode against the
   wrong parameters yields plausible output, not an error.

4.4.  Parameter-Set Pins

   A pin is a JSON object:























Charlot                   Expires 24 April 2027                 [Page 7]

Internet-Draft            WAI Packaging for MSF             October 2026


   +=============+===========+=========================================+
   | Member      | Presence  | Meaning                                 |
   +=============+===========+=========================================+
   | id          | REQUIRED, | A name for people.  A receiver          |
   |             | string    | MUST NOT select or accept a             |
   |             |           | parameter set by it.                    |
   +-------------+-----------+-----------------------------------------+
   | sha256      | REQUIRED, | The SHA-256 of the parameter            |
   |             | string    | set in its form, as 64                  |
   |             |           | lowercase hexadecimal digits.           |
   +-------------+-----------+-----------------------------------------+
   | determinism | REQUIRED, | How the decode is made                  |
   |             | string    | reproducible, in words.                 |
   +-------------+-----------+-----------------------------------------+
   | form        | OPTIONAL, | The form the digest is computed         |
   |             | string    | over (below).                           |
   +-------------+-----------+-----------------------------------------+
   | tier        | OPTIONAL, | The tier the sender claims:             |
   |             | string    | "decode-equivalence", "entropy-         |
   |             |           | consistency" or "none".                 |
   +-------------+-----------+-----------------------------------------+

                            Table 1: Pin Members

   A member of a pin with another JSON type makes the manifest
   malformed.  A null optional member is an absent one.

   With form absent, sha256 is the SHA-256 of the one file that holds
   the set; that is admissible only for a capability [WAI] registers
   with a one-file set.  With form "wai.prior.set", sha256 is the
   SHA-256 of the set's listing.  The listing has one line per file: the
   file's SHA-256 as 64 lowercase hexadecimal digits, two spaces, the
   file's path below the set's root, and a line feed.  A path is one or
   more segments joined by "/"; a segment begins with one of A-Z, a-z,
   0-9, "_" and "-", continues with those and ".", and does not end with
   ".".  Lines are in strictly ascending order of their paths as byte
   strings; no two paths are equal once A-Z are mapped to a-z, and no
   path followed by "/" begins another.  The listing has at least one
   line and nothing else.  [WAI-PRIOR] registers further forms.












Charlot                   Expires 24 April 2027                 [Page 8]

Internet-Draft            WAI Packaging for MSF             October 2026


   A receiver that is to decode through a capability to which a pin
   applies MUST verify the pin first.  The pin resolves when the
   receiver holds a parameter set whose digest, in the pin's form,
   equals sha256: for "wai.prior.set", a listing with that digest
   together with every file it names, each with the digest its line
   gives.  Nothing else satisfies a pin: not a matching id, and not a
   set in another form whose unpacked parameters compare equal.  A pin
   that does not resolve is refused with the first of these reasons that
   applies:

   1.  "pin_malformed": sha256 is not 64 lowercase hexadecimal digits.

   2.  "form_not_registered": form names no registered form.

   3.  "form_unreadable": the receiver has no reader for the form.

   4.  "form_required": form is absent and the capability is not
       registered with a one-file set.

   5.  "prior_revoked" or "prior_not_authorised": the receiver holds a
       key log and refuses the set under it, as [WAI] Section 3.1
       specifies.  A receiver that holds no key log skips this check.

   6.  "prior_not_held": the receiver holds no set with that digest
       ("digest_superseded" where it holds the set that the pin's
       optional supersedes member names).

   7.  "set_malformed": the listing breaks a rule above.

   8.  "part_mismatch": a file the listing names is missing, unreadable,
       or has another digest.

   A pinned decode MUST read its parameters only from the set it
   verified; a decode that needs a file the set lacks is refused
   ("set_incomplete") and is treated as a pin that did not resolve.  A
   refused pin makes its capability unsupported for that envelope; it is
   not a reason to decode anyway.

4.5.  Determinism Tiers

   A learned decode evaluated in floating point does not in general
   reproduce its output across devices.  WAI names two reproducibility
   guarantees [WAI-TIERS]:








Charlot                   Expires 24 April 2027                 [Page 9]

Internet-Draft            WAI Packaging for MSF             October 2026


   entropy-consistency:
      The entropy decode reproduces byte for byte on every conforming
      receiver: the decoded symbols have a portable hash.  The
      reconstruction to the final medium can differ between conforming
      receivers.

   decode-equivalence:
      The whole decode, to the final medium, reproduces byte for byte on
      every conforming receiver: the reconstructed samples have a
      portable hash.  The capability's registration specifies the decode
      in integer or fixed-point arithmetic, entropy stage and synthesis
      alike.

   "none" claims neither.  The tiers are ordered none < entropy-
   consistency < decode-equivalence.  A tier is a property of a
   capability as registered: [WAI] gives each capability a registry
   class, and the class gives the tier.  A pin's tier above its
   capability's does not conform ("tier_exceeds_class"), and a receiver
   MUST NOT rely on it.  A receiver reads a tier token it does not
   recognize as "none".

   An envelope with intent "replicate" over a learned capability MUST be
   over a capability registered at decode-equivalence, with a pin that
   declares decode-equivalence; entropy-consistency MUST NOT back
   "replicate".  A tier covers the medium a receiver emits: a receiver
   that alters the decoded medium (for example with a post-decode
   filter) MUST NOT claim the tier for the result.

   At the time of writing, [WAI] registers "wai.neural.int_synth",
   "wai.neural.int_hyper", "wai.video.int_hyper", "wai.audio.int_codec",
   "wai.splat.int_codec" and "wai.neural.int_mlicpp" at decode-
   equivalence, and "wai.image.jpegai" at entropy-consistency.  This
   list is informative; the registry governs.

5.  Catalog

5.1.  Packaging Values

   This specification extends the allowed packaging values defined in
   Section 5.2.4 of [MSF] with two entries:











Charlot                   Expires 24 April 2027                [Page 10]

Internet-Draft            WAI Packaging for MSF             October 2026


              +==============+==============+===============+
              | Name         | Value        | Reference     |
              +==============+==============+===============+
              | WAI          | wai          | This document |
              +--------------+--------------+---------------+
              | WAI receipts | wai-receipts | Section 6.7   |
              +--------------+--------------+---------------+

                         Table 2: Packaging Values

   Every track whose objects are WAI envelopes MUST declare packaging
   "wai".  On such a track:

   *  every object MUST be exactly one whole envelope.  An object that
      holds part of an envelope, or more than one, is not this
      packaging;

   *  the object boundary MUST be the envelope boundary, so that the
      receipt's commitment to an object (Section 6) and MOQT's object
      identity are the same unit;

   *  a receiver that does not recognize the packaging value "wai" MUST
      NOT attempt to interpret the objects.  MSF's rule that a parser
      ignores fields it does not understand covers unknown fields, not
      unknown packaging values.

5.2.  Track Fields

   This specification adds the following track-level catalog fields for
   tracks with packaging "wai".  They are custom fields under Section 5
   of [MSF]; their "wai_" prefix keeps them from colliding with fields
   MSF defines.



















Charlot                   Expires 24 April 2027                [Page 11]

Internet-Draft            WAI Packaging for MSF             October 2026


   +==============+====================+========+========+============+
   | Field        | Name               |Required|JSON    | Definition |
   |              |                    |        |Type    |            |
   +==============+====================+========+========+============+
   | Capabilities | wai_capabilities   |Yes     |Array of| Section    |
   |              |                    |        |String  | 5.2.1      |
   +--------------+--------------------+--------+--------+------------+
   | Determinism  | wai_determinism    |No      |String  | Section    |
   |              |                    |        |        | 5.2.2      |
   +--------------+--------------------+--------+--------+------------+
   | Pinned       | wai_priors         |No      |Array of| Section    |
   | parameter    |                    |        |Object  | 5.3        |
   | sets         |                    |        |        |            |
   +--------------+--------------------+--------+--------+------------+
   | Receipts     | wai_receipts       |Yes     |Boolean | Section    |
   |              |                    |        |        | 5.2.3      |
   +--------------+--------------------+--------+--------+------------+
   | Receipt      | wai_receipt_alias  |Cond.   |Number  | Section    |
   | alias        |                    |        |        | 5.2.3      |
   +--------------+--------------------+--------+--------+------------+
   | Receipts     | wai_receipts_track |Cond.   |String  | Section    |
   | track        |                    |        |        | 5.2.3      |
   +--------------+--------------------+--------+--------+------------+
   | Stage        | wai_staged         |Cond.   |Object  | Section    |
   |              |                    |        |        | 5.4        |
   +--------------+--------------------+--------+--------+------------+

                          Table 3: Track Fields

5.2.1.  Capabilities

   wai_capabilities lists every capability that an object on the track
   names as its capability or as its fallback.  The list MUST be
   exhaustive for the track: its purpose is to let a receiver decide
   before subscribing whether it can decode what it is about to receive.
   A receiver MUST NOT subscribe on the assumption that an undeclared
   capability will not appear.  A receiver MUST treat an object whose
   envelope names, as the capability it is about to dispatch to, a
   capability the list does not hold as a protocol error, and MUST NOT
   fall back silently.

5.2.2.  Determinism

   wai_determinism is the weakest tier (Section 4.5) that any object on
   the track claims, not the strongest.  Absent means no tier is
   claimed.  A receiver reads a value it does not recognize as "none".
   The field helps a receiver choose a track; the tier a receiver claims
   for an object is the one its own decode earns.



Charlot                   Expires 24 April 2027                [Page 12]

Internet-Draft            WAI Packaging for MSF             October 2026


5.2.3.  Receipts Fields

   wai_receipts:
      Whether the track's objects are covered by receipts (Section 6).
      A receiver reads an absent value as false.

   wai_receipt_alias:
      An integer from 0 to 2^53-1, written as an integer: the
      track_alias that the track's receipts sign (Section 6.5).  MOQT's
      own Track Alias is chosen per session, by each hop (Section 3.1.3
      of [MOQT]), so past the first hop it is not the number the
      receipts sign.  Two tracks of a catalog MUST NOT carry the same
      value.

   wai_receipts_track:
      The name, in this track's namespace, of the track of packaging
      "wai-receipts" that carries this track's receipts (Section 6.7).
      Two tracks of a catalog MUST NOT name the same receipts track.

   A track of a stage set that declares wai_receipts true MUST carry
   wai_receipt_alias and wai_receipts_track (Section 5.4).  On another
   track both are OPTIONAL; a receiver finds a track's receipts chain
   and receipts track by them.  A clone (Section 5.1.6 of [MSF])
   inherits every field of its parent but its name, so a clone of a
   track that declares receipts MUST override both.

5.3.  Pinned Parameter Sets

   A track MAY state, in wai_priors, the pins its objects carry.  A
   receiver can then tell before it subscribes whether it holds the
   parameter sets the track needs, and at which tier each is offered.

   "wai_priors": [
     { "capability": "wai.neural.int_hyper",
       "sha256": "<64 lowercase hexadecimal digits>",
       "form": "wai.prior.set",
       "tier": "decode-equivalence" }
   ]













Charlot                   Expires 24 April 2027                [Page 13]

Internet-Draft            WAI Packaging for MSF             October 2026


   +============+==================+===================================+
   | Member     | Presence         | Meaning                           |
   +============+==================+===================================+
   | capability | REQUIRED,        | A capability the track's          |
   |            | string           | wai_capabilities lists.           |
   +------------+------------------+-----------------------------------+
   | sha256     | REQUIRED,        | A pin's sha256: 64 lowercase      |
   |            | string           | hexadecimal digits.               |
   +------------+------------------+-----------------------------------+
   | form       | OPTIONAL,        | The pin's form.  Absent, or null, |
   |            | string           | where the pin declares none.      |
   +------------+------------------+-----------------------------------+
   | tier       | OPTIONAL,        | The tier the publisher offers the |
   |            | string           | set at.  Advisory.                |
   +------------+------------------+-----------------------------------+

                   Table 4: Members of a wai_priors Entry

   An entry lists a pin for a capability when its capability is that
   capability, its sha256 is the pin's, and its form is the pin's (both
   absent, or the same string).  A member of an entry that this document
   does not define is ignored.

   Reading.
      wai_priors, where present and not null, is an array of objects,
      each with the members above of their types, each capability one
      that the track's wai_capabilities lists, and no two with the same
      capability, sha256 and form.  A receiver that reads anything else
      refuses the track ("catalog_priors_malformed") and does not
      subscribe to it.  A tier this document does not define is read as
      "none".

   Exhaustive.
      Where a track carries wai_priors, the publisher MUST list in it
      every pin that its objects carry.  An object breaks the catalog
      when:

      1.  it carries a pin that no entry lists for its capability or for
          its fallback; or

      2.  an entry names its capability, or its fallback (when not
          null), and the object carries no pin, or carries a pin that no
          entry lists for that capability.

      A publisher whose objects' pin can decode through the fallback
      SHOULD list the set for the fallback as well.





Charlot                   Expires 24 April 2027                [Page 14]

Internet-Draft            WAI Packaging for MSF             October 2026


   Mismatch.
      A receiver checks each object of such a track against the track's
      wai_priors before it dispatches the object.  An object that breaks
      the catalog is refused ("catalog_prior_mismatch"), and the track
      is refused with it: the receiver dispatches no further object of
      the track, and MAY unsubscribe from it.  The catalog never stands
      in for the envelope.  A receiver verifies an object's pin
      (Section 4.4) whether or not the catalog lists it; an entry never
      satisfies a pin, never supplies a pin the envelope lacks, and
      never changes which set a decode reads.

   Tier.
      A listed tier is advisory.  A publisher MUST NOT list a tier above
      the one the capability's registry class gives.  A receiver MUST
      NOT claim a tier on the strength of a listed tier: the tier it
      claims for an object is the one its own decode earns
      (Section 4.5).  A listed tier that differs from the tier an
      object's pin states is not a mismatch.

5.4.  Staged Tracks

   WAI's staged delivery [WAI-STAGED] sends a base first and refinement
   layers after it; a receiver presents the base, and applies each layer
   that arrives in time.  Each layer is a WAI envelope whose capability
   is refinement-only and whose manifest names, in refines, what it
   refines.  A stage set is carried as one track per layer: a base
   track, which carries the set's bases, and a layer track for each
   layer index k, which carries the layers of index k.  A receiver
   chooses its stage by the tracks it subscribes to; a relay forwards
   tracks and never reads an envelope.

   Each track of a set MUST carry, in its catalog entry, a wai_staged
   object:

   "wai_staged": { "set": "cam1", "layer": 1, "lead_ms": 40 }

   set:
      A non-empty string, the same on every track of the set.

   layer:
      An integer from 0 to 255: 0 on a base track, k on a track that
      carries layer k.

   lead_ms:
      On a layer track of a live set, an integer from 0 to 2^53-1: the
      time before a unit's presentation by which the layer must arrive
      to be applied to it. null on a base track.  A receiver ignores it
      when isLive is false.



Charlot                   Expires 24 April 2027                [Page 15]

Internet-Draft            WAI Packaging for MSF             October 2026


   A set's extent is the tracks present: layers 0 to the highest layer a
   track of the set states.  More than one track MAY carry one layer, as
   renditions of it, each with a receipts chain of its own.  A publisher
   puts on a track of layer k only envelopes whose refines.layer is k,
   and on a base track only envelopes with no refines; a receiver
   applies a layer by its own refines, whichever track it came on.  A
   layer track's wai_capabilities lists refinement capabilities, so a
   receiver that does not implement staged delivery finds them
   unsupported and has no reason to subscribe.

   The tracks of a set MUST share one namespace, one isLive
   (Section 5.2.7 of [MSF]) and one renderGroup (Section 5.2.11 of
   [MSF]), present on each and written as an integer.  Every entry of a
   track's depends (Section 5.2.14 of [MSF]) MUST name a track of the
   catalog in the track's namespace; the depends of a track of layer k
   MUST name at least one track of the set at each layer below k and
   none at k or above, and a base track's MUST NOT name a track of the
   set.  A layer track MUST NOT carry altGroup, temporalId or spatialId
   (Section 5.2.12 of [MSF], Section 5.2.16 of [MSF], Section 5.2.17 of
   [MSF]); an altGroup MAY group the base tracks of alternative sets.
   Every track of a set that declares wai_receipts true carries its own
   wai_receipt_alias and receipts track (Section 5.2.3).

   A receiver checks each set's entries in this order, stops at the
   first check that fails, and treats the layer tracks of a set that
   fails as absent (its base tracks remain tracks of packaging "wai"):

   1.  wai_staged has its three members, of their types and ranges;
       packaging is "wai"; isLive is a boolean; the track's name is a
       string and its namespace absent or a string, and no other track
       has that namespace and name; renderGroup, if present, is an
       integer below 2^64; depends, if present, is an array of strings
       ("staged-malformed").

   2.  The set has a track at each layer from 0 to its highest ("staged-
       set-incomplete").

   3.  The depends rules above hold ("staged-depends").

   4.  The tracks share one namespace, one isLive and one renderGroup,
       present on each, and no layer track carries altGroup, temporalId
       or spatialId ("staged-grouping").

   5.  On a live set, lead_ms is an integer on every layer track and
       null on every base track ("staged-lead").






Charlot                   Expires 24 April 2027                [Page 16]

Internet-Draft            WAI Packaging for MSF             October 2026


   6.  Every wai_receipt_alias of the catalog is an integer from 0 to
       2^53-1; each track of the set that declares receipts carries an
       alias and names a receipts track of packaging "wai-receipts" in
       its namespace; and no other track carries that alias or names
       that receipts track ("staged-receipts").

   A track that declares no namespace inherits the catalog track's
   (Section 5.2.2 of [MSF]).  A checker that does not know the catalog
   track's namespace refuses a set that mixes declared and inherited
   namespaces ("staged-malformed").

   Groups and objects.  On a live track each group MUST carry exactly
   one object, which travels in a subgroup of its own (Section 2.2 of
   [MOQT]).  A group of one object is complete when its object is, so
   its group receipt is signed before the object is sent.  Group and
   object identifiers of different tracks need not align: refines names
   what a layer refines.

   Priority.  The base track's publisher priority (Section 5.1 of
   [MOQT]) MUST be strictly below every layer track's, and the priority
   of a track of layer k MUST be no greater than that of any track of a
   layer above k.  This holds for each track's
   DEFAULT_PUBLISHER_PRIORITY (Section 10.4 of [MOQT]) and for every
   subgroup that sets its own.  A receipts track's priority is its media
   track's.  A subscriber that wants the publisher's order SHOULD give
   its requests for a set's tracks one subscriber priority.

   Delivery timeouts.  A publisher SHOULD set a live layer object's
   OBJECT_DELIVERY_TIMEOUT (Section 5.2 of [MOQT]) to no more than its
   slack: the time from publication to the presentation of the last unit
   the object covers, less the layer's lead_ms, less the publisher's
   estimate of the path.  An object whose slack is zero or less cannot
   arrive in time, and the publisher MAY withhold it.  A publisher MUST
   NOT set on a base track a delivery timeout of either kind shorter
   than the time from a base's publication to the presentation of its
   last unit.  A delivery timeout releases bandwidth hop by hop; it is
   not an end-to-end deadline, and whether a layer is late is decided by
   the receiver, as [WAI-STAGED] specifies.

   Capping.  A receiver caps its stage by subscribing to the base
   tracks, to the tracks of layers 1 to n, and to their receipts tracks,
   and to no others.  A relay MUST NOT read an envelope to cap layers.

6.  Receipts







Charlot                   Expires 24 April 2027                [Page 17]

Internet-Draft            WAI Packaging for MSF             October 2026


6.1.  Overview

   A publisher that declares wai_receipts true commits to every object
   of a track, group by group.  For each MOQT group it computes each
   object's content hash, builds a Merkle tree over them, and signs the
   root and the group's metadata with its Ed25519 key [RFC8032]: the
   group receipt.  Each object has an object receipt that carries its
   Merkle inclusion proof.  Group receipts form a chain for each
   publisher key and receipt alias: each names the link hash of the one
   before.  The receipts of group g travel as one object in group g of
   the track's receipts track (Section 6.7), so that a receiver can
   verify the tracks it subscribes to without the receipts of others,
   and can account for an object it did not receive.

   The rules here are those of [WAI-JWP] for the binary form that this
   carriage uses.  That document also defines a JSON form, signed claims
   and key discovery, which this document does not need.

6.2.  Content Hash

   content_hash = BLAKE3("moq-jwp:object\x01" || envelope)

   envelope is the object's payload: the whole envelope, from "WAI1" to
   the last payload byte, with nothing inserted or reframed.

6.3.  Merkle Tree

   A group's objects are its leaves, in MOQT Object ID order, starting
   at 0.  An object's leaf takes the first form below when its receipt
   carries no energy label, and the second when it does (Section 6.4):

   leaf_v1 = BLAKE3("moq-jwp:merkle-leaf\x01" || content_hash)
   leaf_v2 = BLAKE3("moq-jwp:merkle-leaf\x02" || content_hash
                    || u64_be(joules_micro) || class
                    || u32_be(len(origin)) || origin)
   node    = BLAKE3("moq-jwp:merkle-node\x01" || left || right)

   When a level has an odd number of nodes, its last node is duplicated
   to make a pair.  The root is the single node at the top; the root of
   an empty group is 32 zero bytes.  Since an object receipt's object_id
   is both its MOQT Object ID (Section 6.7) and its leaf index
   (Section 6.8), a publisher that declares receipts numbers each
   group's objects from 0, without gaps. joules_micro is the energy, in
   microjoules, that producing the object took, and 0 is the unmetered
   marker, never a figure of zero joules. origin is a UTF-8 label of
   where the object was produced.





Charlot                   Expires 24 April 2027                [Page 18]

Internet-Draft            WAI Packaging for MSF             October 2026


6.4.  Energy Class Encoding

   An energy figure's acquisition class says how the figure was obtained
   [WAI-ENERGY].  Where a receipt signs it, the class is one tag byte
   followed by its evidence:

   +=====+======================+=====================================+
   | Tag | Class                | Followed by                         |
   +=====+======================+=====================================+
   | 0   | unmetered            | nothing                             |
   +-----+----------------------+-------------------------------------+
   | 1   | HwShunt (legacy)     | nothing                             |
   +-----+----------------------+-------------------------------------+
   | 2   | ModelBased           | nothing                             |
   +-----+----------------------+-------------------------------------+
   | 3   | Estimator            | nothing                             |
   +-----+----------------------+-------------------------------------+
   | 4   | OnChipCounter        | u32_be(relative_ppm) ||             |
   |     |                      | u64_be(window_us) || u8(filtering:  |
   |     |                      | 0 unknown, 1 off, 2 on)             |
   +-----+----------------------+-------------------------------------+
   | 5   | CalibratedInstrument | u32_be(relative_ppm) ||             |
   |     |                      | u64_be(window_us) || u32_be(len) || |
   |     |                      | calibration reference, UTF-8        |
   +-----+----------------------+-------------------------------------+

                       Table 5: Acquisition Classes

   relative_ppm is the standard relative uncertainty of the figure in
   parts per million, and window_us the integration window in
   microseconds.  A class in a receipt is valid only when: tag 0 stands
   beside a zero figure and every other tag beside a non-zero one; tag 1
   does not appear (it is accepted only in receipts that predate the
   labels); and for tags 4 and 5, relative_ppm and window_us are both
   non-zero and figure x relative_ppm is at least 288676, the least
   uncertainty a whole number of microjoules can carry.  The classes are
   ordered, strongest first: CalibratedInstrument, OnChipCounter,
   HwShunt, ModelBased, Estimator.

6.5.  Group Signature

   The publisher signs, with pure Ed25519 [RFC8032], one of two signing
   payloads:








Charlot                   Expires 24 April 2027                [Page 19]

Internet-Draft            WAI Packaging for MSF             October 2026


   legacy   = "moq-jwp:group-sign\x01"
           || u64_be(track_alias)        ; the track's wai_receipt_alias
           || u64_be(group_id)           ; the MOQT Group ID
           || merkle_root                ; 32 bytes
           || u64_be(leaf_count)         ; objects in the group
           || u64_be(total_joules_micro) ; sum over the group's objects
           || string(group_start)        ; RFC 3339, first object
           || string(group_end)          ; RFC 3339, last object
           || publisher_key              ; 32 bytes, Ed25519 public key
           || string(signer_id)          ; identity label

   labelled = "moq-jwp:group-sign\x02"
           || (the fields of legacy after its domain, in order)
           || class                      ; the total's class
           || u8(coverage)               ; 0 Whole, 1 Partial
           || u8(has_parent) || parent   ; 1 and the parent's link hash,
                                         ; or 0 and 32 zero bytes

   group_start and group_end are timestamps of the form of [RFC3339].
   signer_id names the signer; a receiver reads nothing from it unless
   it can confirm it by a means outside this document.

   The labelled payload signs the link to the parent group; the legacy
   payload does not.  A labelled group's class is the one its objects
   compose to:

   *  if an object with a non-zero figure carries no label, the group
      MUST be signed in the legacy form;

   *  if no object has a non-zero figure, the class is tag 0 and the
      coverage 0;

   *  otherwise the class is the weakest of the objects' classes among
      those with a non-zero figure, and the coverage is 1 exactly when
      some object's figure is zero.  For a hardware class (tag 4 or 5),
      relative_ppm is at least the ceiling of (sum of figure_i x
      relative_ppm_i) / (sum of figure_i), and window_us is the longest
      of the objects'.  A tag-4 total's filtering state is the objects'
      common one, or 0.  A tag-5 total needs one calibration reference
      shared by every object, or the group is signed in the legacy form.

6.5.1.  Link Hash

   canonical_bytes = signing_payload || signature   ; 64-byte signature
   link_hash = BLAKE3("moq-jwp:receipt-link\x01" || canonical_bytes)






Charlot                   Expires 24 April 2027                [Page 20]

Internet-Draft            WAI Packaging for MSF             October 2026


   signing_payload is the payload of the form the group was signed in.
   A group's parent is the link hash of the previous group of its chain,
   or none for the first.  A legacy group's link hash does not cover its
   parent link, which the legacy payload does not sign.

6.6.  Binary Forms

   group_bin    = canonical_bytes              ; labelled form
                | canonical_bytes              ; legacy form
                  || u8(has_parent) || parent  ;   parent: 32 bytes

   object_body  = u64_be(object_id)
               || content_hash                 ; 32 bytes
               || u64_be(joules_micro)
               || string(origin)
               || u8(n) || sibling x n         ; 32 bytes each, leaf up
               || u64_be(direction_bits)
               || u64_be(leaf_index)
               || u8(leaf_version)             ; 1 leaf_v1, 2 leaf_v2
               || class                        ; leaf_version 2 only

   receipts_bin = "WJR1"
               || group_bin
               || u32_be(count)
               || object_body x count

   The first 19 bytes of group_bin, the signing domain, give its form.
   Every field's length is known when the bytes are read in order.  Bit
   i of direction_bits is 1 when the node at level i is the right child.
   An object receipt inside receipts_bin takes the group's track_alias
   and group_id.

   A reader reads exactly the bytes it is given and refuses them as
   "malformed" at the first of these that holds: the magic is not
   "WJR1"; the signing domain is neither of Section 6.5; the bytes end
   before a field, or bytes follow the last object; a string is not UTF-
   8; a class tag is not one of Section 6.4 or its evidence does not
   read; a coverage byte, parent flag or filtering byte is out of range;
   a parent flag of 0 is followed by bytes that are not zero; or
   leaf_version is neither 1 nor 2.  The form is canonical: a receipt
   has one binary form, and a writer reproduces the bytes it read.

6.7.  The Receipts Track

   A receipts track has packaging "wai-receipts" and is named by its
   media track's wai_receipts_track.  Each media track has a receipts
   track of its own.




Charlot                   Expires 24 April 2027                [Page 21]

Internet-Draft            WAI Packaging for MSF             October 2026


   *  Group g of a receipts track carries one object, the receipts_bin
      of group g of its media track: its group receipt and object
      receipts.  The publisher publishes it no later than that group's
      first object.

   *  A receipt is about one MOQT object.  The group receipt in group g
      of a receipts track has group_id g; each object receipt in it has
      that group_id and, as object_id, the MOQT Object ID of its object;
      its publisher_key is the publisher's key and its track_alias the
      media track's wai_receipt_alias.  A receiver refuses a receipt
      that breaks this ("moqt_mismatch") before it verifies its
      signature, and holds nothing of it.

   *  A receipts track has no delivery timeout of either kind: the
      publisher sets none, and a subscriber sets none on its
      subscription (Section 9.20.3 of [MOQT], Section 9.20.4 of [MOQT]).
      Its publisher priority is its media track's.

   *  Its objects are receipts, not envelopes; Section 5.1's object
      rules do not apply to them.

   A receiver learns the publisher's key by a means outside this
   document: configuration, the session in which it subscribed, or key
   discovery as [WAI-JWP] Section 7 specifies.

6.8.  Verification

   A receiver verifies each group receipt and each object receipt it
   uses in these steps, in order:

   1.  Read.  The receipts_bin reads (Section 6.6); otherwise
       "malformed".  A labelled group's class reads and is valid with
       the group alone: tag 1 does not appear, tag 0 stands exactly
       beside a zero total with coverage 0, and a hardware class meets
       the floor of Section 6.4; otherwise "group_label_invalid".

   2.  Signature.  The publisher key and the signature pass, in order:
       the key is the one encoding of its point that Section 5.1.3 of
       [RFC8032] allows; the key's point is not of small order; S is
       less than L; R is not of small order; and the cofactorless
       equation holds: the point S*B - k*A, with k = SHA-512(R || A ||
       M) mod L over the bytes of R and A as the signature and key give
       them, encodes to R byte for byte.  A key that fails one of the
       first two checks is "bad_signer_key"; a signature that fails a
       later one is "signature_verify_failed".  These checks fix what
       [RFC8032] leaves to the verifier, so that every conforming
       receiver accepts the same signatures.  The receiver then holds a
       verified root.



Charlot                   Expires 24 April 2027                [Page 22]

Internet-Draft            WAI Packaging for MSF             October 2026


   3.  Chain.  Chains are kept per (publisher key, track_alias).  With
       no group of the chain held, a group with no parent starts it.  A
       group whose parent is the head's link hash extends it.  A group
       already admitted, offered again with the same bytes, passes and
       changes nothing.  A second group with no parent, or one whose
       parent is the link hash of a group of the chain other than its
       head, is "chain_break".  A group whose parent the receiver does
       not hold is "parent_not_held": the receiver MAY hold it while it
       recovers the parent, by a FETCH (Section 3.2 of [MOQT]) of the
       receipts track, and MUST NOT accept it until then.  A legacy
       group whose group_id does not exceed its chain head's is
       "group_id_not_increasing".

   4.  Content hash.  For an object the receiver received, the content
       hash of its bytes (Section 6.2) equals the object receipt's;
       otherwise "content_hash_mismatch".

   5.  Inclusion.  A labelled object receipt's class is valid
       (Section 6.4); otherwise "object_label_invalid".  leaf_index is
       below leaf_count, the proof holds exactly ceil(log2(leaf_count))
       siblings (none for one leaf), direction_bits equals leaf_index,
       and object_id equals leaf_index; otherwise
       "proof_position_mismatch".  The object's leaf, in the form its
       leaf_version gives, walked up the proof, reaches the verified
       root; otherwise "inclusion_proof_failed".

   6.  Accept.  The object's bytes are bound to the publisher key at
       (track_alias, group_id, object_id).  Where its leaf is labelled,
       its figure, class and origin are bound with them; otherwise they
       are the publisher's unsigned statements.

   A rejection at steps 1 to 5 is a hard failure for the object.  A
   receiver MUST NOT accept a partial verification, such as a valid
   proof against an unverified root.

   An object receipt checked by steps 1, 2, 3 and 5 for an object the
   receiver did not receive is "inclusion-verified": the publisher
   signed an object with that content hash at that position.  A receiver
   MUST report it as such, and MUST NOT report it, or anything read from
   it, as delivered, or dispatch on it.

   A receiver that holds an accepted object receipt for every leaf of a
   group MUST check that their figures sum to the group's total
   ("group_total_mismatch"), and, for a labelled group, that the group's
   class, coverage and uncertainty are those its objects compose to
   (Section 6.5).





Charlot                   Expires 24 April 2027                [Page 23]

Internet-Draft            WAI Packaging for MSF             October 2026


   Holding and joining.  A receiver that holds groups for missing
   parents MUST state a finite bound on what it holds: per chain, and
   across all its chains, since any key makes a chain.  Past the bound
   it refuses what it holds ("parent_not_recovered") and re-anchors the
   chain at the next validly signed group whose group_id exceeds the
   head's.  A receiver that subscribes to a live track after its first
   group (Section 3.5 of [MOQT]) anchors each chain at the first validly
   signed group it receives.  An anchor establishes only that the key
   signed that group; a receiver MUST report a chain it anchored as
   anchored, with the anchor's group_id, and MUST NOT report the groups
   the anchor skipped as verified.  [WAI-JWP] Section 3 specifies how
   the groups of such a gap, fetched later, are admitted as history.

6.9.  The WAI_RECEIPT Object Property

   An object on a track of packaging "wai" MAY carry its receipt
   commitment as an MOQT Object Property (Section 8.4 of [MOQT]),
   WAI_RECEIPT.  Its value is:

   value = content_hash                    ; 32 bytes
        || vi64(joules_micro)
        || vi64(len) || acquisition        ; UTF-8 class name, or empty
        || vi64(len) || acquisition_evidence
        || group_receipt                   ; 32 bytes

   vi64 is the variable-length integer of Section 8.1 of [MOQT].
   acquisition is the class name of Section 6.4 ("ModelBased",
   "Estimator", "OnChipCounter", "CalibratedInstrument", or "HwShunt"),
   or empty; acquisition_evidence is, for tags 4 and 5, the evidence
   that follows the tag byte, and empty otherwise; group_receipt is the
   link hash of the group receipt covering the object.  The publisher
   MUST place the property inside Immutable Properties (Section 10.7 of
   [MOQT]), which no relay may change or remove.

   *  A receiver refuses a value that ends early, has bytes after
      group_receipt, or whose acquisition is not UTF-8
      ("property_invalid").

   *  A non-zero joules_micro MUST be accompanied by acquisition.  A
      zero joules_micro is the unmetered marker: acquisition and
      acquisition_evidence MUST be empty, and a receiver MUST NOT
      present it as zero joules.  acquisition_evidence MUST be non-empty
      for OnChipCounter and CalibratedInstrument and empty for every
      other class.  A receiver MUST discard a property that breaks this
      item ("property_invalid").






Charlot                   Expires 24 April 2027                [Page 24]

Internet-Draft            WAI Packaging for MSF             October 2026


   *  No signature covers the property.  A receiver MUST NOT report its
      class as signed unless the class, evidence and figure equal those
      in the object's labelled leaf, once the object receipt is accepted
      against the group receipt group_receipt names; where they differ,
      the receiver MUST discard the property ("property_disagrees").

   *  A relay MUST forward the property unchanged.

   *  The property rides on its object and is lost with it; the receipts
      track carries the receipts of an object that is not delivered.
      Absence of the property is not evidence that an object has no
      receipt.

   Until a type is assigned (Section 10.2), a track of packaging "wai"
   carries the property as type 0x3A41, from the range Section 8.4 of
   [MOQT] sets aside for an application's own use.  Another application
   can give that type another meaning, so a receiver reads it only on a
   track of packaging "wai".

6.10.  Relays

   An MOQT relay forwards tracks of packaging "wai" and "wai-receipts"
   as it forwards any track, their payloads opaque (Section 7.8 of
   [MOQT]).  It needs no knowledge of this document and verifies no
   receipt: the receiver verifies every receipt itself.  A relay that
   does not forward an object, because a delivery timeout passed or at
   its discretion, still forwards the receipts track's objects, which
   are separate MOQT objects.  A relay that verifies receipts before
   forwarding them is permitted, and [WAI-JWP] Section 4 states what it
   must preserve.

7.  The codecs Parameter

   The optional codecs parameter of application/wai (Section 10.3) lists
   the capabilities a sequence of objects uses, in the form of
   [RFC6381].  Its WAI elements follow this grammar [RFC5234]:

   wai-element = wai-prefix "." alt *( "|" alt )
   wai-prefix  = "wai1" / "wai2"
   alt         = cap *( "+" cap )
   cap         = 1*lcalnum 1*( "." 1*( lcalnum / "_" ) )
   lcalnum     = %x61-7A / %x30-39









Charlot                   Expires 24 April 2027                [Page 25]

Internet-Draft            WAI Packaging for MSF             October 2026


   A cap is a capability string without its leading "wai.".  In an alt,
   the first cap is a capability a receiver can select, and each "+cap"
   is one whose payload is applied with it.  The element lists every
   capability that any object it describes may dispatch to or apply.  An
   element that begins with "wai", in any case, MUST match the grammar.
   [WAI-HTTP] Section 4 gives the remaining rules.

8.  Implementation Status

   (Note to the RFC Editor: please remove this section before
   publication, as [RFC7942] describes.)

   One open-source implementation family exists, in the repository named
   in the note at the start of this document, under the Apache License
   2.0:

   *  "wai-rs", the WAI reference library: the envelope, dispatch and
      pin verification (Section 4), the tier rules, the catalog check of
      staged tracks and the reading and check of wai_priors (Section 5),
      and a receipts verifier (Section 6).

   *  "joule-moq", an MOQT implementation of [MOQT]: the receipts track
      in its binary form, receipt chains per key and alias, the
      WAI_RECEIPT property at type 0x3A41 inside Immutable Properties,
      and a test relay that drops late objects and still forwards their
      receipts.  A browser receiver built on it refuses an object whose
      capability its track does not declare.

   *  Conformance corpora for the catalog checks, wai_priors, the
      receipts and the property.  Each is checked by the library and by
      an independent verifier, written in Python from the specification
      text, that shares no code with the library.

   Not implemented at the time of writing: no publisher in the
   implementation writes wai_priors, and the browser receiver does not
   read it (it dispatches no capability that decodes against a parameter
   set); no receiver reads wai_determinism; and no type is assigned for
   WAI_RECEIPT.

9.  Security Considerations

   This document relies on MOQT [MOQT] for transport security: QUIC
   protects each hop.  The receipts of Section 6 add integrity from the
   publisher to the receiver across relays; they add no confidentiality.







Charlot                   Expires 24 April 2027                [Page 26]

Internet-Draft            WAI Packaging for MSF             October 2026


9.1.  Receipt Keys

   Each group receipt has one signer, the publisher key in it.  Forging
   one requires the private key or a break of Ed25519.  A valid
   signature shows that a key signed; it does not show whose key it is.
   A receiver MUST NOT present a receipt as the publisher's unless it
   holds the key as the publisher's by a means it trusts (configuration,
   the session, or key discovery as [WAI-JWP] Section 7 specifies).
   Publishers MUST generate keys with a cryptographically secure random
   number generator and MUST NOT use one key for distinct publisher
   identities.  The strict verification of Section 6.8 step 2 refuses
   keys of small order, under which a signature can verify without any
   private key, and makes every conforming receiver accept the same
   signatures.  A compromised key can sign any group; rotation and
   revocation are outside this document.

9.2.  Replay

   A group receipt binds the publisher key, track_alias and group_id
   under its signature, and an object receipt is bound to its leaf
   position, so neither can be moved to another track, group or position
   without detection.  The receipts-track rule of Section 6.7 binds each
   receipt to the MOQT group and object it is carried for.

   Chains are kept per key and track.  The labelled payload signs the
   link to the parent group; the legacy payload does not, so in a legacy
   chain anyone on the path can rewrite the link, and the rule that a
   legacy group's group_id exceeds its head's is the only order that
   chain signs.  A relay can drop a legacy group and rewrite the next
   one's link to hide the gap; only the labelled payload rules that out.

   An anchor (Section 6.8) proves nothing about the groups before it: a
   relay can withhold groups, or offer a joining receiver an old group
   that is validly signed.  A receiver reports anchors and gaps, and MAY
   refuse a live group whose group_end is older than a freshness window
   it states; it applies such a window only to the live edge, never to
   history it fetches.

9.3.  Relay Transparency

   A relay forwards payloads without reading them.  It cannot alter an
   envelope without changing its content hash, nor alter a receipt
   without breaking its signature.  It can drop, delay or withhold
   objects, whole groups of a receipts track, or whole tracks; the
   receipts of Section 6 make an undelivered object accountable, as
   inclusion-verified, but they do not make delivery happen.





Charlot                   Expires 24 April 2027                [Page 27]

Internet-Draft            WAI Packaging for MSF             October 2026


   The WAI_RECEIPT property is not signed.  Immutable Properties forbid
   a relay to change it, but a receiver cannot detect a relay that
   breaks that rule from the property alone, which is why Section 6.9
   lets a receiver report its class only when it matches a signed leaf.

   A relay sees what MOQT exposes: track names, catalogs (unless they
   are encrypted), object sizes, timing and properties, including
   WAI_RECEIPT.

9.4.  Catalog Integrity

   Receipts do not cover the catalog.  Where the catalog is not
   protected end to end, an on-path party able to rewrite it can
   misdeclare a track's capabilities, tiers or pinned parameter sets.
   The envelope remains the authority: a receiver verifies every pin
   before it decodes (Section 4.4), and an object that breaks wai_priors
   refuses its track (Section 5.3), so a misdeclared catalog leads to
   refusal, not to a decode against the wrong parameters.  A listed tier
   is advisory and confers nothing.

9.5.  Parameter Sets

   A learned decoder run against parameters other than the ones a
   payload was coded against produces plausible but wrong output, with
   no error.  The pin makes the parameter set part of what the receiver
   checks, by digest.  A receiver that decodes from bytes other than the
   ones it verified (for example by reading a file again after checking
   it) loses that protection; a receiver SHOULD decode from the very
   bytes it verified.

9.6.  Resource Consumption

   A receiver bounds what it parses and holds: the manifest limits of
   Section 4.1; a bound on the receipts it holds for missing parents
   (Section 6.8); and the bounds of [WAI] Section 2 on decoded payloads.
   A receiver SHOULD check a receipts_bin's object count, and a Merkle
   proof's sibling count, against the bytes that remain before it
   allocates anything for them.

9.7.  Privacy

   Receipts carry the publisher key, a signer label, origin labels,
   timestamps and energy figures in cleartext, and a receipts track is
   visible to every relay that forwards it.  They reveal when and where
   objects were produced, and what producing them cost.  A publisher can
   send the unmetered marker in place of a figure and an empty origin.
   A deployment that needs these hidden from relays encrypts the
   receipts track's objects end to end, for example with



Charlot                   Expires 24 April 2027                [Page 28]

Internet-Draft            WAI Packaging for MSF             October 2026


   [SECURE-OBJECTS]; the receipts then commit to the bytes carried.

10.  IANA Considerations

10.1.  MSF Packaging Values

   This document requests no IANA action for the packaging values "wai"
   and "wai-receipts".  [MSF] lists its allowed packaging values in its
   own text (Section 5.2.4 of [MSF]) and creates no registry for them,
   and this document extends that list (Section 5.1), as other MSF
   packaging documents do.

10.2.  MOQ Properties

   This document requests that IANA register the following entry in the
   "MOQ Properties" registry established by Section 16.8 of [MOQT], with
   a type from the range 0x80 to 0x37FF, whose registration policy is
   Specification Required:

    +===========+=============+========+==============================+
    | Type      | Name        | Scope  | Specification                |
    +===========+=============+========+==============================+
    | TBD (odd) | WAI_RECEIPT | Object | Section 6.9 of this document |
    +-----------+-------------+--------+------------------------------+

                       Table 6: WAI_RECEIPT Property

   The type is odd, since the value is a byte sequence (Section 8.3 of
   [MOQT]).  Until a type is assigned, implementations use 0x3A41, from
   the range 0x3800 to 0x3FFF that Section 8.4 of [MOQT] reserves for
   application-specific use; no registration is possible in that range,
   and none is requested for it.

10.3.  Media Type application/wai

   This document requests that IANA register the media type application/
   wai in the "Media Types" registry, in the standards tree, as
   [RFC6838] provides for a registration made by an IETF document.

   Type name:  application

   Subtype name:  wai

   Required parameters:  N/A

   Optional parameters:  codecs, as Section 7 of this document defines.

   Encoding considerations:  binary



Charlot                   Expires 24 April 2027                [Page 29]

Internet-Draft            WAI Packaging for MSF             October 2026


   Security considerations:  See Section 9 of this document.  A WAI
      object names the decoder its payload needs and does not carry
      executable code.

   Interoperability considerations:  An object is a "WAI1" envelope
      (Section 4.1) or a "WAI2" envelope ([WAI] Section 7.1).  A reader
      refuses an unknown major version.

   Published specification:  This document, and [WAI].

   Applications that use this media type:  Media publishers, relays,
      caches and players that carry WAI envelopes over MOQT or HTTP.

   Fragment identifier considerations:  None defined by this document.

   Additional information:  Deprecated alias names for this type: N/A

      Magic number(s): 57 41 49 31 ("WAI1") or 57 41 49 32 ("WAI2") at
      offset 0

      File extension(s): .wai

      Macintosh file type code(s): N/A

   Person and email address to contact for further information:  The
      author of this document.

   Intended usage:  COMMON

   Restrictions on usage:  N/A

   Author:  See the Author's Address section of this document.

   Change controller:  IETF

10.4.  Capability Strings

   This document creates no registry for capability strings or tier
   names.  [WAI] registers them under its own registry policy.

11.  References

11.1.  Normative References

   [BLAKE3]   "The BLAKE3 Hashing Framework", Work in Progress,
              Internet-Draft, draft-aumasson-blake3-00, July 2024,
              <https://datatracker.ietf.org/doc/html/draft-aumasson-
              blake3-00>.



Charlot                   Expires 24 April 2027                [Page 30]

Internet-Draft            WAI Packaging for MSF             October 2026


   [MOQT]     "Media over QUIC Transport", Work in Progress, Internet-
              Draft, draft-ietf-moq-transport-22, 1 October 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-moq-
              transport-22>.

   [MSF]      "MOQT Streaming Format", Work in Progress, Internet-Draft,
              draft-ietf-moq-msf-01, 2 June 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-moq-msf-
              01>.

   [RFC2119]  "Key words for use in RFCs to Indicate Requirement
              Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
              1997, <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3339]  "Date and Time on the Internet: Timestamps", RFC 3339,
              DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.

   [RFC5234]  "Augmented BNF for Syntax Specifications: ABNF", STD 68,
              RFC 5234, DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC6381]  "The 'Codecs' and 'Profiles' Parameters for "Bucket" Media
              Types", RFC 6381, DOI 10.17487/RFC6381, August 2011,
              <https://www.rfc-editor.org/info/rfc6381>.

   [RFC6838]  "Media Type Specifications and Registration Procedures",
              BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/info/rfc6838>.

   [RFC8032]  "Edwards-Curve Digital Signature Algorithm (EdDSA)",
              RFC 8032, DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8174]  "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
              Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8259]  "The JavaScript Object Notation (JSON) Data Interchange
              Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December
              2017, <https://www.rfc-editor.org/info/rfc8259>.

   [SHS]      National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", FIPS PUB 180-4,
              DOI 10.6028/NIST.FIPS.180-4, August 2015,
              <https://doi.org/10.6028/NIST.FIPS.180-4>.





Charlot                   Expires 24 April 2027                [Page 31]

Internet-Draft            WAI Packaging for MSF             October 2026


   [WAI]      "WAI v1.0: Web AI Media Transport and Execution", Draft
              Standard, open-standards repository, wai/SPEC.md, October
              2026, <https://git.transaction.science/Transaction-
              Science/open-standards/src/branch/main/wai/SPEC.md>.

11.2.  Informative References

   [CMSF]     "CMSF- a CMAF compliant implementation of MOQT Streaming
              Format", Work in Progress, Internet-Draft, draft-ietf-moq-
              cmsf-01, 3 June 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-moq-
              cmsf-01>.

   [RFC7942]  "Improving Awareness of Running Code: The Implementation
              Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942,
              July 2016, <https://www.rfc-editor.org/info/rfc7942>.

   [SECURE-OBJECTS]
              "End-to-End Secure Objects for Media over QUIC Transport",
              Work in Progress, Internet-Draft, draft-ietf-moq-secure-
              objects-01, 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-moq-secure-objects-01>.

   [WAI-ENERGY]
              "WAI Extension: Energy Measurement", open-standards
              repository, wai/extensions/energy-measurement.md, October
              2026, <https://git.transaction.science/Transaction-
              Science/open-standards/src/branch/main/wai/extensions/
              energy-measurement.md>.

   [WAI-HTTP] "WAI Extension: HTTP Delivery", open-standards repository,
              wai/extensions/http-delivery.md, October 2026,
              <https://git.transaction.science/Transaction-Science/open-
              standards/src/branch/main/wai/extensions/http-
              delivery.md>.

   [WAI-JWP]  "WAI Extension: JWP Receipt Chain", open-standards
              repository, wai/extensions/jwp-receipts.md, October 2026,
              <https://git.transaction.science/Transaction-Science/open-
              standards/src/branch/main/wai/extensions/jwp-receipts.md>.

   [WAI-MOQ]  "WAI Extension: MoQ Streaming Format", open-standards
              repository, wai/extensions/moq-streaming-format.md,
              October 2026, <https://git.transaction.science/
              Transaction-Science/open-
              standards/src/branch/main/wai/extensions/moq-streaming-
              format.md>.




Charlot                   Expires 24 April 2027                [Page 32]

Internet-Draft            WAI Packaging for MSF             October 2026


   [WAI-PRIOR]
              "WAI Extension: Prior Carriage", open-standards
              repository, wai/extensions/prior-carriage.md, October
              2026, <https://git.transaction.science/Transaction-
              Science/open-standards/src/branch/main/wai/extensions/
              prior-carriage.md>.

   [WAI-STAGED]
              "WAI Extension: Staged Delivery", open-standards
              repository, wai/extensions/staged-delivery.md, October
              2026, <https://git.transaction.science/Transaction-
              Science/open-standards/src/branch/main/wai/extensions/
              staged-delivery.md>.

   [WAI-TIERS]
              "WAI Extension: Determinism Tiers for Neural Decode",
              open-standards repository, wai/extensions/determinism-
              tiers.md, October 2026, <https://git.transaction.science/
              Transaction-Science/open-
              standards/src/branch/main/wai/extensions/determinism-
              tiers.md>.

Appendix A.  Catalog Example

   A live catalog with a stage set (a base track and one layer track,
   each with its receipts track) and an on-demand track of a learned
   image capability that states its pinned parameter set.  The digest is
   a placeholder.























Charlot                   Expires 24 April 2027                [Page 33]

Internet-Draft            WAI Packaging for MSF             October 2026


   { "version": 1,
     "tracks": [
     { "namespace": "example/cam1", "name": "cam1/base",
       "packaging": "wai", "isLive": true, "targetLatency": 300,
       "role": "video", "renderGroup": 1,
       "wai_capabilities": ["wai.video.int_motion"],
       "wai_determinism": "decode-equivalence",
       "wai_receipts": true, "wai_receipt_alias": 7,
       "wai_receipts_track": "cam1/base/receipts",
       "wai_staged": { "set": "cam1", "layer": 0,
                       "lead_ms": null } },
     { "namespace": "example/cam1", "name": "cam1/L1",
       "packaging": "wai", "isLive": true, "targetLatency": 300,
       "role": "video", "renderGroup": 1, "depends": ["cam1/base"],
       "wai_capabilities": ["wai.video.int_refine"],
       "wai_determinism": "decode-equivalence",
       "wai_receipts": true, "wai_receipt_alias": 8,
       "wai_receipts_track": "cam1/L1/receipts",
       "wai_staged": { "set": "cam1", "layer": 1, "lead_ms": 20 } },
     { "namespace": "example/cam1", "name": "cam1/base/receipts",
       "packaging": "wai-receipts", "isLive": true },
     { "namespace": "example/cam1", "name": "cam1/L1/receipts",
       "packaging": "wai-receipts", "isLive": true },
     { "namespace": "example/net", "name": "pictures",
       "packaging": "wai", "isLive": false, "role": "video",
       "wai_capabilities": ["wai.neural.int_hyper",
                            "wai.image.png"],
       "wai_determinism": "decode-equivalence",
       "wai_priors": [
         { "capability": "wai.neural.int_hyper",
           "sha256":
    "a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1",
           "form": "wai.prior.set", "tier": "decode-equivalence" } ],
       "wai_receipts": true, "wai_receipt_alias": 9,
       "wai_receipts_track": "pictures/receipts" },
     { "namespace": "example/net", "name": "pictures/receipts",
       "packaging": "wai-receipts", "isLive": false } ] }

   An object on "pictures" is a WAI envelope whose capability is
   "wai.neural.int_hyper", whose fallback is "wai.image.png", and whose
   pin names the listed set.  A receiver that holds that set decodes the
   learned payload; one that does not falls back to PNG.  An object
   whose pin named another set would refuse the track.








Charlot                   Expires 24 April 2027                [Page 34]

Internet-Draft            WAI Packaging for MSF             October 2026


Appendix B.  Refusal Reasons

       +=================================================+=========+
       | Reason                                          | Raised  |
       |                                                 | by      |
       +=================================================+=========+
       | missing_capability                              | Section |
       |                                                 | 4.3     |
       +-------------------------------------------------+---------+
       | pin_malformed, form_not_registered,             | Section |
       | form_unreadable, form_required, prior_revoked,  | 4.4     |
       | prior_not_authorised, prior_not_held,           |         |
       | digest_superseded, set_malformed,               |         |
       | part_mismatch, set_incomplete                   |         |
       +-------------------------------------------------+---------+
       | tier_exceeds_class                              | Section |
       |                                                 | 4.5     |
       +-------------------------------------------------+---------+
       | catalog_priors_malformed,                       | Section |
       | catalog_prior_mismatch                          | 5.3     |
       +-------------------------------------------------+---------+
       | staged-malformed, staged-set-incomplete,        | Section |
       | staged-depends, staged-grouping, staged-lead,   | 5.4     |
       | staged-receipts                                 |         |
       +-------------------------------------------------+---------+
       | moqt_mismatch                                   | Section |
       |                                                 | 6.7     |
       +-------------------------------------------------+---------+
       | malformed, group_label_invalid, bad_signer_key, | Section |
       | signature_verify_failed, chain_break,           | 6.8     |
       | parent_not_held, parent_not_recovered,          |         |
       | group_id_not_increasing, content_hash_mismatch, |         |
       | object_label_invalid, proof_position_mismatch,  |         |
       | inclusion_proof_failed, group_total_mismatch    |         |
       +-------------------------------------------------+---------+
       | property_invalid, property_disagrees            | Section |
       |                                                 | 6.9     |
       +-------------------------------------------------+---------+

                          Table 7: Refusal Reasons

Appendix C.  Correspondence with the WAI Texts

   This document restates, for carriage over MOQT, parts of the WAI
   specification and its extensions.  Where this document and the cited
   text differ, the difference is a defect in one of them.





Charlot                   Expires 24 April 2027                [Page 35]

Internet-Draft            WAI Packaging for MSF             October 2026


    +============================+===================================+
    | This document              | WAI text                          |
    +============================+===================================+
    | Section 4.1, Section 4.2   | [WAI] Sections 2 and 3            |
    +----------------------------+-----------------------------------+
    | Section 4.3                | [WAI] Section 4                   |
    +----------------------------+-----------------------------------+
    | Section 4.4                | [WAI] Section 3.1; [WAI-PRIOR]    |
    +----------------------------+-----------------------------------+
    | Section 4.5                | [WAI-TIERS] Sections 2 and 3      |
    +----------------------------+-----------------------------------+
    | Section 5.1, Section 5.2   | [WAI-MOQ] Sections 3 and 4        |
    +----------------------------+-----------------------------------+
    | Section 5.3                | [WAI-MOQ] Section 4.2             |
    +----------------------------+-----------------------------------+
    | Section 5.4                | [WAI-MOQ] Section 4.1             |
    +----------------------------+-----------------------------------+
    | Section 6.2 to Section 6.8 | [WAI-JWP] Sections 2, 2.7 and 3;  |
    |                            | [WAI-ENERGY] Sections 2.3 and 2.7 |
    +----------------------------+-----------------------------------+
    | Section 6.9                | [WAI-MOQ] Section 5               |
    +----------------------------+-----------------------------------+
    | Section 7, Section 10.3    | [WAI-HTTP] Sections 3 and 4       |
    +----------------------------+-----------------------------------+

                         Table 8: Correspondence

Author's Address

   David Charlot
   Transaction Science
   Email: TBD (owner confirms at submission)



















Charlot                   Expires 24 April 2027                [Page 36]