Re: Split error codes in two

[Martin Thomson <[e-mail]>]

On Tue, Sep 5, 2017 at 6:03 AM, Christian Huitema <[e-mail]> wrote:
> 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...

MAX_STREAM_DATA definitely has to be visible to the transport.  But
having STOP_SENDING visible is actually more of a hazard than a help.
If the transport cancels a stream, then it might destroy application
state.

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

No, it's not a priority, but it was easy to do.  And I can't see any
way that 4 billion helps us.

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

We've a fair bit of experience with that.  Provided that we don't put
an insane policy on the registry, new values are easy to acquire.  I
prefer the "provisional registration" approach, but we also have the
policy TLS uses, and there is the option of a free-for-all chunk.
None of that requires 4 billion codes.