Stream reset semantics

[vasilvv]

We need to define whether WebTransport stream reset acts the way TCP and HTTP/2 reset does (resetting send side resets the receive side), or the way QUIC and HTTP/3 reset does (separate RESET_STREAM and STOP_SENDING).

My intuition here is that it's easier to go HTTP/2 way, since adding one-way reset to HTTP/2 would be a much more complex change than requiring QUIC endpoints to send STOP_SENDING on RESET_STREAM and vice versa.

[kixelated]

For QuicTransport, there should be way to gracefully half-close a stream. The ability to half-reseting a stream doesn't really matter but I would suggest consistency. If HTTP/2 is a burden to implement... that's a better case for dropping it than to make the ideal implementations worse.

[afrind]

You can half-close a QUIC stream by sending a FIN. Do you need the ability to half-close a QUIC stream in error?

[vasilvv]

WebTransport over HTTP/2 that the Working Group have adopted effectively resolves this in favor of unifying on QUIC reset semantics. Closing this as resolved.