From d28671138d0cab7c1c48c74eca6d4fa81a9c5fcc Mon Sep 17 00:00:00 2001 From: afrind Date: Wed, 22 Oct 2025 14:08:59 -0700 Subject: [PATCH 1/3] RFC: Change SUBSCRIBE_UPDATE to REQUEST_UPDATE This creates a mechanism to refresh auth credentials for PUBLISH, SUBSCRIBE_NAMESPACE and PUBLISH_NAMESPACE. A side-effect is that it allows the subscriber to change the priority of a FETCH (we closed #1204 already but this would address it). If we decide to address #1270, this will help. Fixes: #1267 Fixes: #1204 --- draft-ietf-moq-transport.md | 131 ++++++++++++++++++------------------ 1 file changed, 66 insertions(+), 65 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index 9d8a874ca..59c01b02c 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -870,7 +870,7 @@ initiates a subscription to a track by sending the SUBSCRIBE message. The publisher either accepts or rejects the subscription using SUBSCRIBE_OK or REQUEST_ERROR. Once either of these sequences is successful, the subscription moves to the `Established` state and can -be updated by the subscriber using SUBSCRIBE_UPDATE. Either endpoint +be updated by the subscriber using REQUEST_UPDATE. Either endpoint can terminate an `Established` subscription, moving it to the `Terminated` state. The subscriber terminates a subscription using UNSUBSCRIBE, the publisher terminates a subscription using @@ -896,7 +896,7 @@ REQUEST_ERROR | SUBSCRIBE_OK | | PUBLISH_OK | REQUEST_ERROR | V V | | +-------------+ | | | Established | ------+ - | | | | SUBSCRIBE_UPDATE + | | | | REQUEST_UPDATE | +-------------+ <-----+ | | | | | UNSUBSCRIBE | | PUBLISH_DONE | @@ -923,7 +923,7 @@ Forward State is 1, the publisher sends objects. The initiator of the subscription sets the initial Forward State in either PUBLISH or SUBSCRIBE. The sender of PUBLISH_OK can update the Forward State based on its preference. Once the subscription is established, the subscriber can update the Forward State by -sending SUBSCRIBE_UPDATE. Control messages, such as PUBLISH_DONE +sending REQUEST_UPDATE. Control messages, such as PUBLISH_DONE ({{message-publish-done}}) are still sent on subscriptions in Forward State 0. Either endpoint can initiate a subscription to a track without exchanging any @@ -1051,7 +1051,7 @@ One possible subscriber pattern is to SUBSCRIBE to a Track using Filter Type `Largest Object` and observe the `Largest Location` in the response. If the Object ID is below the application's threshold, the subscriber sends a FETCH for the beginning of the Group. If the Object ID is above the threshold and the -Track supports dynamic groups, the subscriber sends a SUBSCRIBE_UPDATE message with the +Track supports dynamic groups, the subscriber sends a REQUEST_UPDATE message with the NEW_GROUP_REQUEST parameter equal to the Largest Location's Group, plus one (see {{new-group-request}}). @@ -1195,7 +1195,7 @@ A lower priority number indicates higher priority; the highest priority is 0. `Subscriber Priority` is a priority number associated with an individual request. It is specified in the SUBSCRIBE or FETCH message, and can be -updated via SUBSCRIBE_UPDATE message. The subscriber priority of an individual +updated via REQUEST_UPDATE message. The subscriber priority of an individual schedulable object is the subscriber priority of the request that caused that object to be sent. When subscriber priority is changed, a best effort SHOULD be made to apply the change to all objects that have not been scheduled, but it is @@ -1371,7 +1371,7 @@ multiple subscribers request the same Track. Subscription aggregation allows relays to make only a single upstream subscription for the Track. The published content received from the upstream subscription request is cached and shared among the pending subscribers. -Because SUBSCRIBE_UPDATE only allows narrowing a subscription, relays that +Because MOQT restricts widening a subscription, relays that aggregate upstream subscriptions can subscribe using the Largest Object filter to avoid churn as downstream subscribers with disparate filters subscribe and unsubscribe from a Track. @@ -1442,7 +1442,7 @@ one publisher is available, the Relay MAY send the FETCH to any of them. When a Relay receives an authorized SUBSCRIBE for a Track with one or more `Established` upstream subscriptions, it MUST reply with SUBSCRIBE_OK. If the SUBSCRIBE has Forward State=1 and the upstream subscriptions are in Forward -State=0, the Relay MUST send SUBSCRIBE_UPDATE with Forward=1 to all publishers. +State=0, the Relay MUST send REQUEST_UPDATE with Forward=1 to all publishers. If there are no `Established` upstream subscriptions for the requested Track, the Relay MUST send a SUBSCRIBE request to each publisher that has published the subscription's namespace or prefix thereof. If the SUBSCRIBE has Forward=1, @@ -1550,7 +1550,7 @@ The following Message Types are defined: |-------|-----------------------------------------------------| | 0x4 | SUBSCRIBE_OK ({{message-subscribe-ok}}) | |-------|-----------------------------------------------------| -| 0x2 | SUBSCRIBE_UPDATE ({{message-subscribe-update}}) | +| 0x2 | REQUEST_UPDATE ({{message-request-update}}) | |-------|-----------------------------------------------------| | 0xA | UNSUBSCRIBE ({{message-unsubscribe}}) | |-------|-----------------------------------------------------| @@ -1594,7 +1594,7 @@ ongoing requests, and supports the endpoint's ability to limit the concurrency and frequency of requests. Request IDs for one endpoint increment independently from those sent by the peer endpoint. The client's Request ID starts at 0 and are even and the server's Request ID starts at 1 and are odd. The Request ID -increments by 2 with each FETCH, SUBSCRIBE, SUBSCRIBE_UPDATE, +increments by 2 with each FETCH, SUBSCRIBE, REQUEST_UPDATE, SUBSCRIBE_NAMESPACE, PUBLISH, PUBLISH_NAMESPACE or TRACK_STATUS request. Other messages with a Request ID field reference the Request ID of another message for correlation. If an endpoint receives a Request ID that is not valid @@ -1642,7 +1642,7 @@ these parameters to appear in Setup messages. #### AUTHORIZATION TOKEN Parameter {#authorization-token} The AUTHORIZATION TOKEN parameter (Parameter Type 0x03) MAY appear in a -CLIENT_SETUP, SERVER_SETUP, PUBLISH, SUBSCRIBE, SUBSCRIBE_UPDATE, +CLIENT_SETUP, SERVER_SETUP, PUBLISH, SUBSCRIBE, REQUEST_UPDATE, SUBSCRIBE_NAMESPACE, PUBLISH_NAMESPACE, TRACK_STATUS or FETCH message. This parameter conveys information to authorize the sender to perform the operation carrying the parameter. @@ -1821,7 +1821,8 @@ The subscription has Publisher Priorty 128 if this parameter is omitted. #### SUBSCRIBER PRIORITY Parameter {#subscriber-priority} The SUBSCRIBER_PRIORITY parameter (Parameter Type 0x20) MAY appear in a -SUBSCRIBE, SUBSCRIBE_UPDATE, TRACK_STATUS, PUBLISH_OK or FETCH message. It is an +SUBSCRIBE, REQUEST_UPDATE (for a subscription or FETCH), +TRACK_STATUS, PUBLISH_OK or FETCH message. It is an integer expressing the priority of a subscription relative to other subscriptions and fetch responses in the same session. Lower numbers get higher priority. See {{priorities}}. The range is restricted to 0-255. If a @@ -1852,7 +1853,8 @@ REQUEST_OK, PUBLISH or FETCH, the receiver uses Ascending (0x1). #### SUBSCRIPTION FILTER Parameter {#subscription-filter} The SUBSCRIPTION_FILTER parameter (Parameter Type 0x21) MAY appear in a -SUBSCRIBE, TRACK_STATUS, PUBLISH_OK or SUBSCRIBE_UPDATE message. It is a +SUBSCRIBE, TRACK_STATUS, PUBLISH_OK or REQUEST_UPDATE (for a subscription) +message. It is a length-prefixed Subscription Filter (see {{subscription-filters}}). If the length of the Subscription Filter does not match the parameter length, the publisher MUST close the session with `PROTOCOL_VIOLATION`. @@ -1870,9 +1872,9 @@ or UNSUBSCRIBE, depending on its role. This value is advisory and the sender can terminate the subscription prior to or after the expiry time. The receiver of the parameter can extend the subscription by sending a -SUBSCRIBE_UPDATE (TODO: SUBSCRIPTION_UPDATE). If the receiver of the parameter +REQUEST_UPDATE. If the receiver of the parameter has one or more updated AUTHORIZATION_TOKENs, it SHOULD include those in the -SUBSCRIBE_UPDATE. Relays that send this parameter and applications that receive +REQUEST_UPDATE. Relays that send this parameter and applications that receive it MAY introduce jitter to prevent many endpoints from updating simultaneously. @@ -1882,7 +1884,7 @@ does not expire or expires at an unknown time. #### LARGEST OBJECT Parameter {#largest-param} The LARGEST_OBJECT parameter (Parameter Type 0x9) MAY appear in SUBSCRIBE_OK, -PUBLISH or in REQUEST_OK in response to SUBSCRIBE_UPDATE. It is a +PUBLISH or in REQUEST_OK in response to REQUEST_UPDATE for a subscription. It is a length-prefixed Location structure (see {{location-structure}}) containing the largest Location in the Track observed by the sending endpoint (see {{subscription-filters}}. If Objects have been published on this Track the @@ -1894,13 +1896,13 @@ any Objects in the Track. #### FORWARD Parameter The FORWARD parameter (Parameter Type 0x10) MAY appear in SUBSCRIBE, -SUBSCRIBE_UPDATE, PUBLISH, PUBLISH_OK, TRACK_STATUS, TRACK_STATUS_OK, and +REQUEST_UPDATE (for a subscription), PUBLISH, PUBLISH_OK, TRACK_STATUS, TRACK_STATUS_OK, and SUBSCRIBE_NAMESPACE. It is a variable length integer specifying the Forwarding State on affected subscriptions (see {{subscriptions}}). The allowed values are 0 (don't forward) or 1 (forward). If an endpoint receives a value outside this range, it MUST close the session with `PROTOCOL_VIOLATION`. -If the parameter is omitted from SUBSCRIBE_UPDATE, the value for the +If the parameter is omitted from REQUEST_UPDATE, the value for the subscription remains unchanged. If the parameter is omitted from any other message, the default value is 1. @@ -1910,7 +1912,7 @@ The DYNAMIC_GROUPS parameter (parameter type 0x30) MAY appear in PUBLISH or SUBSCRIBE_OK. Values larger than 1 are a Protocol Violation. When the value is 1, it indicates that the subscriber can request the Original Publisher to start a new Group by including the NEW_GROUP_REQUEST parameter in PUBLISH_OK or -SUBSCRIBE_UPDATE for this Track. +REQUEST_UPDATE for this Track. Relays MUST preserve the value of this parameter received from an upstream publisher in SUBSCRIBE_OK or PUBLISH when sending these messages to downstream @@ -1919,10 +1921,10 @@ subscribers. #### NEW GROUP REQUEST Parameter {#new-group-request} The NEW_GROUP_REQUEST parameter (parameter type 0x32) MAY appear in PUBLISH_OK, -SUBSCRIBE or SUBSCRIBE_UPDATE. It is an integer representing the largest Group +SUBSCRIBE or REQUEST_UPDATE for a subscription. It is an integer representing the largest Group ID in the Track known by the subscriber, plus 1. A value of 0 indicates that the subscriber has no Group information for the Track. A subscriber MUST NOT send -this parameter in PUBLISH_OK or SUBSCRIBE_UPDATE if the publisher did not +this parameter in PUBLISH_OK or REQUEST_UPDATE if the publisher did not include DYNAMIC_GROUPS=1 when establishing the subscription. A subscriber MAY include this parameter in SUBSCRIBE without foreknowledge of support. If the original publisher does not support dynamic Groups, it ignores the parameter in that @@ -1942,7 +1944,7 @@ A relay that receives a NEW_GROUP_REQUEST for a Track without an `Established` subscription MUST include the NEW_GROUP_REQUEST when subscribing upstream. A relay that receives a NEW_GROUP_REQUEST for an established subscription with a -value of 0 or a value larger than the Largest Group MUST send a SUBSCRIBE_UPDATE +value of 0 or a value larger than the Largest Group MUST send a REQUEST_UPDATE including the NEW_GROUP_REQUEST to the publisher unless: 1. The Track does not support dynamic Groups @@ -2155,7 +2157,7 @@ REQUESTS_BLOCKED Message { ## REQUEST_OK {#message-request-ok} -The REQUEST_OK message is sent to a response to SUBSCRIBE_UPDATE, TRACK_STATUS, +The REQUEST_OK message is sent to a response to REQUEST_UPDATE, TRACK_STATUS, SUBSCRIBE_NAMESPACE and PUBLISH_NAMESPACE requests. The unique request ID in the REQUEST_OK is used to associate it with the correct type of request. @@ -2334,65 +2336,64 @@ SUBSCRIBE_OK Message { * Parameters: The parameters are defined in {{version-specific-params}}. -## SUBSCRIBE_UPDATE {#message-subscribe-update} +## REQUEST_UPDATE {#message-request-update} -A subscriber sends a SUBSCRIBE_UPDATE to a publisher to modify an existing -subscription. - -When updating the Subscription Filter (see {{subscription-filters}}), -the Start Location MUST not decrease, as an attempt to -to do so could fail. If Objects with Locations smaller than the current -subscription's Largest Location are required, FETCH can be used to retrieve -them. A publisher MUST terminate the session with a `PROTOCOL_VIOLATION` if the -SUBSCRIBE_UPDATE violates this rule. - -When a subscriber narrows their subscription (increase the Start Location and/or -decrease the End Group), it might still receive objects -outside the new range if the publisher sent them before the update was -processed. When a subscriber increases the End Location, the Largest Object at -the publisher might already be larger than the previous End Location. This will -create a gap in the subscription. The REQUEST_OK in response to the -SUBSCRIBE_UPDATE will include the LARGEST_OBJECT parameter, and the subscriber -can issue a FETCH to retrieve the omitted Objects, if any. - -The receiver of a SUBSCRIBE_UPDATE MUST respond with exactly one REQUEST_OK -or REQUEST_ERROR message indicating if the update was successful. When an -update is unsuccessful, the publisher MUST also terminate the subscription with -PUBLISH_DONE with error code `UPDATE_FAILED`. +The sender of a request can later send a REQUEST_UPDATE to to modify it. -Like SUBSCRIBE, End Group MUST be greater than or equal to the Group specified -in `Start`. +The receiver of a REQUEST_UPDATE MUST respond with exactly one REQUEST_OK +or REQUEST_ERROR message indicating if the update was successful. -If a parameter previously set on the subscription in `SUBSCRIBE`, `PUBLISH_OK` -or `SUBSCRIBE_UPDATE` is not present in `SUBSCRIBE_UPDATE`, its value remains -unchanged. +If a parameter previously set on the request is not present in +`REQUEST_UPDATE`, its value remains unchanged. -There is no mechanism to remove a parameter from a subscription. +There is no mechanism to remove a parameter from a request. -The format of SUBSCRIBE_UPDATE is as follows: +The format of REQUEST_UPDATE is as follows: ~~~ -SUBSCRIBE_UPDATE Message { +REQUEST_UPDATE Message { Type (i) = 0x2, Length (16), Request ID (i), - Subscription Request ID (i), + Existing Request ID (i), Number of Parameters (i), Parameters (..) ... } ~~~ -{: #moq-transport-subscribe-update-format title="MOQT SUBSCRIBE_UPDATE Message"} +{: #moq-transport-request-update-format title="MOQT REQUEST_UPDATE Message"} * Request ID: See {{request-id}}. -* Subscription Request ID: The Request ID of the SUBSCRIBE - ({{message-subscribe-req}}) this message is updating. This MUST match an - existing Request ID. The publisher MUST close the session with ` - `PROTOCOL_VIOLATION` if the subscriber specifies an invalid Subscription - Request ID. +* Existing Request ID: The Request ID of the request this message is + updating. This MUST match the Request ID of an existing request. The + receiver MUST close the session with `PROTOCOL_VIOLATION` if the sender + specifies an invalid Existing Request ID, or if the parameters included + in the REQUEST_UPDATE are invalid for the type of request being modified. * Parameters: The parameters are defined in {{version-specific-params}}. +### Updating Subscriptions + +When updating the Subscription Filter (see {{subscription-filters}}), +the Start Location MUST not decrease, as an attempt to +to do so could fail. If Objects with Locations smaller than the current +subscription's Largest Location are required, FETCH can be used to retrieve +them. A publisher MUST terminate the session with a `PROTOCOL_VIOLATION` if the +REQUEST_UPDATE violates this rule. + +When a subscriber narrows their subscription (increase the Start Location and/or +decrease the End Group), it might still receive objects +outside the new range if the publisher sent them before the update was +processed. When a subscriber increases the End Location, the Largest Object at +the publisher might already be larger than the previous End Location. This will +create a gap in the subscription. The REQUEST_OK in response to the +REQUEST_UPDATE will include the LARGEST_OBJECT parameter, and the subscriber +can issue a FETCH to retrieve the omitted Objects, if any. + +When a subscription +update is unsuccessful, the publisher MUST also terminate the subscription with +PUBLISH_DONE with error code `UPDATE_FAILED`. + ## UNSUBSCRIBE {#message-unsubscribe} @@ -2584,8 +2585,8 @@ MALFORMED_TRACK (0x7): {{malformed-tracks}}). UPDATE_FAILED (0x8): -: SUBSCRIBE_UPDATE failed on this subscription (see - {{message-subscribe-update}}). +: REQUEST_UPDATE failed on this subscription (see + {{message-request-update}}). ## FETCH {#message-fetch} @@ -2851,7 +2852,7 @@ Relays without an `Established` subscription MAY forward TRACK_STATUS to one or publishers, or MAY initiate a subscription (subject to authorization) as described in {{publisher-interactions}} to determine the response. The publisher does not send PUBLISH_DONE for this request, and the subscriber cannot send -SUBSCRIBE_UPDATE or UNSUBSCRIBE. +REQUEST_UPDATE or UNSUBSCRIBE. ## PUBLISH_NAMESPACE {#message-pub-ns} @@ -3434,7 +3435,7 @@ not limited to: * An Object in an open Subgroup exceeding its Delivery Timeout * Early termination of subscription due to an UNSUBSCRIBE message * A publisher's decision to end the subscription early -* A SUBSCRIBE_UPDATE moving the subscription's End Group to a smaller Group or +* A REQUEST_UPDATE moving the subscription's End Group to a smaller Group or the Start Location to a larger Location * Omitting a Subgroup Object due to the subcriber's Forward State From 4f638b18b51915d1c59c829b1de8c8b5de89deb3 Mon Sep 17 00:00:00 2001 From: afrind Date: Wed, 22 Oct 2025 14:10:53 -0700 Subject: [PATCH 2/3] ws --- draft-ietf-moq-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index 59c01b02c..bfb680f53 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -2341,7 +2341,7 @@ SUBSCRIBE_OK Message { The sender of a request can later send a REQUEST_UPDATE to to modify it. The receiver of a REQUEST_UPDATE MUST respond with exactly one REQUEST_OK -or REQUEST_ERROR message indicating if the update was successful. +or REQUEST_ERROR message indicating if the update was successful. If a parameter previously set on the request is not present in `REQUEST_UPDATE`, its value remains unchanged. From 6d570c836e72133c1e1f8f9a4d174a1085bd3017 Mon Sep 17 00:00:00 2001 From: Ye-Kui Wang <98077873+yekuiwang@users.noreply.github.com> Date: Wed, 22 Oct 2025 22:28:49 +0000 Subject: [PATCH 3/3] Consistent use of "`Established` subscription" --- 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 bfb680f53..e8608a7da 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -1350,7 +1350,7 @@ the content associated with the Track. The authorization information can be part of request itself or part of the encompassing session. The specifics of how a relay authorizes a user are outside the scope of this specification. -The relay MUST have an established upstream subscription before sending +The relay MUST have an `Established` upstream subscription before sending SUBSCRIBE_OK in response to a downstream SUBSCRIBE. If a relay does not have sufficient information to send a FETCH_OK immediately in response to a FETCH, it MUST withhold sending FETCH_OK until it does. @@ -1943,7 +1943,7 @@ Relay Handling: A relay that receives a NEW_GROUP_REQUEST for a Track without an `Established` subscription MUST include the NEW_GROUP_REQUEST when subscribing upstream. -A relay that receives a NEW_GROUP_REQUEST for an established subscription with a +A relay that receives a NEW_GROUP_REQUEST for an `Established` subscription with a value of 0 or a value larger than the Largest Group MUST send a REQUEST_UPDATE including the NEW_GROUP_REQUEST to the publisher unless: @@ -2927,7 +2927,7 @@ PUBLISH_NAMESPACE_CANCEL Message { ## SUBSCRIBE_NAMESPACE {#message-subscribe-ns} The subscriber sends the SUBSCRIBE_NAMESPACE control message to a publisher to -request the current set of matching published namespaces and established +request the current set of matching published namespaces and `Established` subscriptions, as well as future updates to the set. ~~~ @@ -2966,7 +2966,7 @@ the corresponding PUBLISH_NAMESPACE or PUBLISH_NAMESPACE_DONE message. A subscriber cannot make overlapping namespace subscriptions on a single session. Within a session, if a publisher receives a SUBSCRIBE_NAMESPACE with a -Track Namespace Prefix that shares a common prefix with an established namespace +Track Namespace Prefix that shares a common prefix with an `Established` namespace subscription, it MUST respond with REQUEST_ERROR with error code `PREFIX_OVERLAP`.