Subject: [quicwg/base-drafts] STOP_SENDING is not depicted in the send FSM (#2283)

From: Rui Paulo <[email-masked]>
Date: Wed, 02 Jan 2019 14:01:51 -0800

The text says:

>From any of the “Ready”, “Send”, or “Data Sent” states, an application can signal that it wishes to abandon transmission of stream data. Alternatively, an endpoint might receive a STOP_SENDING frame from its peer. In either case, the endpoint sends a RESET_STREAM frame, which causes the stream to enter the “Reset Sent” state.

But STOP_SENDING is not depicted in the send state diagram.  Shouldn't we add this to the diagram under "Send RESET_STREAM" ?

-- 
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/issues/2283

---

From: Martin Thomson <[email-masked]>
Date: Wed, 02 Jan 2019 15:43:44 -0800

STOP_SENDING has no direct effect on the stream states.  Its omission was intentional.  That it triggers a the sending of RESET_STREAM is an indirect effect.  It's the RESET_STREAM that acts on the state.

-- 
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/issues/2283#issuecomment-451019848

---

From: Rui Paulo <[email-masked]>
Date: Wed, 02 Jan 2019 22:32:19 -0800

To me, the sending of the RESET_STREAM is a *direct* effect of receiving the STOP_SENDING.  We put STOP_SENDING in the receiving stream states, so it's omission from the sending stream states was odd to me.

-- 
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/issues/2283#issuecomment-451064787

---

From: janaiyengar <[email-masked]>
Date: Thu, 03 Jan 2019 17:26:34 -0800

What @martinthomson said. Receiving a STOP_SENDING indicates that a stream was created which is why it's there in the Receiving Stream States.  It's to handle the case where a reordered STOP_SENDING is received. 

-- 
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/issues/2283#issuecomment-451330662

---

From: Mike Bishop <[email-masked]>
Date: Tue, 08 Jan 2019 11:13:44 -0800

@rpaulo, you're exactly correct, but making the wrong inference from it.  The direct effect of the STOP_SENDING is the generation of a RESET_STREAM.  That itself isn't a stream state transition -- it's the sending of RESET_STREAM that has an effect on the state machine, regardless of why it's sent.  Including it in the diagram risks implying that a state change takes place regardless of whether the RESET_STREAM gets sent, and it doesn't.

Otherwise stated, only the originator of a stream part can reset it.  STOP_SENDING is a request to do so, but doesn't perform the action itself.

-- 
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/issues/2283#issuecomment-452417455