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

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Jul 2019 00:14:58 -0700

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.

Closes #2884.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2888

-- Commit Summary --

  * Firm up language around stream termination

-- File Changes --

    M draft-ietf-quic-transport.md (19)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2888.patch
https://github.com/quicwg/base-drafts/pull/2888.diff

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

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 10 Jul 2019 06:49:39 -0700

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