Change:
The strong requirements here were wrong. What is necessary from these sections is defining operations in QUIC that application protocols can depend on being present. Levying the requirement on implementations was incorrect. As some application protocols don't use certain QUIC features, it is not necessary to require implementations to support features if they are not general purpose. This rephrases these requirements without normative language, instead concentrating on what services the application protocol can depend on. This translates into requirements on implementations, but only via the application protocols they intend to support.
S 5.4 requires that the application be able to control resource allocation of various types, including flow control and the number of permitted streams of each type; This seems like a good idea, but it seems like one could have a reasonable QUIC stack that did not do this.
I would prefer to leave this. Noting that the level of control is not specified. This also suggests that the stack provide a keep-alive control, but there are likely cases (I'm thinking here of DNS over QUIC) where that is unlikely to be a useful feature. The goal is to list things that the specification believes a generic stack will provide. Maybe we could avoid the implication that such an implementation is incomplete by saying that specialized implementations might provide less than a complete API.
NAME willing to fight for this one?
After discussing with editors, we think that it would be better to remove the MUST in this section and say something like: "A general purpose QUIC implementation provides the following functions:" and add "A specialized implementation might provide a subset of these." The same applies to the stream operations.
I think that is a positive change. Borderline design issue by the sound of it. It would be good to see the PR once its available.

Discussion:
2.4. <del> There are certain operations that 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. </del> <ins> This document does not define an API for QUIC, but instead defines a set of functions on streams that application protocols can rely upon. An application protocol can assume that an implementation of QUIC provides an interface that includes the operations described in this section.  An implementation designed for use with a specific application protocol might provide only those operations that are used by that protocol. </ins> <del> On the sending part of a stream, application protocols need to be able to: </del> <ins> On the sending part of a stream, an application protocol can: </ins> write data, understanding when stream flow control credit (data- flow-control) has successfully been reserved to send the written

frame (frame-reset-stream) if the stream was not already in a terminal state. <del> On the receiving part of a stream, application protocols need to be able to: </del> <ins> On the receiving part of a stream, an application protocol can: </ins> read data; and abort reading of the stream and request closure, possibly resulting in a STOP_SENDING frame (frame-stop-sending). <del> 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. </del> <ins> An application protocol can also request 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.

5.3. <del> There are certain operations that 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. </del> <ins> This document does not define an API for QUIC, but instead defines a set of functions for QUIC connections that application protocols can rely upon.  An application protocol can assume that an implementation of QUIC provides an interface that includes the operations described in this section.  An implementation designed for use with a specific application protocol might provide only those operations that are used by that protocol. </ins> <del> When implementing the client role, applications need to be able to: </del> <ins> When implementing the client role, an application protocol can: </ins> open a connection, which begins the exchange described in handshake;

be informed when Early Data has been accepted or rejected by a server. <del> When implementing the server role, applications need to be able to: </del> <ins> When implementing the server role, an application protocol can: </ins> listen for incoming connections, which prepares for the exchange described in handshake;

from the client's resumption ticket and enable rejecting Early Data based on that information. <del> In either role, applications need to be able to: </del> <ins> In either role, an application protocol can: </ins> configure minimum values for the initial number of permitted streams of each type, as communicated in the transport parameters