MOQ agenda highlights Required Request ID, MAX_REQUEST_UPDATES, and DELIVERY_TIMEOUT
Mo Zanaty (mzanaty) flagged Required Request ID, MAX_REQUEST_UPDATES, and DELIVERY_TIMEOUT in the latest MOQ meeting agenda and slide update. 1608 is a major change to the core data model that makes subgroups semantical…
Thread Snapshot
- List:
moq@ietf.org - Root subject: Monday's agenda is ready
- Representative message: [Moq] Re: Monday's agenda is ready
- Thread root: [Moq] Monday's agenda is ready
- Messages fetched in thread: 4
- Published: 2026-04-27
- Source: IETF Mailing List
Summary
Mo Zanaty (mzanaty) flagged Required Request ID, MAX_REQUEST_UPDATES, and DELIVERY_TIMEOUT in the latest MOQ meeting agenda and slide update. 1608 is a major change to the core data model that makes subgroups semantical…
Why It Matters
Agenda mail is a strong signal of where editor and chair attention is going next. This thread points implementers toward Required Request ID, MAX_REQUEST_UPDATES, and DELIVERY_TIMEOUT, which can affect request handling, timeout behavior, or other core transport semantics.
Notable Details
- #1608 Make Subgroup ID identical to first Object Id in the Subgroup
- #1519/#1603 Required Request ID
- #1613 Add MAX_REQUEST_UPDATES setup option and TOO_MANY_REQUEST_UPDATES error
- #1605 Split DELIVERY_TIMEOUT into two types of timeout
- 1608 is a major change to the core data model that makes subgroups semantically meaningless, as they would encode transport irregularities that destroy the app’s semantic meaning. A primary driver for adopting subgroups was video with scalable layers where the subgroup ID identified the layer. 1608 essentially removes subgroup ID, so there is no way to identify layers using MOQT alone. LOC originally embedded layer identifiers but removed this when MOQT added subgroups. I still think this was the right direction to have generally consistent semantics across apps at the core MOQT level data model.
- I agree it is useful (essential in some cases) to know if an object starts a subgroup. This can be indicated in the subgroup header using different type values for start of subgroup vs continued subgroup. IMO, that is a much better solution than changing the core data model.
Source Excerpt
1608 is a major change to the core data model that makes subgroups semantically meaningless, as they would encode transport irregularities that destroy the app’s semantic meaning. A primary driver for adopting subgroups was video with scalable layers where the subgroup ID identified the layer. 1608 essentially removes…