Change:
As per URL HTTP MUST allow enough uni streams credits for mandatory streams (control, QPACK encoder/decoder, other mandatory extensions) but is not required to grant additional credits if the peer wastes them. This is the companion PR to updating the requirements in the HTTP draft, and together they I created a separate PR since it touches -http instead of -qpack, so it doesn't get blocked by the QPACK refactoring.
It's acceptable but not ideal. Didnt we just remove a mandatory TP in some unrelated change?
Also rebased to fix conflict.
That is an exceptionally long sentence. But I think the text is correct.
Now that is being merged, we have the possibility to avoid creating unnecessary encoder / decoder streams. Avoiding creation is beneficial for memory-constrained devices, because they can configure the QUIC transport stack to handle at most one unidirectional stream (in each direction) to support HTTP/3 if the QPACK state forbids 1) peer's creation of the encoder stream when endpoint's is zero, and 2) peer's creation of decoder stream is delayed until the endpoint's creation of the encoder stream. With the proposed changes, a memory constrained HTTP/3 stack that sends of zero and never opens an encoder stream can be certain that the peer never opens an encoder stream or a decoder stream. Note that it has minimal impact to existing implementations; regarding creation of the encoder stream, states that the stream cannot be used until SETTINGS is being received. It is a clarification (or a requirement) that "use" includes the creation of the stream. The situation is the same for the decoder stream. Pull request filed as .
Discussed in Tokyo; do not require creating the streams, but creating them is not forbidden even if the setting prevents their use.
And make sure that constrained devices can trivially detect and reset non-forbidden forbidden streams instead of assigning state.
I made to try and put into writing what was discussed in Tokyo since there hasn't been any actiity in a while. Incidentally we run into the problem of allowing endpoints to create all QPACK control streams while interop'ing between quant and quiche HTTP/3.
Discussed and clarified in London. HTTP MUST set initialmaxuni_streams to at least 3 HTTP does not have to keep granting more credit if the peer burns the stream credits on grease/push/extensions. Peers SHOULD create control, qpack encoder and decoder as their first 3 streams if they plan to use them, since there's no guarantee of ever getting more credit.
Created in addition to the existing PR to also update the -http requirements as per the discussion in London.
There's one nit which implies a design question; once that's settled one way or another, I'm happy with this.

Discussion:
remote peer reaches the limit early and becomes blocked.  In particular, the value chosen for "initial_max_uni_streams" should consider that remote peers may wish to exercise reserved stream <del> behavior (stream-grease).  To reduce the likelihood of blocking, both clients and servers SHOULD send a value of three or greater for the QUIC transport parameter "initial_max_uni_streams", and a value of 1,024 or greater for the QUIC transport parameter </del> <ins> behavior (stream-grease).  To avoid blocking, both clients and servers MUST allow the peer to create at least one unidirectional stream for the HTTP control stream plus the number of unidirectional streams required by mandatory extensions (such as QPACK) by setting an appropriate value for the QUIC transport parameter "initial_max_uni_streams" (three being the minimum value required for the base HTTP/3 protocol and QPACK), and SHOULD use a value of 1,024 or greater for the QUIC transport parameter </ins> "initial_max_stream_data_uni". <ins> Note that an endpoint is not required to grant additional credits to create more unidirectional streams if its peer consumes all the initial credits before creating the critical unidirectional streams. Endpoints SHOULD create the HTTP control stream as well as the unidirectional streams required by mandatory extensions (such as the QPACK encoder and decoder streams) first, and then create additional streams as allowed by their peer. </ins> If the stream header indicates a stream type which is not supported by the recipient, the remainder of the stream cannot be consumed as the semantics are unknown.  Recipients of unknown stream types MAY