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

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.