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 <[email protected]> On Behalf Of Martin Thomson Sent: Monday, November 9, 2020 3:30 AM To: [email protected] 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.
smime.p7s
Description: S/MIME cryptographic signature
