§6.2.

Publishing Namespaces

A publisher MAY send PUBLISH_NAMESPACE messages to any subscriber. A PUBLISH_NAMESPACE indicates to the subscriber that the publisher has tracks available in that namespace. A subscriber MAY send SUBSCRIBE or FETCH for tracks in a namespace without having received a PUBLISH_NAMESPACE for it.

If a publisher is authoritative for a given namespace, or is a relay that has received an authorized PUBLISH_NAMESPACE for that namespace from an upstream publisher, it MUST send a PUBLISH_NAMESPACE to any subscriber that has subscribed via SUBSCRIBE_NAMESPACE for that namespace, or a prefix of that namespace. A publisher MAY send the PUBLISH_NAMESPACE to any other subscriber.

An endpoint SHOULD report the reception of a REQUEST_OK or REQUEST_ERROR to the application to inform the search for additional subscribers for a namespace, or to abandon the attempt to publish under this namespace. This might be especially useful in upload or chat applications. A subscriber MUST send exactly one REQUEST_OK or REQUEST_ERROR as the first message on the bidi stream in response to a PUBLISH_NAMESPACE. The publisher SHOULD close the session with a protocol error if it receives more than one.

A PUBLISH_NAMESPACE is withdrawn by cancelling the request (see Section 3.3.1), although it is not a protocol error for the subscriber to send a SUBSCRIBE or FETCH message for a track in a namespace after the namespace is withdrawn.

A subscriber can cancel the request (see Section 3.3.1) to revoke acceptance of a PUBLISH_NAMESPACE. If the reason for cancellation is expiration of authorization credentials, the publisher can send PUBLISH_NAMESPACE again on a new bidi stream with refreshed authorization, or close the stream and discard associated state.

While PUBLISH_NAMESPACE indicates to relays how to connect publishers and subscribers, it is not a full-fledged routing protocol and does not protect against loops and other phenomena. In particular, PUBLISH_NAMESPACE SHOULD NOT be used to find paths through richly connected networks of relays.

A subscriber MAY send a SUBSCRIBE or FETCH for a track to any publisher. If it has accepted a PUBLISH_NAMESPACE with a namespace that exactly matches the namespace for that track, it SHOULD only request it from the senders of those PUBLISH_NAMESPACE messages.

This is one section of the MoQT specification, rendered per-section for quick reference and citation. The authoritative text is draft-ietf-moq-transport-17 at the IETF.