]>

kixelated@gmail.com

wit moq This document specifies how a MoQ Transport track carries DEFLATE-compressed payloads. Each subgroup is one raw DEFLATE stream, sync flushed at each object boundary, so every object stays self-delimited while later objects compress against the earlier ones in the subgroup. Small repetitive payloads compress several times better than they do alone, and a dropped group costs nothing beyond itself because the window never spans one. Nothing is added to the wire: the application declares the track compressed, and a relay forwards it unchanged.

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 when, and only when, they appear in all capitals, as shown here.

Introduction A live track is usually many small payloads rather than a few large ones. DEFLATE on one such payload alone is close to useless: the window starts cold, and below a few hundred bytes the block overhead can exceed the savings. The redundancy worth exploiting is between payloads: a JSON snapshot followed by its deltas, a telemetry record repeated at 50 Hz, successive subtitle cues. Compressing a whole track captures that redundancy but breaks on delivery. Groups are dropped, arrive out of order, and a subscriber joins at an arbitrary point, so a window spanning data it never received cannot be reconstructed. Scoping the window to a subgroup is the compromise: a drop costs nothing beyond itself, joining costs only the current group, and the transport never has to know.

Compression Scope Each subgroup is a separate DEFLATE stream: its object payloads share one window, in order, starting cold. has no subgroups, so each group is one stream of frames. The application decides which subgroups a track uses; a consumer knows which to expect and decodes each one's objects in order. A publisher MUST NOT send a compressed track in datagrams, which are neither ordered nor reliable. An object with no payload is skipped, neither advancing nor resetting the window.

Compressed Stream A subgroup's payloads are compressed, in order, into one raw DEFLATE stream , with no zlib or gzip wrapper. A publisher MUST sync flush after each payload, which ends the block and byte-aligns the output while retaining the window (, Z_SYNC_FLUSH in zlib). Each object carries the bytes that flush produced, with no length prefix. A sync flush always ends with the marker 0x00 0x00 0xff 0xff. A publisher MUST omit it from each object and a consumer MUST append it before decompressing, the same trick as permessage-deflate (). A zero-length payload is neither compressed nor decompressed. The stream is never terminated: no object ends in a final block, so a consumer decompresses incrementally and MUST NOT treat the absent end of stream as truncation. A consumer missing an object MUST abandon the rest of the subgroup, which it can no longer decompress. The compression level is a publisher's choice; any conformant stream decodes.

Declaring Compression The application declares a track compressed, conventionally with a .z suffix on the track name, or in its catalog. A consumer MUST NOT infer compression from the payload: raw DEFLATE has no magic number, so a wrong guess yields plausible garbage. There is deliberately no transport signal. A relay drops objects and re-frames what it forwards, so a transport that knew about the window would make the relay responsible for emitting a stream that still decodes, which means carrying a DEFLATE implementation. Instead a relay forwards opaque bytes, and an endpoint that has never heard of this document never asks for a compressed track.

Security Considerations A shared window is a side channel. The compressed size of one payload reveals how much it has in common with the payloads before it, enough to recover a secret an attacker can partially guess, as CRIME and BREACH demonstrated against TLS and HTTP compression. A publisher MUST NOT compress a secret and attacker-influenced data in the same subgroup. Encryption does not mitigate this, since the sizes are visible to anyone on the path. A few bytes can inflate to gigabytes, so a consumer MUST bound the decompressed size of each object and abandon the subgroup once that bound is exceeded. Each open subgroup also holds a window of up to 32 KiB, so a consumer SHOULD bound how many it decompresses at once.

IANA Considerations This document requests no registrations. The format lives inside object payloads, which treats as opaque.

Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document defines a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. An extension based on this framework compresses the payload data portion of WebSocket data messages on a per-message basis using parameters negotiated during the opening handshake. This framework provides a general method for applying a compression algorithm to the contents of WebSocket messages. Each compression algorithm has to be defined in a document defining the extension by specifying the parameter negotiation and the payload transformation algorithm in detail. This document also specifies one specific compression extension using the DEFLATE algorithm. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. moq-lite is designed to fanout live content 1->N across the internet. It leverages QUIC to prioritize important content, avoiding head-of- line blocking while respecting encoding dependencies. While primarily designed for media, the transport is payload agnostic and can be proxied by relays/CDNs without knowledge of codecs, containers, or encryption keys.

Acknowledgments This document was drafted with the assistance of Claude, an AI assistant by Anthropic.