Skip to content

Consistent use of "Established subscription" #1333

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from
Closed

Consistent use of "Established subscription" #1333

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d286711
RFC: Change SUBSCRIBE_UPDATE to REQUEST_UPDATE
afrind Oct 22, 2025
4f638b1
ws
afrind Oct 22, 2025
6d570c8
Consistent use of "`Established` subscription"
yekuiwang Oct 22, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
139 changes: 70 additions & 69 deletions draft-ietf-moq-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -896,7 +896,7 @@ REQUEST_ERROR | SUBSCRIBE_OK | | PUBLISH_OK | REQUEST_ERROR
| V V |
| +-------------+ |
| | Established | ------+
| | | | SUBSCRIBE_UPDATE
| | | | REQUEST_UPDATE
| +-------------+ <-----+
| | | |
| UNSUBSCRIBE | | PUBLISH_DONE |
Expand All @@ -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
Expand Down Expand Up @@ -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}}).

Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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.
Expand All @@ -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.
Expand Down Expand Up @@ -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,
Expand Down Expand Up @@ -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}}) |
|-------|-----------------------------------------------------|
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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`.
Expand All @@ -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.

Expand All @@ -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
Expand All @@ -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.

Expand All @@ -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
Expand All @@ -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
Expand All @@ -1941,8 +1943,8 @@ 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
value of 0 or a value larger than the Largest Group MUST send a SUBSCRIBE_UPDATE
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:

1. The Track does not support dynamic Groups
Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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}

Expand Down Expand Up @@ -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}

Expand Down Expand Up @@ -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}

Expand Down Expand Up @@ -2926,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.

~~~
Expand Down Expand Up @@ -2965,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`.

Expand Down Expand Up @@ -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

Expand Down