Re: [quicwg/base-drafts] Remap STOPPING to something other than zero (#1804)

[Nick Banks <[e-mail]>]

> I oppose to using 0xffxx, because the range is define as for private use in the transport error codes

Where is that indiciated. Is that HQ specific? Here is the blurb from the transport spec about application error codes:

```
   There is no restriction on the use of the 16-bit error code space for
   application protocols.  However, QUIC reserves the error code with a
   value of 0 to mean STOPPING.  The application error code of STOPPING
   (0) is used by the transport to cancel a stream in response to
   receipt of a STOP_SENDING frame.
```
In generally, I feel that taking one single value from an otherwise completely free number space for just one particular scenario feels bad to me. There are plenty of other ways to achieve the same thing as STOPPING.

- You could have a different frame type (STOP_COMPLETE).
- You could just accept any RST_STREAM in response to a STOP_SENDING as confirmation.
- You could have a special bit/flag in the RST_STREAM to indicate there is no application error code.

IMO, reserving one value is the worst way to achieve this. Someone will always not be happy whatever value we chose, and the application layer will not understand why it can't use one value. How do you enforce that at an API layer? Wait until they happen to try to send that (in some particular, edge case scenario?) and then error out? What is the chance they don't see that until they deploy?

-- 
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/1804#issuecomment-424799049