MOQ at IETF 2026: What Changed in the Latest Drafts

As of September 3, 2026, the most important MOQ news is not that draft-ietf-moq-transport received another routine refresh. It is that the recent 2026 work has turned several long-running design debates into concrete wire-protocol decisions that implementers now need to absorb.

The latest published transport draft is draft-ietf-moq-transport-20, dated 31 August 2026 and expiring 4 March 2027. It follows draft-ietf-moq-transport-19 from 6 July 2026 and draft-ietf-moq-transport-18 from 12 May 2026. The working-group context matters too: the August 24, 2026 MOQ virtual interim minutes say the session focused on draft-ietf-moq-transport, especially location filters, fill fetches, OR filter semantics, namespace parameters, cache-field immutability, and top-track notification work. Those minutes also record a September 2, 2026 virtual interop for draft 18 and two September virtual interims before an in-person Seattle interim on October 14-15, 2026.

This article is the practical readout for engineering teams tracking Media over QUIC: what changed in the latest drafts, what did not change in the catalog work, and what the implementation ecosystem is already doing with those decisions.

The short version

Three spec changes stand out.

Area	What changed	Why implementers should care
Fill / joining behavior	draft-ietf-moq-transport-20 replaces Joining FETCH with fill fetch streams and adds FILL_PARAMETERS.	Catch-up behavior is becoming an explicit subscription mode instead of a separate FETCH flavor, which affects relay state, subscriber catch-up code, and test-vector coverage.
Filter semantics	draft-ietf-moq-transport-19 added Range Filters for Subscriptions and SUBSCRIBE_TRACKS; -20 restructures Location Filters and carries FETCH ranges inside LOCATION_FILTER.	Filter logic is moving into reusable parameters that apply across request types, so relay implementers need one coherent filtering engine rather than one-off FETCH code.
Publisher state / prioritization	draft-ietf-moq-transport-20 adds PUBLISH_STATE_NOTIFY, moves subscription parameters to REQUEST_UPDATE, and clarifies how PUBLISH carries subscription parameters without copying authorization tokens from SUBSCRIBE_TRACKS.	Track switching and relay-side scheduling are shifting away from extra request/OK round trips and toward publisher-driven state notification.

There is also a negative-but-important update: the working-group catalog draft did not move in 2026. The Datatracker page for draft-ietf-moq-catalogformat-01 marks it as an expired, archived/dead WG document, with latest revision 8 July 2024 and last update 9 January 2025. That means current implementers should treat catalog interop as a format-profile question, not as a fresh 2026 standards dependency.

What was latest on the standards track

The transport draft is still the center of gravity. The header of draft-ietf-moq-transport-20 names the document Media over QUIC Transport, lists it as Standards Track, and says it defines MOQT as a publish/subscribe protocol over QUIC and WebTransport that can run point-to-point or through relays. It is dated 31 August 2026 and points implementers to the working-group GitHub repo and the IETF Datatracker for status.

The August 31 working-group mail announcing -20 is unusually helpful because Ian Swett framed the revision as a staging point: the editors shipped -20 before larger editorial changes, planned a purely editorial -21, and planned a -22 around September 15, 2026, four weeks before the Seattle interim. In other words, the next churn may be mostly text organization, but the -20 protocol deltas are the substantive set to implement now.

A useful way to read the 2026 sequence is:

1. May 12, 2026: draft-ietf-moq-transport-18 rewrote a large amount of control-plane shape: moqt:// URI handling, SUBSCRIBE_NAMESPACE versus SUBSCRIBE_TRACKS, request stream reset semantics, REQUEST_OK aliases, track properties on REQUEST_OK, mandatory-to-understand track extensions, session-level tracks, revised joining FETCH behavior, delta-encoded fetch objects, FILL_TIMEOUT, and better startup/0-RTT guidance.
2. July 6, 2026: draft-ietf-moq-transport-19 added Range Filters across Subscriptions and SUBSCRIBE_TRACKS, allowed multiple concurrent subscriptions per track, moved GROUP_ORDER, renamed PUBLISH_BLOCKED to PUBLISH_SKIPPED, tightened GOAWAY and request-stream behavior, and clarified relay handling for track properties and immutable properties.
3. August 31, 2026: draft-ietf-moq-transport-20 replaced Joining FETCH with fill fetch streams, moved FETCH ranges into LOCATION_FILTER, added PUBLISH_STATE_NOTIFY, added INCLUDE_PROPERTIES, clarified PUBLISH/subscription parameter rules, removed VERSION_NEGOTIATION_FAILED, tightened relay obligations for upstream FETCH, defined moqt URI host resolution, and added new security guidance around impersonation, authorization, logging, URI handling, and relay confidentiality.

That is not cosmetic churn. It is the protocol moving from “can we describe the data model?” toward “can different relays, publishers, and clients make the same decision under load?”

Change 1: Joining FETCH became fill fetch streams

The most implementation-visible change in -20 is the replacement of Joining FETCH with fill fetch streams. The draft changelog says -20 “Replace[s] Joining FETCH with fill fetch streams” and adds a FILL_PARAMETERS parameter whose presence on a subscription requests a fill. It also removes the Joining variant of FETCH and the old “standalone” terminology.

The practical impact is big: catch-up is now expressed as part of the subscription lifecycle. A subscriber can say, in effect, “continue the live subscription, but fill this range behind it,” using parameters rather than switching into a separate joining-fetch model. That makes the behavior easier for relays to reason about because the fill is tied to the request state that will also carry live objects.

For implementers, the checklist is concrete:

• Parser and serializer code needs FILL_PARAMETERS, not a separate Joining FETCH code path.
• Subscription state needs to remember that a request can have active fill work and live forwarding work at the same time.
• Scheduling must define how objects delivered by fill interact with objects delivered by the ongoing subscription; -20 explicitly adds scheduling language for fill-delivered versus subscription-delivered objects.
• Error handling needs to follow the updated location/filter semantics, because the fill range now lives in parameters rather than in legacy FETCH fields.

This also explains why interop work is important. If one implementation still treats catch-up as a standalone fetch while another treats it as fill attached to a subscription, the two sides may appear compatible at setup and fail only when a subscriber joins a live track late.

Change 2: Filters became the load-bearing abstraction

The 2026 drafts make filters much more central.

draft-ietf-moq-transport-19 added Range Filters that can filter objects from Subscriptions and SUBSCRIBE_TRACKS. The same revision also introduced a MAX_REQUEST_UPDATES setup option and TOO_MANY_REQUEST_UPDATES error, allowed multiple concurrent subscriptions per track, updated forward-state handling for relays, and clarified authorization trust for namespace subscriptions.

Then draft-ietf-moq-transport-20 reworked the Location Filter to match the other filter parameters and moved the FETCH range into LOCATION_FILTER instead of carrying it in message fields. That sounds like a small cleanup until you look at what it does to relay code: filters become the common language for “what subset of objects does this request want?” whether the request started as a subscription, a subscription over discovered tracks, or a fill operation.

The August 24 interim minutes confirm that filters were not a side issue. They call out location filters and fill fetches as a central discussion topic, record consensus to retain SetID-based OR filter functionality, and note that relays can use SetIDs to deduplicate identical upstream data requests. The same meeting discussed whether namespace subscriptions should take parameters and how far updates should go without exploding state-machine complexity.

A separate August 2026 individual draft, draft-yuyou-moq-conditional-filtering-00, shows where the filter model may go next. The proposal introduces RANGE_FILTER_CONDITION, tying Range Filter SetIDs to relay-observable metrics so a relay can autonomously activate or deactivate filter sets at group boundaries. It explicitly positions itself as compatible with existing SetID-based Range Filters rather than as a replacement.

Do not treat that individual draft as part of MOQT yet. Treat it as a useful signal: once filters become the shared abstraction, people immediately start using them for adaptive delivery, congestion response, and relay-side selection.

Change 3: Publisher state is getting cheaper to signal

The other major -20 control-plane shift is publisher state notification.

draft-ietf-moq-transport-20 adds PUBLISH_STATE_NOTIFY, adds INCLUDE_PROPERTIES, says PUBLISH can carry Subscription Parameters, and clarifies that AUTHORIZATION_TOKEN is never copied from SUBSCRIBE_TRACKS. It also moves Subscription Parameters to REQUEST_UPDATE rather than PUBLISH_OK, and allows FORWARD on REQUEST_UPDATE for SUBSCRIBE_TRACKS.

The August interim gives useful color. For Issue 1830, “Top Tracks,” the minutes say Mo Zanaty planned to update the Top Tracks PR to use the newly merged PUBLISH_NOTIFY mechanism, with the expected benefit of cutting control-channel traffic in half during track switches by eliminating a REQUEST_UPDATE and OK round trip. Even if the exact message name changed in the published -20 text, the direction is clear: publisher-originated state changes are becoming a first-class way to reduce control-plane chatter.

That matters for any product that expects frequent changes in active layers, preferred tracks, or route choices. A live sports or watch-party workload does not merely subscribe once and coast. Viewers switch angles, tracks appear and disappear, relays migrate upstreams, and the system needs to avoid adding an extra round trip for every state hint.

The implementation impact is subtle:

• Subscribers need to process publisher-side state notification as authoritative protocol input, not as optional metadata.
• Relays need to decide which state to expose downstream and which properties remain immutable once an object is cached.
• Auth code needs to be careful not to propagate credentials across request types just because two messages are related.
• Observability should correlate notifications, updates, and resulting object delivery so operators can debug a switch without packet archaeology.

This is exactly the kind of change that tends to create version skew: all peers can speak “MOQT,” but only peers tracking the same request/update model will behave predictably under churn.

Security guidance got more operational

draft-ietf-moq-transport-20 also adds a cluster of security updates that are easy to miss if you only scan message names. The changelog adds a Preventing Impersonation section, expands mutual TLS and authorization guidance, adds moqt URI security considerations, warns about logging untrusted string fields, and recommends end-to-end object encryption when relays should not learn object contents.

That maps directly to deployment reality. MOQ relays are not just dumb packet forwarders. They make filtering, caching, routing, and scheduling decisions. Once relays can see names, properties, priorities, and subscription parameters, the security model has to say what a relay is allowed to trust, what a publisher is allowed to assert, and what a subscriber should avoid leaking into logs.

For teams building pilots, this is the line between a lab demo and a reviewable architecture. The draft is signaling that authorization and relay trust boundaries are no longer “later” topics.

What changed in moq-catalog? Mostly: nothing new on the IETF track

The catalog story is more awkward, and therefore more important to state precisely.

The working-group catalog draft is draft-ietf-moq-catalogformat-01, dated 8 July 2024. Its Datatracker page marks the document as an Expired Internet-Draft, Expired & archived, and a Dead WG Document, with last update 9 January 2025. The draft still describes the catalog as JSON metadata that lets subscribers select, subscribe to, and initialize tracks. It includes common fields such as version, streamingFormat, streamingFormatVersion, tracks, catalogs, namespace, name, packaging, renderGroup, selectionParams, codec, mimeType, bitrate, resolution, language, dependencies, and initialization tracks.

The practical conclusion is not “catalogs do not matter.” It is the opposite: catalogs matter enough that implementers are solving them in running code while the old WG document is stale.

Evidence from the implementation side is visible in recent releases. Eyevinn’s warp-player release notes from July 6, 2026 mention a catalog-retrieval selector and buffer profile tuning. The older gomoqt release captured in our database mentioned MSF documentation covering catalog, catalog delta, timeline, and broadcast concepts. The catalog concept remains useful, but if you are building against the latest transport draft, you should expect catalog details to be implementation/profile-specific unless the WG revives or replaces the catalog draft.

For procurement and architecture reviews, this is the correct risk statement: MOQT transport is active; common catalog standardization is not currently moving at the same pace.

Implementation signals: who is absorbing the churn?

Our ingested DB and fresh GitHub checks show that several public projects are tracking the churn closely enough to be useful signals.

moq-wg/moq-transport

The working-group source repo tagged draft-ietf-moq-transport-20 at commit d1004ff on August 31, 2026, with release notes for draft 20. Since then, the repo has already taken editorial commits on September 1-2, 2026, including moving range-filter wire format text, moving location-filter wire encoding, promoting setup options into their own sections, and renaming “Forwarding Preference” to “Delivery Mode.” That matches the mailing-list note that -21 should be editorial.

cloudflare/moq-rs

The Cloudflare Rust implementation is still active. GitHub release metadata shows moq-transport-v0.16.2 published August 29, 2026. The release notes are less about new features and more about operability: threading SessionId through sessions, publishers, subscribers, streams, request-id paths, and control-plane sites so sessions can be correlated in logs. Adjacent releases for moq-test-client, moq-sub, moq-relay-ietf, and moq-pub shipped the same day.

That is a useful maturity signal. When an implementation release is mostly adding correlation IDs and hardening session logging, it usually means teams are trying to debug multi-peer behavior, not merely make a happy-path demo compile.

moq-dev/moq

The moq-dev/moq project is also moving quickly. GitHub release metadata shows moq-relay-v0.14.15 and obs-moq-v0.5.13 published September 2, 2026. Recent notes include native Flutter bindings, relay/session fixes, live-edge resolution fixes, cache/eviction behavior, route-resume work, microphone publication control, and media pipeline fixes across relay, JavaScript, GStreamer, OBS, CLI, and FFI components.

That matters because it is not just a protocol crate. It is a sign that MOQ is being exercised through application-facing tooling: players, publishers, OBS, GStreamer, and relay infrastructure.

facebookexperimental/moxygen

The facebookexperimental/moxygen repository describes itself as a C++ implementation of Media over QUIC Transport with a library, relay, samples, and interop tooling. Our September 3 DB ingest flagged it as a repo to watch, and the GitHub API showed the repository pushed on September 3, 2026. That does not prove production deployment, but it is a strong implementation signal from an organization already represented in the editor list for the transport draft.

moqtap and test vectors

The moqtap ecosystem is worth watching because interop needs artifacts, not only libraries. Our DB ingested moqtap/test-vectors v0.15.0 on September 3, 2026, with a note about exercising repeated AUTHORIZATION_TOKEN on every draft that allows it. It also ingested moqtap trace and moqtap-js trace releases around draft-era trace format work.

For implementers, this is a practical path to lower risk: build against the spec text, then pin to public vectors and traces that encode actual interop edge cases.

New adopter signals: use caution

It is tempting to turn every new GitHub repo into an adoption headline. We should not do that.

Our September feed surfaced repos such as webrtc-moq-sip, wave-moq-edge, MoQ-Test-Tools, moqt-js, and mcp-moqt-transport. Those are useful discovery signals, but most should be described as experiments, tooling, or projects to watch unless they publish a customer deployment or production statement.

The strongest “new adopter” signal in August is Nokia Research’s conditional-filter draft and demo material, because it pairs a standards proposal with an implementation note in the WG mailing-list discussion. Even there, the right wording is “active research and implementation feedback,” not “adoption.”

For teams evaluating MOQ, the lesson is simple: track implementer velocity, but separate three things that are often conflated:

1. Spec implementation: a project implements the current wire protocol.
2. Interop participation: a project tests against other independent implementations.
3. Production adoption: a real product routes customer media through it.

The first two are visible in public today. The third needs stronger evidence than repository activity.

Why -20 is an inflection point

The most useful mental model for draft-ietf-moq-transport-20 is “less special-case transport, more parameterized request state.”

Earlier MOQ drafts were still trying to settle names, request shapes, and how relays should reason about objects. By -20, many of the newest changes share one theme: move behavior into parameters and state transitions that can be reused across request types.

That theme shows up in:

• FILL_PARAMETERS, which turns catch-up into subscription-associated state.
• LOCATION_FILTER, which carries ranges in filter parameters instead of bespoke FETCH fields.
• Range Filters and SetIDs, which provide the common logic that later conditional filtering proposals can reference.
• REQUEST_UPDATE, which becomes the locus for changing subscription parameters.
• PUBLISH_STATE_NOTIFY, which lets publisher-side state move without a full request-response cycle.
• Immutable properties and explicit relay-processing rules, which reduce ambiguity once objects are cached or forwarded.

The result is not a smaller protocol. The result is a protocol that is becoming more internally consistent. That is exactly what you want before serious interop testing: fewer magic branches, more reusable rules, and clearer failure modes.

What teams should do this week

If you own a MOQ implementation, -20 should trigger a focused compatibility pass.

Transport layer

• Add or update FILL_PARAMETERS handling.
• Remove assumptions that Joining FETCH is a separate message variant.
• Move FETCH range parsing into LOCATION_FILTER semantics.
• Ensure filter parameters work for both Subscriptions and SUBSCRIBE_TRACKS.
• Re-check request-stream FIN/RST/STOP_SENDING behavior inherited from -19.

Relay behavior

• Treat upstream FETCH as mandatory where -20 says a relay MUST send it to at least one publisher.
• Revisit deduplication around OR filters and SetIDs.
• Audit whether cached malformed-track objects can leak into downstream delivery.
• Preserve immutable properties and ignore conflicting later values where required.
• Log notification/update flows with stable session and request correlation IDs.

Security and auth

• Do not copy AUTHORIZATION_TOKEN from SUBSCRIBE_TRACKS into PUBLISH flows.
• Re-check mutual TLS and authorization assumptions.
• Avoid logging untrusted string fields without escaping or policy.
• Decide whether relays are allowed to see object payloads; if not, use end-to-end object encryption.
• Treat moqt URI parsing as security-sensitive input, especially around host resolution and query components.

Catalog and player integration

• Do not wait for a fresh 2026 catalog draft before testing transport interop.
• Document which catalog/profile fields your implementation actually emits.
• Prefer profile-specific conformance tests over vague “supports catalog” claims.
• Link player, packager, and relay releases to exact transport draft support.

What to watch next

The next useful checkpoints are already visible:

• A likely editorial draft-ietf-moq-transport-21 after the post--20 cleanup commits.
• A planned draft-ietf-moq-transport-22 around September 15, 2026, according to the August 31 mailing-list note.
• The September 2026 virtual interims and the October 14-15 Seattle interim.
• Whether conditional range filtering remains an individual draft or influences the working-group transport text.
• Whether a revived or replacement catalog draft appears, or whether implementation profiles continue to dominate catalog interoperability.

For now, the actionable conclusion is: update to the -20 mental model, do not overstate catalog stability, and test fill/filter/state-notify behavior before claiming current-draft interop.

Primary sources

• draft-ietf-moq-transport-20, 31 August 2026
• draft-ietf-moq-transport Datatracker page
• draft-ietf-moq-transport-20 GitHub release-notes commit
• August 31, 2026 working-group note announcing -20
• August 24, 2026 MOQ virtual interim minutes
• September 2, 2026 draft-18 virtual interop thread
• draft-ietf-moq-catalogformat-01, 8 July 2024
• draft-ietf-moq-catalogformat Datatracker page
• draft-yuyou-moq-conditional-filtering-00
• cloudflare/moq-rs releases
• moq-dev/moq releases
• facebookexperimental/moxygen
• moqtap/test-vectors

Related MOQ Edge reading

• Start with the Media over QUIC topic hub for the broader protocol map.
• Compare browser transport options in the WebTransport topic hub.
• Track daily standards and implementation updates on /updates.
• Subscribe via /newsletter or compare analyst plans on /pricing.