[or-cvs] [tor/master 02/10] Change "server" to "relay", so as to match existing terminology

[arma at torproject.org]

Author: Steven Murdoch <Steven.Murdoch at cl.cam.ac.uk>
Date: Mon, 15 Mar 2010 00:14:41 +0000
Subject: Change "server" to "relay", so as to match existing terminology
Commit: b112ecbcd96064ed2c4b5104e80cca0235eff876

---
 .../ideas/xxx-automatic-node-promotion.txt         |   22 ++++++++++----------
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt b/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt
index 2af1df6..d96861d 100644
--- a/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt
+++ b/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt
@@ -9,7 +9,7 @@ Target:
 
    This proposal describes how Tor clients could determine when they
    have sufficient bandwidth capacity and are sufficiently reliable to
-   become either bridges are Tor servers. When they meet this
+   become either bridges or Tor relays. When they meet this
    criteria, they will automatically promote themselves, based on user
    preferences. The proposal also defines the new controller messages
    and options which will control this process.
@@ -21,7 +21,7 @@ Target:
    particularly the case for bridges, because these are gradually
    being blocked, and thus no longer of use to people within some
    countries. By automatically promoting Tor clients to bridges, and
-   perhaps also to full public servers, this proposal aims to solve
+   perhaps also to full public relays, this proposal aims to solve
    these problems.
  
    Only Tor clients which are sufficiently useful should be promoted,
@@ -43,7 +43,7 @@ Target:
    - auto (A): Currently a client, but will consider promotion
    - bridge (B): Currently a bridge, and will stay as such
    - auto-bridge (AB): Currently a bridge, but will consider promotion
-   - server (S): Currently a public server, and will stay as such
+   - relay (R): Currently a public relay, and will stay as such
 
    The state can be fully controlled from the configuration file or
    controller, but the normal state transitions are as follows:
@@ -54,16 +54,16 @@ Target:
    Auto -> auto-bridge: Tor has detected that it is sufficiently
     reliable to be a *bridge*
    Auto -> bridge: Tor has detected that it is sufficiently reliable
-    to be a *server*, but the user has chosen to remain a *bridge*
-   Auto -> server: Tor has detected that it is sufficiently reliable
-    to be *server*, and will skip being a *bridge*
-   Auto-bridge -> server: Tor has detected that it is sufficiently
-    reliable to be a *server*
+    to be a *relay*, but the user has chosen to remain a *bridge*
+   Auto -> relay: Tor has detected that it is sufficiently reliable
+    to be *relay*, and will skip being a *bridge*
+   Auto-bridge -> relay: Tor has detected that it is sufficiently
+    reliable to be a *relay*
 
    Note that this model does not support demotion. If this is
    desirable, there should be some memory as to whether the previous
-   state was server, bridge, or auto-bridge. Otherwise the user may be
-   prompted to become a server, although he has opted to only be a
+   state was relay, bridge, or auto-bridge. Otherwise the user may be
+   prompted to become a relay, although he has opted to only be a
    bridge.
 
 3.x User interaction policy
@@ -85,7 +85,7 @@ Target:
 
    Finally, Tor could by default not make any transition, and the user
    would need to opt in by stating the maximum level (bridge or
-   server) to which the node may automatically promote itself.
+   relay) to which the node may automatically promote itself.
 
 3.x New options
 
-- 
1.7.1