Change:
This was a little woolly. Hopefully this is crisper. Basically, the application protocol is what asks for stream reset, either directly, or by sending STOP_SENDING. I added a recommendation for application protocols to define handling for prematurely cancelled streams. That is, I believe, just editorial, even though it uses 2119 language, because we already do that.
Section 11.2 of the transport draft reads: >RESETSTREAM MUST be instigated by the protocol using QUIC, either directly or through the receipt of a STOPSENDING frame from a peer. RESETSTREAM carries an application error code. Resetting a stream without knowledge of the application protocol could cause the protocol to enter an unrecoverable state. Application protocols might require certain streams to be reliably delivered in order to guarantee consistent state between endpoints. This would suggest that the transport implementation itself should not be deciding to send RESETSTREAMs on its own, rather it is a matter of the application protocol using QUIC. However, it is somewhat weaselly about STOPSENDING. My original interpretation of this text was that the implementation should expose the fact that a STOPSENDING has been received, but it is up to the application protocol to actually reset the stream. This interpretation is not consistent with section 3.5, Solicited State Transitions: I believe the only reasonable way to interpret this is that the transport itself should respond to the STOPSENDING by issuing a RESETSTREAM. Requiring that the QUIC implementation itself reset the stream seems to go against the philosophy that the application protocol should have complete control over resets. It's true that in the case of receiving a STOPSENDING, the protocol on the other side is asking for a RESETSTREAM, but the entity being solicited should be its peer protocol implementation, not the QUIC implementation. I believe we can fix this by altering the normative text requiring sending a RESETSTREAM, instead prescribing that an application protocol ought to handle STOPSENDING by eventually fulfilling the solicited reset.
I don't see any inconsistency here. This is the relevant text: This says that RESETSTREAM is only sent if the application protocol asks for it. That means either the local stack or the remote stack. As you say, the transport is required to send RESETSTREAM in response to STOP_SENDING. I can firm that up.
I am suggesting more than just a clarification change, actually. I'm disputing that it makes sense for the transport to be the one initiating the RESETSTREAM as opposed to the STOPSENDING merely being informative to the application protocol, i.e. it should be the application protocol's responsibility to respond to the STOPSENDING by resetting the stream. From an implementation standpoint, one would obviously want feedback on receiving a STOPSENDING frame. This makes it so the implementation has to make a choice when receiving the STOPSENDING. Is it supposed to reset the stream before or after delivering this information to the application protocol? This has consequences as resetting the stream before informing the application obviously effects the stream state. Is there any disadvantage to instead only requiring that the transport inform the application protocol of the receipt of the STOPSENDING, and then the application protocol is left to decide when to actually reset the relevant stream?
There are two concerns that come to mind. 1) The application can implement this incorrectly. 2) The application may be slow to process the STOP_SENDING, and in the meantime a lot of unnecessary data may be sent. Doing this at the transport layer allows immediate processing.
The application may also have delivered everything including FIN.
The application can also incorrectly implement having its stream reset without notification, as is currently allowed by the spec. The spec as written IMO encourages confusing semantics with respect to STOPSENDING, as it forces the transport to send the reset and leaves it up to the implementation to decide how and when it notifies the application. We don't need to be forceful in saying the application MUST handle it, i.e. we don't need to disallow transport implementations from responding to the STOPSENDING without application input. I am suggesting that we not require that the transport be the one to do it. I don't see an advantage to allowing the application to take control of sending the reset if it wants to. I don't see how this is a concern. For such cases either the application can still issue a reset for the stream, or the transport implementation can optionally take control of it and issue the reset itself.
It may not be in the application protocols best interest to have a forced reset in this case.

Discussion:
RESET_STREAM frame (frame-reset-stream) with an appropriate error code to terminate just the affected stream. <del> RESET_STREAM MUST be instigated by the protocol using QUIC, either directly or through the receipt of a STOP_SENDING frame from a peer. RESET_STREAM carries an application error code.  Resetting a stream without knowledge of the application protocol could cause the protocol to enter an unrecoverable state.  Application protocols might require certain streams to be reliably delivered in order to guarantee consistent state between endpoints. </del> <ins> RESET_STREAM MUST be instigated by the protocol using QUIC. RESET_STREAM carries an application error code.  Only the application protocol is able to cause a stream to be terminated.  A local instance of the application protocol uses a direct API call and a remote instance uses the STOP_SENDING frame, which triggers an automatic RESET_STREAM. Resetting a stream without knowledge of the application protocol could cause the protocol to enter an unrecoverable state. Application protocols might require certain streams to be reliably delivered in order to guarantee consistent state between endpoints. Application protocols SHOULD define rules for handling streams that are prematurely cancelled by either endpoint. </ins> 12.