IETF MOQ WG: CMSF updates

Message Snapshot

• List: moq@ietf.org
• Thread subject: CMSF updates
• Message subject: [Moq] CMSF updates
• Author: Law, Will
• Published: 2026-06-03T12:18:33.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Law, Will posted to the MOQ working group mailing list on June 3, 2026. In conjunction with the MSF update, we also release draft-01 of the CMAF-Compliant MOQT Streaming Format (CMSF) specification. Below is a summary o…

Why It Matters

This message came from the public MOQ working group archive and captures active discussion, meeting coordination, or implementation feedback around Media over QUIC.

Message Excerpt

In conjunction with the MSF update, we also release draft-01 of the CMAF-Compliant MOQT Streaming Format (CMSF) specification. Below is a summary of changes between -00 and -01. This spec is under development. Issueshttps://github.com/moq-wg/cmsf/issues are welcome, especially when driven by implementation experienc…

Plain-Text Body

In conjunction with the MSF update, we also release draft-01 of the CMAF-Compliant MOQT Streaming Format (CMSF) specification.

https://datatracker.ietf.org/doc/draft-ietf-moq-cmsf/01/

Below is a summary of changes between -00 and -01.

This spec is under development. Issueshttps://github.com/moq-wg/cmsf/issues are welcome, especially when driven by implementation experience.

Cheers

Will

---

New Features

1. CENC-Based Content Protection (Section 4, entirely new)

The main addition is a full DRM/content protection framework using ISO Common Encryption [CENC], deliberately distinct from the MSF end-to-end encryption (MoQ Secure Objects). The rationale is that CENC allows decryption to be delegated to a CDM in hardware or a trusted execution environment �X enabling commercial DRM systems (Widevine, PlayReady, FairPlay) required for high-value content.

The framework introduces:

• A root-level contentProtections array in the catalog, containing one object per DRM system configuration. Each object has: * refID �X unique identifier referenced by tracks * defaultKIDs �X array of Key ID UUIDs (matching CENC default_KID) * scheme �X "cenc" (AES-CTR) or "cbcs" (AES-CBC pattern, recommended for hardware decoder compatibility) * drmSystem object containing: systemID (UUID), laURL (license server), certURL (certificate server, required for FairPlay), authURL (authorization server), pssh (Base64 PSSH box), and robustness
• A track-level contentProtectionRefIDs array pointing at root-level entries �X tracks may reference multiple DRM systems simultaneously
• Requirements for protected initialization data: the initDataList entry MUST include the sinf/schm/schi/tenc box chain per [CENC] Section 6
• A ClearKey sub-section (4.3) for testing/development using the W3C EME Common System ID, with guidance on laURL and pssh

Well-known System IDs documented: Widevine (edef8ba9-...), PlayReady (9a04f079-...), FairPlay (94ce86fb-...), ClearKey (1077efec-...).

---

Catalog Syntax Changes

1. Initialization data: initData �� initRef + initDataList

In v00, each track carried its Base64 initialization header inline as an initData field. In v01, this is updated to use the MSF-01 pattern:

• Initialization data is placed in a root-level initDataList array (each entry with id, type: "inline", and data)
• Tracks reference it by id via the new initRef field

This matches the change made in MSF-01 and reduces duplication when multiple tracks share the same initialization data.

2. version type changed: Number �� String

The version field in v00 examples used a JSON number (1). In v01 examples it is a JSON string ("1"), consistent with the MSF-01 version field convention.

3. Object Packaging: ISO BMFF track requirement loosened

In v00, the requirement read "MUST contain a single [ISOBMFF] track." In v01 it simply reads "MUST contain a single track" �X removing the…