[tor-dev] Towards a new version of the PT spec...

[Yawning Angel]

So, we currently have a Pluggable Transport (PT) spec, and it kind-of
sort-of works (The documentation is a mess that I'm working on
cleaning up, but it's an orthogonal issue for how well it works).

There are a number of problems with the current PT spec that require
breaking backward compatibility to fix, so eventually I would like to
do so.

I'm soliciting input on what people would also like to see in a
(currently hypothetical) PT spec 2.0 beyond what I already have in mind:

 MUST haves:
  * Support dual stack Bridges correctly (Multiple server endpoints per
    transport)
  * Increase the argument space beyond 510 bytes (Prop. #227).
  * Mandatory ExtORPort support (currently optional, but metrics are
    good).
  * Centralized logging by the calling process (Probably via stderr).
  * AF_UNIX support where sensible for better sandboxing.

 MIGHT haves:
  * Rename the env vars to not start with "TOR_PT".  Some people claim
    that this is a good idea (I think it is stupid and cosmetic).
  * Ability to force at least clients to stop network activity without
    tearing the PT down.
  * Deprecate SOCKS4a, and make SOCKS5 mandatory for clients.

 UNLIKELY:
  * Specify an interface for where fork()/exec() isn't possible (iOS).
    I don't think this is makes sense because it is probably too
    platform/caller specific.
  * Allow operating both as a client and a server simultaneously.  I
    don't see a problem with running 2 copies of something for this
    use case.

I probably missed some things.  If people have strong opinions about
this, do reply, otherwise I *will* design something that I like, which
will not include what other people want.

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150907/f50dea5c/attachment-0001.sig>