Change:
has been sent or received. To drain a WebTransport session, either endpoint can send a <del> DRAIN_WEBTRANSPORT_SESSION capsule.  An endpoint SHOULD NOT initiate new WebTransport streams or datagram flows after sending or receiving a DRAIN_WEBTRANSPORT_SESSION capsule.  Both endpoints can continue sending data on existing streams and datagram flows, but SHOULD attempt to gracefully terminate the session as quickly as possible. </del> <ins> DRAIN_WEBTRANSPORT_SESSION capsule.  After sending or receiving a DRAIN_WEBTRANSPORT_SESSION capsule, an endpoint MAY continue using the session but SHOULD attempt to gracefully terminate the session as soon as possible. </ins> 5.

Discussion:
FYI, the API PR for a client receiving a DRAINWEBTRANSPORTSESSION capsule is here: URL A separate issue has been opened for the client sending a DRAINWEBTRANSPORTSESSION capsule: URL After receiving a DRAINWEBTRANSPORTSESSION capsule from the server, the PR prevents the application from opening new unidirectional or bidirectional streams, but doesn't prevent it from continuing to send datagrams. Is that appropriate, or should the application treat receipt of the DRAINWEBTRANSPORTSESSION capsule more like a hint (e.g. it probably shouldn't open new unidirectional or bidirectional streams but it's not prohibited from doing so)?
Section 4.6 of WebTransport over HTTP/3 (URL) now covers the HTTP/3 GOAWAY frame. When sent from the server -> client this indicates that client attempts to construct additional WebTransport objects will fail. Does receipt of a GOAWAY frame need to be indicated to the application, or can it just deal with a (future) constructor error? The DRAINWEBTRANSPORTSESSION capsule PR has been merged, but the draft including the merged PR has not been published yet.
An HTTP/3 server needs the ability to gracefully drain existing connections. For HTTP/3, this involves sending a GOAWAY frame indicating that future requests should use a new HTTP/3 connection. However, the behavior of GOAWAY is partially undefined with WebTransport sessions. After receiving a GOAWAY, the client is no longer able to make new CONNECT requests. This means that any new WebTransport sessions will need to use a new HTTP/3 connection. This is great. However, it's not clear how existing sessions should behave after receiving a GOAWAY frame. Are they prohibited from creating new streams? How does this interact with the stream ID sent in the GOAWAY frame? Should the application expose the receipt of a GOAWAY to start a shutdown process?
Thanks for opening this issue -- it's been on my mind as well. I think it's important that we think through all the graceful draining scenarios, including when there are multiple proxies between the WT client and server, and one of the proxies initiates the drain. We already have a use-case which requires a session to be able to create new streams after the receipt of a connection level GOAWAY.

We've been exploring using a GOAWAY with MAXINT to signal the peer to stop creating new sessions, but continuing to all new streams within existing sessions. I don't think this totally jives with the definition of GOAWAY in the H3 spec, and I don't think it would work if there were 3 or more intermediaries. What would happen if WebTransport defined a GOAWAY frame that could be sent on the CONNECT stream to signal the intent to drain a session, but not the connection?
I think we should inform application of GOAWAY signal, and possibly add a GOAWAY on the CONNECT stream for intermediation between proxies.
Chair notes from IETF 112 meeting: no clear consensus in the room to do this. NAME has volunteered to write a PR proposal with justification of use-case to help motivate this.
Let me see if I can do the justification here, then draft the PR. Having a first class mechanism to "make-before-break" is a key reliability feature in HTTP/2 and HTTP/3. Intermediaries that carry WebTransport sessions but do not originate originate them need a mechanism to tell the application endpoints that draining is happening, so it can't be built exclusively into the application protocols HTTP/3 GOAWAY is too broad when multiple sessions pooled and multiple proxy hops are involved It's cheap to add a message that carries this signal on the CONNECT stream, and it's cheap to ignore it if you want to. As a concrete proposal within the current draft using capsules: I don't think we need to include any stream information in the Capsule, such as the highest peer initiated uni and bidi stream IDs received by this endpoint. Since the signal is delivered to the application endpoints, they can react and generate their own application level signal, if desired. The signal is only useful if it can be delivered to the application. If we agree this is valuable, should we open an issue for W3C? Writing this up made me realize that the WT over HTTP/3 draft doesn't describe how it interacts with GOAWAY. I opened to track that.
Chair: discussed in the room at IETF113, NAME will write a PR