Apply "cell" and "message" consistently

Done by grepping for "cell" and making sure it was accurate in every
place where it occurs.  In tor-spec, I also searched for "message".

Part of #253.

1 files changed, 9 insertions, 9 deletions

diff --git a/spec/tor-spec/subprotocol-versioning.md b/spec/tor-spec/subprotocol-versioning.md
index b8ce11d..5f43c71 100644
--- a/spec/tor-spec/subprotocol-versioning.md
+++ b/spec/tor-spec/subprotocol-versioning.md
@@ -78,7 +78,7 @@ support "1-5". Eventually we will drop "1" and "2".
 
 ## "LinkAuth" {#link-auth}
 
-LinkAuth protocols correspond to varieties of Authenticate cells used for
+LinkAuth protocols correspond to varieties of AUTHENTICATE cells used for
 the v3+ link protocols.
 
 Current versions are:
@@ -94,7 +94,7 @@ Current versions are:
 ## "Relay"
 
 The "relay" protocols are those used to handle CREATE/CREATE2
-cells, and those that handle the various RELAY cell types received
+cells, and those that handle the various relay messages received
 after a CREATE/CREATE2 cell.  (Except, relay cells used to manage
 introduction and rendezvous points are managed with the "HSIntro"
 and "HSRend" protocols respectively.)
@@ -111,9 +111,9 @@ Current versions are as follows.
 
    Relay=2 has limited IPv6 support:
 
-    * Clients might not include IPv6 ORPorts in EXTEND2 cells.
+    * Clients might not include IPv6 ORPorts in EXTEND2 messages.
     * Relays (and bridges) might not initiate IPv6 connections in
-      response to EXTEND2 cells containing IPv6 ORPorts, even if they
+      response to EXTEND2 messages containing IPv6 ORPorts, even if they
       are configured with an IPv6 ORPort.
 
    However, relays support accepting inbound connections to their IPv6
@@ -121,7 +121,7 @@ Current versions are as follows.
    connections to other relays.
 
  * "3" -- relays support extending over IPv6 connections in response to an
-   EXTEND2 cell containing an IPv6 ORPort.
+   EXTEND2 message containing an IPv6 ORPort.
 
    Bridges might not extend over IPv6, because they try to imitate
    client behaviour.
@@ -129,14 +129,14 @@ Current versions are as follows.
    A successful IPv6 extend requires:
      * Relay subprotocol version 3 (or later) on the extending relay,
      * an IPv6 ORPort on the extending relay,
-     * an IPv6 ORPort for the accepting relay in the EXTEND2 cell, and
+     * an IPv6 ORPort for the accepting relay in the EXTEND2 message, and
      * an IPv6 ORPort on the accepting relay.
    (Because different tor instances can have different views of the
    network, these checks should be done when the path is selected.
    Extending relays should only check local IPv6 information, before
    attempting the extend.)
 
-   When relays receive an EXTEND2 cell containing both an IPv4 and an
+   When relays receive an EXTEND2 message containing both an IPv4 and an
    IPv6 ORPort, and there is no existing authenticated connection with
    the target relay, the extending relay may choose between IPv4 and
    IPv6 at random. The extending relay might not try the other address,
@@ -177,7 +177,7 @@ The "HSIntro" protocol handles introduction points.
  * "4" -- support ed25519 authentication keys which is defined by the HS v3
    protocol as part of [proposal 224] in Tor 0.3.0.4-alpha.
 
- * "5" -- support ESTABLISH_INTRO cell DoS parameters extension for onion
+ * "5" -- support ESTABLISH_INTRO message DoS parameters extension for onion
    service version 3 only in Tor 0.4.2.1-alpha.
 
 <a id="tor-spec.txt-9.5"></a>
@@ -188,7 +188,7 @@ The "HSRend" protocol handles rendezvous points.
 
  * "1" -- supports all features in Tor 0.0.6.
 
- * "2" -- supports RENDEZVOUS2 cells of arbitrary length as long as they
+ * "2" -- supports RENDEZVOUS2 messages of arbitrary length as long as they
    have 20 bytes of cookie in Tor 0.2.9.1-alpha.
 
 <a id="tor-spec.txt-9.6"></a>