Conversation
Replace SETUP handshake with ALPN-based version negotiation (moq-lite-xx). Add FETCH stream for single group download, PROBE stream for bitrate measurement, start/end group ranges to subscriptions, and GROUP_DROP for indicating unavailable groups. Unknown stream types are now non-fatal to enable extension negotiation via stream probing. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Claude finished @kixelated's task —— View job Pull Request Review
|
Remove Instant Delta from FRAME and the Instant section from Delivery. Expiration is now based on when the first byte of a group arrives rather than per-frame instant values. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Claude finished @kixelated's task —— View job Pull Request ReviewReviewing PR #15: MOQ Lite Draft-03 updates Todo List:
Protocol Specification ReviewThis PR introduces significant improvements to the MOQ Lite Draft-03 specification. Here's my comprehensive analysis: Protocol Design Quality ✅Strengths:
Technical Correctness ✅New Features Analysis:
Priority System (draft-lcurley-moq-lite.md:243-297): The dual priority system (subscriber + publisher) with concrete examples (lines 260-285) is well-architected for relay scenarios. Potential Issues
|
Expiration is computed by comparing a group's arrival time to the latest group's arrival time. A group is never expired until a newer group (by sequence number) exists. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Claude finished @kixelated's task —— View job Pull Request ReviewReviewing PR #15: MOQ Lite Draft-03 updates Todo List:
Protocol Specification ReviewThis PR introduces significant improvements to the MOQ Lite Draft-03 specification. Here's my comprehensive analysis: Protocol Design Quality ✅Strengths:
Technical Correctness ✅New Features Analysis:
Priority System (draft-lcurley-moq-lite.md:243-297): The dual priority system (subscriber + publisher) with concrete examples (lines 260-285) is well-architected for relay scenarios where conflicts can occur. Potential Issues
|
Replace start/end group with Group Sequence + Group Count for fewer bytes on the wire. Count of 0 means unbounded. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Claude finished @kixelated's task —— View job Pull Request ReviewReviewing PR #15: MOQ Lite Draft-03 updates Todo List:
Comprehensive Protocol Specification ReviewThis PR introduces significant improvements to the MOQ Lite Draft-03 specification. Based on my analysis of the 266 additions and 115 deletions, here's my comprehensive review: Major Protocol Changes ✅
Technical Quality Assessment ✅Protocol Design Strengths:
Performance Considerations:
Potential Issues
|
Remove ANNOUNCE_INIT to simplify the protocol and avoid large messages. The publisher now sends individual ANNOUNCE messages for all matching broadcasts. Add Hops field to ANNOUNCE as a tiebreaker for multiple paths. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Claude finished @kixelated's task —— View job Pull Request ReviewReviewing PR #15: MOQ Lite Draft-03 updates Todo List:
Comprehensive Protocol Specification ReviewThis PR introduces significant improvements to the MOQ Lite Draft-03 specification. Based on my analysis of the 279 additions and 155 deletions, here's my comprehensive review: Major Protocol Changes ✅
Technical Quality Assessment ✅Protocol Design Strengths:
Performance Considerations:
Potential Issues
|
Add a type field before message length to distinguish SUBSCRIBE_OK (0x0) and SUBSCRIBE_DROP (0x1) on the subscribe response stream. SUBSCRIBE_OK must be the first message; SUBSCRIBE_DROP before it is invalid. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Claude finished @kixelated's task —— View job Pull Request ReviewReviewing PR #15: MOQ Lite Draft-03 updates Todo List:
Protocol Specification ReviewThis PR contains refinements to the MOQ Lite Draft-03 specification with focused corrections and clarifications. Here's my comprehensive analysis: Change Summary ✅The changes in this PR are primarily editorial improvements and consistency fixes rather than substantial protocol modifications:
Technical Quality Assessment ✅Protocol Design Improvements:
Message Encoding Quality:
Security Considerations ✅Positive Aspects:
Remaining Issues:
Performance Impact ✅No Performance Concerns:
Documentation Quality ✅Improvements:
Format Quality:
Implementation Considerations ✅Backward Compatibility:
Edge Cases Handled:
Minor Observations 📝
Overall AssessmentThis is a high-quality set of refinements that improves the specification's clarity, consistency, and maintainability without introducing breaking changes or complexity. Key Improvements:
Recommendation: ✅ APPROVE These are exactly the kind of iterative improvements that strengthen a protocol specification. The changes are well-reasoned, maintain compatibility, and improve implementer experience. Remaining Action Items:
|
WalkthroughThe draft reorganizes moq-lite into a new revision with ALPN-based version negotiation and immediate session activation after QUIC/WebTransport handshake; extension negotiation uses stream probing via unknown-type stream resets. ANNOUNCE_INIT is removed; ANNOUNCE gains Hops. New stream types FETCH (single-group HTTP-like downloads) and PROBE (ongoing bitrate measurement) are added. SUBSCRIBE, SUBSCRIBE_UPDATE, and SUBSCRIBE_OK carry explicit Priority, Ordered, Max Latency, Start Group, and End Group fields; SUBSCRIBE_DROP is added. GROUP and FRAME semantics clarify gaps and out-of-order delivery. Message encodings, stream types, and public constants are revised; legacy SESSION_* constructs removed. 🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (1)
draft-lcurley-moq-lite.md (1)
159-161: Handshake section duplicates the Session section verbatim — consider removing or cross-referencing.Lines 159–161 reproduce the same two sentences already stated at Lines 78–80 with no additional content. This creates a maintenance hazard where one copy could drift from the other.
✂️ Proposed fix: replace with a cross-reference
## Handshake -The moq-lite version is negotiated via ALPN during the QUIC handshake. -The ALPN format is `moq-lite-xx` where `xx` is the two-digit draft version. -The session is active immediately after the connection is established. +See the [Session](`#session`) section for version negotiation details. +There are no additional handshake messages; the session is active immediately after the connection is established.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@draft-lcurley-moq-lite.md` around lines 159 - 161, The Handshake section duplicates the Session section's ALPN and session-active sentences; remove the repeated sentences in the Handshake section and replace them with a brief cross-reference to the Session section (e.g., "See the Session section for ALPN negotiation and session activation details"), ensuring references to the ALPN format `moq-lite-xx` and the immediate session activation remain only in the Session section; update any nearby anchors or headings if needed so the cross-reference resolves correctly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@draft-lcurley-moq-lite.md`:
- Line 273: Update the sentence fragment in the line "The subscriber priority
takes precedence, so we could override it if we decided to full screen Ali's
window:" to use the hyphenated adjective form by changing "full screen Ali's
window" to "full-screen Ali's window" so the phrase correctly uses a compound
adjective.
- Around line 491-498: Clarify that the "Group Sequence" field in SUBSCRIBE_OK
is the raw absolute sequence (no +1 offset) by adding a sentence to the
paragraph for SUBSCRIBE_OK stating that "Group Sequence is an absolute group
sequence number, not the +1-offset encoding used by SUBSCRIBE's Start Group";
reference the symbols "Group Sequence", "SUBSCRIBE_OK", "SUBSCRIBE Start Group"
(and note that SUBSCRIBE_DROP reuses the same field name) so readers understand
the asymmetry.
- Around line 519-521: Clarify that for SUBSCRIBE_DROP the field "Group Count =
0" means "drop all remaining groups up to the subscription's End Group (if End
Group ≠ 0) or drop indefinitely (if End Group = 0/unbounded)"; explicitly state
this contrasts with SUBSCRIBE_OK where "Group Count = 0" denotes an unbounded
continuation. Update the SUBSCRIBE_DROP description to say that when End Group ≠
0 the drop is bounded by End Group (finite), and when End Group = 0 the
publisher MUST treat the subscription as terminated and send a FIN immediately
after issuing the SUBSCRIBE_DROP with Group Count = 0. Reference the symbols
SUBSCRIBE_DROP, SUBSCRIBE_OK, Group Count, Group Sequence and End Group when
making these edits.
- Around line 78-82: Clarify ALPN usage: state that "moq-lite-xx" as an ALPN
label applies only to bare-QUIC deployments (i.e., negotiated during the QUIC
handshake), and add a separate paragraph explaining WebTransport-over-HTTP/3
behavior where the underlying QUIC ALPN remains "h3" and the moq-lite protocol
must be advertised as a WebTransport subprotocol token via the
WT-Available-Protocols / WT-Protocol CONNECT headers; reference the existing
ALPN text and the terms "moq-lite-xx", "WT-Available-Protocols", and
"WT-Protocol" so readers know which mechanism to use in each deployment.
- Around line 207-208: Clarify the FIN semantics for Subscribe streams by
documenting two edge cases: (1) specify that a GROUP stream reset (QUIC RST) is
treated as an implied SUBSCRIBE_DROP for that group unless an explicit
SUBSCRIBE_DROP is received, and therefore it counts as "accounted for" toward
issuing the Subscribe stream FIN (reference: GROUP stream, SUBSCRIBE_DROP,
Subscribe stream FIN); and (2) define what "track ended" means for unbounded
subscriptions — state that the publisher indicates track end either by sending a
sentinel final group sequence (e.g., final group number) or by issuing a
publisher-side FIN on the track, and that either of these events closes
unbounded Subscribe streams (reference: unbounded subscriptions, track end,
publisher FIN).
- Around line 378-380: The sentence currently says "A client MUST ONLY alternate
between status values" but should refer to the ANNOUNCE sender, so change
"client" to "publisher" (i.e., the sender of ANNOUNCE messages) to match the
Flow section; update the ANNOUNCE description around the "status" rule (the
sentence referencing status/alternation) and any other occurrences in the
document to use "publisher" (or "sender") consistently so relays/bridges are
correctly covered.
- Around line 414-416: The spec is ambiguous about byte alignment between
"Subscriber Ordered (1)" and the varint "Subscriber Max Latency (i)"; update the
message layout so the varint starts on a byte boundary by replacing the current
bit-field pair with an explicit single byte flag: define "Subscriber Flags (8)"
where bit 7 = Ordered and bits 6–0 = Reserved (0), and remove the separate
"Subscriber Ordered (1)" and trailing implicit padding; apply the same change to
the SUBSCRIBE_UPDATE and SUBSCRIBE_OK message layouts and add a short prose note
that Reserved bits MUST be set to 0 and that Subscriber Max Latency (i) begins
at the next byte boundary.
---
Nitpick comments:
In `@draft-lcurley-moq-lite.md`:
- Around line 159-161: The Handshake section duplicates the Session section's
ALPN and session-active sentences; remove the repeated sentences in the
Handshake section and replace them with a brief cross-reference to the Session
section (e.g., "See the Session section for ALPN negotiation and session
activation details"), ensuring references to the ALPN format `moq-lite-xx` and
the immediate session activation remain only in the Session section; update any
nearby anchors or headings if needed so the cross-reference resolves correctly.
draft-lcurley-moq-lite.md
Outdated
| **Group Sequence**: | ||
| The resolved absolute start group sequence. | ||
|
|
||
| **Group Count**: | ||
| The number of consecutive groups in the subscription, starting from Group Sequence. | ||
| A value of 0 means unbounded. | ||
|
|
||
| See [SUBSCRIBE](#subscribe) for information about the other fields. |
There was a problem hiding this comment.
Clarify that Group Sequence in SUBSCRIBE_OK is NOT +1-encoded like Start Group in SUBSCRIBE.
SUBSCRIBE's Start Group uses an offset encoding where 0 = latest and non-zero = absolute sequence + 1 (Lines 443–444). SUBSCRIBE_OK's Group Sequence is described as "the resolved absolute start group sequence" without explicitly noting it carries the raw absolute value (no +1 offset). This asymmetry is easily misread, especially when SUBSCRIBE_DROP reuses the same Group Sequence field name.
Add a clarifying sentence, e.g.:
"This is an absolute group sequence number, not the +1-offset encoding used in SUBSCRIBE Start Group."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@draft-lcurley-moq-lite.md` around lines 491 - 498, Clarify that the "Group
Sequence" field in SUBSCRIBE_OK is the raw absolute sequence (no +1 offset) by
adding a sentence to the paragraph for SUBSCRIBE_OK stating that "Group Sequence
is an absolute group sequence number, not the +1-offset encoding used by
SUBSCRIBE's Start Group"; reference the symbols "Group Sequence",
"SUBSCRIBE_OK", "SUBSCRIBE Start Group" (and note that SUBSCRIBE_DROP reuses the
same field name) so readers understand the asymmetry.
|
Claude finished @kixelated's task —— View job Pull Request ReviewReviewing PR #15: MOQ Lite Draft-03 updates Todo List:
Comprehensive Protocol Specification ReviewThis PR introduces significant improvements to the MOQ Lite Draft-03 specification. Based on my analysis of the protocol changes, here's my comprehensive review: Major Protocol Improvements ✅1. ALPN-Based Session Negotiation (lines 78-80)
2. Stream-Based Architecture (lines 163-181)
3. New FETCH Stream (lines 210-217)
4. SUBSCRIBE_DROP Mechanism (lines 502-527)
5. PROBE Stream (lines 219-226)
Technical Quality Assessment ✅Protocol Design Strengths:
Performance Characteristics:
Areas for Improvement
|
There was a problem hiding this comment.
Actionable comments posted: 6
♻️ Duplicate comments (1)
draft-lcurley-moq-lite.md (1)
78-84: ALPN/WebTransport negotiation section looks good.The text now correctly distinguishes bare-QUIC (ALPN token during the QUIC handshake) from WebTransport over HTTP/3, which offers a protocol negotiation mechanism similar to ALPN, using
WT-Available-Protocolsin the CONNECT request to enumerate possible protocols in preference order. The extension negotiation via stream probing is a clean addition.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@draft-lcurley-moq-lite.md` around lines 78 - 84, The ALPN/WebTransport negotiation text is correct and needs no change; confirm that the document uses the `moq-lite-xx` version identifier consistently and that the distinction between bare QUIC ALPN negotiation and WebTransport over HTTP/3 using `WT-Available-Protocols`/`WT-Protocol` in the CONNECT request is preserved, and ensure the paragraph explaining extension negotiation via stream probing (opening a stream with an unknown type and peer RESET) remains as-is.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@draft-lcurley-moq-lite.md`:
- Around line 213-215: Clarify that the Fetch response stream carries only bare
FRAME messages and does not include a preceding GROUP header: update the text
around the FETCH/FRAME/GROUP descriptions to state explicitly that unlike Group
Streams (which MUST start with a GROUP message), a Fetch response returns FRAME
messages directly with no GROUP frame, and that the Subscribe ID and Group
Sequence for those frames are taken from the original FETCH request (i.e., the
group sequence is the one requested in the FETCH message). Include references to
the FETCH, FRAME, and GROUP symbols so readers understand this exception.
- Around line 490-493: The spec currently defines "Start Group" = 0 requires the
publisher to send a subsequent SUBSCRIBE_OK but omits an error/timeout path; add
a sentence after the "Start Group" definition stating that if the subscriber
does not receive a resolved non-zero Start Group in a subsequent SUBSCRIBE_OK
within an implementation-specific timeout, the subscriber MAY reset/terminate
the stream (or send an explicit error/UNSUBSCRIBE) to avoid hanging, and include
that this timeout and behavior are implementation-specific; reference the terms
"Start Group" and "SUBSCRIBE_OK" when adding the sentence so it's clear where
the timeout applies.
- Around line 222-226: Clarify PROBE semantics by stating that the subscriber
MAY send additional PROBE messages over the same bidirectional stream to update
the target bitrate and that the publisher MUST treat each PROBE as a new target
to attempt (or explicitly document if it only accepts the first), and also
specify how the publisher replies (periodic PROBE responses reflecting current
measured bitrate) and what to do if it cannot honor updates (e.g., reset the
stream if PROBE unsupported); reference the PROBE message, subscriber, publisher
and the bidirectional stream to make this negotiation behavior explicit.
- Line 643: Appendix B's "No group/object ID gaps" entry conflicts with the
updated GROUP section and zero-frame group allowance; update or remove that
appendix entry so it reflects the spec body: state that subscribers MUST handle
gaps (as described in the GROUP section) and that zero-frame groups are
permitted to represent gaps, or remove the assertion that gaps cannot exist;
ensure the appendix text references the GROUP behavior and the zero-frame group
allowance to avoid misleading implementors.
- Around line 476-485: The SUBSCRIBE_OK and SUBSCRIBE_DROP message definitions
break the spec's universal length‑prefixed framing by putting Type before
Message Length, which will mislead generic parsers; update both message
definitions (SUBSCRIBE_OK, SUBSCRIBE_DROP) so that Message Length (i) is the
first field and Type (i) becomes the first byte of the payload (i.e., reorder
fields to "Message Length (i)" then "Type (i) = 0x0/0x1" followed by the
remaining fields), and ensure the spec text clarifies that these messages now
follow the same length‑prefixed framing as ANNOUNCE, SUBSCRIBE, FRAME, etc.
- Around line 518-522: Update the SUBSCRIBE_DROP field descriptions to use the
same +1-offset encoding as SUBSCRIBE and SUBSCRIBE_OK (i.e., "absolute group
sequence + 1, with 0 reserved") so implementations don't silently off-by-one
decode dropped ranges; explicitly state the semantics for End Group = 0 (e.g.,
treat 0 as "unbounded / drop to latest" or "N/A" per your chosen convention) and
mention Start Group = 0 meaning "N/A" or reserved as well, and ensure the prose
references SUBSCRIBE_DROP, Start Group, End Group and the FIN accounting at Line
206 so readers know this change prevents FIN miscounting.
---
Duplicate comments:
In `@draft-lcurley-moq-lite.md`:
- Around line 78-84: The ALPN/WebTransport negotiation text is correct and needs
no change; confirm that the document uses the `moq-lite-xx` version identifier
consistently and that the distinction between bare QUIC ALPN negotiation and
WebTransport over HTTP/3 using `WT-Available-Protocols`/`WT-Protocol` in the
CONNECT request is preserved, and ensure the paragraph explaining extension
negotiation via stream probing (opening a stream with an unknown type and peer
RESET) remains as-is.
| SUBSCRIBE_OK Message { | ||
| Message Length = 0 | ||
| Type (i) = 0x0 | ||
| Message Length (i) | ||
| Publisher Priority (8) | ||
| Publisher Ordered (8) | ||
| Publisher Max Latency (i) | ||
| Start Group (i) | ||
| End Group (i) | ||
| } | ||
| ~~~ |
There was a problem hiding this comment.
Type before Message Length breaks the spec's universal length-prefixed framing.
The spec states (Line 334–336): "Most messages are prefixed with a variable-length integer indicating the number of bytes in the message payload that follows." Every other message (ANNOUNCE_PLEASE, ANNOUNCE, SUBSCRIBE, SUBSCRIBE_UPDATE, FETCH, PROBE, GROUP, FRAME) follows Message Length (i) as the first field. SUBSCRIBE_OK and SUBSCRIBE_DROP uniquely put Type (i) first, meaning the byte values 0x0 and 0x1 appear where a parser expects a length. A generic subscriber-side parser reading the Subscribe response stream will interpret the Type varint as a length and then misalign every subsequent field — causing silent wire-level misparse.
The spec needs to either:
- Explicitly document that the Subscribe response stream uses a Type–Length–Value framing (not Length-first like all other streams), so parsers know to read
Typefirst. - Move
TypeafterMessage Lengthand make it the first byte of the message payload (consistent with the rest of the spec).
💡 Option 2: move Type inside the length-prefixed payload
SUBSCRIBE_OK Message {
+ Message Length (i)
+ Type (i) = 0x0
- Type (i) = 0x0
- Message Length (i)
Publisher Priority (8)
Publisher Ordered (8)
Publisher Max Latency (i)
Start Group (i)
End Group (i)
}
SUBSCRIBE_DROP Message {
+ Message Length (i)
+ Type (i) = 0x1
- Type (i) = 0x1
- Message Length (i)
Start Group (i)
End Group (i)
Error Code (i)
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@draft-lcurley-moq-lite.md` around lines 476 - 485, The SUBSCRIBE_OK and
SUBSCRIBE_DROP message definitions break the spec's universal length‑prefixed
framing by putting Type before Message Length, which will mislead generic
parsers; update both message definitions (SUBSCRIBE_OK, SUBSCRIBE_DROP) so that
Message Length (i) is the first field and Type (i) becomes the first byte of the
payload (i.e., reorder fields to "Message Length (i)" then "Type (i) = 0x0/0x1"
followed by the remaining fields), and ensure the spec text clarifies that these
messages now follow the same length‑prefixed framing as ANNOUNCE, SUBSCRIBE,
FRAME, etc.
| **Start Group**: | ||
| The resolved absolute start group sequence. | ||
| A value of 0 means the start group is not yet known; the publisher MUST send a subsequent SUBSCRIBE_OK with a resolved value. | ||
| A non-zero value is the absolute group sequence + 1. |
There was a problem hiding this comment.
No timeout or error path defined when Start Group = 0 is never resolved in a subsequent SUBSCRIBE_OK.
The spec requires the publisher to send a follow-up SUBSCRIBE_OK with a resolved Start Group, but provides no guidance to the subscriber if it never arrives. The subscriber has no defined recourse — it silently hangs. Consider adding a sentence that the subscriber MAY reset the stream if the start group is not resolved within an implementation-specific timeout.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@draft-lcurley-moq-lite.md` around lines 490 - 493, The spec currently defines
"Start Group" = 0 requires the publisher to send a subsequent SUBSCRIBE_OK but
omits an error/timeout path; add a sentence after the "Start Group" definition
stating that if the subscriber does not receive a resolved non-zero Start Group
in a subsequent SUBSCRIBE_OK within an implementation-specific timeout, the
subscriber MAY reset/terminate the stream (or send an explicit
error/UNSUBSCRIBE) to avoid hanging, and include that this timeout and behavior
are implementation-specific; reference the terms "Start Group" and
"SUBSCRIBE_OK" when adding the sentence so it's clear where the timeout applies.
| **Start Group**: | ||
| The first absolute group sequence in the dropped range. | ||
|
|
||
| **End Group**: | ||
| The last absolute group sequence in the dropped range (inclusive). |
There was a problem hiding this comment.
SUBSCRIBE_DROP uses raw absolute group sequences while SUBSCRIBE/SUBSCRIBE_OK use +1-offset encoding — silent off-by-one for every implementation.
SUBSCRIBE and SUBSCRIBE_OK both encode group sequences as absolute + 1 (0 reserved for "latest"/"unknown"). SUBSCRIBE_DROP describes Start Group and End Group as plain "absolute group sequence" with no +1 offset and no special meaning for 0. An implementation that applies the same +1 decoding it uses for SUBSCRIBE/SUBSCRIBE_OK will misidentify every dropped range by one, causing the subscriber's FIN accounting (Line 206) to fail silently.
Additionally, End Group = 0 is left undefined here: unlike SUBSCRIBE (unbounded) and SUBSCRIBE_OK (unbounded), there is no guidance on whether End Group = 0 in SUBSCRIBE_DROP means "drop group 0", "drop all remaining", or is an error.
Consider using the same +1-offset convention throughout (SUBSCRIBE_DROP Start Group = 0 can mean "N/A" or reuse the absolute-value convention consistently), and add explicit prose for the 0-value semantics:
💡 Proposed prose fix for SUBSCRIBE_DROP field descriptions
**Start Group**:
-The first absolute group sequence in the dropped range.
+The first group in the dropped range.
+A non-zero value is the absolute group sequence + 1 (matching the encoding in SUBSCRIBE and SUBSCRIBE_OK).
**End Group**:
-The last absolute group sequence in the dropped range (inclusive).
+The last group in the dropped range (inclusive).
+A value of 0 means all remaining groups in the subscription (i.e., up to and including the subscription's End Group if bounded, or until the track ends if unbounded).
+A non-zero value is the absolute group sequence + 1.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@draft-lcurley-moq-lite.md` around lines 518 - 522, Update the SUBSCRIBE_DROP
field descriptions to use the same +1-offset encoding as SUBSCRIBE and
SUBSCRIBE_OK (i.e., "absolute group sequence + 1, with 0 reserved") so
implementations don't silently off-by-one decode dropped ranges; explicitly
state the semantics for End Group = 0 (e.g., treat 0 as "unbounded / drop to
latest" or "N/A" per your chosen convention) and mention Start Group = 0 meaning
"N/A" or reserved as well, and ensure the prose references SUBSCRIBE_DROP, Start
Group, End Group and the FIN accounting at Line 206 so readers know this change
prevents FIN miscounting.
| - Subscriptions start at the latest group, not the latest object. | ||
| - Subscriptions default to the latest group, not the latest object. | ||
| - No subgroups | ||
| - No group/object ID gaps |
There was a problem hiding this comment.
Appendix B "No group/object ID gaps" directly contradicts the new gap requirement in the spec body.
Line 589 (GROUP section) now reads: "A subscriber MUST handle gaps, potentially caused by congestion." Lines 322–323 also explicitly allow zero-frame groups as gaps. The Appendix B entry "No group/object ID gaps" is no longer accurate and will mislead implementors cross-referencing the diff from MoqTransport.
✏️ Proposed fix
-No group/object ID gaps
+Group sequence gaps are supported (subscriber MUST handle gaps)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@draft-lcurley-moq-lite.md` at line 643, Appendix B's "No group/object ID
gaps" entry conflicts with the updated GROUP section and zero-frame group
allowance; update or remove that appendix entry so it reflects the spec body:
state that subscribers MUST handle gaps (as described in the GROUP section) and
that zero-frame groups are permitted to represent gaps, or remove the assertion
that gaps cannot exist; ensure the appendix text references the GROUP behavior
and the zero-frame group allowance to avoid misleading implementors.
There was a problem hiding this comment.
♻️ Duplicate comments (3)
draft-lcurley-moq-lite.md (3)
645-645:⚠️ Potential issue | 🟡 MinorAppendix B still contradicts normative gap behavior.
Line 645 says “No group/object ID gaps,” but Line 591 says subscribers MUST handle gaps. Appendix text should match the body to avoid implementation confusion.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@draft-lcurley-moq-lite.md` at line 645, Appendix B currently states "No group/object ID gaps" which contradicts the normative requirement that subscribers MUST handle gaps; update Appendix B's wording (the "No group/object ID gaps" paragraph) to either remove the absolute claim or explicitly state that gaps can occur and subscribers MUST implement the gap-handling behavior described in the main body (the subscriber requirements), ensuring Appendix B aligns with the normative text.
478-486:⚠️ Potential issue | 🟠 Major
TypebeforeMessage Lengthstill creates framing ambiguity on Subscribe response streams.At Line 478-486 and Line 508-514, both
SUBSCRIBE_OKandSUBSCRIBE_DROPplaceType (i)beforeMessage Length (i). This still deviates from the document’s length-first framing convention and can mislead generic decoders unless you explicitly define this stream as TLV-framed in prose.Also applies to: 508-514
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@draft-lcurley-moq-lite.md` around lines 478 - 486, The SUBSCRIBE_OK and SUBSCRIBE_DROP message layouts violate the document’s length-first framing; change each message so Message Length (i) appears before Type (i) (i.e., swap the two fields in the SUBSCRIBE_OK Message and the SUBSCRIBE_DROP Message definitions) to restore consistent length-first framing and avoid ambiguity for generic decoders (update the entries that currently list "Type (i)" then "Message Length (i)" to list "Message Length (i)" then "Type (i)").
520-525:⚠️ Potential issue | 🟠 Major
SUBSCRIBE_DROPgroup range encoding is inconsistent withSUBSCRIBE/SUBSCRIBE_OK.At Line 521 and Line 524,
Start Group/End Groupare described as raw absolute sequences, whileSUBSCRIBEandSUBSCRIBE_OKuseabsolute + 1encoding (Line 445, Line 450, Line 495, Line 500). This inconsistency is a wire-level off-by-one footgun.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@draft-lcurley-moq-lite.md` around lines 520 - 525, The SUBSCRIBE_DROP group range encoding description is inconsistent with SUBSCRIBE/SUBSCRIBE_OK; update the SUBSCRIBE_DROP fields "Start Group" and "End Group" to use the same "absolute + 1" encoding convention as used by SUBSCRIBE and SUBSCRIBE_OK (rather than raw absolute sequences), and adjust the wording/examples in the SUBSCRIBE_DROP section so Start Group/End Group are documented and encoded as absolute+1 to avoid the off-by-one wire-level bug.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@draft-lcurley-moq-lite.md`:
- Line 645: Appendix B currently states "No group/object ID gaps" which
contradicts the normative requirement that subscribers MUST handle gaps; update
Appendix B's wording (the "No group/object ID gaps" paragraph) to either remove
the absolute claim or explicitly state that gaps can occur and subscribers MUST
implement the gap-handling behavior described in the main body (the subscriber
requirements), ensuring Appendix B aligns with the normative text.
- Around line 478-486: The SUBSCRIBE_OK and SUBSCRIBE_DROP message layouts
violate the document’s length-first framing; change each message so Message
Length (i) appears before Type (i) (i.e., swap the two fields in the
SUBSCRIBE_OK Message and the SUBSCRIBE_DROP Message definitions) to restore
consistent length-first framing and avoid ambiguity for generic decoders (update
the entries that currently list "Type (i)" then "Message Length (i)" to list
"Message Length (i)" then "Type (i)").
- Around line 520-525: The SUBSCRIBE_DROP group range encoding description is
inconsistent with SUBSCRIBE/SUBSCRIBE_OK; update the SUBSCRIBE_DROP fields
"Start Group" and "End Group" to use the same "absolute + 1" encoding convention
as used by SUBSCRIBE and SUBSCRIBE_OK (rather than raw absolute sequences), and
adjust the wording/examples in the SUBSCRIBE_DROP section so Start Group/End
Group are documented and encoded as absolute+1 to avoid the off-by-one
wire-level bug.
1 participant
No description provided.