Back to News
news

IETF MOQ WG: Joining FETCH Survey

Alan Frindell posted to the MOQ working group mailing list on May 11, 2026. Hi, we got cut off at the end of the interim, and we planned to put this survey on list anyways, so here goes. Please reply on list before 5/20…

Source: IETF Mailing ListView source →

Message Snapshot

  • List: moq@ietf.org
  • Thread subject: Joining FETCH Survey
  • Message subject: [Moq] Joining FETCH Survey
  • Author: Alan Frindell
  • Published: 2026-05-11T18:14:42.000Z
  • Source tag: ietf-mailing-list
  • Message URL: Open in IETF Mail Archive

Summary

Alan Frindell posted to the MOQ working group mailing list on May 11, 2026. Hi, we got cut off at the end of the interim, and we planned to put this survey on list anyways, so here goes. Please reply on list before 5/20…

Why It Matters

This message came from the public MOQ working group archive and captures active discussion, meeting coordination, or implementation feedback around Media over QUIC.

Message Excerpt

Hi, we got cut off at the end of the interim, and we planned to put this survey on list anyways, so here goes. Please reply on list before 5/20. If you want to give color to your

Plain-Text Body

Hi, we got cut off at the end of the interim, and we planned to put this survey on list anyways, so here goes.

Please reply on list before 5/20. If you want to give color to your answers that's fine but please choose an answer from the provided options.

Question 1: Are your use cases satisfied?==== Answer 1-5: Which best describes your situation wrt to the currently specified version of joining FETCH? Please exclude any problems related to required-request ID/ordering.

  1. I do not need Joining FETCH to meet my use case(s)

  2. Joining FETCH meets my use cases(s) in both functionality and performance, and is not an undue implementation hassle

  3. Joining FETCH meets my use cases(s) in both functionality and performance, but IS an implementation hassle

  4. Joining FETCH meets my use cases(s) in functionality but has poor performance

  5. Joining FETCH does not meet my use case(s) in functionality and performance

Question 2: Are you laying in the road?===

Answer 1-4 which best describes your situation

  1. I can live with the shape of joining FETCH (two control messages, past and future have separate data planes). Make any small fixes needed and ship.

  2. I cannot live with two control messages, but I can live with separate data planes.

  3. I cannot live with two control messages, but can live with a unified data plane for current group only (groups entirely in the past can have separate data plane).

  4. I cannot live with two control messages nor separate data planes for past and future.

Question 3: Augment or Replace===

If we make a change, it ____ replace Joining FETCH in MOQT (MUST, SHOULD, MAY, MUST NOT)

Question 4: Tolerable Scope of change for past

4.1 Past data must be flow controlled in all cases (Y/N) 4.2 Past data must be flow controlled only if before the current group (Y/N)

4.3 Relays ____ use “Fill” semantics to retrieve all requested objects not in cache, when no existing operation will deliver them (e.g. upstream subscription). (MAY, MUST, MUST NOT)

Question 5: Delay Tolerance

I am willing to delay WGLC and RFC by ___ months to achieve a more preferable Joining FETCH outcome: 0 1 2 3 4+

Stay ahead of MOQ

Get the latest IETF MOQ standards updates, protocol analysis, and ecosystem news delivered to your inbox.

Go deeper with MOQ Edge Pro

Weekly deep-dives, IETF standards tracking, and streaming tech trend reports — from $9/mo.

See plans →