Change:
streams to dedicate resources to, the implementation SHOULD use the information provided by the application. <ins> 2.4. There are certain operations which an application MUST be able to perform when interacting with QUIC streams.  This document does not specify an API, but any implementation of this version of QUIC MUST expose the ability to perform the operations described in this section on a QUIC stream. On the sending part of a stream, application protocols need to be able to: write data, understanding when stream flow control credit (data- flow-control) has successfully been reserved to send the written data end the stream (clean termination), resulting in a STREAM frame (frame-stream) with the FIN bit set; and reset the stream (abrupt termination), resulting in a RESET_STREAM frame (frame-reset-stream), even if the stream was already ended. On the receiving part of a stream, application protocols need to be able to: read data abort reading of the stream and request closure, possibly resulting in a STOP_SENDING frame (frame-stop-sending) Applications also need to be informed of state changes on streams, including when the peer has opened or reset a stream, when a peer aborts reading on a stream, when new data is available, and when data can or cannot be written to the stream due to flow control. </ins> 3. This section describes streams in terms of their send or receive

Discussion:
This consists of two related commits: Defines the minimal set of operations which a QUIC implementation MUST expose to the application, introducing terms for them which don't rely on the specific wire formatting Changes HTTP/3 to use these terms instead of referring to specific QUIC frames Note that this doesn't remove all references to QUIC frames, but the remaining references are explanatory -- they describe what will happen at the transport layer after taking a particular action, rather than being part of the normative text. (But if you find one of these you think needs to go, please include that in this review.) This is a design, because exposing this functionality is mandatory. I'm not sure how you would previously have created a usable QUIC implementation without these operations, but you weren't previously required to have them all.
NAME and NAME I think this is mergeable from an HTTP standpoint. Since it's technically a requirements change (requiring that functionality be exposed), it probably needs to be marked for a consensus call when you think it's ready.
Define terms for the operations which an application can cause a transport to take, and for the events of which the application can be notified by the transport. This should in the process. This issue should: Eliminate the term "trigger" when talking about QUIC frames Try not to mention specific QUIC frames at all Remove "send a QUIC RESETSTREAM" from 7.2.4 Remove "sends a STOPSENDING with HTTPREQUESTCANCELLED, a server MAY send the error code HTTPREQUESTREJECTED in the corresponding RESET_STREAM" from 4.1.2 Reword references to sending values in particular transport parameters I believe those essential functions are: On the connection: Open a connection, specifying certain properties that translate to transport parameters Receive incoming connections, which will possess certain properties based on the peer's transport parameters Participate in deciding whether to accept 0-RTT based on embedded data Provide data to be embedded in resumption tokens Cooperate to control keep-alive, either by sending PINGs directly or by telling the transport that the connection can't be allowed to time out Immediate close On the stream: Read data Write data, understanding at what point flow control credit has been committed Close the sending part Request closure of the receiving part The events we depend on are connection closure and stream closure.

This is largely editorial, since it's mostly defining terminology, but we'll also likely be mandating that QUIC stacks expose these features, so that's normative/design. (Obviously the 0-RTT ones will be "if implemented" requirements.)
Some small suggestions, but looks good overall.