Subject: [quicwg/base-drafts] Transport API: Reset after FIN? (#3163)

From: Mike Bishop <[email-masked]>
Date: Mon, 28 Oct 2019 13:24:44 -0700

In discussion on #2857, @mikkelfj points out that it requires transport stacks to support abrupt closure of a stream even after the stream has been cleanly closed.

This reflects the possibility to transition from "Data Sent" (stream has ended) to "Reset Sent" by sending a RESET_STREAM.  Based on the state diagram in the transport doc, if an implementation was already in the "Data Recvd" state, they wouldn't actually send a RESET_STREAM, as they're already in a terminal state; a reset call would be a no-op or an error of some kind.

However, @mikkelfj points out that in a handle-based API, this essentially means that handles for closed streams have to be recognizable as such for the lifetime of the connection.  This might be burdensome for some implementations.

Should we reword the requirement here to say that it's permitted if the stream hasn't yet reached the "Data Recvd" 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/3163

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Oct 2019 21:06:24 -0700

This was clearly just a miss on the wording.  I don't think that the intent was ever to require that streams be kept around indefinitely.  Sure, some stacks might be able to send RESET_STREAM at a whim, but it's not necessary

-- 
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/3163#issuecomment-547247159

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Oct 2019 16:25:28 -0700

Closed #3163 via #3165.

-- 
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/3163#event-2754142687