Code change:
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?

Related discussion:
text: OBJECT messages to matching subscribers in accordance to each subscription's priority, group order, and delivery timeout. <ins> 5.2.1. This section describes non normative behavior that a publisher MAY choose to implement to allow for a better users experience when switching from WiFi to Cellular networks or visa versa. If the original publisher detects it is likely to need to switch networks, for example because the WiFi signal is getting weaker, and it does not have QUIC connection migration available, it establishes a new session over the new interface and sends an ANNOUCE.  The relay will forward matching subscribes and the publisher publishes objects on both sessions.  Once the subscriptions have migrated over to session on the new network, the publisher can stop publishing objects on the old network.  The relay will drop duplicate objects received on both subscriptions.  Ideally, the subscriptions downstream from the relay do no observe this change, and keep receiving the objects on the same subscription. 5.2.2. This section describes non normative behavior that a publisher MAY choose to implement to allow for a better users experience when a relay sends them a GOAWAY. When a publisher receives a GOAWAY, it starts the process of connecting to a new relay and sends announces, but it does not immediately stop publishing objects to the old relay.  The new relay will send subscribes and the publisher can start sending new objects to the new relay instead of the old relay.  Once objects are going to the new relay, the announcement and subscription to the old relay can be stopped. </ins> 5.3. MOQT encodes the delivery information for a stream via OBJECT headers