Draft: draft-ietf-quic-transport

Commentary: This cribs Lucas ' proposed tweak and makes a few other tiny adjustments . 
 The transport currently says It feels more correct to say I 'll prepare a PR if my understanding and suggestion is correct . 
 It 's a subtle point , but it seems OK . I do find the use of a possessive in that phrasing abhorrent though . 
 I made a stupid typo , whoops . Open to alternative phrasing . " Pulling the rug " comes to mind ... 
 You 're changing the meaning here , and I think the existing phrasing is correct . If you do n't understand the application protocol , you do n't know which streams are safe to reset and which will be connection - fatal . Telling the application protocol that you reset the stream does n't make it any less fatal if you reset the wrong stream . 
 So looking at the paragraph in entirety I agree with : 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 . Is the intention to describe why " RESETSTREAM MUST be instigated by the protocol " ? The words following the normative text are a bit wooly / weasely . I think this paragraph slightly falls victim to the problem that you raised on but from the other side of the coin . Nowhere else do we use the phrase " protocol using QUIC " - it sounds a bit bcp56(bis ) . 
 Yes -- QUIC does n't unilaterally reset streams , because it does n't have the context to do so safely . The application layer on one of the peers has to do that , even if it does so via a STOP_SENDING transmitted by QUIC . 
 Small commentslgtm
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
Resetting a stream without the involvement of the application
protocol could cause the application protocol to enter an
unrecoverable state.  RESET_STREAM MUST only be instigated by the
application protocol that uses QUIC.
Paragraph (version B):
RESET_STREAM carries an application error code, for which the
semantics are defined by the application protocol.  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.
Paragraph (version B):
Application protocols SHOULD define rules for handling streams that
are prematurely cancelled by either endpoint.