Re: [quicwg/base-drafts] Firm up language around stream termination (#2888)

[Ryan Hamilton <[e-mail]>]

RyanAtGoogle commented on this pull request.



> @@ -2601,12 +2601,17 @@ connection in a recoverable state, the endpoint can send a RESET_STREAM frame
 ({{frame-reset-stream}}) with an appropriate error code to terminate just the
 affected stream.
 
-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.
+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.

Hm. The second sentence suggests that the determination of the application error code in the RESET_STREAM is the responsibility of the application. Fair enough. But in this last sentence, it sounds like the RESET_STREAM is generated by the transport (or some such) in response to STOP_SENDING. Also fair enough. But how does the transport determine the application error code.

I think the behavior here is fine, but the text feels... wooly, as you said. I wonder if it might be easier to read if we treated the STOP_SENDING case as more of an exception, than trying to make it part of the general "only the app resets streams" behavior.  *shrug*

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2888#pullrequestreview-260105299