Subject: [quicwg/base-drafts] Resetting stream without knowledge (#2850)

From: Lucas Pardue <[email-masked]>
Date: Wed, 26 Jun 2019 07:24:19 -0700

The transport currently says 
> Resetting a stream without knowledge of the application protocol could cause the protocol to enter an unrecoverable state.

It feels more correct to say 

> Resetting a stream without the application protocols knowledge could cause the it to enter an unrecoverable state.

I'll prepare a PR if my understanding and suggestion is correct.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Jun 2019 08:00:34 -0700

It's a subtle point, but it seems OK.  I do find the use of a possessive in that phrasing abhorrent though.

-- 
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/2850#issuecomment-505914379

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 26 Jun 2019 08:03:12 -0700

I made a stupid typo, whoops. Open to alternative phrasing. "Pulling the rug" comes to mind...

-- 
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/2850#issuecomment-505915442

---

From: Mike Bishop <[email-masked]>
Date: Wed, 26 Jun 2019 09:36:00 -0700

You're changing the meaning here, and I think the existing phrasing is correct.

If you don't understand the application protocol, you don't know which streams are safe to reset and which will be connection-fatal.  Telling the application protocol that you reset the stream doesn't make it any less fatal if you reset the wrong 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/2850#issuecomment-505951840

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 26 Jun 2019 09:52:17 -0700

So looking at the paragraph in entirety I agree with @MikeBishop :

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

Is the intention to describe why " RESET_STREAM 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 https://github.com/quicwg/base-drafts/issues/2805 but from the other side of the coin. Nowhere else do we use the phrase "protocol using QUIC" - it sounds a bit bcp56(bis).

-- 
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/2850#issuecomment-505957711

---

From: Mike Bishop <[email-masked]>
Date: Wed, 26 Jun 2019 09:57:05 -0700

Yes -- QUIC doesn't unilaterally reset streams, because it doesn'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.

-- 
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/2850#issuecomment-505959394