IETF MOQ WG: Review of PR1673

Message Snapshot

• List: moq@ietf.org
• Thread subject: Review of PR1673
• Message subject: [Moq] Re: Review of PR1673
• Author: Cullen Fluffy Jennings
• Published: 2026-07-03T15:01:38.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Cullen Fluffy Jennings posted to the MOQ working group mailing list on July 3, 2026. Cutting out a bunch of stuff where Walk me through how this works with non bearer tokens. It’s fair to say the auth team needs to figu…

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

Cutting out a bunch of stuff where Walk me through how this works with non bearer tokens. It’s fair to say the auth team needs to figure this out but the general design for other protocols is an error to the request that contains the challenge data so the client can re respond with new auth data. The fundamental desig…

Plain-Text Body

Cutting out a bunch of stuff where

Walk me through how this works with non bearer tokens. It’s fair to say the auth team needs to figure this out but the general design for other protocols is an error to the request that contains the challenge data so the client can re respond with new auth data. The fundamental design problem here is you have basically two requests the subscribe, and the fetch in the FILL_PARAMETERS block but the problem is how do you return error for the two different requests as they can both have different errors. Auth seems like the most obvious thing that we need to sort out for this.

Perhaps the FILL_PARAMETERS block solves this but with the joining fetch, it is clear there are multiple ways to solve this. With this design, it removes many of the ways of solving it so it becomes more of an issue.

O generally favor explicit signals for things to happen over implicit changes. It does make sense in the use case you mentioned but consider this use case.

A clients joins starts with the low res version of a video and wants to grab the previous 30 seconds off live incase the user wants to scroll back in time to get what was missed as they joined. Client does fill fetch -30 seconds. After playing for 1 second the client realizes there is enough bandwidth to move up high res video stuff going forward but will still prefer to get the full 30 seconds of low res video before they start fetching previous 30 seconds of high res because the users scrolls back, it would be better to have the low than have no video.

I got strong signal from Ian and Martin a few others but that was before we had seen details of PR. I’m not sure I saw it as strong signal. Given how new this is, I’d rather see us get some experience with this before removing joining fetch.

At the point we are making parameters that are blocks of other parameters and, I think we think about about if that is the right design. We have text about parameters meaning different things depending on where they occur, and the draft is challenging to clearly think about what parameters can occur in what places.