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: Mo Zanaty (mzanaty)
• Published: 2026-05-23T00:29:25.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Mo Zanaty (mzanaty) posted to the MOQ working group mailing list on May 23, 2026. PR#1518 says this: If a track has a Track Property of the specified Property Type, its value is used for filtering both the PUBLISH messa…

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

PR#1518 says this: If a track has a Track Property of the specified Property Type, its value is used for filtering both the PUBLISH message and any Objects from that track that lack their own value for that Property Type. If the Track Property value does not pass the filter, no Objects from that track are delivered. I…

Plain-Text Body

PR#1518 says this: If a track has a Track Property of the specified Property Type, its value is used for filtering both the PUBLISH message and any Objects from that track that lack their own value for that Property Type. If the Track Property value does not pass the filter, no Objects from that track are delivered.

Is this not clear that the PUBLISH message and all objects are filtered out if it has a track property that does not pass the filter? Any proposed changes to make it clearer?

I requested time in London specifically for Track Property Filters, separately from Object Range Filters and Top N Track Filters, to clarify all these details.

Thanks, Mo

---

From: Alan Frindell afrind=40meta.com@dmarc.ietf.org Sent: Friday, May 22, 2026 5:39 PM To: Cullen Fluffy Jennings fluffy@iii.ca Cc: Magnus Westerlund magnus.westerlund=40ericsson.com@dmarc.ietf.org; MOQ Mailing List moq@ietf.org Subject: [Moq] Re: Consensus call on Object filters

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 l…