Media Over QUIC W. Law Internet-Draft Akamai Intended status: Informational S. Nandakumar Expires: 7 January 2027 Cisco 6 July 2026 SCTE35 transmission over MSF Event Timeline draft-wilaw-moq-scte35-event-timeline-00 Abstract Defines the transmission of SCTE 35 data over MSF Event Timeline tracks. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://wilaw.github.io/SCTE35-over-MSF-Event-Timeline/draft-wilaw- moq-scte35-event-timeline.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-wilaw-moq- scte35-event-timeline/. Discussion of this document takes place on the Media Over QUIC Working Group mailing list (mailto:moq@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at https://www.ietf.org/mailman/listinfo/moq/. Source for this draft and an issue tracker can be found at https://github.com/wilaw/SCTE35-over-MSF-Event-Timeline. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Law & Nandakumar Expires 7 January 2027 [Page 1] Internet-Draft SCTE35 over MSF July 2026 This Internet-Draft will expire on 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Track properties . . . . . . . . . . . . . . . . . . . . . . 3 4. SCTE 35 Mapping to MSF Event Timeline . . . . . . . . . . . . 3 4.1. Record Structure . . . . . . . . . . . . . . . . . . . . 3 4.2. Index Selection . . . . . . . . . . . . . . . . . . . . . 4 4.3. Payload Encoding Requirements . . . . . . . . . . . . . . 5 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Example 1: Binary Encoding with PTS Timing . . . . . . . 6 5.2. Example 2: XML Encoding with Immediate Flag . . . . . . . 6 5.3. Example 3: Mixed Timing (UTC and Cancellation) . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6.1. Integrity and Authenticity . . . . . . . . . . . . . . . 7 6.2. Payload Validation . . . . . . . . . . . . . . . . . . . 7 6.3. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction MOQT Streaming Format [MSF] defines Event Timeline tracks as a generic mechanism for transmitting ad hoc data associated with MSF media tracks. [SCTE35] markers signal ad insertion points, program boundaries, and other broadcast events. This draft specifies how SCTE35 data can be transmitted using MSF Event Timeline tracks. Law & Nandakumar Expires 7 January 2027 [Page 2] Internet-Draft SCTE35 over MSF July 2026 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Track properties An MSF track carrying [SCTE35] data MUST * declare a packaging value of "eventtimeline" * declare an eventType value of "urn:scte:scte35:2022:bin" if using binary splice information * declare an eventType value of "urn:scte:scte35:2022:xml" if using xml splice information 4. SCTE 35 Mapping to MSF Event Timeline 4.1. Record Structure Each record in the MSF Event Timeline track for SCTE 35 MUST be a JSON object conforming to the Event Timeline data format defined in [MSF] Section 8.1: it MUST contain exactly one index reference field (t, l, or m), selected per the precedence rules in Section 3.2, and a data field. The data field MUST be an object containing a single scte35_payload member. The scte35_payload contains either the Base64-encoded binary representation of the splice_info_section() or a string containing the escaped XML representation of the SCTE 35 message, per the eventType declared in the track properties (Section 2). { "m": 480500, "data": { "scte35_payload": "/DAhAAAAAAAAAP/wFAUAAArXf+/+AAAAAH4AARSyAAAAAA==" } } Law & Nandakumar Expires 7 January 2027 [Page 3] Internet-Draft SCTE35 over MSF July 2026 { "t": 1756885678361, "data": { "scte35_payload": "/DApAAAAAAAAAP/wBQb+AAAAAAAfAh1zY3RlMzU6U2VnbWVudGF0aW9uRGVzY3JpcHRvcg==" } } { "l": [42, 0], "data": { "scte35_payload": "" } } Since the index reference field itself identifies the timing source used for a record, no additional field is required inside data to disambiguate it. Receivers requiring finer-grained classification (e.g., distinguishing an immediate splice from an event cancellation) MAY inspect the scte35_payload itself, since this information is already present in the SCTE 35 message (splice_immediate_flag, splice_event_cancel_indicator, etc.) and duplicating it in the envelope would be redundant. 4.2. Index Selection Each record MUST select its index reference field according to the following precedence, applied to the SCTE 35 message being carried: * PTS-timed events: If a pts_time (binary) or ptsTime (XML) is present, the record MUST use m, the media time in milliseconds, computed as: floor(((pts_time + pts_adjustment) mod 2^33) / 90). This value MUST be expressed in the same coordinate space as the media time defined for the corresponding Media Timeline track or template ([MSF] Section 7.1.1) of the track(s) named in this track's depends attribute — that is, pts_time and the referenced media track's timestamps MUST share a common zero-point and epoch. Publishers MUST resolve any PTS discontinuities or 2^33 wraparound in the source SCTE 35 stream before computing m, so that the resulting value remains monotonic and consistent with the associated media track's timeline. * Wallclock-timed events: If a utc_splice_time is present without a pts_time, the record MUST use t, set directly to the UTC time expressed as milliseconds since the Unix epoch, per [MSF] Section 8.1. No conversion to media time is required or permitted; this avoids requiring the publisher to maintain a UTC- to-media-time mapping solely for signaling purposes. Law & Nandakumar Expires 7 January 2027 [Page 4] Internet-Draft SCTE35 over MSF July 2026 * Immediate events: If splice_immediate_flag is 1 and no pts_time is present, the record MUST use l, set to the MOQT Location — [Group ID, Object ID] — of the media Object at or immediately preceding which the splice is to take effect. This anchors the event to an actual encoded Object in the dependent media track rather than an approximated wallclock or media time. * Other events: For messages that carry no timing information of their own (e.g., splice_event_cancel_indicator, splice_null()), the record MUST use l, set to the MOQT Location of the media Object with which the record is associated at the time of publication. Publishers MUST use only one index reference field per record, per [MSF] Section 8.1. Because the four cases above use t, m, and l at different times within the same track, this track is a case where index reference types intentionally vary record-to-record, rather than following the "SHOULD use the same index reference type" guidance in [MSF] Section 8.1 — that guidance is best suited to tracks with a single, uniform timing source, which SCTE 35 signaling is not. 4.3. Payload Encoding Requirements * Binary Payloads: When the track is configured for binary carriage, the scte35_payload MUST be a Base64-encoded string of the splice_info_section() as defined in [SCTE35]. * XML Payloads: When the track is configured for XML carriage, the scte35_payload MUST be a string containing the XML representation as defined in [SCTE35]. Characters that are reserved in JSON (such as double quotes, backslashes, and control characters) MUST be properly escaped to maintain JSON validity as per [JSON]. Implementations MUST NOT mix binary and XML payloads within the same MSF Event Timeline track to ensure predictable parsing at the client. 5. Examples To illustrate the implementation of SCTE 35 within the MSF Event Timeline track, the following examples demonstrate the mapping of various timing sources — using MSF's native t, l, and m index reference fields — and the two supported encoding formats (Binary and XML). Law & Nandakumar Expires 7 January 2027 [Page 5] Internet-Draft SCTE35 over MSF July 2026 5.1. Example 1: Binary Encoding with PTS Timing This example shows the standard frame-accurate splice using a pts_time. Per Section 3.2 case 1, the record uses m, the calculated millisecond offset, and the payload is the Base64-encoded binary splice_info_section(). [ { "m": 480500, "data": { "scte35_payload": "/DAhAAAAAAAAAP/wFAUAAArXf+/+AAAAAH4AARSyAAAAAA==" } }, { "m": 510500, "data": { "scte35_payload": "/DAhAAAAAAAAAP/wFAUAAArYf+/+AAAAAH4AARSyAAAAAA==" } } ] 5.2. Example 2: XML Encoding with Immediate Flag In this scenario, the track is configured for XML. The first record illustrates an "immediate" event (splice_immediate_flag="1", no PTS) — per Section 3.2 case 3, it uses l, the MOQT Location of the media Object at which the splice takes effect. The second record shows a standard PTS-timed event, using m. Note the JSON-escaped quotes within the XML string. [ { "l": [15, 0], "data": { "scte35_payload": "" } }, { "m": 92000, "data": { "scte35_payload": "" } } ] Law & Nandakumar Expires 7 January 2027 [Page 6] Internet-Draft SCTE35 over MSF July 2026 5.3. Example 3: Mixed Timing (UTC and Cancellation) This example demonstrates a track that varies its index reference field record-to-record, as permitted by Section 3.2. The first record is anchored to a UTC wallclock moment — per case 2, it uses t directly, with no media-time conversion required. The second is a splice_event_cancel_indicator cancellation with no timing information of its own — per case 4, it uses l, referencing the Location of the media Object with which it is associated at the time of publication. [ { "t": 1756885678361, "data": { "scte35_payload": "/DApAAAAAAAAAP/wBQb+AAAAAAAfAh1zY3RlMzU6U2VnbWVudGF0aW9uRGVzY3JpcHRvcg==" } }, { "l": [15, 3], "data": { "scte35_payload": "/DAWAAAAAAAAAP/wBQIAAAAAf3/yD77y" } } ] 6. Security Considerations The carriage of SCTE 35 signals within the MSF Event Timeline track inherits the security considerations of both the underlying MSF transport and the SCTE 35 standard itself. 6.1. Integrity and Authenticity SCTE 35 messages are frequently used to trigger high-value business logic, such as the insertion of advertising or the enforcement of viewing blackouts. If the MSF track is not protected by transport- layer security (e.g., TLS) or object-level signing, an attacker could modify the "m" timing value or the "scte35_payload" to disrupt ad delivery or cause unauthorized content transitions. 6.2. Payload Validation Implementations MUST treat the scte35_payload as untrusted data. Receivers should implement robust parsing for both Base64-encoded binary data and XML strings to prevent buffer overflow attacks or XML External Entity (XXE) exploits. Specifically, when parsing XML- encoded SCTE 35, parsers SHOULD be configured to disallow DTDs and external entities. Large scte35_payload strings (especially in XML) Law & Nandakumar Expires 7 January 2027 [Page 7] Internet-Draft SCTE35 over MSF July 2026 could lead to memory exhaustion if not bound-checked by the JSON parser. 6.3. Denial of Service (DoS) An attacker could inject a high frequency of timeline records with conflicting "m" values. This could lead to "event thrashing," where the client device is forced to rapidly switch states, potentially leading to resource exhaustion or a degraded user experience. 7. IANA Considerations This document adds two entries to the "MSF Event Timeline Types" registry. +==========================+=====================+===============+ | Event Type | Description | Specification | +==========================+=====================+===============+ | urn:scte:scte35:2022:bin | SCTE 35 binary | this | | | splice_info_section | | +--------------------------+---------------------+---------------+ | urn:scte:scte35:2022:xml | SCTE 35 XML | this | | | representation | | +--------------------------+---------------------+---------------+ Table 1 8. Acknowledgments The IETF moq workgroup. 9. Normative References [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [MSF] Law, W. and S. Nandakumar, "MOQT Streaming Format", Work in Progress, Internet-Draft, draft-ietf-moq-msf-01, 2 June 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Law & Nandakumar Expires 7 January 2027 [Page 8] Internet-Draft SCTE35 over MSF July 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SCTE35] "SCTE 35: Digital Program Insertion Cueing Message", 2022, . Authors' Addresses Will Law Akamai Email: wilaw@akamai.com Suhas Nandakumar Cisco Email: snandaku@cisco.com Law & Nandakumar Expires 7 January 2027 [Page 9]