If the subscriber is aware of a namespace of interest, it can send SUBSCRIBE_NAMESPACE to publishers/relays it has established a session with. The recipient of this message will send any relevant NAMESPACE, NAMESPACE_DONE or PUBLISH messages for that namespace, or more specific part of that namespace. This includes echoing back published Tracks and/or Track Namespaces under the SUBSCRIBE_NAMESPACE prefix to the endpoint that sent them. If an endpoint accepts its own PUBLISH, this behaves as self-subscription described in Section 5.1.
A SUBSCRIBE_NAMESPACE with zero Track Namespace fields indicates the sender is interested in all tracks and/or namespaces from the receiver.
The subscriber sends SUBSCRIBE_NAMESPACE on a new bidirectional stream and the publisher MUST send a single REQUEST_OK or REQUEST_ERROR as the first message on the bidirectional stream in response to a SUBSCRIBE_NAMESPACE. The subscriber SHOULD close the session with a protocol error if it detects receiving more than one.
If a Subscription cannot be created because there is no available Request ID, the Publisher sends a PUBLISH_BLOCKED message on the response stream to indicate the Full Track Name of the Subscription that could not be established. The Publisher MUST NOT send a PUBLISH for a Track after PUBLISH_BLOCKED has been sent. The subscriber can instead issue a SUBSCRIBE to establish a subscription to that track.
The receiver of a REQUEST_OK or REQUEST_ERROR ought to forward the result to the application, so the application can decide which other publishers to contact, if any.
A SUBSCRIBE_NAMESPACE can be cancelled by closing the stream with either a FIN or RESET_STREAM. Cancelling does not prohibit original publishers from sending further PUBLISH_NAMESPACE or PUBLISH messages, but relays MUST NOT send any further PUBLISH messages to a client without knowing the client is interested in and authorized to receive the content.