Change:
encoded using the QUIC variable length integer scheme described in RFC9000. <ins> The client MAY optimistically open unidirectional and bidirectional streams, as well as send datagrams, for a session that it has sent the CONNECT request for, even if it has not yet received the server's response to the request.  On the server side, opening streams and sending datagrams is possible as soon as the CONNECT request has been received. </ins> If at any point a session ID is received that cannot a valid ID for a client-initiated bidirectional stream, the recipient MUST close the connection with an H3_ID_ERROR error code. 4.1. <del> Once established, both endpoints can open unidirectional streams. The HTTP/3 unidirectional stream type SHALL be 0x54.  The body of the </del> <ins> WebTransport endpoints can initiate unidirectional streams.  The HTTP/3 unidirectional stream type SHALL be 0x54.  The body of the </ins> stream SHALL be the stream type, followed by the session ID, encoded as a variable-length integer, followed by the user-specified stream data (fig-unidi).

Discussion:
In order to save a round-trip on connection establishment, a client could optimistically open streams just after sending the CONNECT request, before it has received a reply from the server. As both unidirectional and bidirectional streams are identified by the session ID, the server will be able to associate these streams with the WebTransport session as soon as it has processed the CONNECT request. In case the server rejects the CONNECT request, the client should probably reset / cancel these streams. Note that this doesn't require any additional logic on the server side, as the server needs to be prepared to receive streams for sessions that it didn't establish anyway (a malicious client might open streams with arbitrary session IDs, and a server should better be prepared for that). Currently, the spec forbids opening unidirectional streams before the session is established: There's no such restriction for bidirectional stream.
I believe this is a left-over from the older text of the draft. We've agreed in that both types of streams should be sent immediately, and as far as I remember, that is what the Chrome implementation does.
That's great! I'll write up a PR. How does that work? I tried it out, but it seems like waits for the response to the CONNECT request. This is my JS code: Removing the also doesn't work, then I'm getting this error: Any hint would be highly appreciated.
Good question. I am not sure the current API state machine allows this; when I said "what the Chrome implementation does", I meant that it supports receiving streams before it considers them confirmed (for the client, it means that streams received before HTTP 200 for the CONNECT stream are buffered instead of dropped). We should probably figure out how to allow this on the client side, but that's a W3C issue.
From my reading of the W3C spec this is already allowed: URL So maybe this is just a bug in Chrome that it returns the ?
Sounds like we need an editorial PR to clarify that this is allowed
adds some text to clarify that opening streams as well as sending datagrams is permitted as soon as the CONNECT request has been sent out.
We need to pick one. The main two options are and . We've discussed this separately within W3C (see w3c/webtransport), and the conclusion there was that it would make more sense to just use URIs.

We should discuss this at the upcoming IETF meeting.
(No hats) I think using https would be the simplest option here, so I'd be inclined to go with that
Discussed at IETF 110. Consensus in the room was for using .
Consensus confirmed on the list, the scheme in the draft is already . Closing this.
(no hats)