Code change:
6.7. <ins> A publisher issues a "SUBSCRIBE_FIN" message to all subscribers indicating it is done publishing objects on the subscribed track. The format of "SUBSCRIBE_FIN" is as follows: Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this track. Final Object: The largest Object Sequence sent by the publisher in an OBJECT message in the "Final Group" for this track. 6.8. A publisher issues a "SUBSCRIBE_RST" message to all subscribers indicating there wan an error publishing to the given track and subscription is terminated. The format of "SUBSCRIBE_RST" is as follows: Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). Error Code: Identifies an integer error code for subscription failure. Reason Phrase Length: The length in bytes of the reason phrase. Reason Phrase: Provides the reason for subscription error and "Reason Phrase Length" field carries its length. Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this track. Final Object: The largest Object Sequence sent by the publisher in an OBJECT message in the "Final Group" for this track. 6.9. </ins> The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBE REQUESTs for tracks within the announced Track Namespace.  The receiver verifies the publisher is

Related discussion:
text: Once again data is flowing from A to R to B. I think it would be bad if the new ANNOUNCE, or an error on the QUIC connection from A to R caused a termination or error of the subscribe between B and R. I'm think it is better for B to unsubscribe if it is not receiving the media it wold expect.
Having explicit messages reflecting the actions would be my inclination as well. I thought it might be beneficial to explain the role of the above proposed messages with few flow diagrams Here is the happy path flow (it ignores Subscribe_OK and response flows to keep the flow focussed)
Summary thoughts: Want to support disconnection without propagation to all subscribers (ie: If there were two publishers) Need a way to cleanly unsubscribe from a track (UNSUBSCRIBE) - Like STOPSENDING? Need a way to indicate that a relay is no longer the place to subscribe to for a track (ie: UNANNOUNCE) But UNANNOUNCE does not indicate an unsubscription. Need a way to indicate the track is FIN'd and ending, could use the catalog or put in the protocol (or both) Likely want a way to drain a relay, such as an HTTP GOAWAY style functionality. (Could be SUBSCRIBETERMINATE) Timeouts do need to be handled, even if they're not the ideal/clean case. Want to know whether the relay wants to stop publishing or the origin did, so a client can decide whether to re-sub. NOTE: Objects can be dropped, hard to know if they'll ever arrive. Cullen will summarize a proposal. Note that the relay doesn't really need to know about tracks or what its subscribing to. An open issue is how to do FIN, whether it as part of Objects, only the catalog, a separate message, etc.
Rough notes on proposal in the call: The catalog updates and says what the last message in a track is. Catalogs are a way that endpoints can say there will never be more on a track. The annouce has an equivalent un-Annouce message. It changes routing of future subscribes but does not change state of existing subscribes. The entity that send an subscribe and send an un-subscribe The entity that receives a subscribe can send a go-away which will let the entity that sent the subscribe go do something new ( like subscribe to something else ).