The central interaction with a publisher is to send SUBSCRIBE and/or FETCH for a particular track. The subscriber expects to receive a SUBSCRIBE_OK/FETCH_OK and objects from the track.
A publisher MUST send exactly one SUBSCRIBE_OK or SUBSCRIBE_ERROR in response to a SUBSCRIBE. It MUST send exactly one FETCH_OK or FETCH_ERROR in response to a FETCH. The subscriber SHOULD close the session with a protocol error if it receives more than one.
A subscriber keeps SUBSCRIBE state until it sends UNSUBSCRIBE, or after receipt of a SUBSCRIBE_DONE or SUBSCRIBE_ERROR. Note that SUBSCRIBE_DONE does not usually indicate that state can immediately be destroyed, see Section 8.11.
A subscriber keeps FETCH state until it sends FETCH_CANCEL, receives FETCH_ERROR, or receives a FIN or RESET_STREAM for the FETCH data stream. If the data stream is already open, it MAY send STOP_SENDING for the data stream along with FETCH_CANCEL, but MUST send FETCH_CANCEL.
The Publisher can destroy subscription or fetch state as soon as it has received UNSUBSCRIBE or FETCH_CANCEL, respectively. It MUST reset any open streams associated with the SUBSCRIBE or FETCH. It can also destroy state after closing the FETCH data stream.
The publisher can immediately delete SUBSCRIBE state after sending SUBSCRIBE_DONE, but MUST NOT send it until it has closed all related streams. It can destroy all FETCH state after closing the data stream.
A SUBSCRIBE_ERROR or FETCH_ERROR indicates no objects will be delivered, and both endpoints can immediately destroy relevant state. Objects MUST NOT be sent for requests that end with an error.