Original text:
streams to dedicate resources to, the implementation SHOULD use the information provided by the application.  3. This section describes streams in terms of their send or receive 3.5. <del> If an endpoint is no longer interested in the data it is receiving on a stream, it MAY send a STOP_SENDING frame identifying that stream to prompt closure of the stream in the opposite direction.  This typically indicates that the receiving application is no longer reading data it receives from the stream, but it is not a guarantee that incoming data will be ignored. </del>  STREAM frames received after sending STOP_SENDING are still counted toward connection and stream flow control, even though these frames TBD.  6. Version negotiation ensures that client and server agree to a QUIC

Reviewer comments:
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.

Revised text:
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 3.5.  <ins> If an application is no longer interested in the data it is receiving on a stream, it can abort reading the stream and specify an application error code. If the stream is in the "Recv or "Size Known" states, the transport SHOULD signal this by sending a STOP_SENDING frame to prompt closure of the stream in the opposite direction.  This typically indicates that the receiving application is no longer reading data it receives from the stream, but it is not a guarantee that incoming data will be ignored. </ins> STREAM frames received after sending STOP_SENDING are still counted toward connection and stream flow control, even though these frames TBD. <ins> 5.4. There are certain operations which an application MUST be able to perform when interacting with the QUIC transport.  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 connection. When implementing the client role, applications need to be able to: open a connection, which begins the exchange described in handshake; enable 0-RTT; and be informed when 0-RTT has been accepted or rejected by a server. When implementing the server role, applications need to be able to: listen for incoming connections, which prepares for the exchange described in handshake; if Early Data is supported, embed application-controlled data in the TLS resumption ticket sent to the client; and if Early Data is supported, retrieve application-controlled data from the client's resumption ticket and enable rejecting Early Data based on that information. In either role, applications need to be able to: configure minimum values for the initial number of permitted streams of each type, as communicated in the transport parameters (transport-parameters); control resource allocation of various types, including flow control and the number of permitted streams of each type; identify whether the handshake has completed successfully or is still ongoing keep a connection from silently closing, either by generating PING frames (frame-ping) or by requesting that the transport send additional frames before the idle timeout expires (idle-timeout); and immediately close (immediate-close) the connection. </ins> 6. Version negotiation ensures that client and server agree to a QUIC