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.

3 files changed, 28 insertions, 27 deletions

diff --git a/spec/padding-spec/circuit-level-padding.md b/spec/padding-spec/circuit-level-padding.md
index 086d0f8..85f9137 100644
--- a/spec/padding-spec/circuit-level-padding.md
+++ b/spec/padding-spec/circuit-level-padding.md
@@ -14,7 +14,7 @@ rate limiting, and circuit application conditions have been added.
 
 At present, Tor uses this system to deploy two pairs of circuit padding
 machines, to obscure differences between the setup phase of client-side
-onion service circuits, up to the first 10 cells.
+onion service circuits, up to the first 10 relay cells.
 
 This specification covers only the resulting behavior of these padding
 machines, and thus does not cover the state machine implementation details or
@@ -31,11 +31,11 @@ advertised as "Padding=2".
 
 Because circuit padding machines only become active at certain points in
 circuit lifetime, and because more than one padding machine may be active at
-any given point in circuit lifetime, there is also a padding negotiation
-cell and a negotiated response. These are relay commands 41 and 42, with
-relay headers as per section 6.1 of tor-spec.txt.
+any given point in circuit lifetime, there is also a PADDING_NEGOTIATE
+message and a PADDING_NEGOTIATED message. These are relay commands 41 and 42 respectively,
+with relay headers as per section 6.1 of tor-spec.txt.
 
-The fields of the relay cell Data payload of a negotiate request are
+The fields in the body of a PADDING_NEGOTIATE message are
 as follows:
 
 ```text
@@ -61,14 +61,14 @@ as follows:
 
 When a client wants to start a circuit padding machine, it first checks that
 the desired destination hop advertises the appropriate subprotocol version for
-that machine. It then sends a circpad_negotiate cell to that hop with
+that machine. It then sends a PADDING_NEGOTIATE message to that hop with
 command=CIRCPAD_COMMAND_START, and machine_type=CIRCPAD_MACHINE_CIRC_SETUP (for
 the circ setup machine, the destination hop is the second hop in the
 circuit). The machine_ctr is the count of which machine instance this is on
 the circuit. It is used to disambiguate shutdown requests.
 
-When a relay receives a circpad_negotiate cell, it checks that it supports
-the requested machine, and sends a circpad_negotiated cell, which is formatted
+When a relay receives a PADDING_NEGOTIATE message, it checks that it supports
+the requested machine, and sends a PADDING_NEGOTIATED message, which is formatted
 in the data payload of a relay cell with command number 42 (see tor-spec.txt
 section 6.1), as follows:
 
@@ -102,11 +102,12 @@ Clients MAY send padding cells towards the relay before receiving the
 circpad_negotiated response, to allow for outbound cover traffic before
 negotiation completes.
 
-Clients MAY send another circpad_negotiate cell before receiving the
+Clients MAY send another PADDING_NEGOTIATE message before receiving the
 circpad_negotiated response, to allow for rapid machine changes.
 
-Relays MUST NOT send padding cells or circpad_negotiated cells, unless a
-padding machine is active. Any padding-related cells that arrive at the client
+Relays MUST NOT send padding cells or PADDING_NEGOTIATE messages unless a
+padding machine is active. Any padding cells or padding-related messages
+that arrive at the client
 from unexpected relay sources are protocol violations, and clients MAY
 immediately tear down such circuits to avoid side channel risk.
 
@@ -138,7 +139,7 @@ surrounded in \[brackets\] are outgoing, the others are incoming):
 \[EXTEND2\] -> EXTENDED2 -> \[EXTEND2\] -> EXTENDED2 -> \[BEGIN\] -> CONNECTED
 
 When this is done, the client has established a 3-hop circuit and also opened
-a stream to the other end. Usually after this comes a series of DATA cell that
+a stream to the other end. Usually after this comes a series of DATA message that
 either fetches pages, establishes an SSL connection or fetches directory
 information:
 
@@ -227,7 +228,7 @@ becomes:
   [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [EST_REND] -> REND_EST
      -> [PADDING_NEGOTIATE] -> [DROP] -> PADDING_NEGOTIATED -> DROP...
 
-  After which normal application DATA cells continue on the circuit.
+  After which normal application DATA-bearing cells continue on the circuit.
 ```
 
 Hence this way we make rendezvous circuits look like general circuits up
@@ -243,8 +244,8 @@ will look alike.
 ### Circuit setup machine overhead { #setup-overhead }
 
 For the intro circuit case, we see that the origin-side machine just sends a
-single \[PADDING_NEGOTIATE\] cell, whereas the origin-side machine sends a
-PADDING_NEGOTIATED cell and between 7 to 10 DROP cells. This means that the
+single PADDING_NEGOTIATE message, whereas the origin-side machine sends a
+PADDING_NEGOTIATED message and between 7 to 10 DROP cells. This means that the
 average overhead of this machine is 11 padding cells per introduction circuit.
 
 For the rend circuit case, this machine is quite light. Both sides send 2
diff --git a/spec/padding-spec/connection-level-padding.md b/spec/padding-spec/connection-level-padding.md
index c2890d8..f3c0fb7 100644
--- a/spec/padding-spec/connection-level-padding.md
+++ b/spec/padding-spec/connection-level-padding.md
@@ -6,7 +6,7 @@
 
 ## Background
 
-Tor clients and relays make use of CELL_PADDING to reduce the resolution of
+Tor clients and relays make use of PADDING to reduce the resolution of
 connection-level metadata retention by ISPs and surveillance infrastructure.
 
 Such metadata retention is implemented by Internet routers in the form of
@@ -114,7 +114,7 @@ If another cell is sent for any reason before this timer expires, the timer
 is reset to a new random value.
 
 If the connection remains inactive until the timer expires, a
-single CELL_PADDING cell will be sent on that connection (which will
+single PADDING cell will be sent on that connection (which will
 also start a new timer).
 
 In this way, the connection will only be padded in a given direction in
@@ -187,7 +187,7 @@ idle, so we expect the actual overhead to be much lower than this.
 ## Reducing or Disabling Padding via Negotiation { #negotiation }
 
 To allow mobile clients to either disable or reduce their padding overhead,
-the CELL_PADDING_NEGOTIATE cell (tor-spec.txt section 7.2) may be sent from
+the PADDING_NEGOTIATE cell (tor-spec.txt section 7.2) may be sent from
 clients to relays. This cell is used to instruct relays to cease sending
 padding.
 
@@ -207,7 +207,7 @@ Tor connection down to 69KB per one-time-use Tor connection. For continual
 usage, the maximum overhead goes from 103 bytes/sec down to 46 bytes/sec.
 
 If a client opts to completely disable padding, it sends a
-CELL_PADDING_NEGOTIATE to instruct the relay not to pad, and then does not
+PADDING_NEGOTIATE to instruct the relay not to pad, and then does not
 send any further padding itself.
 
 Currently, clients negotiate padding only when a channel is created,
@@ -216,9 +216,9 @@ accept padding negotiation messages at any time.
 
 If a client which previously negotiated reduced, or disabled, padding, and
 wishes to re-enable default padding (ie padding according to the consensus
-parameters), it SHOULD send CELL_PADDING_NEGOTIATE START with zero in the
+parameters), it SHOULD send PADDING_NEGOTIATE START with zero in the
 ito_low_ms and ito_high_ms fields.  (It therefore SHOULD NOT copy the values
-from its own established consensus into the CELL_PADDING_NEGOTIATE cell.)
+from its own established consensus into the PADDING_NEGOTIATE cell.)
 This avoids the client needing to send updated padding negotiations if the
 consensus parameters should change.  The recipient's clamping of the timing
 parameters will cause the recipient to use its notion of the consensus
diff --git a/spec/padding-spec/overview.md b/spec/padding-spec/overview.md
index 0abe739..594b9d4 100644
--- a/spec/padding-spec/overview.md
+++ b/spec/padding-spec/overview.md
@@ -5,16 +5,16 @@
 Tor supports two classes of cover traffic: connection-level padding, and
 circuit-level padding.
 
-Connection-level padding uses the CELL_PADDING cell command for cover
-traffic, where as circuit-level padding uses the RELAY_COMMAND_DROP relay
-command. CELL_PADDING is single-hop only and can be differentiated from
+Connection-level padding uses the PADDING cell command for cover
+traffic, where as circuit-level padding uses the DROP relay
+command. PADDING cells are single-hop only and can be differentiated from
 normal traffic by Tor relays ("internal" observers), but not by entities
 monitoring Tor OR connections ("external" observers).
 
-RELAY_COMMAND_DROP is multi-hop, and is not visible to intermediate Tor
+DROP relay messages are multi-hop, and is not visible to intermediate Tor
 relays, because the relay command field is covered by circuit layer
-encryption. Moreover, Tor's 'recognized' field allows RELAY_COMMAND_DROP
-padding to be sent to any intermediate node in a circuit (as per Section
+encryption. Moreover, Tor's 'recognized' field allows DROP messages
+to be sent to any intermediate node in a circuit (as per Section
 6.1 of tor-spec.txt).
 
 Tor uses both connection level and circuit level padding. Connection