[tor-commits] [torspec/master] Fix up a dangling sentence and a dangling idea

[nickm at torproject.org]

commit eda9c36984f2969c971746e482549da79d3e4da8
Author: Nick Mathewson <nickm at torproject.org>
Date:   Mon Mar 21 12:14:05 2011 -0400

    Fix up a dangling sentence and a dangling idea
---
 proposals/180-pluggable-transport.txt |   25 ++++++++++++++-----------
 1 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/proposals/180-pluggable-transport.txt b/proposals/180-pluggable-transport.txt
index 2df0ced..dc0564d 100644
--- a/proposals/180-pluggable-transport.txt
+++ b/proposals/180-pluggable-transport.txt
@@ -127,7 +127,7 @@ Design overview
   list it in your torrc.  The program tells Tor which transports it
   provides.  The Tor consensus should carry a new approved version number that
   is specific for pluggable transport; this will allow Tor to know when a
-  particular transport is known to be unsafe safe or non-functional.
+  particular transport is known to be unsafe, safe, or non-functional.
 
   Bridges (and maybe relays) report in their descriptors which transport
   protocols they support.  This information can be copied into bridge
@@ -260,7 +260,8 @@ Managed proxy interface
        will give a comma-separated list.  Clients MUST accept
        comma-separated lists containing any version that they
        recognize, and MUST work correctly even if some of the
-       versions they don't recognize are non-numeric.
+       versions they don't recognize are non-numeric.  Valid version
+       characters are non-space, non-comma printing ASCII characters.
 
       {Client only}
 
@@ -440,7 +441,9 @@ Bridge authority behavior
 
   We need to specify a way to test different transport methods that
   bridges claim to support.  We should test as many as possible.  We
-  should NOT require that we have a way to tra
+  should NOT require that we have a way to test every possible
+  transport method before we allow its use: the point of this design
+  is to remove bottlenecks in transport deployment.
 
 Bridgedb behavior:
 
@@ -451,15 +454,15 @@ Bridgedb behavior:
 
 Implementation plan
 
-  First, we should implement per-bridge socks settings (as
-  described above in "manually configuring a client proxy for a
-  bridge") and the extended-server-port mechanism.  This will let
-  bridges run transport proxies such that they can hand-generate
-  bridge lines to give to clients for testing.
+  First, we should implement per-bridge proxies via the "external
+  proxy" method described in "Specifications: Client behavior".  the
+  extended-server-port mechanism.  This will let bridges run
+  transport proxies such that they can give bridge lines to
+  give to clients for testing, so long as the user configures and
+  launches their proxies on their own.
 
-  Once that's done, we can improve usability a little bit by
-  implementing external proxies.  Once that's done, we can see if we
-  need any managed proxies, or if the whole idea there is silly.
+  Once that's done, we can see if we need any managed proxies, or if
+  the whole idea there is silly.
 
   If we do, the next most important part seems to be getting
   the client-side automatic part written.  And once that's done, we