IETF MOQ WG: Consensus call on Object filters

Message Snapshot

• List: moq@ietf.org
• Thread subject: Consensus call on Object filters
• Message subject: [Moq] Re: Consensus call on Object filters
• Author: Alan Frindell
• Published: 2026-05-22T21:39:17.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 22, 2026. I found one aspect of the Object/Range filters was a little confusing during the call, and cannot reconcile with the current PR text: do these…

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

I found one aspect of the Object/Range filters was a little confusing during the call, and cannot reconcile with the current PR text: do these parameters elicit different publisher behavior based on the context in

Plain-Text Body

I found one aspect of the Object/Range filters was a little confusing during the call, and cannot reconcile with the current PR text: do these parameters elicit different publisher behavior based on the context in which they appear?

The text of the PR implies that, for example, a Property filter in SUBSCRIBE_TRACKS does not impact the control plane - e.g. a SUB_TRACKS with Property: Foo=1 will still get a PUBLISH for a Track with Track Property: Foo=0. This is because objects might also have an override of Property Foo, and those that do get delivered.

I think this contradicted what I heard in the meeting, which is that the subscriber wouldn't even get a PUBLISH in this case. The text itself seems consistent, which is good, and it mirrors the concept that params in SUBSCRIBE_TRACKS are essentially applied to all the subscriptions matching the prefix. However, there is more utility in letting the Property filters in a SUBSCRIBE_TRACKS prevent the subscriber from ever receiving a PUBLISH for non-matching tracks. The concrete examples I've heard here really do apply to Track Properties that are unlikely to change object to object (codec=AV1). It's much less expensive to apply filters once at PUBLISH time than on every object in the Track.

I get the sense the wg has mostly considered the Range filters as they apply to SUBSCRIBE rather than SUBSCRIBE_TRACKS. If the feature is adopted, we'll need to clarify the ambiguity.

On the consensus call for integrating this feature into MOQT, I am neutral. As the feature applies to SUBSCRIBE/PUBLISH, it's clear how to implement, and dovetails with concepts we already have -- location filters and forward. Filtering out an entire subgroup, or a range of objects with low priority are broadly applicable features. I think most of the DOS concerns can be addressed once we tackle allowing multiple subscriptions to the same track - see issue 1633. There are tools for relays to protect compute, though it's unclear if these will lead to interop problems like, "My cool app needs 10 filters but the relay only supports 5, or 0". App developers could end up needing to fall back to subscriber-side filtering.

Since the feature is entirely optional, it could also live in an extension draft rather than the core. I'm ok to defer to the group.

Thanks

-Alan