From e5dac7c29d30e4ff2f3a1e1ca781ae26bd859186 Mon Sep 17 00:00:00 2001 From: afrind Date: Mon, 6 Oct 2025 16:05:59 -0700 Subject: [PATCH 1/2] RFC: Define End-To-End parameters A strawman that could address #1278 1. Make unknown message params a PROTOCOL_VIOLATION 2. Make all subscriber message params hop-by-hop 3. Define publisher message parameter scope case-by-case: e2e: PUBLISHER_PRIORITY MAX_CACHE_DURATION DELIVERY_TIMEOUT [GROUP_ORDER] [DYNAMIC_GROUPS] hbh: AUTH_TOKEN EXPIRES [LARGEST_OBJECT] [FORWARD] --- draft-ietf-moq-transport.md | 41 +++++++++++++++++++++++++++++-------- 1 file changed, 33 insertions(+), 8 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index 66515f8a2..fe8442653 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -1531,24 +1531,23 @@ for the peer, or a new request with a Request ID that is not the next in sequence or exceeds the received MAX_REQUEST_ID, it MUST close the session with `INVALID_REQUEST_ID`. -## Parameters {#params} +## Message Parameters {#params} -Some messages include a Parameters field that encodes optional message -elements. +Some messages include a Parameters field that encodes optional message elements. +All parameters included in a message MUST be defined in the negotiated version +of MOQT or negotiated via Setup Parameters. An endpoint that receives an +unknown message parameters MUST close the session with `PROTOCOL_VIOLATION`. Senders MUST NOT repeat the same parameter type in a message unless the parameter definition explicitly allows multiple instances of that type to be sent in a single message. Receivers SHOULD check that there are no -unauthorized duplicate parameters and close the session as a -`PROTOCOL_VIOLATION` if found. Receivers MUST allow duplicates of unknown -parameters. +unexpected duplicate parameters and close the session as a +`PROTOCOL_VIOLATION` if found. The Parameters in SUBSCRIBE, PUBLISH_OK and FETCH MUST NOT cause the publisher to alter the payload of the objects it sends, as that would violate the track uniqueness guarantee described in {{track-scope}}. -Receivers ignore unrecognized parameters. - The number of parameters in a message is not specifically limited, but the total length of a control message is limited to 2^16-1 bytes. @@ -1561,6 +1560,16 @@ messages and for all other message types. SETUP message parameter types are defined in {{setup-params}}. Version-specific parameter types are defined in {{version-specific-params}}. +### Parameter Scope + +Message Parameters sent by the subscriber are always intended for the peer +endpoint and are not forwarded by Relays. Some message parameters sent by the +publisher are intended for the peer endpoint and are not forwarded by Relays, +while others relate to the Track or subscription and are considered End-to-End, +as noted in the parameter definition. End-to-End Parameters sent in PUBLISH, +SUBSCRIBE_OK, TRACK_STATUS_OK or FETCH_OK MUST be cached by Relays and included +in future downstream subscriptions or fetches for that Track. + ### Version Specific Parameters {#version-specific-params} Each version-specific parameter definition indicates the message types in which @@ -1681,6 +1690,9 @@ The AUTHORIZATION TOKEN parameter MAY be repeated within a message as long as the combination of Token Type and Token Value are unique after resolving any aliases. +When sent by a publisher, this parameter is not End-To-End (see +{{parameter-scope}}). + #### DELIVERY TIMEOUT Parameter {#delivery-timeout} The DELIVERY TIMEOUT parameter (Parameter Type 0x02) MAY appear in a @@ -1717,6 +1729,9 @@ successfully delivered within the timeout period before sending any data for that Object, taking into account priorities, congestion control, and any other relevant information. +When sent by a publisher, this parameter is End-To-End (see +{{parameter-scope}}). + #### MAX CACHE DURATION Parameter {#max-cache-duration} The MAX_CACHE_DURATION parameter (Parameter Type 0x04) MAY appear in a PUBLISH, @@ -1729,6 +1744,9 @@ multi-object stream will expire earlier than Objects later in the stream. Once Objects have expired from cache, their state becomes unknown, and a relay that handles a downstream request that includes those Objects re-requests them. +When sent by a publisher, this parameter is End-To-End (see +{{parameter-scope}}). + #### PUBLISHER PRIORITY Parameter {#subscriber-priority} The PUBLISHER PRIORITY parameter (Parameter Type 0x0E) specifies the priority of @@ -1740,6 +1758,9 @@ subscription inherit this priority, unless they specifically override it. The subscription has Publisher Priorty 128 if this parameter is omitted. +When sent by a publisher, this parameter is End-To-End (see +{{parameter-scope}}). + #### EXPIRES Parameter {#expires} @@ -1760,6 +1781,10 @@ simultaneously. If the EXPIRES parameter is 0 or is not present in a message, the subscription does not expire or expires at an unknown time. +When sent by a publisher, this parameter is not End-To-End (see +{{parameter-scope}}). + + ## CLIENT_SETUP and SERVER_SETUP {#message-setup} The `CLIENT_SETUP` and `SERVER_SETUP` messages are the first messages exchanged From cb80fbda43f448fa3c296002d8c94a9131e544cc Mon Sep 17 00:00:00 2001 From: afrind Date: Sun, 9 Nov 2025 21:45:46 -0800 Subject: [PATCH 2/2] clarify some publisher only/subscriber only params --- draft-ietf-moq-transport.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index ed66ffcfa..ee3df6704 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -1788,7 +1788,7 @@ multi-object stream will expire earlier than Objects later in the stream. Once Objects have expired from cache, their state becomes unknown, and a relay that handles a downstream request that includes those Objects re-requests them. -When sent by a publisher, this parameter is End-To-End (see +This parameter, which is only sent by publishers, is End-To-End (see {{parameter-scope}}). #### PUBLISHER PRIORITY Parameter {#subscriber-priority} @@ -1802,7 +1802,7 @@ subscription inherit this priority, unless they specifically override it. The subscription has Publisher Priorty 128 if this parameter is omitted. -When sent by a publisher, this parameter is End-To-End (see +This parameter, which is only sent by publishers, is End-To-End (see {{parameter-scope}}). #### SUBSCRIBER PRIORITY Parameter {#subscriber-priority) @@ -1881,7 +1881,7 @@ Relays MUST preserve the value of this parameter received from an upstream publisher in SUBSCRIBE_OK or PUBLISH when sending these messages to downstream subscribers. -When sent by a publisher, this parameter is End-To-End (see +This parameter, which is only sent by publishers, is End-To-End (see {{parameter-scope}}). #### NEW GROUP_REQUEST Parameter {#new-group-request} @@ -1923,7 +1923,7 @@ to the Largest Group, it does not send a NEW_GROUP_REQUEST upstream. After sending a NEW_GROUP_REQUEST upstream, the request is considered outstanding until the Largest Group increases. -When sent by a publisher, this parameter is not End-To-End (see +This parameter, which is only sent by subscribers, is not End-To-End (see {{parameter-scope}}). ## CLIENT_SETUP and SERVER_SETUP {#message-setup}