Re: Split error codes in two

[Christian Huitema <[e-mail]>]

On 9/3/2017 9:55 PM, Martin Thomson wrote:
> In doing this, I realized two further things:
>
> 1. STOP_SENDING is a purely application-layer construct, but it's a
> transport-layer frame.  That makes it much harder to manage with this
> change.  Moving it to HTTP makes a lot of sense (to me).
>
>    https://github.com/quicwg/base-drafts/pull/759

Arguably, MAX STREAM DATA is also an application-layer construct. If an
application does not want to receive more bytes on a stream, it could
stop increasing that counter. That would have more or less the same
effect as STOP SENDING, in a passive aggressive way...

>
> 2. We are now nudging 20 error codes (plus the per-frame-type ones).
> 4 billion might be a little more space than we need, so halving the
> number of bits with give error cords seems reasonable:
>
>    https://github.com/quicwg/base-drafts/pull/723
Is that really a priority? I mean, we probably do not really need to
save 2 bytes in error messages.

And then, how do we deal with extensions? Suppose that I define an
experimental version of the protocol that brings both new functionality
and new error codes. What number range shall I use for these extended
error codes?

-- 
Christian Huitema