Change:
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> <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

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.