Subject: [quicwg/base-drafts] Define and reserve "NOERROR" application error code in transport (#862)

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Thu, 12 Oct 2017 15:36:33 +0000 (UTC)

At the moment, application error code STOPPING(0) is defined, and reserved in transport.
I think that defining and reserving "NOERROR" application code in transport is nice because an implementation can initialize error code variables with it.  STOPPING does not sound like "NOERROR" for me.  Perhaps, use 0 for NOERROR, and 1 for STOPPING.

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

---

From: janaiyengar <[email-masked]>
Date: Thu, 12 Oct 2017 18:33:52 +0000 (UTC)

The application is expected to send RST_STREAM with an application error code, except for the one case when the transport sends it in response to a STOP_SENDING. STOPPING is reserved in the application error code space for the transport to use for this one case. It's not really NOERROR.

I understand the initialization problem (which is why 0 tends to be special), but when sending a RST_STREAM from the application, 0 (STOPPING) should not be used. It's only to be used by the transport. The application can initialize to 0 and should not call RST_STREAM with 0. (See the http draft, STOPPING is purely reserved but the semantics are not defined there.)

I see that there's a sentence that needs fixing "A STOP_SENDING frame requests that the receiving application send a RST_STREAM frame." This should have "endpoint" or "transport" instead of "application". That may have caused some confusion -- I'll fix this.

-- 
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/862#issuecomment-336226805

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Oct 2017 22:37:17 +0000 (UTC)

Closed #862 via #863.

-- 
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/862#event-1291277723