Subject: Re: [quicwg/base-drafts] Minor inconsistency of error when MAX_STREAMS exceeds 2^60 (#3781)

From: ianswett <[email-masked]>
Date: Mon, 13 Jul 2020 15:58:51 -0700

@marten-seemann suggested that it should only be a FRAME_ENCODING_ERROR, as it's invalid to send a MAX_STREAMS larger than 2^60 under any circumstance, regardless of connection state, and I agree that's the clearest application of our principles.

-- 
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/3781#issuecomment-657847310

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 13 Jul 2020 16:29:01 -0700

I agree that requiring the use of FRAME_ENOCDING_ERROR is fine.

Even though we occasionally allow an endpoint to use multiple error codes when there is more than one way of checking the status (i.e. FLOW_CONTROL_ERROR vs. FRAME_ENCODING_ERROR for STREAM frames), the check required in this particular case is purely unrelated to the connection state. Hence my +1.

-- 
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/3781#issuecomment-657874412

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 14 Jul 2020 15:33:58 -0700

I would be happy with a single error too. I'm not fussy about the actual code used as long as the spec is clear and consistent. That means that we'd need to reduce STREAMS_BLOCKED to one error code too, and potentially any other situation that allows either.

-- 
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/3781#issuecomment-658446153