A subscription can be initiated by either a publisher or a subscriber. A publisher initiates a subscription to a track by sending the PUBLISH message. The subscriber either accepts or rejects the subscription using PUBLISH_OK or PUBLISH_ERROR. A subscriber initiates a subscription to a track by sending the SUBSCRIBE message. The publisher either accepts or rejects the subscription using SUBSCRIBE_OK or SUBSCRIBE_ERROR. Once either of these sequences is successful, the subscription can be updated by the subscriber using SUBSCRIBE_UPDATE, terminated by the subscriber using UNSUBSCRIBE, or terminated by the publisher using SUBSCRIBE_DONE.
All subscriptions have a Forward State which is either 0 or 1. If the Forward State is 0, the publisher does not send objects for the subscription. If the Forward State is 1, the publisher sends objects. The initiator of the subscription sets the initial Forward State in either PUBLISH or SUBSCRIBE. The sender of PUBLISH_OK can update the Forward State based on its preference. Once the subscription is established, the subscriber can update the Forward State by sending SUBSCRIBE_UPDATE.
Either endpoint can initiate a subscription to a track without exchanging any prior messages other than SETUP. Relays MUST NOT send any PUBLISH messages without knowing the client is interested in and authorized to receive the content. The communication of intent and authorization can be accomplished by the client sending SUBSCRIBE_ANNOUNCES, or conveyed in other mechanisms out of band.
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. A subscriber MUST send exactly one PUBLISH_OK or PUBLISH_ERROR in response to a PUBLISH. The peer SHOULD close the session with a protocol error if it receives more than one.
A subscriber keeps subscription 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.12.
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 subscription 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 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.
A FETCH_ERROR indicates that both endpoints can immediately destroy state. Since a relay can start delivering FETCH Objects from cache before determining the result of the request, some Objects could be received even if the FETCH results in error.
The Parameters in SUBSCRIBE, PUBLISH_OK and FETCH MUST NOT cause the publisher to alter the payload of the objects it sends, as that would violate the track uniqueness guarantee described in Section 2.5.1.