Change:
0x170d7b68 <del> WebTransport data stream reset because the associated WebTransport session has been closed. </del> <ins> WebTransport data stream aborted because the associated WebTransport session has been closed. </ins> This document.

Discussion:
The draft says that all streams need to be closed when the WebTransport session is closed. This makes me wonder: Which error code to use for that? Should we mandate using the same error code that the WebTransport session was closed with? Stream tracking: If it's the WebTransport implementation's responsibility to reset all the stream, this means that I need to keep another list / map of streams (outside of my QUIC stack). The interesting question is how to garbage collect closed streams from that list. It seems like the only way to do so is by introducing a callback for my QUIC stack to signal that a stream was closed / reset in both directions, so I can clean it up on the WebTransport layer.
Regarding the first issue, I was going to add a separate error code, but forgot to. Wrote to address this. Regarding the second issue, I am not sure what the question here. In Chromium, we keep a list of stream IDs for every WebTransport session, and call Reset() on all stream once the CONNECT stream is closed.
NAME gentle ping
fixes the issue. Regarding my second point, I assume that most implementations will actually keep a second map of streams around, but that's an implementation detail that we probably don't need to address in the spec.
The draft currently states: It's clear that without a CONNECT stream that new streams cannot be created and datagrams cannot be sent, but WT streams that were opened for that session could continue operating normally. This is how push streams are handled in H2 and H3 -- the push stream continues even if the associated stream is terminated. An endpoint always has the option to reset/stop sending WT streams when the session terminates. This is somewhat related to the graceful drain issue ()
Discussed at IETF 110. We should keep the current behavior for now, and revisit once we have more implementation experience.
Chair: discussed at 113, consensus in room to have close of CONNECT stream close all webtransport streams and datagrams. NAME will double-check that this is what the draft currently says
Draft says: That should be sufficient (I've opened to add an error code)
QuicTransport identifies itself using an ALPN and both peers agree to transfer additional configuration via a client-initiated stream (ID 2).

I think it would be an improvement if this origin indication was moved into the QUIC transport parameters and exchanged via the TLS ClientHello. There would be a few benefits (in no particular order): A server can terminate an invalid origin/path prior to performing the expensive TLS handshake. A server does not need to buffer stream data (inbound and outbound) waiting until stream 2 has arrived. A load balancer can route new connections to the correct server based on the path in the ClientHello. Currently, a load balancer must terminate TLS and buffer all streams until it can parse stream 2 prior to making a routing decision. QUIC stream IDs could be exposed to the application without the asterisks that stream 2 has already been used. The first client packet (ClientHello) must already be padded to 1200 bytes. The origin and path parameters would replace some of that padding and overall reduce the bandwidth for a new connection. There would be a few downsides: Long paths and origins could cause fragment the ClientHello message into multiple packets. Requires and . QUIC libraries need to expose or support the new transport parameters.
One more downside: The path and origin won't be encrypted. This leaks more information than SNI alone and would especially be a problem if ESNI is the future. Yeah, unfortunately I think this alone is a reason to stick with the stream 2 approach. Thanks for letting me think out loud!
Yeah, that's pretty much the reason why stream 2 exists (we tried a few ways to limit ourselves to transport params, but those didn't work out). It's possible that we could use for this, but ALPS is still in very early stage, so it's hard to tell if it will be useful.