A publisher MAY send PUBLISH_NAMESPACE messages to any subscriber. A PUBLISH_NAMESPACE indicates to the subscriber that the publisher has tracks available in namespaces matching the Track Namespace Prefix it carries (see Section 2.4.2). A subscriber MAY send SUBSCRIBE, FETCH or TRACK_STATUS for tracks in a namespace without having received a PUBLISH_NAMESPACE for it.
The receiver verifies the publisher is authorized to publish tracks under this prefix.
A subscriber MUST send exactly one PUBLISH_NAMESPACE_OK or PUBLISH_NAMESPACE_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.
An endpoint SHOULD report the reception of a PUBLISH_NAMESPACE_OK or PUBLISH_NAMESPACE_ERROR to the application to inform the search for additional subscribers for a namespace, or to abandon the attempt to publish under this namespace.
If a subscriber has accepted a PUBLISH_NAMESPACE with a namespace that exactly matches the namespace for a given track, it SHOULD only request the Track from the sender(s) of those PUBLISH_NAMESPACE messages.
A PUBLISH_NAMESPACE is withdrawn by cancelling the request (see Section 6.4.2.3), although it is not a protocol error for the subscriber to send a SUBSCRIBE, FETCH or TRACK_STATUS message for a track in a namespace after the namespace is withdrawn.
A subscriber can cancel the request (see Section 6.4.2.3) 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.
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. In particular, PUBLISH_NAMESPACE SHOULD NOT be used to find paths through richly connected networks of relays.