Revise our pluggable transport specification
As part of our work for Sponsor 28, we will revise our PT specification. This will happen in two steps. First, we need to reach out to implementors and ask them about their experience, feedback, and suggestions. We also need to review the independently-developed PT v2.1 specification. Once we have a comprehensive understanding of the spec's shortcomings (both ours and PT v2.1's), we need to update our spec and implementations (e.g., goptlib). Ideally, we should try to merge our efforts with PT v2.1, so the community has a single specification that we all agree on.
Here's a preliminary list of issues with our current spec:
- The PT should be able to communicate its bootstrap status to the invoking process.
- The spec should incorporate the proposed dormant mode (see #28849 (moved)).
- Some PTs such as meek and snowflake don't rely on an IP address. The current workaround is to use awkward pseudo IP addresses.
- Other transports may want to rely on multiple IP address. We need to reconsider the outdated notion of a bridge line.