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. Clearly, it could be done with an implementation-defined API, but it would be nice if the codes were in the same number space as the transport errors like "CONNECTION_REFUSED" or "PROTOCOL_VIOLATION". That number space is effectively unlimited. I suppose I could just squat on some values, but there is always the risk of colliding with some later definition. I understand that I could use the extension mechanism for the error code space, write a draft and somehow manage to get it approved by an expert, published as an RFC, and have the numbers registered by IANA. But that feels like a lot of work, so I was wondering whether we could just add three codes in section 22.4 of the transport draft. Any opinion in this group? -- Christian Huitema
