Media Over QUIC W. Law Internet-Draft Akamai Intended status: Informational S. Nandakumar Expires: 4 December 2026 Cisco 2 June 2026 MOQT Streaming Format draft-ietf-moq-msf-01 Abstract This document specifies the MOQT Streaming Format, designed to operate on Media Over QUIC Transport. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://moq- wg.github.io/msf/ draft-ietf-moq-msf.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- ietf-moq-msf/. Discussion of this document takes place on the Media Over QUIC Working Group mailing list (mailto:moq@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at https://www.ietf.org/mailman/listinfo/moq/. Source for this draft and an issue tracker can be found at https://github.com/moq-wg/msf. 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/. 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 4 December 2026. Law & Nandakumar Expires 4 December 2026 [Page 1] Internet-Draft MOQT Streaming Format June 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Media packaging . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. LOC packaging . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Time-alignment . . . . . . . . . . . . . . . . . . . . . 7 4.3. Content protection and encryption . . . . . . . . . . . . 8 4.3.1. Encryption scheme signaling . . . . . . . . . . . . . 8 4.3.2. Key management . . . . . . . . . . . . . . . . . . . 8 4.3.3. Recommended encryption scheme . . . . . . . . . . . . 9 4.3.4. Encrypted object structure . . . . . . . . . . . . . 9 5. Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Root Catalog Fields . . . . . . . . . . . . . . . . . . . 10 5.1.1. MSF version . . . . . . . . . . . . . . . . . . . . . 11 5.1.2. Generated at . . . . . . . . . . . . . . . . . . . . 11 5.1.3. Is Complete . . . . . . . . . . . . . . . . . . . . . 11 5.1.4. Tracks . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.5. Publish tracks . . . . . . . . . . . . . . . . . . . 12 5.1.6. Delta update . . . . . . . . . . . . . . . . . . . . 12 5.1.7. Initialization Data List . . . . . . . . . . . . . . 13 5.2. Track Object Fields . . . . . . . . . . . . . . . . . . . 13 5.2.1. Tracks object . . . . . . . . . . . . . . . . . . . . 15 5.2.2. Track namespace . . . . . . . . . . . . . . . . . . . 15 5.2.3. Track name . . . . . . . . . . . . . . . . . . . . . 15 5.2.4. Packaging . . . . . . . . . . . . . . . . . . . . . . 16 5.2.5. Event timeline type . . . . . . . . . . . . . . . . . 16 5.2.6. Track role . . . . . . . . . . . . . . . . . . . . . 16 5.2.7. Is Live . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.8. Target latency . . . . . . . . . . . . . . . . . . . 18 5.2.9. Buffers . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.10. Track label . . . . . . . . . . . . . . . . . . . . . 19 5.2.11. Render group . . . . . . . . . . . . . . . . . . . . 19 Law & Nandakumar Expires 4 December 2026 [Page 2] Internet-Draft MOQT Streaming Format June 2026 5.2.12. Alternate group . . . . . . . . . . . . . . . . . . . 19 5.2.13. Initialization reference . . . . . . . . . . . . . . 19 5.2.14. Dependencies . . . . . . . . . . . . . . . . . . . . 20 5.2.15. Template . . . . . . . . . . . . . . . . . . . . . . 20 5.2.16. Temporal ID . . . . . . . . . . . . . . . . . . . . . 20 5.2.17. Spatial ID . . . . . . . . . . . . . . . . . . . . . 20 5.2.18. Codec . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2.19. Mimetype . . . . . . . . . . . . . . . . . . . . . . 21 5.2.20. Framerate . . . . . . . . . . . . . . . . . . . . . . 21 5.2.21. Timescale . . . . . . . . . . . . . . . . . . . . . . 21 5.2.22. Maximum Bitrate . . . . . . . . . . . . . . . . . . . 21 5.2.23. Average Bitrate . . . . . . . . . . . . . . . . . . . 21 5.2.24. Maximum GOP Duration . . . . . . . . . . . . . . . . 21 5.2.25. Maximum Group Duration . . . . . . . . . . . . . . . 22 5.2.26. Width . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.27. Height . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.28. Audio sample rate . . . . . . . . . . . . . . . . . . 22 5.2.29. Channel configuration . . . . . . . . . . . . . . . . 22 5.2.30. Display width . . . . . . . . . . . . . . . . . . . . 22 5.2.31. Display height . . . . . . . . . . . . . . . . . . . 23 5.2.32. Language . . . . . . . . . . . . . . . . . . . . . . 23 5.2.33. Parent name . . . . . . . . . . . . . . . . . . . . . 23 5.2.34. Parent namespace . . . . . . . . . . . . . . . . . . 23 5.2.35. Track duration . . . . . . . . . . . . . . . . . . . 23 5.2.36. Connection URI . . . . . . . . . . . . . . . . . . . 23 5.2.37. Token . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.38. Encryption scheme . . . . . . . . . . . . . . . . . . 24 5.2.39. Cipher suite . . . . . . . . . . . . . . . . . . . . 24 5.2.40. Key ID . . . . . . . . . . . . . . . . . . . . . . . 25 5.2.41. Track Base Key . . . . . . . . . . . . . . . . . . . 26 5.2.42. Authorization Info . . . . . . . . . . . . . . . . . 26 5.2.43. Token Delivery via URI . . . . . . . . . . . . . . . 27 5.2.44. Accessibility . . . . . . . . . . . . . . . . . . . . 27 5.3. Delta updates . . . . . . . . . . . . . . . . . . . . . . 28 5.4. Variable Substitution . . . . . . . . . . . . . . . . . . 29 5.4.1. Variable Syntax . . . . . . . . . . . . . . . . . . . 29 5.4.2. Variable Resolution . . . . . . . . . . . . . . . . . 29 5.5. Catalog Compression . . . . . . . . . . . . . . . . . . . 30 5.6. Catalog Examples . . . . . . . . . . . . . . . . . . . . 30 5.6.1. Time-aligned Audio/Video Tracks with single quality . . . . . . . . . . . . . . . . . . . . . . . 30 5.6.2. Simulcast video tracks - 3 alternate qualities along with audio . . . . . . . . . . . . . . . . . . . . . 31 5.6.3. SVC video tracks with 2 spatial and 2 temporal qualities . . . . . . . . . . . . . . . . . . . . . . 33 5.6.4. Delta update - adding two tracks . . . . . . . . . . 35 5.6.5. Delta update removing tracks . . . . . . . . . . . . 36 Law & Nandakumar Expires 4 December 2026 [Page 3] Internet-Draft MOQT Streaming Format June 2026 5.6.6. Time-aligned Audio/Video Tracks with custom field values . . . . . . . . . . . . . . . . . . . . . . . 37 5.6.7. Time-aligned VOD Audio/Video Tracks . . . . . . . . . 38 5.6.8. Encrypted Audio/Video Tracks . . . . . . . . . . . . 39 5.6.9. Media timeline and Event timeline . . . . . . . . . . 40 5.6.10. Media timeline template . . . . . . . . . . . . . . . 42 5.6.11. Video track with embedded captions and SCTE-35 events . . . . . . . . . . . . . . . . . . . . . . . 43 5.6.12. Video track with CEA-708 captions . . . . . . . . . . 45 5.6.13. Terminating a live broadcast . . . . . . . . . . . . 45 5.6.14. Variable Substitution for personalized delivery . . . 46 5.6.15. Time-aligned Audio/Video Tracks with Authorization . 47 5.6.16. Publish tracks for logs and metrics . . . . . . . . . 48 6. Media transmission . . . . . . . . . . . . . . . . . . . . . 50 6.1. Group numbering . . . . . . . . . . . . . . . . . . . . . 50 6.2. Object Numbering . . . . . . . . . . . . . . . . . . . . 50 7. Media Timeline track . . . . . . . . . . . . . . . . . . . . 51 7.1. Media Timeline track payload . . . . . . . . . . . . . . 51 7.1.1. Explicit entry format . . . . . . . . . . . . . . . . 51 7.2. Media Timeline Catalog requirements . . . . . . . . . . . 52 7.3. Media Timeline track updating . . . . . . . . . . . . . . 52 7.4. Media Timeline Template . . . . . . . . . . . . . . . . . 52 7.4.1. Template Format . . . . . . . . . . . . . . . . . . . 52 7.4.2. Template Immutability . . . . . . . . . . . . . . . . 53 8. Event Timeline track . . . . . . . . . . . . . . . . . . . . 54 8.1. Event Timeline data format . . . . . . . . . . . . . . . 54 8.2. Event Timeline Catalog requirements . . . . . . . . . . . 54 8.3. Event Timeline track updating . . . . . . . . . . . . . . 55 8.4. Event timeline track examples . . . . . . . . . . . . . . 55 8.4.1. Event timeline track with wallclock time indexing . . 55 8.4.2. Event timeline track with MOQT Location indexing . . 56 9. Log track . . . . . . . . . . . . . . . . . . . . . . . . . . 56 9.1. Log track payload . . . . . . . . . . . . . . . . . . . . 56 9.2. Log track namespace and name . . . . . . . . . . . . . . 56 9.3. Log track Group ID and Object ID . . . . . . . . . . . . 57 9.4. Log track catalog requirements . . . . . . . . . . . . . 57 10. Metrics track . . . . . . . . . . . . . . . . . . . . . . . . 57 10.1. Metrics track payload . . . . . . . . . . . . . . . . . 57 10.2. Metrics track namespace and name . . . . . . . . . . . . 58 10.3. Metrics track Group ID and Object ID . . . . . . . . . . 58 10.4. Metrics track catalog requirements . . . . . . . . . . . 58 10.5. Well-known event timeline types . . . . . . . . . . . . 59 11. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 59 11.1. URL construction and interpretation . . . . . . . . . . 59 11.1.1. Reserved fragment parameters . . . . . . . . . . . . 62 11.1.2. MSF Namespace-Name String Encoding . . . . . . . . . 63 11.1.3. Example MSF URLs . . . . . . . . . . . . . . . . . . 64 11.2. Initiating a broadcast . . . . . . . . . . . . . . . . . 65 Law & Nandakumar Expires 4 December 2026 [Page 4] Internet-Draft MOQT Streaming Format June 2026 11.3. Ending a live broadcast . . . . . . . . . . . . . . . . 65 11.4. Authorization . . . . . . . . . . . . . . . . . . . . . 65 11.4.1. Discovering Authorization Requirements . . . . . . . 65 11.4.2. Token Acquisition . . . . . . . . . . . . . . . . . 66 11.4.3. Presenting Authorization . . . . . . . . . . . . . . 66 11.4.4. Handling Authorization Failures . . . . . . . . . . 67 12. MSF Properties . . . . . . . . . . . . . . . . . . . . . . . 67 12.1. Compression Signaling . . . . . . . . . . . . . . . . . 67 12.1.1. MSF_COMPRESSION Track Property . . . . . . . . . . . 68 12.1.2. MSF_COMPRESSION Object Property . . . . . . . . . . 69 13. Security Considerations . . . . . . . . . . . . . . . . . . . 69 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 14.1. "MOQT URI Fragment Types" registry . . . . . . . . . . . 69 14.2. "MSF Event Timeline Types" registry . . . . . . . . . . 69 14.3. MSF_COMPRESSION Track Property . . . . . . . . . . . . . 70 14.4. MSF_COMPRESSION Object Property . . . . . . . . . . . . 70 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 15.1. Normative References . . . . . . . . . . . . . . . . . . 71 15.2. Informative References . . . . . . . . . . . . . . . . . 73 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 74 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 1. Introduction MOQT Streaming Format (MSF) is a media format designed to deliver LOC [LOC] compliant media content over Media Over QUIC Transport (MOQT) [MoQTransport]. MSF works by fragmenting the bitstream into objects that can be independently transmitted. MSF leverages a catalog format to describe the output of the original publisher. MSF specifies how content should be packaged and signaled, defines how the catalog communicates the content, specifies prioritization strategies for real-time and workflows for beginning and terminating broadcasts. MSF also details how end-subscribers may perform adaptive bitrate switching. MSF is targeted at real-time and interactive levels of live latency, as well as VOD content. This document describes version 1 of the streaming format. 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. Law & Nandakumar Expires 4 December 2026 [Page 5] Internet-Draft MOQT Streaming Format June 2026 This document uses the conventions detailed in Section 1.3 of [RFC9000] when describing the binary encoding. 3. Scope The purpose of MSF is to provide an interoperable media streaming format operating over [MoQTransport]. Interoperability implies that: * An original publisher can package incoming media content into tracks, prepare a catalog and announce the availability of the content to an MOQT relay. Media content refers to audio and video data, as well as ancillary data such as captions, subtitles, accessibility and other timed-text data. * An MOQT relay can process the announcement as well as cache and propagate the tracks, both to other relays or to the final subscriber. * A final subscriber can parse the catalog, request tracks, decode and render the received media data. MSF is intended to provide a format for delivering commercial media content. To that end, the following features are within scope: * Video codecs - all codecs supported by [LOC] * Audio codecs - all audio codecs supported by [LOC] * Catalog track - describes the availability and characteristics of content produced by the original publisher. * Timeline track - describes the relationship between MOQT Group and Object IDs to media time. * Token-based authorization and access control * Captions + Subtitles - support for [WEBVTT] and [IMSC1] transmission * Latency support across multiple regimes (thresholds are informative only and describe the delay between the original publisher placing the content on the wire and the final subscriber rendering it) * Real-time - less than 500ms * Interactive - between 500ms and 2500ms Law & Nandakumar Expires 4 December 2026 [Page 6] Internet-Draft MOQT Streaming Format June 2026 * Standard - above 2500ms * VOD latency - content that was previously produced, is no longer live and is available indefinitely. * Content encryption * ABR between time-synced tracks - subscribers may switch between tracks at different quality levels in order to maximize visual or audio quality under conditions of throughput variability. * Capable of delivering interstitial advertising. * Logs and analytics management - support for the reporting of client-side QoE and relay delivery actions via publish tracks using [MOQLOG] and [MOQMETRICS]. Initial versions of MSF will prioritize basic features necessary to exercise interoperability across delivery systems. Later versions will add commercially necessary features. 4. Media packaging MSF delivers LOC [LOC] packaged media bitstreams. 4.1. LOC packaging This specification references Low Overhead Container (LOC) [LOC] to define how audio and video content is packaged. With this packaging mode, each EncodedAudioChunk or EncodedVideoChunk sample is placed in a separate MOQT Object. Samples that belong to the same Group of Pictures (GOP) MUST be placed within the same MOQT Group. When LOC packaging is used for a track, the catalog packaging attribute (Section 5.2.4) MUST be present and it MUST be populated with a value of "loc". 4.2. Time-alignment MSF Tracks MAY be time-aligned. Those that are, are subject to the following requirements: * Tracks advertised in the catalog as belonging to a common alternate group MUST be time-aligned. * The render duration of the first media object of each equally numbered MOQT Group, after decoding, SHOULD have overlapping presentation time. Law & Nandakumar Expires 4 December 2026 [Page 7] Internet-Draft MOQT Streaming Format June 2026 A consequence of this restriction is that an MSF receiver SHOULD be able to cleanly switch between time-aligned media tracks at group boundaries. If time-aligned media tracks do not have overlapping presentation time at equally-numbered group boundaries, then an alternate mechanism, not defined by this specification, must be provided to the client to enable it to switch smoothly between time-aligned, but numerically dissimilar, Group IDs. 4.3. Content protection and encryption MSF supports end-to-end encryption of media content using MoQ Secure Objects [SecureObjects]. When encryption is enabled, the payload of LOC-packaged media objects is encrypted and authenticated, while relays can still route content based on unencrypted header information. 4.3.1. Encryption scheme signaling The encryption scheme and parameters are signaled in the catalog using the following track-level fields: * encryptionScheme Section 5.2.38 - identifies the encryption mechanism * cipherSuite Section 5.2.39 - specifies the AEAD algorithm * keyId Section 5.2.40 - identifies the key material for decryption * trackBaseKey Section 5.2.41 - the base key material for this track When the encryptionScheme field is present in a track definition, subscribers MUST decrypt the object payload using the specified scheme before processing. 4.3.2. Key management The keyId and trackBaseKey values are obtained from an external key management system and the mechanism for obtaining these values is out of scope for this specification. Examples of key management systems include MLS-based key distribution [E2EE-MLS] or other out-of-band key exchange mechanisms. Depending on the key management mechanism in use, a keyId MAY be scoped to: * A single track Law & Nandakumar Expires 4 December 2026 [Page 8] Internet-Draft MOQT Streaming Format June 2026 * A single MoQ Session * Multiple tracks across one or more MoQ sessions Publishers and subscribers MUST use the same key management system and agree on the keyId scope semantics for interoperable operation. 4.3.3. Recommended encryption scheme The RECOMMENDED encryption scheme for MSF is "moq-secure-objects". Implementations supporting content encryption MUST implement the "moq-secure-objects" scheme as defined in [SecureObjects]. When using the "moq-secure-objects" scheme: * The cipherSuite field MUST be present and set to a supported cipher suite value * The keyId field MUST be present to identify the key material * The trackBaseKey field MUST be present to provide the base key material 4.3.4. Encrypted object structure For LOC-packaged tracks with encryption enabled (see [SecureObjects], Section 4): * The immutable header extensions (including Group ID and Object ID) remain in plaintext and are authenticated * The object payload is encrypted and authenticated using the specified cipher * Private header extensions (type 0xA) are encrypted alongside the payload 5. Catalog A Catalog is an MOQT Track that provides information about the other tracks being produced by a MSF publisher. A Catalog is used by MSF publishers for advertising their output and for subscribers in consuming that output. The payload of the Catalog object is opaque to Relays and can be end-to-end encrypted. The Catalog provides the names and namespaces of the tracks being produced, along with the relationship between tracks, properties of the tracks that consumers may use for selection and any relevant initialization data. Law & Nandakumar Expires 4 December 2026 [Page 9] Internet-Draft MOQT Streaming Format June 2026 The catalog track MUST have a case-sensitive Track Name of "catalog". A catalog object MAY be independent of other catalog objects or it MAY represent a delta update of a prior catalog object. The first catalog object published within a new group MUST be independent and MUST provide a complete catalog that does not require any prior catalog object for interpretation. Any catalog updates that precede the first Object of the latest Group MUST be ignored. A catalog object SHOULD be published only when the availability of tracks changes, or after a period of time has passed such that the catalog object might fall out of cache in a delivery network. Each catalog update MUST be mapped to an MOQT Object. All catalog updates, both independent and delta, MUST be mapped to MOQT sub-group 0. The first Object (with Object ID 0) in any Group in a catalog track MUST hold an independent copy of the catalog. All subsequent Objects within that Group (i.e Objects IDs >= 1) MUST hold a delta update. As soon as an independent update is produced, it MUST be placed at the start of a new Group. Subscribers accessing the catalog MUST use SUBSCRIBE with a Joining FETCH (offset = 0) in order to obtain the latest complete catalog along with all subsequent catalog objects, including delta updates, that follow. A catalog is a JSON [JSON] document, comprised of a series of mandatory and optional fields. At a minimum, a catalog MUST provide all mandatory fields. Some fields are conditional depending on the type of content carried. A producer MAY add additional fields to the ones described in this draft. Custom field names MUST NOT collide with field names described in this draft. A parser MUST ignore fields it does not understand. 5.1. Root Catalog Fields Table 1 lists the fields defined at the root of the catalog JSON object. Law & Nandakumar Expires 4 December 2026 [Page 10] Internet-Draft MOQT Streaming Format June 2026 +==========================+===============+===============+ | Field | Name | Definition | +==========================+===============+===============+ | MSF version | version | Section 5.1.1 | +--------------------------+---------------+---------------+ | Generated at | generatedAt | Section 5.1.2 | +--------------------------+---------------+---------------+ | Is Complete | isComplete | Section 5.1.3 | +--------------------------+---------------+---------------+ | Tracks | tracks | Section 5.1.4 | +--------------------------+---------------+---------------+ | Publish tracks | publishTracks | Section 5.1.5 | +--------------------------+---------------+---------------+ | Delta update | deltaUpdate | Section 5.1.6 | +--------------------------+---------------+---------------+ | Initialization Data List | initDataList | Section 5.1.7 | +--------------------------+---------------+---------------+ Table 1 5.1.1. MSF version Required: Yes JSON Type: String Location: Root Catalog Specifies the version of MSF referenced by this catalog. There is no guarantee that future catalog versions are backwards compatible and field definitions and interpretation may change between versions. A subscriber MUST NOT attempt to parse a catalog version which it does not understand. For usage against IETF Internet-Draft releases, follow the convention of specifying the version as "draft-XX". For example "draft-03" refers to the -03 draft release. 5.1.2. Generated at Required: Optional JSON Type: Number Location: Root Catalog The wallclock time at which this catalog instance was generated, expressed as the number of milliseconds that have elapsed since January 1, 1970 (midnight UTC/GMT). This field SHOULD NOT be included if the isLive field is false. 5.1.3. Is Complete Required: Optional JSON Type: Boolean Location: Root Catalog Law & Nandakumar Expires 4 December 2026 [Page 11] Internet-Draft MOQT Streaming Format June 2026 A catalog-level indication that the broadcast is complete. This is a commitment that all tracks are complete, no new tracks will be added to the catalog, and no new content will be published on any track. Note that even if all individual tracks have isLive Section 5.2.7 set to FALSE, new tracks could still be added to the catalog until isComplete is set to TRUE. This field MUST NOT be included if it is FALSE. This field MUST NOT be removed from a catalog once it has been added. 5.1.4. Tracks Required: Yes JSON Type: Array Location: Root Catalog An array of track objects Section 5.2.1. 5.1.5. Publish tracks Location: R Required: Optional JSON Type: Array An array of publish track objects. Publish tracks define tracks to which the subscriber can publish data, such as logs, metrics, or other QoE data. This enables bi-directional communication where the subscriber acts as a publisher for specific tracks. Each publish track object follows the same structure as a regular track object Section 5.2.1 but is used for the reverse direction of data flow. 5.1.6. Delta update Required: Optional JSON Type: Array Location: Root Catalog An ordered Array of operation objects that specify changes to apply to the catalog. If this field is present, the catalog represents a delta (or partial) update with a restricted set of fields and special processing rules - see Section 5.3. If this field is absent, the catalog is independent. Operations are applied sequentially in the order they appear in the array. Each operation object MUST contain an "op" field indicating the operation type, and a "tracks" field containing an Array of track objects Section 5.2.1. The following operation types are defined: * "add" - Add new tracks that have not previously been declared. The value of the "tracks" field is an Array of track objects Section 5.2.1. Law & Nandakumar Expires 4 December 2026 [Page 12] Internet-Draft MOQT Streaming Format June 2026 * "remove" - Remove tracks that have been previously declared. The value of the "tracks" field is an Array of track objects Section 5.2.1. Each track object MUST include a Track Name Section 5.2.3 field, MAY include a Track Namespace Section 5.2.2 field, and MUST NOT hold any other fields. * "clone" - Clone new tracks from previously declared tracks. The value of the "tracks" field is an Array of track objects Section 5.2.1. Each track object MUST include a Parent Name Section 5.2.33 field and MAY include a Parent namespace Section 5.2.34 field. The cloned track inherits all attributes from the parent except the Track Name which MUST be new. Attributes redefined in the track object override inherited values. 5.1.7. Initialization Data List Required: Optional JSON Type: Array Location: Root Catalog An array of initialization reference objects. Each initialization reference object has the following fields: * id : a string defining a reference to this initialization data which is unique within the scope of the catalog. * type: as string defining the type of reference. This version of the specification defines a single allowed type, per the table below +========+=============================================+ | Type | Data field definition | +========+=============================================+ | inline | Base64 [BASE64] encoded initialization data | +--------+---------------------------------------------+ Table 2 * data: a string holding the init payload as defined by the type. The Initialization Data List, if present, MUST be located after the tracks array in the root of the JSON catalog. The purpose of this is to improve the human readability of the catalog tracks by moving the verbose init data towards the end of the document. 5.2. Track Object Fields Table 2 lists the fields defined within each track object. Law & Nandakumar Expires 4 December 2026 [Page 13] Internet-Draft MOQT Streaming Format June 2026 +========================+==================+================+ | Field | Name | Definition | +========================+==================+================+ | Track namespace | namespace | Section 5.2.2 | +------------------------+------------------+----------------+ | Track name | name | Section 5.2.3 | +------------------------+------------------+----------------+ | Packaging | packaging | Section 5.2.4 | +------------------------+------------------+----------------+ | Event timeline type | eventType | Section 5.2.5 | +------------------------+------------------+----------------+ | Is Live | isLive | Section 5.2.7 | +------------------------+------------------+----------------+ | Target latency | targetLatency | Section 5.2.8 | +------------------------+------------------+----------------+ | Buffers | buffers | Section 5.2.9 | +------------------------+------------------+----------------+ | Track role | role | Section 5.2.6 | +------------------------+------------------+----------------+ | Track label | label | Section 5.2.10 | +------------------------+------------------+----------------+ | Render group | renderGroup | Section 5.2.11 | +------------------------+------------------+----------------+ | Alternate group | altGroup | Section 5.2.12 | +------------------------+------------------+----------------+ | Initialization ref | initRef | Section 5.2.13 | +------------------------+------------------+----------------+ | Dependencies | depends | Section 5.2.14 | +------------------------+------------------+----------------+ | Temporal ID | temporalId | Section 5.2.16 | +------------------------+------------------+----------------+ | Spatial ID | spatialId | Section 5.2.17 | +------------------------+------------------+----------------+ | Codec | codec | Section 5.2.18 | +------------------------+------------------+----------------+ | Mime type | mimeType | Section 5.2.19 | +------------------------+------------------+----------------+ | Framerate | framerate | Section 5.2.20 | +------------------------+------------------+----------------+ | Timescale | timescale | Section 5.2.21 | +------------------------+------------------+----------------+ | Maximum Bitrate | bitrate | Section 5.2.22 | +------------------------+------------------+----------------+ | Average Bitrate | avgBitrate | Section 5.2.23 | +------------------------+------------------+----------------+ | Maximum GOP Duration | maxGopDuration | Section 5.2.24 | +------------------------+------------------+----------------+ | Maximum Group Duration | maxGroupDuration | Section 5.2.25 | Law & Nandakumar Expires 4 December 2026 [Page 14] Internet-Draft MOQT Streaming Format June 2026 +------------------------+------------------+----------------+ | Width | width | Section 5.2.26 | +------------------------+------------------+----------------+ | Height | height | Section 5.2.27 | +------------------------+------------------+----------------+ | Audio sample rate | samplerate | Section 5.2.28 | +------------------------+------------------+----------------+ | Channel configuration | channelConfig | Section 5.2.29 | +------------------------+------------------+----------------+ | Display width | displayWidth | Section 5.2.30 | +------------------------+------------------+----------------+ | Display height | displayHeight | Section 5.2.31 | +------------------------+------------------+----------------+ | Language | lang | Section 5.2.32 | +------------------------+------------------+----------------+ | Parent name | parentName | Section 5.2.33 | +------------------------+------------------+----------------+ | Parent namespace | parentNamespace | Section 5.2.34 | +------------------------+------------------+----------------+ | Track duration | trackDuration | Section 5.2.35 | +------------------------+------------------+----------------+ | Authorization Info | authInfo | Section 5.2.42 | +------------------------+------------------+----------------+ | Accessibility | accessibility | Section 5.2.44 | +------------------------+------------------+----------------+ Table 3 5.2.1. Tracks object A track object is a JSON Object containing a collection of fields whose location is specified in Table 2. 5.2.2. Track namespace Required: Optional JSON Type: String Location: Track Object The name space under which the track name is defined. See section 2.3 of [MoQTransport]. The track namespace is optional. If it is not declared within a track, then each track MUST inherit the namespace of the catalog track. A namespace declared in a track object overrides any inherited name space. 5.2.3. Track name Required: Yes JSON Type: String Location: Track Object Law & Nandakumar Expires 4 December 2026 [Page 15] Internet-Draft MOQT Streaming Format June 2026 A string defining the name of the track. See section 2.3 of [MoQTransport]. Within the catalog, track names MUST be unique per namespace. 5.2.4. Packaging Required: Yes JSON Type: String Location: Track Object A string defining the type of payload encapsulation. Allowed values are strings as defined in Table 3. +================+===============+==================+ | Name | Value | Reference | +================+===============+==================+ | LOC | loc | See RFC XXXX | +----------------+---------------+------------------+ | Media Timeline | mediatimeline | See Section 7 | +----------------+---------------+------------------+ | Event Timeline | eventtimeline | See Section 8 | +----------------+---------------+------------------+ | MoQ Log | moqlog | See [MOQLOG] | +----------------+---------------+------------------+ | MoQ Metrics | moqmetrics | See [MOQMETRICS] | +----------------+---------------+------------------+ Table 4 Table 3: Allowed packaging values 5.2.5. Event timeline type Required: Optional JSON Type: String Location: Track Object A String defining the type & structure of the data contained within the data field of the Event timeline track. Types are defined by the application provider and are not centrally registered. Implementers are encouraged to use a unique naming scheme, such as Reverse Domain Name Notation, where domain name components are listed in reverse order (e.g., "com.example.myeventtype"), to avoid naming collisions. This field is required if the Section 5.2.4 value is "eventtimeline". This field MUST NOT be used if the packaging value is not "eventtimeline". 5.2.6. Track role Required: Optional JSON Type: String Location: Track Object Law & Nandakumar Expires 4 December 2026 [Page 16] Internet-Draft MOQT Streaming Format June 2026 A string defining the role of content carried by the track. Specified roles are described in Table 4. These role values are case-sensitive. This role field MAY be used in conjunction with the Mimetype Section 5.2.19 to fully describe the content of the track. Table 4: Reserved track roles +==================+==========================+ | Role | Description | +==================+==========================+ | audiodescription | An audio description for | | | visually impaired users | +------------------+--------------------------+ | video | Visual content | +------------------+--------------------------+ | audio | Audio content | +------------------+--------------------------+ | mediatimeline | An MSF media timeline | | | Section 7 | +------------------+--------------------------+ | eventtimeline | An MSF event timeline | | | Section 8 | +------------------+--------------------------+ | caption | A textual representation | | | of the audio track | +------------------+--------------------------+ | subtitle | A transcription of the | | | spoken dialogue | +------------------+--------------------------+ | signlanguage | A visual track for | | | hearing impaired users. | +------------------+--------------------------+ | log | A log publishing track | | | per [MOQLOG]. | +------------------+--------------------------+ | metrics | A metrics publishing | | | track per [MOQMETRICS]. | +------------------+--------------------------+ Table 5 Custom roles MAY be used as long as they do not collide with the specified roles. Law & Nandakumar Expires 4 December 2026 [Page 17] Internet-Draft MOQT Streaming Format June 2026 5.2.7. Is Live Required: Yes JSON Type: Boolean Location: Track Object A track-level indication of whether new Objects will be added to this specific track. True if new Objects will be added to the track. False if no new Objects will be added to the track. A False value is sent under two possible conditions: * the publisher of a previously live track has ended the track. * the track is Video-On-Demand (VOD) and was never live. A True value MUST never follow a False value. 5.2.8. Target latency Required: Optional JSON Type: Number Location: Track Object The target latency in milliseconds. Target latency is defined as the offset in wallclock time between when content was encoded and when it is displayed to the end user. For example, if a frame of video is encoded at 10:08:32.638 UTC and the target latency is 5000, then that frame should be rendered to the end-user at 10:08:37.638 UTC. If isLive is FALSE, this field MUST be ignored. All tracks belonging to the same render group MUST have identical target latencies. All tracks belonging to the same alternate group MUST have identical target latencies. If this field is absent from the track definition, and isLive is TRUE, then the player MAY choose the latency with which it renders the content. This property MUST NOT be present if the buffers Section 5.2.9 property is present within a track definition. 5.2.9. Buffers Required: Optional JSON Type: Object Location: Track Object An object defining a set of target buffers. Buffer is defined as the duration of media data that MUST be buffered before decoding commences. This is typically known as a forward or jitter-buffer in a media player.Players with identical buffer lengths are likely to be synchronized. The target buffer object has these keys: * target : defines the target buffer in integer milliseconds. Players SHOULD attempt to stabilize playback at this value. * min : defines the minimum buffer in milliseconds. Players SHOULD NOT operate below this value. * max : defines the maximum buffer in milliseconds. Players SHOULD NOT operate above this value. Law & Nandakumar Expires 4 December 2026 [Page 18] Internet-Draft MOQT Streaming Format June 2026 Keys are optional. Unknown keys in the target buffer object MUST be ignored. If isLive is FALSE, this target buffer property MUST be ignored. All tracks belonging to the same render group MUST have identical target buffers. All tracks belonging to the same alternate group MUST have identical target buffers. If this field is absent from the track definition, and isLive is TRUE, then the player MAY choose the buffers with which it conducts playback. This property MUST NOT be present if the target latency Section 5.2.8 property is present within a track definition. 5.2.10. Track label Required: Optional JSON Type: String Location: Track Object A string defining a human-readable label for the track. Examples might be "Overhead camera view" or "Deutscher Kommentar". Note that the [JSON] spec requires UTF-8 support by decoders. 5.2.11. Render group Required: Optional JSON Type: Number Location: Track Object An integer specifying a group of tracks which are designed to be rendered together. Tracks with the same group number SHOULD be rendered simultaneously and are designed to accompany one another. A common example would be tying together audio and video tracks. 5.2.12. Alternate group Required: Optional JSON Type: Number Location: Track Object An integer specifying a group of tracks which are alternate versions of one-another. Alternate tracks represent the same media content, but differ in their selection properties. Alternate tracks MUST have matching media time sequences. A subscriber typically subscribes to one track from a set of tracks specifying the same alternate group number. A common example would be a set video tracks of the same content offered in alternate bitrates. 5.2.13. Initialization reference Required: Optional JSON Type: String Location: Track Object A string pointing at the id field of an entry in the Initialization Data List Section 5.1.7. Law & Nandakumar Expires 4 December 2026 [Page 19] Internet-Draft MOQT Streaming Format June 2026 5.2.14. Dependencies Required: Optional JSON Type: Array Location: Track Object Certain tracks may depend on other tracks for decoding. Dependencies holds an array of track names Section 5.2.3 on which the current track is dependent. Since only the track name is signaled, the namespace of the dependencies is assumed to match that of the track declaring the dependencies. 5.2.15. Template Required: Optional JSON Type: Array Location: Track Object A media timeline template for tracks with fixed-duration segments. It specifies the relationship between media time, MOQT Location, and wallclock time through starting points and intervals. See Section 7.4 for the complete format specification, field definitions, and computation formulas. Tracks that include a template field SHOULD NOT also have a separate media timeline track, as the template provides equivalent functionality. Different tracks (e.g., audio and video) MAY have independent template values to accommodate different group durations. 5.2.16. Temporal ID Required: Optional JSON Type: Number Location: Track Object A number identifying the temporal layer/sub-layer encoding of the track, starting with 0 for the base layer, and increasing by 1 for the next higher temporal fidelity. 5.2.17. Spatial ID Required: Optional JSON Type: Number Location: Track Object A number identifying the spatial layer encoding of the track, starting with 0 for the base layer, and increasing by 1 for the next higher fidelity. 5.2.18. Codec Required: Conditional JSON Type: String Location: Track Object A string defining the codec used to encode the track. For LOC packaged content, the string codec registrations are defined in Sect 3 and Section 4 of [WEBCODECS-CODEC-REGISTRY]. This property MUST be Law & Nandakumar Expires 4 December 2026 [Page 20] Internet-Draft MOQT Streaming Format June 2026 specified for tracks which have an inherent codec associated with them (e.g., audio and video tracks). It is not required for raw data tracks or event streams. 5.2.19. Mimetype Required: Optional JSON Type: String Location: Track Object A string defining the mime type [MIME] of the track. 5.2.20. Framerate Required: Optional JSON Type: Number Location: Track Object A number defining the framerate of the track, expressed as frames per second. This property SHOULD only accompany video or other frame- based content. 5.2.21. Timescale Required: Optional JSON Type: Number Location: Track Object The number of time units that pass per second. 5.2.22. Maximum Bitrate Required: Conditional JSON Type: Number Location: Track Object A number defining the maximum bitrate of the track, expressed in bits per second. This property MUST be specified for audio and video tracks. 5.2.23. Average Bitrate Required: Optional JSON Type: Number Location: Track Object A number defining the average bitrate of the track, over the lifetime of the track, expressed in bits per second. 5.2.24. Maximum GOP Duration Required: Optional JSON Type: Number Location: Track Object A number defining the maximum duration, expressed in milliseconds, between successive independently decodable points (random access points) in the media track. This property SHOULD only accompany video tracks. Law & Nandakumar Expires 4 December 2026 [Page 21] Internet-Draft MOQT Streaming Format June 2026 5.2.25. Maximum Group Duration Required: Optional JSON Type: Number Location: Track Object A number defining the maximum duration, expressed in milliseconds, of any MOQT Group in this track. This value helps subscribers estimate buffer requirements for the track. 5.2.26. Width Required: Optional JSON Type: Number Location: Track Object A number expressing the maximum encoded width of the video frames in pixels. This property SHOULD accompany tracks which have a visual representation. 5.2.27. Height Required: Optional JSON Type: Number Location: Track Object A number expressing the maximum encoded height of the video frames in pixels. This property SHOULD accompany tracks which have a visual representation. 5.2.28. Audio sample rate Required: Conditional JSON Type: Number Location: Track Object The number of audio frame samples per second. This property MUST accompany tracks for which audio codecs are specified. 5.2.29. Channel configuration Required: Conditional JSON Type: String Location: Track Object A string specifying the audio channel configuration. A string is used in order to provide the flexibility to describe complex channel configurations for multi-channel and Next Generation Audio schemas. This property MUST accompany tracks for which audio codecs are specified. 5.2.30. Display width Required: Optional JSON Type: Number Location: Track Object A number expressing the intended display width of the track content in pixels. This property SHOULD only accompany tracks which have a visual representation. Law & Nandakumar Expires 4 December 2026 [Page 22] Internet-Draft MOQT Streaming Format June 2026 5.2.31. Display height Required: Optional JSON Type: Number Location: Track Object A number expressing the intended display height of the track content in pixels. This property SHOULD only accompany tracks which have a visual representation. 5.2.32. Language Required: Optional JSON Type: String Location: Track Object A string defining the dominant language of the track. The string MUST be one of the standard Tags for Identifying Languages as defined by [LANG]. 5.2.33. Parent name Required: Optional JSON Type: String Location: Track Object A string defining the parent track name Section 5.2.3 to be cloned. This field MUST only be included inside a clone operation in a delta update Section 5.1.6. 5.2.34. Parent namespace Required: Optional JSON Type: String Location: Track Object A string defining the parent track namespace Section 5.2.2 to be cloned. This field MUST only be included inside a clone operation in a delta update Section 5.1.6. If this field is missing from a clone operation, then the namespace of the catalog is assumed. 5.2.35. Track duration Required: Optional JSON Type: Number Location: Track Object The duration of the track expressed in integer milliseconds. This field MUST NOT be included if the isLive Section 5.2.7 field value is true. 5.2.36. Connection URI Required: Optional JSON Type: String Location: Track Object Law & Nandakumar Expires 4 December 2026 [Page 23] Internet-Draft MOQT Streaming Format June 2026 A string containing the MOQT connection endpoint URI for the publish track. When specified, the subscriber MUST establish a new MOQT connection to this URI for publishing the track data. If this field is absent, the subscriber SHOULD reuse the existing MOQT connection that was used to receive the catalog. The URI MUST be a valid MOQT endpoint URI as defined by [MoQTransport] (Sect 3.1.1). Examples include "moqt://logs.example.com:4443", "moqt://metrics.example.com:8443", or "https://logs.example.com/moqt". 5.2.37. Token Required: Optional JSON Type: String Location: Track Object A string containing an authentication token or credential for the track. For publish tracks, this token authorizes the subscriber to publish data to the specified track. The format and validation of the token is application-specific. 5.2.38. Encryption scheme Required: Optional JSON Type: String Location: Track Object A string identifying the encryption scheme used to protect the track content. The default and RECOMMENDED value is "moq-secure-objects" as defined in [SecureObjects]. If this field is absent, the track content is unencrypted. Table 5: Registered encryption schemes +====================+====================+=================+ | Name | Value | Reference | +====================+====================+=================+ | MoQ Secure Objects | moq-secure-objects | [SecureObjects] | +--------------------+--------------------+-----------------+ Table 6 Custom encryption schemes MAY be used. Custom scheme names SHOULD use Reverse Domain Name Notation to avoid collisions (e.g., "com.example.custom-encryption"). 5.2.39. Cipher suite Required: Optional JSON Type: String Location: Track Object Law & Nandakumar Expires 4 December 2026 [Page 24] Internet-Draft MOQT Streaming Format June 2026 A string identifying the AEAD cipher suite used for encryption. This field MUST be present when encryptionScheme is specified. For the "moq-secure-objects" scheme, the following cipher suites are defined: Table 6: Cipher suites for moq-secure-objects +============================+============================+======+ | Name | Value | Tag | | | | Size | +============================+============================+======+ | AES-128-GCM-SHA256 | aes-128-gcm-sha256 | 128 | | | | bits | +----------------------------+----------------------------+------+ | AES-256-GCM-SHA512 | aes-256-gcm-sha512 | 128 | | | | bits | +----------------------------+----------------------------+------+ | AES-128-CTR-HMAC-SHA256-80 | aes-128-ctr-hmac-sha256-80 | 80 | | | | bits | +----------------------------+----------------------------+------+ Table 7 Implementations MUST support "aes-128-gcm-sha256". Implementations SHOULD support "aes-128-ctr-hmac-sha256-80" for scenarios requiring smaller authentication tags. 5.2.40. Key ID Required: Optional JSON Type: String Location: Track Object A string identifying the key material used for encryption. This value is transmitted in the Secure Object KID extension header as defined in ([SecureObjects], Section 4.2) of each encrypted object. The keyId and associated trackBaseKey are obtained from an external key management system. The mechanism for obtaining these values is out of scope for this specification. Examples include MLS-based key distribution [E2EE-MLS] or other out-of-band key exchange mechanisms. The scope of a keyId is determined by the key management system in use. A keyId MAY be scoped to a single track, a single MSF session, or multiple tracks and sessions. When multiple tracks share the same Key ID, they MAY share the same base key material, though per-track keys are derived using the track name as defined in ([SecureObjects], Section 5). Law & Nandakumar Expires 4 December 2026 [Page 25] Internet-Draft MOQT Streaming Format June 2026 5.2.41. Track Base Key Required: Optional JSON Type: String Location: Track Object A base64-encoded [BASE64] string containing the base key material for this track, as defined in ([SecureObjects], Section 5). This field works in conjunction with keyId to provide the cryptographic material needed for decryption. The trackBaseKey is obtained from the same key management system that provides the keyId. When present, this field contains the raw key material that, together with the track name and other parameters defined in ([SecureObjects], Section 5), is used to derive the actual encryption keys. Publishers and subscribers MUST use matching trackBaseKey values for successful decryption. 5.2.42. Authorization Info Required: Optional JSON Type: Object Location: Track Object An object indicating that authorization is required to access this track. The presence of this field signals to subscribers that they must obtain and present valid authorization tokens when subscribing to this track. The keys of this object are authorization scheme identifiers. Registered schemes are defined in Table 7. The values are scheme- specific configuration objects defined by the referenced specifications. Table 7: Registered Authorization Schemes +==============+==============+===================+ | Scheme | Value | Reference | +==============+==============+===================+ | Privacy Pass | privacy-pass | [PrivacyPassAuth] | +--------------+--------------+-------------------+ | CAT | cat | [C4M] | +--------------+--------------+-------------------+ Table 8 Custom authorization schemes MAY be used. Custom scheme names MUST use a unique naming convention, such as Reverse Domain Name Notation (e.g., "com.example.custom-auth"), to avoid naming collisions. Law & Nandakumar Expires 4 December 2026 [Page 26] Internet-Draft MOQT Streaming Format June 2026 Subscribers inspect the authInfo field to determine which authorization scheme to use and then obtain tokens through out-of- band mechanisms. The specific token format, acquisition process, and presentation method are defined by the authorization scheme specification. 5.2.43. Token Delivery via URI Tokens can be delivered to subscribers through the catalog request URI using variable substitution. Fragment parameters (following the # character) are processed client-side and can be substituted into catalog fields using the variable substitution mechanism defined in Section 5.4. For example, given a URI: moqt://relay.example.com/live#namespace--name&token=XYZ789 A catalog with: "authInfo": { "cat": "%token%" } Would be resolved by the subscriber to include "cat": "XYZ789", which is then presented in control messages as specified by the authorization scheme. 5.2.44. Accessibility Required: Optional JSON Type: Array Location: Track Object An array of accessibility descriptors indicating accessibility features embedded within the track. Each descriptor is a JSON Object containing: * A required 'scheme' field (String) identifying the accessibility scheme. * A required 'value' field (String) specifying the accessibility channels or features available. Table 6: Registered accessibility schemes Law & Nandakumar Expires 4 December 2026 [Page 27] Internet-Draft MOQT Streaming Format June 2026 +===============================+=========================+ | Scheme | Description | +===============================+=========================+ | urn:scte:dash:cc:cea-608:2015 | CEA-608 closed captions | +-------------------------------+-------------------------+ | urn:scte:dash:cc:cea-708:2015 | CEA-708 closed captions | +-------------------------------+-------------------------+ Table 9 The 'value' field for CEA-608/708 schemes uses the format defined by [SCTE214-1], where caption service channels are specified as semicolon-separated pairs of channel identifier and language code (e.g., "CC1=eng;CC3=spa"). A subscriber MAY use this information to determine caption availability and configure an appropriate caption decoder. 5.3. Delta updates A catalog update might contain incremental changes. This is a useful property if many tracks may be initially declared but then there are small changes to a subset of tracks. The producer can issue a delta update to describe these changes. Changes are described incrementally, meaning that a delta update can itself modify a prior delta update. A restricted set of operations are allowed with each delta update: * Add a new track that has not previously been declared. * Add a new track by cloning a previously declared track. * Remove a track that has been previously declared. The following rules are to be followed in constructing and processing delta updates: * A delta update MUST include the Delta Update Section 5.1.6 field with at least one operation. It MUST NOT contain an instance of a Tracks Section 5.1.4 field or an MSF version Section 5.1.1 field. * Operations are applied sequentially in the order they appear in the deltaUpdate array. Each operation is applied to the target document; the resulting document becomes the target of the next operation. Evaluation continues until all operations are successfully applied. Law & Nandakumar Expires 4 December 2026 [Page 28] Internet-Draft MOQT Streaming Format June 2026 * The tuple of Track Namespace and Track Name defines a fixed set of Track attributes which MUST NOT be modified after being declared. To modify any attribute, a new track with a different Namespace|Name tuple is created by Adding or Cloning and then the old track is removed. * Producers that publish frequent delta updates SHOULD periodically publish a new independent catalog in a new MOQT Group in order to bound the amount of delta processing required for joining subscribers. 5.4. Variable Substitution Catalog field values MAY contain variables that are substituted at delivery time. This mechanism enables a single cached catalog to be customized for each viewer, supporting use cases such as personalized advertising, A/B watermarking, QoE reporting endpoints, and logging identifiers. 5.4.1. Variable Syntax Variables are denoted by enclosing the variable name in percent characters (%). Variable names MUST consist of alphanumeric characters, hyphens, and underscores. Variable names are case- sensitive. The percent character (%) MUST NOT appear in catalog field values except as part of a variable reference. Literal percent characters are not permitted. Variable values MUST consist only of alphanumeric characters, hyphens, underscores, and the at sign (@). Special characters including commas, semicolons, quotes, ampersands, and other punctuation MUST NOT appear in variable values. This restriction prevents injection attacks and ensures safe substitution into catalog field values. 5.4.2. Variable Resolution Variables are resolved from the fragment identifier of the URI used to access the catalog. The fragment identifier is the portion following the # character and is processed entirely client-side, making it suitable for per-viewer customization without affecting server-side caching. Query parameters (following the ? character) are reserved for server- side processing and MUST NOT be used for variable substitution. Law & Nandakumar Expires 4 December 2026 [Page 29] Internet-Draft MOQT Streaming Format June 2026 When a subscriber requests a catalog using a URI containing a fragment identifier, the fragment is parsed as key-value pairs (using & as delimiter and = as separator). Each key becomes available as a variable name, and the variable is replaced with the corresponding value. 5.5. Catalog Compression Catalogs can contain significant redundancy, particularly when initialization data is included. To reduce payload size, catalog objects MAY be compressed using the MSF_COMPRESSION property (Section 12.1). If all catalog objects are compressed, the track property (Section 12.1.1) is used. If only some catalog objects are compressed (for example, the complete catalog is compressed while delta updates are not), the object property (Section 12.1.2) is used on each compressed object. 5.6. Catalog Examples The following section provides non-normative JSON examples of various catalogs compliant with this draft. 5.6.1. Time-aligned Audio/Video Tracks with single quality This example shows a catalog for a media producer capable of sending LOC packaged, time-aligned audio and video tracks. Law & Nandakumar Expires 4 December 2026 [Page 30] Internet-Draft MOQT Streaming Format June 2026 { "version": "1", "generatedAt": 1746104606044, "tracks": [ { "name": "1080p-video", "namespace": "conference.example.com/conference123/alice", "packaging": "loc", "isLive": true, "targetLatency": 2000, "role": "video", "renderGroup": 1, "codec":"av01.0.08M.10.0.110.09", "width":1920, "height":1080, "framerate":30, "bitrate":1500000 }, { "name": "audio", "namespace": "conference.example.com/conference123/alice", "packaging": "loc", "isLive": true, "targetLatency": 2000, "role": "audio", "renderGroup": 1, "codec":"opus", "samplerate":48000, "channelConfig":"2", "bitrate":32000 } ] } 5.6.2. Simulcast video tracks - 3 alternate qualities along with audio This example shows a catalog for a media producer capable of sending 3 time-aligned video tracks for high definition, low definition and medium definition video qualities, along with an audio track. In this example the namespace is absent, which infers that each track must inherit the namespace of the catalog. { "version": "1", "generatedAt": 1746104606044, "tracks":[ { "name": "hd", Law & Nandakumar Expires 4 December 2026 [Page 31] Internet-Draft MOQT Streaming Format June 2026 "renderGroup": 1, "packaging": "loc", "isLive": true, "targetLatency": 1500, "role": "video", "codec":"av01", "width":1920, "height":1080, "bitrate":5000000, "framerate":30, "altGroup":1 }, { "name": "md", "renderGroup": 1, "packaging": "loc", "isLive": true, "targetLatency": 1500, "role": "video", "codec":"av01", "width":720, "height":640, "bitrate":3000000, "framerate":30, "altGroup":1 }, { "name": "sd", "renderGroup": 1, "packaging": "loc", "isLive": true, "targetLatency": 1500, "role": "video", "codec":"av01", "width":192, "height":144, "bitrate":500000, "framerate":30, "altGroup":1 }, { "name": "audio", "renderGroup": 1, "packaging": "loc", "isLive": true, "targetLatency": 1500, "role": "audio", "codec":"opus", Law & Nandakumar Expires 4 December 2026 [Page 32] Internet-Draft MOQT Streaming Format June 2026 "samplerate":48000, "channelConfig":"2", "bitrate":32000 } ] } 5.6.3. SVC video tracks with 2 spatial and 2 temporal qualities This example shows a catalog for a media producer capable of sending scalable video codec with 2 spatial and 2 temporal layers with a dependency relation as shown below: +----------+ +----------->| S1T1 | | | 1080p30 | | +----------+ | ^ | | +----------+ | | S1TO | | | 1080p15 | | +----------+ +-----+----+ ^ | SOT1 | | | 480p30 | | +----------+ | ^ +----------+ | | SOTO | | | 480p15 |---------+ +----------+ The corresponding catalog uses "depends" attribute to express the track relationships. { "version": "1", "generatedAt": 1746104606044, "tracks":[ { "name": "480p15", "namespace": "conference.example.com/conference123/alice", "renderGroup": 1, "packaging": "loc", "isLive": true, "buffers": {"target":2000}, "role": "video", "codec":"av01.0.01M.10.0.110.09", Law & Nandakumar Expires 4 December 2026 [Page 33] Internet-Draft MOQT Streaming Format June 2026 "width":640, "height":480, "bitrate":3000000, "framerate":15 }, { "name": "480p30", "namespace": "conference.example.com/conference123/alice", "renderGroup": 1, "packaging": "loc", "isLive": true, "buffers": {"target":2000}, "role": "video", "codec":"av01.0.04M.10.0.110.09", "width":640, "height":480, "bitrate":3000000, "framerate":30, "depends": ["480p15"] }, { "name": "1080p15", "namespace": "conference.example.com/conference123/alice", "renderGroup": 1, "packaging": "loc", "isLive": true, "buffers": {"target":2000}, "role": "video", "codec":"av01.0.05M.10.0.110.09", "width":1920, "height":1080, "bitrate":3000000, "framerate":15, "depends":["480p15"] }, { "name": "1080p30", "namespace": "conference.example.com/conference123/alice", "renderGroup": 1, "packaging": "loc", "isLive": true, "buffers": {"target":2000}, "role": "video", "codec":"av01.0.08M.10.0.110.09", "width":1920, "height":1080, "bitrate":5000000, Law & Nandakumar Expires 4 December 2026 [Page 34] Internet-Draft MOQT Streaming Format June 2026 "framerate":30, "depends": ["480p30", "1080p15"] }, { "name": "audio", "namespace": "conference.example.com/conference123/alice", "renderGroup": 1, "packaging": "loc", "isLive": true, "buffers": {"target":2000}, "role": "audio", "codec":"opus", "samplerate":48000, "channelConfig":"2", "bitrate":32000 } ] } 5.6.4. Delta update - adding two tracks This example shows the catalog delta update for a media producer adding two tracks to an established video conference. One track is newly declared, the other is cloned from a previous track. Law & Nandakumar Expires 4 December 2026 [Page 35] Internet-Draft MOQT Streaming Format June 2026 { "generatedAt": 1746104606044, "deltaUpdate": [ { "op": "add", "tracks": [ { "name": "slides", "isLive": true, "role": "video", "codec": "av01.0.08M.10.0.110.09", "width": 1920, "height": 1080, "framerate": 15, "bitrate": 750000, "renderGroup": 1 } ] }, { "op": "clone", "tracks": [ { "parentName": "video-1080", "parentNamespace": "example.com/custom", "name": "video-720", "width": 1280, "height": 720, "bitrate": 600000 } ] } ] } 5.6.5. Delta update removing tracks This example shows a delta update for a media producer removing two tracks from an established video conference. Law & Nandakumar Expires 4 December 2026 [Page 36] Internet-Draft MOQT Streaming Format June 2026 { "generatedAt": 1746104606044, "deltaUpdate": [ { "op": "remove", "tracks": [{"name": "video"}, {"name": "slides"}] } ] } 5.6.6. Time-aligned Audio/Video Tracks with custom field values This example shows a catalog for a media producer capable of sending LOC packaged, time-aligned audio and video tracks along with custom fields in each track description. Law & Nandakumar Expires 4 December 2026 [Page 37] Internet-Draft MOQT Streaming Format June 2026 { "version": "1", "generatedAt": 1746104606044, "tracks": [ { "name": "1080p-video", "namespace": "conference.example.com/conference123/alice", "packaging": "loc", "isLive": true, "buffers": {"target":2000, "min": 1500, "max": 5000}, "role": "video", "renderGroup": 1, "codec":"av01.0.08M.10.0.110.09", "width":1920, "height":1080, "framerate":30, "bitrate":1500000, "com.example-billing-code": 3201, "com.example-tier": "premium", "com.example-debug": "h349835bfkjfg82394d945034jsdfn349fns" }, { "name": "audio", "namespace": "conference.example.com/conference123/alice", "packaging": "loc", "isLive": true, "buffers": {"target":2000, "min": 1500, "max": 5000}, "role": "audio", "renderGroup": 1, "codec":"opus", "samplerate":48000, "channelConfig":"2", "bitrate":32000 } ] } 5.6.7. Time-aligned VOD Audio/Video Tracks This example shows a catalog for a media producer offering VOD (video on-demand) non-live content. The content is LOC packaged, and includes time-aligned audio and video tracks. Law & Nandakumar Expires 4 December 2026 [Page 38] Internet-Draft MOQT Streaming Format June 2026 { "version": "1", "tracks": [ { "name": "video", "namespace": "movies.example.com/assets/boy-meets-girl-season3/episode5", "packaging": "loc", "isLive": false, "trackDuration": 8072340, "renderGroup": 1, "codec":"av01.0.08M.10.0.110.09", "width":1920, "height":1080, "framerate":30, "bitrate":1500000 }, { "name": "audio", "namespace": "movies.example.com/assets/boy-meets-girl-season3/episode5", "packaging": "loc", "isLive": false, "trackDuration": 8072340, "renderGroup": 1, "codec":"opus", "samplerate":48000, "channelConfig":"2", "bitrate":32000 } ] } 5.6.8. Encrypted Audio/Video Tracks This example shows a catalog for encrypted LOC-packaged audio and video tracks using MoQ Secure Objects with AES-128-GCM. Law & Nandakumar Expires 4 December 2026 [Page 39] Internet-Draft MOQT Streaming Format June 2026 { "version": "1", "generatedAt": 1746104606044, "tracks": [ { "name": "1080p-video", "namespace": "conference.example.com/conference123/alice", "packaging": "loc", "isLive": true, "targetLatency": 2000, "role": "video", "renderGroup": 1, "codec": "av01.0.08M.10.0.110.09", "width": 1920, "height": 1080, "framerate": 30, "bitrate": 1500000, "encryptionScheme": "moq-secure-objects", "cipherSuite": "aes-128-gcm-sha256", "keyId": "key-2024-q1-premium", "trackBaseKey": "dGhpc2lzYXNhbXBsZWJhc2VrZXk=" }, { "name": "audio", "namespace": "conference.example.com/conference123/alice", "packaging": "loc", "isLive": true, "targetLatency": 2000, "role": "audio", "renderGroup": 1, "codec": "opus", "samplerate": 48000, "channelConfig": "2", "bitrate": 32000, "encryptionScheme": "moq-secure-objects", "cipherSuite": "aes-128-gcm-sha256", "keyId": "key-2024-q1-premium", "trackBaseKey": "dGhpc2lzYXNhbXBsZWJhc2VrZXk=" } ] } 5.6.9. Media timeline and Event timeline This example shows a catalog for a media producer capable of sending LOC packaged, time-aligned audio and video tracks, along with a Media Timeline which describes the history of those tracks and an Event Timeline providing synchronized data. Law & Nandakumar Expires 4 December 2026 [Page 40] Internet-Draft MOQT Streaming Format June 2026 { "version": "1", "generatedAt": 1746104606044, "tracks": [ { "name": "history", "namespace": "conference.example.com/conference123/alice", "packaging": "mediatimeline", "mimetype": "application/json", "depends": ["1080p-video","audio"] }, { "name": "identified-objects", "namespace": "another-provider/time-synchronized-data", "packaging": "eventtimeline", "eventType": "com.ai-extraction/appID/v3", "mimetype": "application/json", "depends": ["1080p-video"] }, { "name": "1080p-video", "namespace": "conference.example.com/conference123/alice", "packaging": "loc", "isLive": true, "targetLatency": 2000, "role": "video", "renderGroup": 1, "codec":"av01.0.08M.10.0.110.09", "width":1920, "height":1080, "framerate":30, "bitrate":1500000 }, { "name": "audio", "namespace": "conference.example.com/conference123/alice", "packaging": "loc", "isLive": true, "targetLatency": 2000, "role": "audio", "renderGroup": 1, "codec":"opus", "samplerate":48000, "channelConfig":"2", "bitrate":32000 } ] } Law & Nandakumar Expires 4 December 2026 [Page 41] Internet-Draft MOQT Streaming Format June 2026 5.6.10. Media timeline template This example shows a catalog using inline media timeline templates instead of an explicit media timeline track. The Section 5.2.15 attribute on each track defines a regular pattern where each segment is 2002ms long. Clients can compute any entry using the template parameters. Note that different tracks MAY have different template values to accommodate different group durations. { "version": "1", "generatedAt": 1746104606044, "tracks": [ { "name": "1080p-video", "namespace": "conference.example.com/conference123/alice", "packaging": "loc", "isLive": true, "targetLatency": 2000, "role": "video", "renderGroup": 1, "template": [0, 2002, [0, 0], [1, 0], 1759924158381, 2002], "codec":"av01.0.08M.10.0.110.09", "width":1920, "height":1080, "framerate":30, "bitrate":1500000 }, { "name": "audio", "namespace": "conference.example.com/conference123/alice", "packaging": "loc", "isLive": true, "targetLatency": 2000, "role": "audio", "renderGroup": 1, "template": [0, 2002, [0, 0], [1, 0], 1759924158381, 2002], "codec":"opus", "samplerate":48000, "channelConfig":"2", "bitrate":32000 } ] } Law & Nandakumar Expires 4 December 2026 [Page 42] Internet-Draft MOQT Streaming Format June 2026 5.6.11. Video track with embedded captions and SCTE-35 events This example shows a live broadcast with CEA-608 closed captions embedded in the video track and a separate SCTE-35 event timeline for ad insertion. Law & Nandakumar Expires 4 December 2026 [Page 43] Internet-Draft MOQT Streaming Format June 2026 { "version": "1", "generatedAt": 1746104606044, "tracks": [ { "name": "video", "packaging": "loc", "isLive": true, "targetLatency": 4000, "role": "video", "renderGroup": 1, "codec": "avc1.4d401f", "width": 1920, "height": 1080, "framerate": 30, "bitrate": 5000000, "accessibility": [ { "scheme": "urn:scte:dash:cc:cea-608:2015", "value": "CC1=eng;CC3=spa" } ] }, { "name": "audio", "packaging": "loc", "isLive": true, "targetLatency": 4000, "role": "audio", "renderGroup": 1, "codec": "opus", "samplerate": 48000, "channelConfig": "2", "bitrate": 128000 }, { "name": "scte35", "packaging": "eventtimeline", "eventType": "urn:scte:scte35:2013:bin", "mimeType": "application/json", "isLive": true, "role": "eventtimeline", "depends": ["video"] } ] } Law & Nandakumar Expires 4 December 2026 [Page 44] Internet-Draft MOQT Streaming Format June 2026 5.6.12. Video track with CEA-708 captions This example shows a live broadcast with CEA-708 closed captions embedded in the video track, demonstrating multiple caption services. { "version": "1", "generatedAt": 1746104606044, "tracks": [ { "name": "video", "packaging": "loc", "isLive": true, "targetLatency": 4000, "role": "video", "renderGroup": 1, "codec": "hev1.1.6.L93.B0", "width": 1920, "height": 1080, "framerate": 30, "bitrate": 4000000, "accessibility": [ { "scheme": "urn:scte:dash:cc:cea-708:2015", "value": "1=lang:eng;2=lang:spa;3=lang:fra" } ] }, { "name": "audio", "packaging": "loc", "isLive": true, "targetLatency": 4000, "role": "audio", "renderGroup": 1, "codec": "mp4a.40.2", "samplerate": 48000, "channelConfig": "2", "bitrate": 128000 } ] } 5.6.13. Terminating a live broadcast This example shows a catalog for a media producer terminating a previously live broadcast containing a video and an audio track. Law & Nandakumar Expires 4 December 2026 [Page 45] Internet-Draft MOQT Streaming Format June 2026 { "version": "1", "generatedAt": 1746104606044, "isComplete": true, "tracks": [] } 5.6.14. Variable Substitution for personalized delivery This example shows a catalog using variable substitution to enable personalized advertising and reporting while maintaining cacheability. Given a catalog request URI of: moqt://relay.example.com/sports/catalog?a=1#token=1234&id=bob&event=xyz The fragment parameters (token, id, event) are available for variable substitution. The following catalog template: { "version": "1", "tracks": [ { "name": "video", "packaging": "loc", "isLive": true, "role": "video", "renderGroup": 1 }, { "name": "cmcdv2-%id%", "namespace": "advertising-decisions/live-sports/%event%", "packaging": "eventtimeline", "eventType": "com.example.iab.vast", "c4m": "%token%" } ] } Would be resolved by the subscriber as: Law & Nandakumar Expires 4 December 2026 [Page 46] Internet-Draft MOQT Streaming Format June 2026 { "version": "1", "tracks": [ { "name": "video", "packaging": "loc", "isLive": true, "role": "video", "renderGroup": 1 }, { "name": "cmcdv2-bob", "namespace": "advertising-decisions/live-sports/xyz", "packaging": "eventtimeline", "eventType": "com.example.iab.vast", "c4m": "1234" } ] } 5.6.15. Time-aligned Audio/Video Tracks with Authorization This example shows a catalog for a media producer requiring authorization for premium content. The premium 4K track uses CAT authorization with a token resolved via variable substitution from %cat-token%. The standard 720p track uses Privacy Pass with a token resolved from %pp-token%. Token presentation timing is determined by the authorization scheme specification. { "version": "1", "generatedAt": 1746104606044, "tracks": [ { "name": "premium-4k-video", "namespace": "streaming.example.com/live/sports", "packaging": "loc", "isLive": true, "targetLatency": 2000, "role": "video", "renderGroup": 1, "codec": "av01.0.12M.10.0.110.09", "width": 3840, "height": 2160, "framerate": 60, "bitrate": 15000000, "authInfo": { "cat": "%cat-token%" Law & Nandakumar Expires 4 December 2026 [Page 47] Internet-Draft MOQT Streaming Format June 2026 } }, { "name": "standard-720p-video", "namespace": "streaming.example.com/live/sports", "packaging": "loc", "isLive": true, "targetLatency": 2000, "role": "video", "renderGroup": 2, "codec": "av01.0.05M.10.0.110.09", "width": 1280, "height": 720, "framerate": 30, "bitrate": 2500000, "authInfo": { "privacy-pass": "%pp-token%" } }, { "name": "audio", "namespace": "streaming.example.com/live/sports", "packaging": "loc", "isLive": true, "targetLatency": 2000, "role": "audio", "renderGroup": 1, "codec": "opus", "samplerate": 48000, "channelConfig": "2", "bitrate": 128000 } ] } 5.6.16. Publish tracks for logs and metrics This example shows a catalog that includes publish tracks for client- side logging and metrics collection. The subscriber can publish QoE data and logs back to the delivery system using these track definitions. The namespace and track name formats follow the conventions defined in [MOQLOG] and [MOQMETRICS]. Law & Nandakumar Expires 4 December 2026 [Page 48] Internet-Draft MOQT Streaming Format June 2026 { "version": "1", "generatedAt": 1746104606044, "tracks": [ { "name": "video", "namespace": "broadcast.example.com/live/stream1", "packaging": "loc", "isLive": true, "targetLatency": 2000, "role": "video", "renderGroup": 1, "codec": "av01.0.08M.10.0.110.09", "width": 1920, "height": 1080, "framerate": 30, "bitrate": 1500000 }, { "name": "audio", "namespace": "broadcast.example.com/live/stream1", "packaging": "loc", "isLive": true, "targetLatency": 2000, "role": "audio", "renderGroup": 1, "codec": "opus", "samplerate": 48000, "channelConfig": "2", "bitrate": 32000 } ], "publishTracks": [ { "namespace": "moq://metrics.moq.arpa/v1/%resourceId%", "name": "4", "packaging": "moqmetrics", "role": "metrics", "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." }, { "namespace": "moq://moq-syslog.arpa/logs-v1/%resourceId%", "name": "6", "packaging": "moqlog", "role": "log", "connectionUri": "moqt://logs.example.com:4443", "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." } Law & Nandakumar Expires 4 December 2026 [Page 49] Internet-Draft MOQT Streaming Format June 2026 ] } In this example: * The metrics track uses the namespace format defined in [MOQMETRICS] with %resourceId% as a placeholder for the subscriber's unique resource identifier. The track name "4" indicates Warning level granularity. * The log track uses the namespace format defined in [MOQLOG] with %resourceId% as a placeholder. The track name "6" indicates Informational level priority. This track establishes a separate connection to logs.example.com. * Both tracks include authentication tokens for publishing authorization. * The subscriber MUST replace %resourceId% with their actual resource identifier as defined in the respective specifications. 6. Media transmission The MOQT Groups and MOQT Objects need to be mapped to MOQT Streams. Irrespective of the Section 4 in place, each MOQT Object MUST be mapped to a new MOQT Stream. 6.1. Group numbering Group IDs for a track MUST be unique and MUST increase monotonically. Within a continuous publishing session, each subsequent Group ID SHOULD increase by 1. When a publisher restarts (e.g., after connectivity loss or encoder restart), it MUST ensure the new starting Group ID is greater than any previously published Group ID for that track. One approach is to use the current wall clock time in milliseconds since the Unix epoch as the starting Group ID. If a publisher maintains state across a restart and knows the previous Group ID, it SHOULD signal the gap using the MOQT Prior Group ID Gap Extension header. 6.2. Object Numbering Object ID MUST be zero for the first Object within a Group and then MUST increase monotonically by one within that Group. Law & Nandakumar Expires 4 December 2026 [Page 50] Internet-Draft MOQT Streaming Format June 2026 7. Media Timeline track The media timeline track provides data about the previously published Groups and their relationship to wallclock time and media time. Media timeline tracks allow players to seek to precise points behind the live head in a live broadcast, or for random access in a VOD asset. Media timeline tracks are optional. Multiple media timeline tracks can exist inside a catalog. 7.1. Media Timeline track payload A media timeline track is a JSON [JSON] document. This document MAY be compressed using the MSF_COMPRESSION property (Section 12.1). The document supports two formats: an explicit entry format and a template format. Publishers MAY combine both formats in a single document. 7.1.1. Explicit entry format The explicit format contains an array of records. Each record consists of an array of three required items, whose ordinal position defines their type: * The first item holds the media presentation timestamp, expressed as a JSON Number. This value MUST match the media presentation timestamp, expressed as the floor in integral milliseconds, of the first media sample in the referenced Object. Implementers who require increased time precision can parse the retrieved media object itself. * The second item holds the MOQT Location of the entry, defined as a tuple of the MOQT Group ID and MOQT Object ID, and expressed as a JSON Array of Numbers, where the first number is the Group ID and the second number is the Object ID. * The third item holds the wallclock time at which the media was encoded, defined as the number of milliseconds that have elapsed since January 1, 1970 (midnight UTC/GMT) and expressed as a JSON Number. For VOD assets, or if the wallclock time is not known, the value SHOULD be 0. An example media timeline is shown below: Law & Nandakumar Expires 4 December 2026 [Page 51] Internet-Draft MOQT Streaming Format June 2026 [ [0, [0,0], 1759924158381], [2002, [1,0], 1759924160383], [4004, [2,0], 1759924162385], [6006, [3,0], 1759924164387], [8008, [4,0], 1759924166389] ] 7.2. Media Timeline Catalog requirements A media timeline track MUST carry a 'type' identifier in the Catalog with a value of "mediatimeline". A media timeline track MUST carry a 'depends' attribute which contains an array of all track names to which the media timeline track applies. The mime-type of a media timeline track MUST be specified as "application/json". 7.3. Media Timeline track updating The publisher MUST publish an independent media timeline in the first MOQT Object of each MOQT Group of a media timeline track. An independent media timeline object MUST contain all media timeline records accumulated and accessible up to that point, allowing a subscriber joining at any group boundary to receive the accessible timeline history. The publisher MAY publish incremental updates in the second and subsequent Objects within each Group. Incremental updates contain only new media timeline records since the previous media timeline Object in that Group. 7.4. Media Timeline Template When the relationship between media time, MOQT Location and wallclock time follows a regular, predictable pattern, a media timeline template MAY be used instead of an explicit media timeline track. The template approach is best suited for content with fixed-duration segments, such as VOD assets or live broadcasts with constant segment durations. For content with variable segment durations, the explicit media timeline track (Section 7.1) MUST be used instead. 7.4.1. Template Format A media timeline template is expressed as an inline track attribute using the Section 5.2.15 field. The template is a JSON Array containing six mandatory values in the following fixed order: 1. startMediaTime - The media presentation timestamp of the first entry, as defined for media timeline entries in Section 7.1.1. Law & Nandakumar Expires 4 December 2026 [Page 52] Internet-Draft MOQT Streaming Format June 2026 2. deltaMediaTime - The constant interval between media presentation timestamps, expressed as a JSON Number in milliseconds. 3. startLocation - The MOQT Location of the first entry, as defined for media timeline entries in Section 7.1.1. 4. deltaLocation - The constant interval between MOQT Locations, expressed as a JSON Array of two Numbers where the first number is the Group ID delta and the second number is the Object ID delta. 5. startWallclock - The wallclock time of the first entry, as defined for media timeline entries in Section 7.1.1. For VOD assets, or if the wallclock time is not known, the value SHOULD be 0. 6. deltaWallclock - The constant interval between wallclock times, expressed as a JSON Number in milliseconds. For VOD assets, or if the wallclock time is not known, the value SHOULD be 0. All six values are mandatory and MUST appear in the specified order. Clients compute entry values using the following formulas, where n is the zero-based entry index: mediaTime[n] = startMediaTime + (n * deltaMediaTime) location[n] = [startLocation[0] + (n * deltaLocation[0]), startLocation[1] + (n * deltaLocation[1])] wallclock[n] = startWallclock + (n * deltaWallclock) An example template value is shown below: [0, 2002, [0, 0], [1, 0], 1759924158381, 2002] This template indicates that the first entry has media time 0ms, location [0,0], and wallclock time 1759924158381. Each subsequent entry increments media time by 2002ms, location by [1,0] (next group, same object), and wallclock by 2002ms. 7.4.2. Template Immutability Unlike the explicit media timeline track, the media timeline template is intended to be immutable once publishing starts. Publishers MUST NOT change the template values for a track after the first Object has been published. Law & Nandakumar Expires 4 December 2026 [Page 53] Internet-Draft MOQT Streaming Format June 2026 8. Event Timeline track The event timeline track provides a mechanism to associate ad-hoc event metadata with the broadcast. Use-case examples include live sports score data, GPS coordinates of race cars, SAP-types for media segments or active speaker notifications in web conferences. To allow the client to bind this event metadata with the broadcast content described by the media timeline track, each event record MUST contain a reference to one of Media PTS, wallclock time or MOQT Location. Event timeline tracks are optional. Multiple event timeline tracks can exist inside a catalog. The type & structure of the data contained within each event timeline track is declared in the catalog, to facilitate client selection and parsing. 8.1. Event Timeline data format An event timeline track is a JSON [JSON] document. This document MAY be compressed using the MSF_COMPRESSION property (Section 12.1). The document contains an array of records. Each record consists of a JSON Object containing the following required fields: * An index reference, which MUST be either 't' for wallclock time, 'l' for Location or 'm' for Media PTS. Only one of these index values may be used within each record. Event timelines SHOULD use the same index reference type for each record. The definitions for wallclock time, Location and Media PTS are identical to those defined for media timeline payload Section 7.1. Wallclock time and media PTS values are JSON Number, while Location value is an Array of Numbers, where the first item represents the MOQT GroupID and the second item the MOQT Object ID. * A 'data' Object, whose structure is defined by the Section 5.2.5 value declared for this track in the Catalog. 8.2. Event Timeline Catalog requirements An event timeline track MUST carry: * a Section 5.2.4 attribute with a value of "eventtimeline". * a Section 5.2.14 attribute which contains an array of all track names to which the event timeline track applies. * a Section 5.2.19 attribute with a value of "application/json". Law & Nandakumar Expires 4 December 2026 [Page 54] Internet-Draft MOQT Streaming Format June 2026 * an Section 5.2.5 attribute declaring the type & structure of data contained in the event timeline track. 8.3. Event Timeline track updating The publisher MUST publish an independent event timeline in the first MOQT Object of each MOQT Group of an event timeline track. An independent event timeline object MUST contain all event timeline records accumulated and accessible up to that point, allowing a subscriber joining at any group boundary to receive the accessible event history. The publisher MAY publish incremental updates in the second and subsequent Objects within each Group. Incremental updates contain only new event timeline records since the previous event timeline Object in that Group. 8.4. Event timeline track examples 8.4.1. Event timeline track with wallclock time indexing This example shows how sports scores and game information might be defined in a live sports broadcast. [ { "t": 1756885678361, "data": { "status": "in_progress", "period": 1, "clock": "12:00", "homeScore": 0, "awayScore": 0, "lastPlay": "Game Start" } }, { "t": 1756885981542, "data": { "status": "in_progress", "period": 1, "clock": "09:25", "homeScore": 2, "awayScore": 0, "lastPlay": "Team A: #23 makes 2-pt jump shot" } } ] Law & Nandakumar Expires 4 December 2026 [Page 55] Internet-Draft MOQT Streaming Format June 2026 8.4.2. Event timeline track with MOQT Location indexing This example shows drone GPS coordinates synched with the start of each Group. [ { "l": [0,0], "data": [47.1812,8.4592] }, { "l": [1,0], "data": [47.1662,8.5155] } ] 9. Log track Log tracks provide a mechanism for subscribers to publish diagnostic and operational log data back to the delivery system. This enables QoE monitoring, debugging, and analytics collection. Log tracks are defined in the catalog's publishTracks array with a packaging value of "moqlog". 9.1. Log track payload The log track payload format is defined in [MOQLOG]. Each MOQT Object contains a single JSON-formatted log entry. The log entry structure includes optional fields such as severity, timestamp, hostname, application name, process ID, message ID, and the log message itself. Additional structured data fields support distributed tracing integration with TraceID, SpanID, and InstrumentationScope aligned with OpenTelemetry specifications. Implementations MUST follow the object payload format specified in Section 4 of [MOQLOG]. 9.2. Log track namespace and name TODO: Finalize on track naming Log tracks MUST use the namespace and track name format defined in Section 3 of [MOQLOG]. The Track Namespace consists of the tuples: (moq://moq-syslog.arpa/logs-v1/),(resourceID) where resourceID is a unique identifier for the publishing resource. The Track Name is a single byte containing the log priority level in binary. Priority levels range from 0 (Emergency) to 7 (Debug), following syslog severity conventions. Law & Nandakumar Expires 4 December 2026 [Page 56] Internet-Draft MOQT Streaming Format June 2026 9.3. Log track Group ID and Object ID The Group ID represents the timestamp at which the log entry was captured, truncated to a 62-bit binary integer representing microseconds since the Unix epoch. This allows log entries to be naturally ordered by time within the MOQT object model. The Object ID is set to zero for a log entry unless multiple log messages occur within the same microsecond, in which case the Object ID increments to distinguish between messages captured at the same timestamp. 9.4. Log track catalog requirements A log track MUST be declared in the publishTracks array of the catalog with: * a Section 5.2.4 attribute with a value of "moqlog". * a Section 5.2.6 attribute with a value of "log". A log track MAY include: * a Section 5.2.36 attribute if logs should be published to a different endpoint. * a Section 5.2.37 attribute for publish authorization. 10. Metrics track Metrics tracks provide a mechanism for subscribers to publish quantitative measurements back to the delivery system. This enables QoE analytics, performance monitoring, and operational dashboards. Metrics tracks are defined in the catalog's publishTracks array with a packaging value of "moqmetrics". 10.1. Metrics track payload The metrics track payload format is defined in [MOQMETRICS]. The data model consists of Resources (systems generating metrics identified by ResourceID), optional Attributes (dimensional key-value pairs), and Metrics (named measurements with timeseries values). [MOQMETRICS] defines two metric value types - Gauge and Counter. Both value types support either 64-bit floating point or integer representation. Implementations MUST follow the object payload format specified in Section 3 of [MOQMETRICS]. Law & Nandakumar Expires 4 December 2026 [Page 57] Internet-Draft MOQT Streaming Format June 2026 10.2. Metrics track namespace and name TODO: Finalize the track naming. Metrics tracks MUST use the namespace and track name format defined in Section 3 of [MOQMETRICS]. The Track Namespace consists of the tuples: (moq://metrics.moq.arpa/v1/),(resourceID) where resourceID is a unique identifier for the publishing resource. The Track Name identifies the granularity level for the metrics being published, specified as a single tuple () where granularity-level is a value from 0 (Emergency) to 7 (Debug). Higher priority levels (lower numbers) indicate more critical metrics that should always be reported. 10.3. Metrics track Group ID and Object ID The Group ID represents the capture time as the number of milliseconds since January 1, 1970 (Unix epoch). This allows metrics to be naturally grouped and ordered by their capture timestamp within the MOQT object model. Within each Group, Object IDs are assigned as follows: * *Object ID 0*: Contains the capture timestamp as Unix epoch time in nanoseconds, along with any optional attributes for the metrics in this group. * *Object ID 1 and above*: Each subsequent Object contains an individual metric as a name-value pair. This structure allows a single capture event to include multiple metrics while maintaining efficient MOQT caching and distribution. 10.4. Metrics track catalog requirements A metrics track MUST be declared in the publishTracks array of the catalog with: * a Section 5.2.4 attribute with a value of "moqmetrics". * a Section 5.2.6 attribute with a value of "metrics". A metrics track MAY include: * a Section 5.2.36 attribute if metrics should be published to a different endpoint. Law & Nandakumar Expires 4 December 2026 [Page 58] Internet-Draft MOQT Streaming Format June 2026 * a Section 5.2.37 attribute for publish authorization. 10.5. Well-known event timeline types Event timelines can carry various types of broadcast metadata synchronized with media content. The "MSF Event Timeline Types" registry (Section 14.2) maintains a list of well-known event types. Publishers SHOULD use registered types when applicable to ensure interoperability. Event timelines can carry data types including but not limited to: * Ad insertion signaling (e.g., SCTE-35 splice points) - see [SCTE35-MSF] * Out-of-band timed-text cues (WebVTT, IMSC1) - see [WebVTT-MSF] and [IMSC1-MSF] * Sports scores and game state * GPS coordinates and telemetry * Active speaker notifications * Custom application-specific metadata The packaging format and data structure for each event type is defined by the specification referenced in the registry. Custom event types not in the registry SHOULD use Reverse Domain Name Notation (e.g., "com.example.myeventtype") to avoid naming collisions. 11. Workflow 11.1. URL construction and interpretation An MSF URL identifies a MOQT session and an optional sub-resource within that session. It inherits the MOQT URI scheme defined in [MoQTransport] and extends it to add a fragment definition, which defines the type, the namespace and name of the track along with optional key-value attributes. Law & Nandakumar Expires 4 December 2026 [Page 59] Internet-Draft MOQT Streaming Format June 2026 ; MSF URI Definition ; The following rules are imported from RFC 3986: ; authority (Section 3.2) ; path-abempty (Section 3.3) ; query (Section 3.4) msf-uri = "moqt://" authority path-abempty [ "?" query ] "#" msf-fragment The MOQT specification carries the normative definition of these components, along with processing instructions. They are repeated here for clarity. In the event of any conflict, the definition in [MoQTransport] is authoritative. * Scheme: This case-insensitive scheme defines the underlying transport. The client may use either a WebTransport or native QUIC connection. A moqt URI can be converted to an https URI by replacing the scheme, so the path-abempty and query components use the same syntax as https URIs. * Authority: Required. Contains the host and optional port (defaulting to 443). This information is used by the client to establish the transport session. * Path: Optional. If present, it provides server-specific configuration or routing information used during connection initialization. * Query: Optional. Contains key-value parameters separated by &. If the query is absent, the ? separator MUST be omitted. Query arguments are intended for the server and SHOULD be ignored by the client. This specification registers a fragment type of "msf" in the "MOQT URI Fragment Types" registry established by [MoQTransport] (see Section 14). This type is required for any URL defining an MSF resource. The value of this type is the msf-fragment-value. The msf-fragment is defined by the following ABNF: Law & Nandakumar Expires 4 December 2026 [Page 60] Internet-Draft MOQT Streaming Format June 2026 ; MSF Fragment Definition ; The following rules are imported from RFC 3986: ; pchar (Section 3.3) ; unreserved (Section 2.3) ; pct-encoded (Section 2.1) ; sub-delims (Section 2.2) msf-fragment = "msf:" msf-fragment-value msf-fragment-value = track-identifier [ "&" parameter-list ] track-identifier = 1*( pchar-no-amp / "/" ) ; MSF namespace-name string ; MUST NOT contain '&' or '?' ; '?' MUST be percent-encoded as %3F within this component parameter-list = parameter *( "&" parameter ) parameter = param-name "=" param-value param-name = 1*( pchar-no-amp / "/" ) param-value = *( pchar-no-amp / "/" ) ; Derived from RFC 3986 pchar (Section 3.3), excluding '&' and '?': ; pchar = unreserved / pct-encoded / sub-delims / ":" / "@" ; '&' is excluded as it serves as the MSF fragment component delimiter. ; '?' is excluded to avoid ambiguity with the URI query component delimiter. pchar-no-amp = unreserved / pct-encoded / sub-delims-no-amp / ":" / "@" ; Derived from RFC 3986 sub-delims (Section 2.2), excluding '&': ; sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" sub-delims-no-amp = "!" / "$" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" The msf-fragment-value identifies a specific Track. The track- identifier MUST be formatted as an MSF namespace-name string (see Section 11.1.2). The client uses this identifier to initiate a SUBSCRIBE or FETCH command once the transport session is established. The namespace-name string MAY be followed by a series of key-value parameters, each separated from the preceding element by &. These key-value parameters are intended for processing by the client and, being part of the fragment, are not transferred to the server at connection time. Certain of the fragment key-value parameters have a reserved meaning, as defined by Section 11.1.1. Law & Nandakumar Expires 4 December 2026 [Page 61] Internet-Draft MOQT Streaming Format June 2026 11.1.1. Reserved fragment parameters Table 8 defines reserved key names for the parameter portion of the msf-fragment. Keynames are case-sensitive. +=================+=============================================+ | Name | Description | +=================+=============================================+ | wallclock-range | A subclip defined by a wallclock time range | +-----------------+---------------------------------------------+ | mediatime-range | A subclip defined by a media time range | +-----------------+---------------------------------------------+ | location-range | A subclip defined by a MOQT Location range | +-----------------+---------------------------------------------+ | c4m | A base64 encoded C4M token | +-----------------+---------------------------------------------+ | connection | Mandates a connection type | +-----------------+---------------------------------------------+ Table 10 * wallclock-range - a range defined by start and end wallclock times, each expressed as milliseconds since Unix Epoch and separated by a "-" dash. The dash and end time MAY be omitted to indicate an open range. The range definition is inclusive. * mediatime-range - a range defined by start and end media times, each expressed as milliseconds and separated by a "-" dash. The dash and end time MAY be omitted to indicate an open range. The range definition is inclusive. * location-range - a range defined by start and end media MOQT Location separated by a "-" dash. Range definitions are inclusive. MOQT Location is expressed as Group ID and Object ID separated by a "." dot. End Location may be omitted to indicate an open range which continues to the end of the content. End Object ID may be omitted, indicating the whole end group is included in the range. The "." dot and "-" dash separators MUST be omitted when the second value is omitted. * c4m - a base64 encoded token, as defined by [C4M]. * connection - mandates the client to use a particular connection type when connecting to the server. There are two allowed values - "q" or "wt". "q" indicates that a Native QUIC connection MUST be used. "wt" indicates that a WebTransport connection MUST be used. Law & Nandakumar Expires 4 December 2026 [Page 62] Internet-Draft MOQT Streaming Format June 2026 If multiple ranges are specified within the same URL for the same parameter, the client MUST process the union of those ranges. Example fragment parameters: * connection=q * connection=wt * wallclock-range=1761759637565-1761759836189 * wallclock-range=1761751753894 * mediatime-range=0-13421 * mediatime-range=982 * location-range=34.0-2145.16 * location-range=16.24 (open range starting at Group ID 16 Object ID 24) * location-range=16-24 (range from Group ID 16 through to and including all Objects in Group ID 24) * c4m=gqhkYWxnIGVzaGFyqGR0eXBNhdZ9hdWQAY3VybGZlbWlzcwZleWV2aW5uZWlhdGVwQWNyZW5lY 11.1.2. MSF Namespace-Name String Encoding To represent MoQ Tuples (which are sequences of byte strings) within the URL fragment, MSF uses a specific encoding convention, which is normatively defined by MOQT [MoQTransport] and repeated here for convenience: * Hierarchy: Each element of the Namespace tuple is rendered in order, separated by a single hyphen (-). * Delimiter: The Track Name is appended to the end, separated from the namespace by a double hyphen (--). * Character Escaping: - Unreserved characters (a-z, A-Z, 0-9, _) are represented literally. Law & Nandakumar Expires 4 December 2026 [Page 63] Internet-Draft MOQT Streaming Format June 2026 - All other byte values (including hyphens and periods used as data) MUST be percent-encoded using a period (.) followed by two lowercase hexadecimal digits (e.g., a literal hyphen in a name becomes .2d). Note: This encoding ensures that the structural delimiters (- and --) remain unambiguous. 11.1.3. Example MSF URLs * URL pointing at a catalog track (either WebTransport or native QUIC may be used): moqt://example.com/server/ config?a=1&b=2#msf:customer-livestream-123--catalog - Session: example.com/server/config?a=1&b=2 - Streaming format type: msf - Namespace: ('customer', 'livestream', '123') - Track Name: 'catalog' * URL with a required raw QUIC connection pointing at a catalog: moqt://example.com/relay-app/relayID#msf:customerID-broadcastID-- catalog&connection=q * URL pointing at a non-catalog track, with a required WebTransport connection moqt://example.com/relay-app/relayID#msf:customerID- broadcastID--video&connection=wt * URL pointing at a subclip: moqt://example.com/relay-app/ relayID#msf:customerID-broadcastID--catalog&location-range=34-64 * URL pointing at a catalog and supplying a token for the client: (linebreaks for display only) moqt://example.com/relay-app/ relayID#msf:customerID-broadcastID-- catalog&c4m=gqhkYWxnIGVzaGFyqGR0eXBNhdZ9hdWQAY3VybGZlbWlzcwZleWV2 aW5uZWlhdGVwQWNyZW5lYnJmcmVqMTIzNDU2NzgwMHZpc3VlZF9hdD0xNzMwNDM * URL pointing at a catalog and supplying a token for the client along with a separate token for the server: (linebreaks for display only) moqt://example.com/relay-app/ relayID?token=HTRCII74GHFT@JHBCV SW56HKKneH2Dbyq6NHBI2#msf:customerID-broadcastID--catalog&c4m=gqh kYWxnIGVzaGFyqGR0eXBNhdZ9hdWQAY3VybGZlbWlzcwZleWV2aW5uZWlhdGVwQWN yZW5lYnJmcmVqMTIzNDU2NzgwMHZpc3VlZF9hdD0xNzMwNDM Law & Nandakumar Expires 4 December 2026 [Page 64] Internet-Draft MOQT Streaming Format June 2026 11.2. Initiating a broadcast An MSF publisher MUST publish a catalog track object before publishing any media track objects. 11.3. Ending a live broadcast After publishing a catalog and defining tracks carrying live content, an original publisher can deliver a deterministic signal to all subscribers that the broadcast is complete by taking the following steps: * Send a SUBSCRIBE_DONE (See MOQT Sect 8.1.2) message for all active tracks using status code 0x2 Track Ended. * If the live stream is being converted instantly to a VOD asset, then publish an independent (non-delta) catalog update which, for each track, sets isLive Section 5.2.7 to FALSE and adds a track duration Section 5.2.35 field. * If the live stream is being terminated permanently without conversion to VOD, then publish an independent catalog update which signals isComplete Section 5.1.3 as TRUE and which contains an empty Tracks Section 5.1.4 field. 11.4. Authorization MSF supports token-based authorization through pluggable authentication schemes. Both original publishers and end subscribers can independently acquire authorization tokens and present them to relays. Relays use these tokens to authorize whether an end subscriber is permitted to setup the connection, as well as to receive content and/or to send content. 11.4.1. Discovering Authorization Requirements End subscribers discover authorization requirements by parsing the catalog. For each track of interest, examine the authInfo field. If present, the track requires authorization and the subscriber must obtain appropriate credentials for one of the schemes listed in the field. Original publishers and end subscribers may obtain authorization tokens from multiple sources, including out-of-band provisioning or as a parameter in the connection URI. These tokens can be presented either in the connection setup message (CLIENT_SETUP) or in control messages (SUBSCRIBE, FETCH, PUBLISH, PUBLISH_NAMESPACE) as described in Section 11.4.3. Law & Nandakumar Expires 4 December 2026 [Page 65] Internet-Draft MOQT Streaming Format June 2026 11.4.2. Token Acquisition Token acquisition is out of scope for this specification. Both original publishers and end subscribers independently obtain tokens through mechanisms such as: * Direct authentication with a distribution service * OAuth 2.0 or OpenID Connect flows * Out-of-band provisioning The token acquisition endpoint and flow depend on the authorization scheme and deployment configuration. Original publishers and end subscribers MAY use the same or different authorization services depending on the deployment. Tokens MAY also be supplied as parameters in the connection URI. When a connection URI contains token parameters, the subscriber extracts the token value and includes it in the appropriate MOQT message. For example: moqt://relay.example.com/moqt#namespace--name&token=eyJhbGciOiJFZERTQSJ9... URI parameters provide a convenient mechanism for distributing pre- authorized playback links. The parameter name and format are deployment-specific. 11.4.3. Presenting Authorization Once tokens are obtained, both original publishers and end subscribers present them to relays according to the scheme specification. Tokens MAY be presented in the SETUP message (CLIENT_SETUP or SERVER_SETUP) using the AUTHORIZATION TOKEN setup parameter, or in individual control messages using the AUTHORIZATION TOKEN message parameter. When a token is associated with a track, it MUST be included in ALL control messages that accept the AUTHORIZATION TOKEN parameter and are associated with that track. For end subscribers, this includes SUBSCRIBE, SUBSCRIBE_NAMESPACE, FETCH, and REQUEST_UPDATE messages. For original publishers, this includes PUBLISH and PUBLISH_NAMESPACE messages. This requirement applies regardless of whether the token was also provided in SETUP. Law & Nandakumar Expires 4 December 2026 [Page 66] Internet-Draft MOQT Streaming Format June 2026 11.4.4. Handling Authorization Failures When a relay rejects an authorization token, subscribers SHOULD handle the failure gracefully: * If a SUBSCRIBE or FETCH request is rejected due to invalid or expired authorization, the subscriber MAY attempt to obtain a fresh token and retry the request. * If a token is rejected due to insufficient scope, the subscriber SHOULD NOT retry with the same token. * For interactive applications, subscribers MAY prompt users to re- authenticate when authorization fails. * Subscribers SHOULD implement exponential backoff when retrying failed authorization attempts to avoid overwhelming the relay or token issuer. The specific error codes and retry semantics are defined by the authorization scheme specifications. See [PrivacyPassAuth] for Privacy Pass error handling and [C4M] for CAT error handling. 12. MSF Properties MSF defines MOQT Track Properties and Object Properties (see [MoQTransport]) to signal metadata about MSF tracks and objects. These properties are carried in MOQT control messages and object headers, allowing endpoints to learn track and object characteristics before processing payload data. 12.1. Compression Signaling MSF provides two mutually exclusive mechanisms to signal compression of track payloads, including catalogs (Section 5), media timeline tracks (Section 7), and event timeline tracks (Section 8). Publishers MUST use one of the following approaches: * *Track Property* (Section 12.1.1): Signals that ALL objects in the track are compressed using the specified algorithm. * *Object Property* (Section 12.1.2): Signals compression on individual objects, allowing a mixture of compressed and uncompressed objects within the same track. Law & Nandakumar Expires 4 December 2026 [Page 67] Internet-Draft MOQT Streaming Format June 2026 A publisher MUST NOT use both mechanisms on the same track. If the track property is set, then every object in the track is compressed and the object property MUST NOT be present. If compression varies between objects, then the track property MUST NOT be set and the object property MUST be used on each compressed object. The compression algorithm values used by both mechanisms are: +=======+=======================+===========+ | Value | Compression Algorithm | Reference | +=======+=======================+===========+ | 0 | None (uncompressed) | RFC XXXX | +-------+-----------------------+-----------+ | 1 | GZIP | [GZIP] | +-------+-----------------------+-----------+ Table 11 Table: MSF Compression Values All MSF implementations MUST support both uncompressed payloads (value 0 or property absent) and GZIP compressed payloads (value 1). 12.1.1. MSF_COMPRESSION Track Property The MSF_COMPRESSION track property signals that ALL objects in the track are compressed using the specified algorithm. This mechanism is appropriate when every object published on the track uses the same compression. Publishers MUST include the MSF_COMPRESSION track property in the PUBLISH message (publisher-initiated flow) or SUBSCRIBE_OK (subscriber-initiated flow). Subscribers MUST check for this property in the corresponding message before processing the track payload. If the property is absent, and no per-object compression is signaled, the subscriber MUST treat the payload as uncompressed. If the property is present with a value the subscriber does not support, the subscriber MUST NOT attempt to process the payload and SHOULD unsubscribe from the track. Law & Nandakumar Expires 4 December 2026 [Page 68] Internet-Draft MOQT Streaming Format June 2026 12.1.2. MSF_COMPRESSION Object Property The MSF_COMPRESSION object property signals that an individual object is compressed. This mechanism is appropriate when a track contains a mixture of compressed and uncompressed objects. For example, a catalog track where the first object in a group (the complete catalog) is compressed, but subsequent delta update objects within the same group are uncompressed. Publishers MUST include the MSF_COMPRESSION object property on each compressed object. Subscribers MUST check for this property on each received object before processing its payload. If the property is absent on an object, the subscriber MUST treat that object's payload as uncompressed. If the property is present with a value the subscriber does not support, the subscriber MUST NOT attempt to process that object. 13. Security Considerations ToDo 14. IANA Considerations 14.1. "MOQT URI Fragment Types" registry This document creates a new entry in the "MOQT URI Fragment Types" registry (see [MoQTransport] Sect 14.3). +===============+=======================+===============+ | Fragment Type | Description | Specification | +===============+=======================+===============+ | msf | MOQT Streaming Format | this | +---------------+-----------------------+---------------+ Table 12 14.2. "MSF Event Timeline Types" registry This document establishes the "MSF Event Timeline Types" registry. This registry lists the event types that can be used with the eventType field Section 5.2.5 in MSF catalogs. New entries in this registry are subject to Expert Review policy as defined in [RFC8126]. The initial contents of this registry are: Law & Nandakumar Expires 4 December 2026 [Page 69] Internet-Draft MOQT Streaming Format June 2026 +==========================+=====================+===============+ | Event Type | Description | Specification | +==========================+=====================+===============+ | urn:scte:scte35:2013:bin | SCTE-35 binary | [SCTE35-MSF] | | | splice_info_section | | +--------------------------+---------------------+---------------+ | urn:scte:scte35:2013:xml | SCTE-35 XML | [SCTE35-MSF] | | | representation | | +--------------------------+---------------------+---------------+ | urn:msf:timedtext:webvtt | WebVTT timed text | [WebVTT-MSF] | | | cues | | +--------------------------+---------------------+---------------+ | urn:msf:timedtext:imsc1 | IMSC1 timed text | [IMSC1-MSF] | | | cues | | +--------------------------+---------------------+---------------+ Table 13 14.3. MSF_COMPRESSION Track Property This document requests IANA to register the following entry in the "Track Properties" registry established by [MoQTransport] (Section 14.4): +=================+=============+============+===========+ | Property Name | Property ID | Value Type | Reference | +=================+=============+============+===========+ | MSF_COMPRESSION | TBD | varint | RFC XXXX | +-----------------+-------------+------------+-----------+ Table 14 The MSF_COMPRESSION track property indicates that ALL objects on the track are compressed using the specified algorithm. See Section 12.1.1 for the full specification. 14.4. MSF_COMPRESSION Object Property This document requests IANA to create a new "MSF Compression Algorithms" registry with the following initial values: Law & Nandakumar Expires 4 December 2026 [Page 70] Internet-Draft MOQT Streaming Format June 2026 +=======+=======================+===========+ | Value | Compression Algorithm | Reference | +=======+=======================+===========+ | 0 | None (uncompressed) | RFC XXXX | +-------+-----------------------+-----------+ | 1 | GZIP | [GZIP] | +-------+-----------------------+-----------+ Table 15 Values 2-127 are available for registration via Standards Action. Values 128 and above are reserved for private use. 15. References 15.1. Normative References [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [C4M] Law, W., Lemmons, C., Simon, G., and S. Nandakumar, "Authentication scheme for MOQT using Common Access Tokens", Work in Progress, Internet-Draft, draft-ietf-moq- c4m-00, 19 September 2025, . [GZIP] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, . [IMSC1] "W3C, TTML Profiles for Internet Media Subtitles and Captions 1.0 (IMSC1)", April 2016, . [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [LANG] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . Law & Nandakumar Expires 4 December 2026 [Page 71] Internet-Draft MOQT Streaming Format June 2026 [LOC] Zanaty, M., Nandakumar, S., and P. Thatcher, "Low Overhead Media Container", Work in Progress, Internet-Draft, draft- ietf-moq-loc-02, 15 March 2026, . [MIME] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [MOQLOG] Jennings, C. F. and S. Nandakumar, "Logging over Media over QUIC Transport", Work in Progress, Internet-Draft, draft-jennings-moq-log-03, 20 October 2025, . [MOQMETRICS] Jennings, C. F. and S. Nandakumar, "Metrics over MOQT", Work in Progress, Internet-Draft, draft-jennings-moq- metrics-02, 20 October 2025, . [MoQTransport] Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet- Draft, draft-ietf-moq-transport-18, 12 May 2026, . [PrivacyPassAuth] Nandakumar, S., Jennings, C. F., and T. Meunier, "Privacy Pass Authentication for Media over QUIC (MoQ)", Work in Progress, Internet-Draft, draft-ietf-moq-privacy-pass- auth-02, 2 March 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Law & Nandakumar Expires 4 December 2026 [Page 72] Internet-Draft MOQT Streaming Format June 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [SecureObjects] Jennings, C. F., Nandakumar, S., and R. Barnes, "End-to- End Secure Objects for Media over QUIC Transport", Work in Progress, Internet-Draft, draft-jennings-moq-secure- objects-04, 8 February 2026, . [WEBCODECS-CODEC-REGISTRY] "WebCodecs Codec Registry", September 2024, . [WEBVTT] "World Wide Web Consortium (W3C), WebVTT: The Web Video Text Tracks Format", April 2019, . 15.2. Informative References [E2EE-MLS] Jennings, C. F., Nandakumar, S., and R. Barnes, "End-to- end Security for Media over QUIC", Work in Progress, Internet-Draft, draft-jennings-moq-e2ee-mls-03, 30 June 2025, . [IMSC1-MSF] "IMSC1 Packaging for MOQT Streaming Format", 2026, . [SCTE214-1] "SCTE 214-1: MPEG DASH for IP-Based Cable Services Part 1 - MPD Constraints and Extensions", 2022, . [SCTE35-MSF] "SCTE-35 over MSF Event Timeline", 2026, . Law & Nandakumar Expires 4 December 2026 [Page 73] Internet-Draft MOQT Streaming Format June 2026 [WebVTT-MSF] "WebVTT Packaging for MOQT Streaming Format", 2026, . Acknowledgments * the MoQ Workgroup and mailing lists. Contributors The following persons where the co-authors of the individual draft (draft-law-moq-warpstreamingformat) this document is based on: * Luke Curley * Victor Vasiliev * Suhas Nandakumar * Kirill Pugin * Will Law Authors' Addresses Will Law Akamai Email: wilaw@akamai.com Suhas Nandakumar Cisco Email: snandaku@cisco.com Law & Nandakumar Expires 4 December 2026 [Page 74]