Code change:
The application SHOULD use a relevant status code in SUBSCRIBE_DONE, as defined below: <ins> 5.1.1. This section describes behavior a subscriber MAY implement to allow for a better user experience when a relay sends a GOAWAY. When a subscriber receives the GOAWAY message, it starts of the process of connecting to a new relay and sending the SUBSCRIBE requests for all it's active subscriptions to the new relay.  The new relay will send a response to the subscribes and once this has happened, the subscription to the old relay can be stopped with an UNSUBSCRIBE. </ins> 5.2. Publishing through the relay starts with publisher sending ANNOUNCE <del> control message with a "Track Namespace" (model-track). </del> <ins> control message with a "Track Namespace" (model-track).  The annouce allows the relays to know which publisher to forward a SUBSCRIBE to. </ins> Relays MUST ensure that publishers are authorized by: Verifying that the publisher is authorized to publish the content associated with the set of tracks whose Track Namespace matches <del> the announced namespace.  Specifics of where the authorization happens, either at the relays or forwarded for further processing, depends on the way the relay is managed and is application specific (typically based on prior business agreement). </del> <ins> the announced namespace.  Specifics of where the authorization and identification of the publisher happens either at the relays or forwarded for further processing, depends on the way the relay is managed and is application specific (typically based on prior business agreement). </ins> Relays respond with an ANNOUNCE_OK or ANNOUNCE_ERROR control message providing the result of announcement.  The entity receiving the ANNOUNCE MUST send only a single response to a given ANNOUNCE of <del> either ANNOUNCE_OK or ANNOUNCE_ERROR.  When a publisher wants to stop new subscriptions for an announced namespace it sends an UNANNOUNCE. A subscriber indicates it will no longer route subscriptions for a namespace it previously responded ANNOUNCE_OK to by sending an ANNOUNCE_CANCEL. </del> <ins> either ANNOUNCE_OK or ANNOUNCE_ERROR. A Relay can receive announcements from multiple publishers for the same tracknamespace and it MUST respond with appropriate response to each of the publishers, in the same way as it would responds when processing ANNOUNCE from a single publisher for a given tracknamespace. When a publisher wants to stop new subscriptions for an announced namespace it sends an UNANNOUNCE.  A subscriber indicates it will no longer route subscriptions for a namespace it previously responded ANNOUNCE_OK to by sending an ANNOUNCE_CANCEL. </ins> A relay manages sessions from multiple publishers and subscribers, connecting them based on the track namespace.  This MUST use an exact

Related discussion:
text: Many thanks on review and any help of fixing all the small stuff (point me too it, or PR on the PR, anything) much appreciated.
NAME - thanks for review. I think I fixed all the stuff you raised. Can you take another look NAME - handing the baton to you on this one. Thanks you
At interim, to support make before break use-cases, we need to clarify relay behavior when a new announce arrives for existing published.
This came up during discussion of . The current draft is ambiguous whether multiple distinct publishers (not reconnect) can announce the same namespace to a relay. If that is allowed, should SUBSCRIBE messages be sent to all publishers that have announced that namespace? What happens if multiple SUBSCRIBE_OKs come back? Do we need normative text describing how a relay handles all these situations, or is it implementation specific? Some possible error conditions: Two publishers publisher the same track/group/object with different content One publisher skips an object (perhaps due to a delivery timeout) but another publisher sends it ?
I initially added a recommended session migration algorithm in . However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol. This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:
I think it'd be useful to have a PR to look at if you're willing to write one up?