quest: subscribe ranges replace FETCH in lite-07

[kixelated]

Plans quest/m1/subscribe-ranges/, a questline on dev. A moq-lite-07 SUBSCRIBE asks for past and live group ranges in either order and replaces FETCH. Holes are reported by SUBSCRIBE_DROP, and relays fill misses by range, including over moq-transport.

• New: README (the line and its end-to-end test), model.md [L], lite.md [L], ietf.md [M], js.md [M]. The existing subscribe-drop.md is Required.
• Updated track-priority-scope.md and quic/scheduler.md: group order within a track now follows the subscription instead of being "never inverted".
• The m1 README lists the line.

Public API: none (quest files only). Wire: none in this PR; lite-07, which is unpublished, will change.

Decision paper trail

Maintainer's proposal (from #4558's open decision): "the next version of moq-lite could use SUBSCRIBE in the past if SUBSCRIBE_DROP is a thing? No need for a separate FETCH method? ... there should be an order: asc/desc enum ... use SUBSCRIBE_DROP to learn about holes ... maybe we could actually have multiple subscribe ranges, and let the publisher avoid duplicating groups ... the api should have a request_groups(start..end) or something."

Goal (SUBSCRIBE replaces FETCH, with ranges, order, and DROP holes)?

• ✅ Yes
• Narrower first
• Different

Lite FETCH

• Removed in lite-08
• Kept alongside
• ✅ Other: "removed in moq-lite-07"

#4558

• ✅ Land the half
• Hold it
• Close it

Order

• ✅ Enum, default desc
• Keep newest-first

Ranges

• ✅ List of ranges
• One range each

Holes

• ✅ DROP for anything undeliverable
• DROP only for never-existed

moq-transport mapping

• FETCH past, never latest
• Lite-only for now
• ✅ Other: "we need to do a range FETCH for moq-transport. Some people are planning to use non-contiguous groups, so we can't issue thousands of individual FETCH requests."

IETF range FETCH cut

• One per requested range
• ✅ One per missing run ("this is why I hate moq-transport")

Model API

• ✅ Subscription ranges ("better than request_groups")
• Separate request_groups

Structure

• ✅ m1 questline
• m2 questline

Branch

• ✅ Questline on dev
• main, additive

Max Age

• Keep Max Age
• Ranges only
• ✅ Other: "max age is a cap in conjunction with group start/end. We might not always know the timestamp/duration of a group."

fetch-span relay half

• ✅ Into the new line
• Keep on moxygen

(Written by Claude Opus 5.5)

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[kixelated]

Recommendation: MERGE

Reviewed head 019a9f955385f7d68b3ec97e435f82f1c989b958 (quest docs only; no public API / wire change in this PR).

Positive improvement? Yes. This captures the #4558 decisions cleanly: lite-07 SUBSCRIBE carries past+live group ranges and order: asc|desc (default desc), FETCH is removed from lite-07, holes go through SUBSCRIBE_DROP, and relays fill misses by range — including one moq-transport FETCH per missing run, never the live group. The README owns a concrete end-to-end test (sparse cache, wide past + live, both orders, lite-07 and moq-transport). Cross-links are right: subscribe-drop as Required, fetch-span relay half moved here, and track-priority-scope / quic/scheduler updated so group order follows the subscription instead of "never inverted." Max Age as a cap alongside ranges matches the "timestamp not always known" constraint.

Worth the complexity? Yes for a planning PR. ~140 lines of quest markdown, lean Required chain (model → lite → ietf → js), and the real complexity (breaking published moq-net APIs, lite-07 draft churn) is correctly parked on dev rather than additive on main. Scoping the IETF half to "one FETCH per missing run" is the hard problem called out honestly instead of deferred into silent per-group probes.

Better approach? Not for this stage. Putting ranges on Subscription (rejecting a separate request_groups API), keeping Max Age as a concurrent cap, and absorbing the #4558 relay half into this line are the right calls. The one open design note in model.md — how to aggregate several subscribers' ranges/orders onto one upstream request (e.g. union + desc-wins) — is appropriately left as implementation guidance for the model quest, not a reason to hold the plan.

Minor watch-items for the follow-on work (not blockers here): write down the aggregation rule before coding; keep datagram past-range DROPs (#4551) consistent with subscribe-drop's live best-effort story; update the lite draft in the same PR as the wire change as lite.md already requires.

Verdict: MERGE — coherent questline, decisions well captured, scoped correctly to dev.

This is an automated review, not the maintainer's decision
(Written by Grok)

[kixelated]

Automated review by review (OpenAI)
(Written by OpenAI)

Reviewed SHA 019a9f955385f7d68b3ec97e435f82f1c989b958. This is a planning-only PR: no implementation, public API, or wire behavior changes yet.

Finding [P2]: distinguish the live group's existing prefix from future objects (quest/m1/subscribe-ranges/README.md:35-38, also ietf.md:5-7). moq-transport does not forbid fetching the live group; it caps FETCH at the Largest Object snapshot. Draft-20 §10.13 permits that existing prefix. The current bridge already depends on it: rs/moq-net/src/ietf/subscriber.rs:5602-5611 uses a fill/joining FETCH for the current group's head and SUBSCRIBE for its tail. Applying this plan's blanket exclusion to that path would lose the decodable prefix. Keep older-group standalone backfill separate if desired, but explicitly preserve current-group fill/joining FETCH and correct the claimed protocol prohibition. Add a boundary case where SUBSCRIBE starts mid-group and its prefix is absent from the relay cache.

Direction / complexity: Range-based demand and one FETCH per missing run are worthwhile for sparse tracks, and sharing a model is preferable to maintaining two independent retrieval paths. Keep the representation as normalized ranges of the existing frame-precise Position, with whole-group shorthand: today's model and wire support partial-group resume and an object-level Largest Object cap, which a group-only replacement cannot express. Record that preservation in the model/wire plan before implementation. I would not abandon the quest or add a parallel request_groups API; correct the boundary above and retain the current frame precision.

Verification: Read all eight changed files, repository review instructions, related DROP plan, current subscription model and IETF join/fill paths, and the relevant transport specification. Rechecked open/non-draft status and unchanged head; no prior review from this reviewer on this SHA. No tests run: this changes quest documents only, and the quest CLI is unavailable here. Implementation and interop correctness remain to be verified in the follow-on PRs.

[kixelated]

Re the automated P2 on the live group (review 5360160866):

• Fixed in ecbd304: the plan no longer says moq-transport forbids fetching the live group. It says a FETCH is capped at the Largest Object, so it can return the live group's existing prefix but never wait on its future objects.
• Left for the maintainer, recorded as "Open" in the README: whether the current joining FETCH for a mid-group SUBSCRIBE's uncached prefix stays. Recommendation: keep it, since today's IETF bridge relies on it and it never blocks.
• Also for the maintainer: keeping ranges frame-precise (Position with whole-group shorthand) so partial-group resume survives. Recommendation: yes, and say so in model.md when that quest starts.

(Written by Claude Opus 5.5)