Code change:
Allow clients to send GOAWAY to signal servers to UNSUBSCRIBE.
PR has GOAWAY as only sent from server to client, but there may be use cases for the reverse as pointed out by NAME
I'm not really clear, what would be the use case for client -> server GOAWAY? If the only use case is a client indicating end of subscription, then I think that would be better encoded in the SUBSCRIPTION_END that Alan mentioned, but if there's other use cases then I could see GOAWAY making more sense.
What if the client is not the original source, but rather a relay. In that case, the relay may need to restart/etc. One option is the relay sends a GOAWAY and the client starts publishing to a new relay. But does it need to do something about it's upstream subscriptions?
FWIW ... relay to relay is out of scope - we are only doing client to relay - we would need a lot more to have a full relay to relay protocol
A client-initiated GOAWAY is weird but kind of makes sense. I'm thinking of the dual ingest case when there are two connections from broadcaster to relay(s). If the client sends a GOAWAY message, it's an explicit signal to the relay that it needs to UNSUBSCRIBE to everything and find another route to the content. The party isn't over, you just can't stay here. But there's some overlap with UNANNOUNCE. I'm not sure if we actually need it.
That use case makes sense. "The party isn't over, you just can't stay here." is awesome tag line for use case. For a graceful shutdown of a publisher, I think the way to do that would be the client publishing sends un-annouce and the relay then ends all the subscriptions, once all the subscriptions are gone, the client closes the connection.
With UNANNOUNCE and ANNOUNCE_CANCEL (), I'm inclined to think we don't need this.
UNANNOUNCE tells the receiver not to send new SUBSCRIBEs, but doesn't currently mean "please UNSUBSCRIBE and find somewhere else to SUBSCRIBE if you still want content". Do we want a message to convey that semantic?
It definitely feels odd given that outside of SETUP and ROLE parameter, MoQT is a symmetric protocol.
My current thinking is that GOAWAY is useful for all publishers, even if they're 'clients' (ie: an original publisher). It also seems useful if an original publisher is publishing to an ingestion server that is about to restart and the server wants to cause them to connect to a different ingestion server. I don't have a clear use for the end subscriber sending a GOAWAY, but it also doesn't seem particularly harmful.
I think you missed a few spots to update (suggestions made), but maybe you intentionally left those as is?

Related discussion:
text: used a Subscribe ID equal or larger than the current Maximum Subscribe ID. <del> GOAWAY Timeout: The session was closed because the client took too </del> <ins> GOAWAY Timeout: The session was closed because the peer took too </ins> long to close the session in response to a GOAWAY (message-goaway) message.  See session migration (session-migration). 3.6. <del> MoqTransport requires a long-lived and stateful session.  However, a service provider needs the ability to shutdown/restart a server without waiting for all sessions to drain naturally, as that can take days for long-form media.  MoqTransport avoids this via the GOAWAY message (message-goaway). </del> <ins> MOQT requires a long-lived and stateful session.  However, a service provider needs the ability to shutdown/restart a server without waiting for all sessions to drain naturally, as that can take days for long-form media.  MOQT enables proactively draining sessions via the GOAWAY message (message-goaway). </ins> <del> The server sends a GOAWAY message, signaling that the client should establish a new session and migrate any active subscriptions.  The GOAWAY message may contain a new URI for the new session, otherwise </del> <ins> The server sends a GOAWAY message, signaling the client to establish a new session and migrate any active subscriptions.  The GOAWAY message optionally contains a new URI for the new session, otherwise </ins> the current URI is reused.  The server SHOULD terminate the session with 'GOAWAY Timeout' after a sufficient timeout if there are still <del> open subscriptions on a connection. </del> <ins> open subscriptions or fetches on a connection. </ins> <del> The GOAWAY message does not immediately impact subscription state.  A subscriber SHOULD individually UNSUBSCRIBE for each existing subscription, while a publisher MAY reject new SUBSCRIBEs while in the draining state.  When the server is a subscriber, it SHOULD send a GOAWAY message to downstream subscribers prior to any UNSUBSCRIBE messages to upstream publishers. </del> <ins> When the server is a subscriber, it SHOULD send a GOAWAY message to downstream subscribers prior to any UNSUBSCRIBE messages to upstream publishers. </ins> After the client receives a GOAWAY, it's RECOMMENDED that the client waits until there are no more active subscriptions before closing the