Code change:
6.3. <del> The server sends a "GOAWAY" message to initiate session migration (session-migration) with an optional URI. </del> <ins> An endpoint sends a "GOAWAY" message to inform the peer it intends to close the session soon.  Servers can use GOAWAY to initiate session migration (session-migration) with an optional URI. </ins> <del> The server MUST terminate the session with a Protocol Violation (session-termination) if it receives a GOAWAY message.  The client MUST terminate the session with a Protocol Violation (session- termination) if it receives multiple GOAWAY messages. </del> <ins> The GOAWAY message does not impact subscription state.  A subscriber SHOULD individually UNSUBSCRIBE for each existing subscription, while a publisher MAY reject new requests while in the draining state. </ins> <del> New Session URI: The client MUST use this URI for the new session if provided.  If the URI is zero bytes long, the current URI is reused instead.  The new session URI SHOULD use the same scheme as the current URL to ensure compatibility. </del> <ins> Upon receiving a GOAWAY, an endpoint SHOULD NOT initiate new requests to the peer including SUBSCRIBE, FETCH, ANNOUNCE and SUBSCRIBE_ANNOUNCE. The endpoint MUST terminate the session with a Protocol Violation (session-termination) if it receives multiple GOAWAY messages. New Session URI: When received by a client, indicates where the client can connect to continue this session.  The client MUST use this URI for the new session if provided.  If the URI is zero bytes long, the client can reuse the current URI is reused instead.  The new session URI SHOULD use the same scheme as the current URL to ensure compatibility. If a server receives a GOAWAY with a non-zero New Session URI Length it MUST terminate the session with a Protocol Violation. </ins> 6.4.

Related discussion:
text: 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.