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: We might need to figure out what data goes in the go away to given info that the clients enough info to do the right thing. Timeout can happen, and connections disappearing, and we need to sort out what impact that has but that is not the primary way to cause flow of media to change. Update: Key issue here is when the relays see the go away, do they drop the related forwarding state for the subscription, or do they just forward the update to the subscribers and wait for the subscribers to remove the subscription.
NAME NAME thanks for capturing the notes. I will work on set of small PRs to capture some of the items from the summary.
The point I was trying to clarify on the last call was that catalog already has a mechanism for a publisher to communicate to all subscribers that the track it has advertised as being available is no longer available. A clean FIN if you like. We can, as has been pointed out, create a control message which says the same thing. But then we have a weird asymmetry in which a publisher notifies clients of track availability through a catalog update but then uses control messages to do the reverse. For good design with clean encapsulation, we should seek symmetry in operation. We should either use control messages to advertise the availability/unavailability of tracks , or use catalogs, but not a hybrid of both. In my understanding of moq-transport, control messages have utility that is scoped to the current hop. They negotiate the format in which data will be exchanged on that hop and issue commands to subscribe/unsubscribe/announce etc. Those commands have no applicability to any other hops on the distribution chain. A catalog however is a contract between a publishers and all subscribers. Unlike control messages, it holds data that is not interpreted hop-by-hop and is intended for targets that can be many hops away. I think relays should be as simple as possible. In my conception, they should not understand whether tracks are being published or not. Their job is to move objects. Their view of the world is around objects and they do not need to understand what tracks are. While of course we can build all sorts of track intelligence in to relays, I think if we can build a base protocol which is agnostic to tracks, then it will be scalable and robust, and cleverness with tracks can evolve in the streaming formats without affecting deployed networks of relays.