We discussed this way back, I think in Paris. We decided then, IIRC, to leave local error codes out of the document, and only include the ones that are communicated over the wire.
There will be many more local error codes; are these three any more special than, say "Received a Stateless Reset"? I agree with Martin on implementation, You can simply number internal error codes starting from 0xff00, for instance, if you want an easy way to demarcate, and to not worry about collision in the future (this is what our implementation does). On Mon, Nov 9, 2020 at 11:36 AM Mike Bishop <mbis...@evequefou.be> wrote: > We at once point had an error code region defined for local use, IIRC. We > removed them. I think Martin's suggestion provides a good workaround for > anyone who wants to combine implementation and protocol error codes. > > -----Original Message----- > From: QUIC <quic-boun...@ietf.org> On Behalf Of Martin Thomson > Sent: Monday, November 9, 2020 3:30 AM > To: quic@ietf.org > Subject: Re: Reserving error codes for "local" errors > > On Sat, Nov 7, 2020, at 17:19, Christian Huitema wrote: > > I wonder whether we could reserve three error codes to signal > > "immediate" termination conditions of a connection: > > > > * termination by idle timeout, > > > > * termination after losing network connectivity, > > > > * termination after multiple PTO expired. > > > > These are errors that need to be signaled by transport to application. > > Our implementation has no need for this capability[1], and as the codes > don't traverse the network, it's not clear that any protocol needs these > either. As these are probably stored in 64-bit values, from which we have > only taken a quarter of the possible values, why not use the other > 13835058055282164000 values available that you can be assured QUIC will > never take? > > [1] Rust enums are weird from the perspective of a C programmer. > >
