webtransport: add a page about streams

content/docs/quic/streams.md

@@ -72,7 +72,7 @@ str, err := conn.OpenStreamSync(ctx)
 Both `OpenStream` and `OpenStreamSync` return an error when the underlying QUIC connection is closed.
 
 
-## Stream States
+## Stream States {#states}
 
 quic-go exposes three different stream abstractions: A `quic.SendStream` and a `quic.ReceiveStream`, for the two directions of unidirectional streams, and a `quic.Stream` for bidirectional streams.
 

content/docs/webtransport/session.md

@@ -1,5 +1,5 @@
 ---
-title: WebTransport Session
+title: Session
 toc: true
 weight: 3
 ---

content/docs/webtransport/streams.md

@@ -0,0 +1,25 @@
+---
+title: Streams
+toc: true
+weight: 4
+---
+
+A WebTransport stream functions similarly to a [QUIC Stream]({{< relref "../quic/streams.md" >}}). In particular, the stream state machines are exactly the same, as detailed in the [QUIC Stream documentation]({{< relref "../quic/streams.md#states" >}}). WebTransport supports both unidirectional and bidirectional streams.
+
+The main difference between a QUIC stream and a WebTransport stream lies in the type of error codes used to reset the stream: QUIC allows error codes up to a 62-bit unsigned integer, while WebTransport error codes are limited to a 32-bit unsigned integer.
+
+
+## Stream Errors
+
+When a stream is reset (i.e. when `CancelRead` or `CancelWrite` are used), applications can communicate an error code to the peer. Subsequent calls to Read and Write may return an error that can be type-asserted as a `quic.StreamError`.
+
+WebTransport itself does not interpret this value; instead, it is the responsibility of the application layer to assign specific meanings to different error codes. 
+
+Below is an example of how to type-assert an error as a `webtransport.StreamError`:
+
+```go
+var streamErr *webtransport.StreamError
+if errors.As(err, &streamErr) {
+  errorCode := streamErr.ErrorCode
+}
+```