]> Paramount

steven.riedl@pluto.tv

Web and Internet Transport Media Over QUIC media over quic moq msf event timeline advertising ad signaling ssai beacon This document defines the carriage of ad creative signaling -- creative identity, tracking events, and measurement verification metadata as specified by SVTA 2053-1 -- in records on a Media over QUIC (MOQT) Streaming Format (MSF) Event Timeline track. It complements the carriage of SCTE-35 splice signaling over the same mechanism: splice events describe where placement opportunities occur on a media timeline, while the event class defined here describes the creatives that fill them and how their playback is to be measured. This binding is the MSF counterpart of the DASH and HLS carriage bindings defined by SVTA 2053-1, which defines none for MOQT. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Media Over QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction SCTE-35 messages carried on an MSF Event Timeline track give Media over QUIC deployments the function SCTE-35 was built for: signaling placement opportunities -- break windows and splice conditioning -- on a shared media timeline, using the Event Timeline mechanism of the MOQT Streaming Format (). What that layer deliberately does not carry is a description of what plays inside those windows. On HLS and DASH, that gap is filled at the manifest: a packager or stitcher decorates each session's playlist with creative identity and tracking metadata. On a one-to-many publish/subscribe transport there is no per-session manifest to decorate -- every subscriber receives the same cached objects -- so anything a client needs at render time (which creative is playing, which tracking resources to request at which quartiles, which verification script to load) must be delivered in band, on the shared timeline, ahead of the splice point. This need is not incidental. Accurate measurement of server-side ad insertion increasingly means client-requested tracking -- per-device accounting at render time rather than server-side firing at publish time, which measures the wrong clock -- and verification means initializing a measurement script before the slot renders. SVTA 2053-1 already standardizes exactly this payload: a Pod/Slot/TrackingEvent/Verification data model (Section 4 of ), explicitly agnostic to client-side, server-side, and server-guided insertion, with carriage bindings defined per stream format -- DASH EventStream, HLS EXT-X-DATERANGE, HLS Interstitials -- and none for MOQT. This document fills that gap using the structures and already put in place: it defines an Event Timeline event class whose records carry SVTA 2053-1 Version 2 carriage envelopes, specifies how those records are timed and correlated with splice signaling, and gives operational guidance for tracking on one-to-many delivery. It changes nothing in the SVTA 2053-1 data model; payload normativity remains with , and this binding could additionally be published as a carriage section in a future revision of that specification. On status: is an adopted work item of the MoQ Working Group, and its Event Timeline mechanism is the substrate here; this document and are individual submissions layered on that substrate, and this one is written to track as it evolves under WG change control -- including following its registry, wherever that registry ultimately lands.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the terms Track, Group, Object, Event Timeline, and the index reference fields t, l, and m as defined in , and the terms Pod, Slot, Tracking Event, Verification, and carriage envelope as defined in Sections 4 and 5 of . Additionally:

Distributor:

The party operating the publisher that emits the media and signaling tracks (typically the party performing ad insertion).

Placement opportunity:

A window on the media timeline, typically signaled by SCTE-35, in which advertising content plays.

Splice signaling track:

An Event Timeline track carrying SCTE-35 records per .

Capability URL:

A URL whose knowledge alone grants the ability to perform a narrow action, used here as a short-lived, opaque reference to a distributor-operated tracking endpoint .

Track Properties An MSF track carrying ad creative signaling:

• MUST declare a packaging value of "eventtimeline";
• MUST declare an eventType value of "urn:svta:advertising-wg:ad-creative-signaling". This is the data scheme URI defined in Section 5 of , used unversioned: as in the DASH binding, the payload version is carried inside the payload itself ();
• MUST declare a depends attribute naming the media track or tracks whose timeline its records index. When the track accompanies a splice signaling track, it SHOULD name the same media track(s) as that track.

Because eventType is uniform for a track, and because implementations do not mix payload flavors within one Event Timeline track (see Section 4.3 of for the same rule applied to SCTE-35), ad creative signaling is carried on a sibling Event Timeline track alongside any splice signaling track, not interleaved within it. A splice signaling track is not required. Ad creative signaling describes what plays inside a placement opportunity; it does not depend on how the boundaries of that opportunity were signaled. A deployment MAY carry ad creative signaling with no SCTE-35 records present, leaving break detection to another mechanism entirely -- in-band timed metadata such as ID3, an emsg box, or the timing carried by the creative records themselves. Where a splice signaling track is present, the alignment rules in let the two be correlated; where it is absent, those rules simply do not apply.

Record Format

Structure Each record is a JSON object following the Event Timeline data format of . A record MUST contain:

• exactly one index reference field -- t (wallclock), l (MOQT Location), or m (media time) -- selected per ; and
• a data field whose value is exactly one Version 2 carriage envelope as defined in .

Index Reference Selection Records describing creatives spliced into the media timeline SHOULD use the m (media time) index, expressed in the coordinate space of the depends media track and sharing that track's timeline zero point. The t (wallclock) index MAY be used where a placement opportunity is defined in wallclock terms and no media time is available. The l (MOQT Location) index MAY be used for records bound to a delivery position rather than a media time. When a splice signaling track accompanies this track, records on the two tracks that describe the same point on the media timeline SHOULD carry index values of the same kind, chosen by the same precedence, so that a consumer can correlate them without converting between index types (). The requirement is on the observable result -- comparable indices for co-timed records -- not on adopting any particular document's selection algorithm. A deployment carrying SCTE-35 records per satisfies it by applying that specification's index selection rules (its Section 4.2) to both tracks.

Payload: Version 2 Carriage Envelope The data field carries one SVTA 2053-1 Version 2 carriage envelope (Section 5.2.2.1 of ) directly: The envelope is self-describing -- version and payload type are fields -- so no additional wrapper member is defined. Unlike the DASH and HLS bindings, where bare Version 1 payload objects are also legal, records in this binding MUST carry Version 2 envelopes only. On a fan-out transport the envelope's features flags are the only capability-signaling mechanism available, and the envelope type field is what allows a uniform track to carry pod, slot, and trackingEvent payloads interchangeably. It is RECOMMENDED that a publisher emit one pod envelope per placement opportunity. slot and trackingEvent envelopes MAY be used (mirroring the granularity options of the DASH binding), but deduplication under redelivery is simplest at pod granularity (see ).

Subscriber Invariance Records on this track MUST be subscriber-invariant: no field value may vary between subscribers. Per-session values enter only after delivery, either by client-side macro substitution (Section 6 of ) against broadcast templates, or by request-time indirection through capability URLs (). A macro template is conformant precisely because the template is identical for every subscriber; substitution is a post-delivery operation. The DASH and HLS bindings of assume a per-session manifest, so payload fields carrying session-scoped tracking values are well-formed in those bindings. That assumption does not hold here: records on a shared Event Timeline track are delivered identically to every subscriber and are relay-cacheable, so a session-scoped field would both leak across sessions and defeat caching.

Timing and Correlation

Shared Index Space A creative signaling record's index values are interpreted in the same coordinate space, with the same timeline zero point, as the depends media track -- and therefore the same space as an accompanying splice signaling track that names the same media track.

Correlation with Splice Signaling The record or records describing a placement opportunity SHOULD carry the same index value as the SCTE-35 record whose splice point opens that opportunity (the same m, or the same l Location when the splice is immediate). A pod whose start differs from the splice point MUST carry an index within the window the splice defines.

Publication Lead The publisher SHOULD publish a placement opportunity's creative signaling record(s) at least one full Group ahead of the media Group containing the splice point. Clients render seconds behind delivery, while render-time tracking and verification fire windows are sub-second: the tracking table must already be resident on the device when the first ad frame displays, with no time for a lookup round trip.

Container-Relative Interior Timing Within the envelope, timing is container-relative, per Sections 4.4.2 and 4.4.5 of : a Slot's start is relative to its Pod, and a Tracking Event's offset is relative to its container. Only the record's index reference is absolute. Consequently, redelivery, looped schedules, and regional timeline shifts never require payload rewrites -- which matters where relays cache and re-serve objects.

Worked Example An SCTE-35 record on the splice signaling track (reproduced from Section 5.1 of ) announces a splice at media time 480500 ms: The companion record on the ad creative signaling track, published at least one Group earlier (), carries the same index. It describes a 45.045-second pod with two slots: explicit quartile tracking and a verification resource on slot 1 (no offset on the quartile events, so timing is driven by event-type semantics per Section 4.4.5 of ), and lazily resolved tracking on slot 2 via $remote ():

Tracking Indirection and Capability URLs Two patterns satisfy . In the first, the record carries broadcast tracking templates and the client performs macro substitution locally at activation; SVTA 2053-1 payloads carry over from the DASH and HLS bindings unchanged and no distributor infrastructure is required, at the cost of exposing vendor endpoint inventory in shared bytes, inflating every record by the full tracking list, and leaving per-device accounting to the macros alone. The second, described in the remainder of this section, defers resolution to a distributor-operated endpoint. Both are conformant; a publisher chooses per deployment. Section 5.2.2.2 of already says interpreters SHOULD defer $remote resolution until the containing object is about to become active. That deferral maps naturally onto broadcast fan-out, with one addition: on a shared timeline, the URLs in tracking and $remote fields SHOULD be short-lived capability URLs referencing a distributor-operated tracking endpoint (a "beacon proxy"), rather than raw measurement-vendor URLs. At activation, the client requests the capability URL (or resolves $remote from it), appending a client identifier (). The endpoint performs macro substitution per Section 6 of (as Section 5.2.3 of provides) and requests the corresponding vendor resources with the calling device's context. Two properties fall out for free on one-to-many delivery:

• Payload size: shared-timeline records stay small even for heavy vendor tracking lists, with late binding after the pod record ships.
• Privacy and cache-safety: no per-user macro values and no vendor endpoint inventory appear in bytes that every subscriber and relay cache can read.

Client Identity and Per-Device Accounting Because every subscriber receives identical records, per-device measurement requires the device to identify itself at request time, not in the payload. A client SHOULD append a pseudonymous, session-scoped client identifier (issued and signed out of band, for example with the playback session) as a query parameter when requesting capability URLs. This mechanism applies to the indirection pattern; under client-side substitution, per-device accounting rests on the macro values alone. The tracking endpoint can then deduplicate on (resource, event, client identifier), count unique reach, and forward at most one request per device per event to vendor resources with that device's context -- preserving per-device measurement semantics without per-device payloads. Raw device identifiers MUST NOT appear in requested URLs.

Load Shaping On a shared fixed timeline, every subscriber reaches the same tracking instant at the same wallclock moment; naive activation-time behavior synchronizes both the $remote resolution fetches and the tracking requests of the entire audience. This applies with particular force under client-side substitution, where no distributor endpoint sits in the path to absorb the burst. Clients SHOULD resolve $remote fields within a randomized window ahead of activation (the publication lead of provides the margin), and SHOULD apply bounded random jitter to tracking requests whose measurement semantics tolerate it, carrying the original event time as data where the measurement moment must be preserved. Verification-critical requests with sub-second fire windows are the exception and are expected to be provisioned for.

Per-Session Insertion Plans Everything above is deliberately identical bytes for every subscriber -- that is what makes it relay-cacheable. Server-guided insertion, per-session capability URLs, and entitlement-scoped fields are per-session by definition and cannot ride the shared timeline. The authors believe the standardization target for that layer is a separate per-session insertion plan mechanism: a unicast-scoped metadata track (or equivalent side channel) carrying distributor session metadata -- the session's pod assignment for each shared-timeline placement opportunity, its capability URLs, and policy fields -- which composes with the shared events defined here (the shared timeline announces placement geometry and the broadcast/default pod; the insertion plan overlays the per-session decision). That mechanism is out of scope for this document and deserves its own. It is named here only as a design constraint: the event class defined in this document is intended to be overridden or parameterized by such a layer without being redefined by it.

Open Issues This section lists issues to be resolved through working group discussion; it is to be removed before publication.

1. Granularity: one pod envelope per placement opportunity (the RECOMMENDED default), or slot/trackingEvent envelopes per creative? Redelivery deduplication is simpler at pod granularity.
2. Update semantics for live: pods change close to air. Is a later record at the same index a full supersede (last-writer-wins), or is a patch rule needed? has no cancel/supersede concept; SCTE-35 inherits cancellation from its payload semantics.
3. Deduplication and late joiners: the DASH/HLS bindings give each event a manifest-unique id for dedup on re-encounter; MSF records carry no id. Is (eventType, index, payload) a sufficient dedup key under relay redelivery and FETCH catch-up -- and which past records MUST a mid-break joiner fetch?
4. Switching sets: when ladder rungs are separate tracks, does one creative signaling track depends on all of them? Splice conditioning can land at slightly different media times per rung; container-relative interior offsets survive that, but a single m may not. Sender-side track switching under discussion in the MOQ Working Group sharpens this: if relays select the delivered rung per subscriber and switch at Group boundaries, (a) these records must remain valid for every rung of a switching set, (b) splice conditioning must keep switching sets coherent at placement boundaries, and (c) the delivered rendition is known only at the client, so rendition-level measurement is necessarily client-observed.
5. Common-format scope: is the Event Timeline binding the whole story, or is a container-level mapping (the envelope in CMAF emsg) also wanted so one payload survives packager transit across HLS/DASH/MOQT boundaries?
6. Feature negotiation on one-to-many: interpreters SHOULD error on unsupported flagged features -- sensible unicast behavior, but a broadcast publisher cannot negotiate per subscriber. Should the catalog advertise which features a track uses so clients subscribe eyes-open?
7. Record integrity: do these records need payload signing (JWS or COSE over the envelope, or a catalog-pinned key) beyond transport authentication? See .

Implementation Status (This section follows and is to be removed before publication as an RFC.) The author operates a continuously running server-side ad insertion deployment over MoQ. This section states what that deployment does and does not implement, because the two are easy to conflate: the mechanism this document specifies is NOT yet what the deployment publishes. Running today:

• Fixed-timeline linear channels, publisher to relay to browser, with ad creatives spliced server-side into one shared broadcast -- so every subscriber receives the same media objects, which is the condition that motivates this document ().
• Placement opportunities detected from inbound in-band SCTE-35 (emsg), parsed to a break window and duration. The deployment consumes SCTE-35; it does not publish SCTE-35 records, and it does not publish a splice signaling track.
• Creative identity and per-creative tracking published in band, ahead of the splice, on a control track the subscriber reads before the first event renders. That validates the delivery model in . The track's schema is the deployment's own and is NOT the event class defined here.
• Tracking indirection exactly as described in : a proxy holds vendor beacon URLs and returns compact per-event capability URLs, which devices fire with their own client identifier, with per-{uuid, event, client} deduplication so a shared broadcast yields per-device counts. This is the part of the document with the most operational experience behind it.
• An MSF catalog, published automatically by the MoQ implementation in use and verified against an interop profile by a tool in the same codebase. A capture from the live deployment validates clean, so the transport and catalog layers this document builds on are exercised, not assumed.

NOT yet implemented:

• The event class this document defines. No track advertises eventType urn:svta:advertising-wg:ad-creative-signaling, and no record carries an SVTA 2053-1 Version 2 carriage envelope (). Migrating the control track to the envelope form is in progress.
• The IANA registration in , which this document requests.
• Correlation with a co-published splice signaling track (), since no such track is published.

Consequently the timing and lead-time rules in and derive from running code, while the record format in and the payload constraint in are specified but unexercised. The JSON Schema and test vectors in are conformance examples written against this specification, not captured output; the rules they express are executed in the implementation's own test suite, so they are internally consistent, but they have not yet been produced by a publisher.

Security Considerations

Integrity of Tracking Records Tracking URLs move money. A relay path is not end-to-end confidential or authentic by default, and a tampered creative signaling record turns a large synchronized audience into a request cannon aimed at an arbitrary URL -- amplifying the denial-of-service concerns already noted for splice records (Section 6.3 of ) with an attacker-chosen target. Deployments MUST authenticate the publication path for this track, and receivers SHOULD restrict tracking requests to URL authorities the distributor has designated (capability URLs at a distributor endpoint make this restriction natural). Whether records additionally need payload signing is tracked in .

Amplification and Load Even absent an attacker, activation-synchronized behavior across a broadcast audience is a self-inflicted denial of service; the mitigations in are accordingly stated as client SHOULDs. Capability URLs bound the blast radius of both cases: devices address the distributor's endpoint, which applies its own policy before any vendor is contacted.

Payload Validation Receivers MUST treat record payloads as untrusted input: enforce size and nesting limits on the JSON envelope, and accept only https URLs in tracking, $remote, and verification fields. Verification resources are executable code; clients MUST apply their platform's script-loading policy and SHOULD load them only for slots that will actually render.

Privacy By construction, the shared timeline carries no per-user data: records are identical for every subscriber, per-device identity is appended by the client at request time (), and identifiers are pseudonymous and session-scoped. Indirection through capability URLs additionally keeps vendor endpoint inventories and macro-expanded values out of relay caches. Distributor tracking endpoints handle real device context (addresses, user agents) and MUST apply applicable consent and data-protection policy before forwarding it to vendors.

IANA Considerations This document requests registration of the following entry in the "MSF Event Timeline Types" registry established by . registers entries in that same registry; this document follows the same pattern. Addition to the MSF Event Timeline Types registry

Event Type	Description	Reference
urn:svta:advertising-wg:ad-creative-signaling	SVTA 2053-1 ad creative signaling, Version 2 carriage envelope	This document;

Editor's note (to be resolved before publication): the URN is defined and owned by the SVTA Advertising Working Group; this registration is made in coordination with that group.

Normative References Akamai Cisco This document specifies the MOQT Streaming Format, designed to operate on Media Over QUIC Transport. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Streaming Video Technology Alliance (SVTA), Advertising Working Group In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Akamai Cisco Defines the transmission of SCTE 35 data over MSF Event Timeline tracks. Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. Society of Cable Telecommunications Engineers IAB Technology Laboratory IAB Technology Laboratory This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Acknowledgments This document deliberately reuses the carriage pattern established by Will Law and Suhas Nandakumar in , and is designed to compose with it. The payload data model is the work of the SVTA Advertising Working Group .

JSON Schema and Test Vectors A JSON Schema for the record shape and a set of test vectors are published alongside this document at https://riedlse.github.io/draft-riedl-moq-ad-creative-signaling/. The schema encodes exactly the two requirements of -- one index reference field, and a data member holding one Version 2 envelope -- and nothing further; the envelope's own contents are governed by , not by this document. The vectors come in two sets, and both matter: six that MUST validate, and six that MUST NOT. A validator that accepts everything passes the first set alone. The rejecting cases pin the constraints most likely to be implemented loosely:

Vector	Rejected because
two-index-fields	carries both m and t; exactly one is allowed
no-index-field	carries none
missing-data	index only, no envelope
v1-bare-payload	a bare Version 1 payload object, which the DASH and HLS bindings accept and this one does not ()
wrong-envelope-version	"version": 1 inside data
unknown-envelope-type	a type outside pod, slot, trackingEvent

A minimal conforming record, one pod envelope describing a single 30 s creative with its quartile chain (timings taken from a running deployment, so the values are the real ones a 30 s transcode produces -- note 30030, not 30000): The urls values are capability URLs (), abbreviated here. Two notes on provenance, so implementers know what these are and are not. The vectors are conformance examples authored against this specification, not captured output. The reference implementation publishes its break timeline on a non-standard control track today; migrating it to the envelope form described here is in progress, and vectors captured from it will replace these once that lands. Their timings, identifiers and quartile offsets are taken from a live deployment, so they are realistic, but the record framing is this document's. The rules the schema expresses are executable and run in that implementation's CI, so the published vectors cannot silently drift from the prose: the valid set is asserted to pass and the invalid set to fail, each for the specific reason its name claims.