IETF MOQ WG: MoQ + Compression

Message Snapshot

• List: moq@ietf.org
• Thread subject: MoQ + Compression
• Message subject: [Moq] Re: MoQ + Compression
• Author: Alan Frindell
• Published: 2026-06-26T19:24:57.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Alan Frindell posted to the MOQ working group mailing list on June 26, 2026. ton. There's so much overlap between NAMESPACE messages, and they literally get duplicated on each NAMESPACE_DONE. Compressing MOQT messages i…

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

ton. There's so much overlap between NAMESPACE messages, and they literally get duplicated on each NAMESPACE_DONE. Compressing MOQT messages is probably better handled by

Plain-Text Body

ton. There's so much overlap between NAMESPACE messages, and they literally get duplicated on each NAMESPACE_DONE.

Compressing MOQT messages is probably better handled by https://datatracker.ietf.org/doc/draft-frindell-moq-moqpack/

For the objects themselves, we need to decide if compression is a hop-by-hop transport compression. If so, it doesn't conflict with MOQT object or caching model. If you want to go full HTTP Accept-Encoding + Vary here, that's a very different direction than what we have:

in which tracks are delivered via Parameters, but the actual content of the tracks does not depend on those parameters; this is in contrast to protocols like HTTP, where request headers can alter the server response.

-Alan