compression: cumulative decompression bound; clarify negotiation

Address review feedback on both drafts:

- Decompression-bomb bound is now cumulative over the group (moq-lite)
  / subgroup (moq-compression), not per slice — since compression is
  stream-scoped, many small slices could otherwise accumulate without
  limit.
- The advertised algorithm list denotes what an endpoint can BOTH
  compress and decompress, with a one-line rationale: flagless
  per-direction selection requires both sides to compute the algorithm
  from public info, so a decompress-only advertisement would force a
  per-message signal we deliberately don't have. (Unifies moq-lite,
  which had said "decompress", with moq-compression.)
- A sender MUST NOT compress before it has received the peer's
  Compression Parameter / COMPRESSION option.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W8bLV6vHzucLNvDhPk3bMP

Author: claude

draft-lcurley-moq-compression.md

@@ -73,7 +73,8 @@ An endpoint that does not support the extension omits the option.
 Negotiation is per direction and per hop. For a given direction sender-to-receiver, the **selected algorithm** is the first identifier in the receiver's advertised list that also appears in the sender's advertised list; if the lists do not intersect, that direction is verbatim.
 Because each endpoint holds both advertised lists once SETUP has been exchanged, both compute the same selection with no further handshake — the receiver's preference governs its own inbound direction, the two directions are independent and MAY select different algorithms, and a simultaneous SETUP exchange creates no ambiguity.
 Since `deflate` is mandatory for any endpoint that advertises the option, two endpoints that both support the extension always share at least one algorithm.
-A sender MUST NOT compress with an algorithm the receiver did not advertise.
+Each endpoint lists only algorithms it can both produce and consume, so either side can compute the selection for either direction without a per-object signal.
+A sender MUST NOT compress with an algorithm the receiver did not advertise, and MUST NOT compress at all before it has received the receiver's COMPRESSION option.
 
 
 # COMPRESSION Track Property
@@ -149,7 +150,7 @@ A publisher MUST NOT set a non-zero COMPRESSION hint on a track whose object pay
 Because compression is scoped to a subgroup, the exposure is bounded to within a single subgroup — which may combine several objects, a wider window than a single object — but it is not eliminated.
 
 A malicious sender could emit a small compressed payload that decompresses to a very large buffer (a "decompression bomb").
-A receiver MUST bound the size of a decompressed object payload. If the bound is exceeded it MUST reset the affected stream (rather than allocate unbounded memory) and MAY close the session with a PROTOCOL_VIOLATION if it considers the peer abusive; the reset is stream-scoped so a single bad subgroup does not tear down unrelated subscriptions.
+Because compression is subgroup-scoped, a receiver MUST bound the cumulative decompressed size of a subgroup — not merely each object's payload, since many small payloads can otherwise accumulate without limit. If the bound is exceeded it MUST reset the affected stream (rather than allocate unbounded memory) and MAY close the session with a PROTOCOL_VIOLATION if it considers the peer abusive; the reset is stream-scoped so a single bad subgroup does not tear down unrelated subscriptions.
 
 Compression is orthogonal to {{moqt}} end-to-end encryption: an encrypted payload is effectively incompressible, so a publisher using end-to-end encryption SHOULD omit COMPRESSION (or use `0`).
 

draft-lcurley-moq-lite.md

@@ -631,13 +631,13 @@ The remaining bindings convey the path in their own handshake.
 A relay MUST NOT forward the Path Parameter; like other per-hop setup metadata it applies only to this hop (see [Session](#session)).
 
 ### Compression Parameter {#compression-parameter}
-The Compression Parameter advertises the payload compression [algorithms](#compression) the sender can *decompress* on this hop, in preference order (most-preferred first).
+The Compression Parameter advertises the payload compression [algorithms](#compression) the sender can both compress and decompress on this hop, in preference order (most-preferred first).
 The Parameter Value is a sequence of algorithm identifiers, each a variable-length integer, packed back-to-back to fill the Parameter Length.
 An endpoint that supports compression MUST include `deflate` (1); `none` (0) MUST NOT be listed. An endpoint that does not support compression omits the parameter.
 
 Negotiation is per direction and per hop, and a relay MUST NOT forward the parameter (see [Session](#session)).
-For a given direction, the algorithm is the first entry in the **receiver's** list that also appears in the **sender's** list: the receiver's preference governs, and because both endpoints hold both lists once SETUP has been exchanged, each computes the same result with no further handshake. The two directions are independent and MAY select different algorithms. Since `deflate` is mandatory for any endpoint that supports compression, two compression-capable endpoints always share at least one algorithm.
-A sender MUST NOT compress when sending to a receiver that advertised no list, so such a receiver gets every Group Stream, Fetch Stream, and datagram verbatim regardless of the Track's `Publisher Compression` signal.
+For a given direction, the algorithm is the first entry in the **receiver's** list that also appears in the **sender's** list: the receiver's preference governs, and because both endpoints hold both lists once SETUP has been exchanged, each computes the same result with no further handshake. Listing only algorithms it can both produce and consume is what lets either endpoint make this selection for either direction without a per-message signal. The two directions are independent and MAY select different algorithms. Since `deflate` is mandatory for any endpoint that supports compression, two compression-capable endpoints always share at least one algorithm.
+A sender MUST NOT compress until it has received the receiver's Compression Parameter; a receiver that advertised no list gets every Group Stream, Fetch Stream, and datagram verbatim regardless of the Track's `Publisher Compression` signal.
 
 
 ## ANNOUNCE_REQUEST
@@ -1217,7 +1217,7 @@ A publisher MUST NOT set a non-zero `Publisher Compression` hint on a Track whos
 Because compression is group-scoped, the exposure is bounded to within a single group — which may combine several frames, a wider window than a single frame — but it is not eliminated.
 
 A malicious sender could emit a small compressed payload that decompresses to a very large buffer (a "decompression bomb").
-A receiver MUST bound the size of a decompressed payload; if the bound is exceeded it MUST reset the affected stream rather than allocate unbounded memory, and MAY close the session with a PROTOCOL_VIOLATION if it considers the peer abusive.
+Because compression is group-scoped, a receiver MUST bound the cumulative decompressed size of a group stream — not merely each frame's slice, since many small slices can otherwise accumulate without limit; if the bound is exceeded it MUST reset the affected stream rather than allocate unbounded memory, and MAY close the session with a PROTOCOL_VIOLATION if it considers the peer abusive.
 
 Compression is orthogonal to end-to-end encryption: an encrypted payload is effectively incompressible, so a publisher using end-to-end encryption SHOULD leave `Publisher Compression` at `0`.