If the subscriber is aware of a namespace of interest, it can send SUBSCRIBE_NAMESPACE or SUBSCRIBE_TRACKS to publishers/relays it has established a session with. The Track Namespace Prefix carried in these messages is compared against the namespaces known to the receiver using Namespace Prefix Matching (Section 9.5, Paragraph 6).
SUBSCRIBE_NAMESPACE requests namespace discovery: the publisher sends relevant NAMESPACE and NAMESPACE_DONE messages for namespaces matching the prefix, including echoing back Track Namespaces under the prefix that have been published to it.
SUBSCRIBE_TRACKS requests track subscriptions: the publisher sends PUBLISH messages for tracks within matching namespaces, excluding tracks published by the subscriber.
Either message with zero Track Namespace fields indicates the sender is interested in all namespaces or all tracks from the receiver, respectively.
By sending SUBSCRIBE_NAMESPACE, the subscriber indicates that it trusts the relay to be authoritative for namespaces matching the requested prefix. NAMESPACE messages received on the SUBSCRIBE_NAMESPACE response stream inherit this trust and do not independently carry authorization.
The subscriber sends SUBSCRIBE_NAMESPACE or SUBSCRIBE_TRACKS 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.
If a Subscription cannot be created because there are no available bidirectional streams or any other reason, the Publisher sends a PUBLISH_SKIPPED message on the SUBSCRIBE_TRACKS response stream to indicate the Full Track Name of the Subscription that was not created. The Publisher MUST NOT send a PUBLISH for a Track for a given SUBSCRIBE_TRACKS after PUBLISH_SKIPPED has been sent, scoped to a single PUBLISH. If, for example, the publisher disconnects from a relay and later reconnects and sends a new PUBLISH, the relay MAY send the new PUBLISH downstream. If desired, the subscriber can 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 or SUBSCRIBE_TRACKS is cancelled as described in Section 3.3.3, by resetting or sending STOP_SENDING on the stream. Cancelling SUBSCRIBE_TRACKS does not prohibit original publishers from sending further 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.