Replace "payload" with "body"

We had used these terms inconsistently; "payload" was far less
common.

Part of #253.

16 files changed, 87 insertions, 71 deletions

diff --git a/spec/control-spec/replies.md b/spec/control-spec/replies.md
index 6fce9b1..ed76cbd 100644
--- a/spec/control-spec/replies.md
+++ b/spec/control-spec/replies.md
@@ -1445,9 +1445,11 @@ dropped cells, and ignored cells (such as padding cells). These
 values include the relay headers, but not circuit headers.
 
 Circuit data that has been validated and processed by Tor is further
-broken down into two categories: delivered payloads and overhead.
-DeliveredBytesRead and DeliveredBytesWritten are the total relay cell
-payloads transmitted since the last CIRC_BW event, not counting relay
+broken down into two categories: delivered relay message bodies,
+and overhead.
+DeliveredBytesRead and DeliveredBytesWritten are the total
+length of the relay message bodies
+transmitted since the last CIRC_BW event, not counting relay
 cell headers or circuit headers. OverheadBytesRead and
 OverheadBytesWritten are the extra unused bytes at the end of each
 cell in order for it to be the fixed CELL_LEN bytes long.
diff --git a/spec/glossary.md b/spec/glossary.md
index aa68699..5f45f7f 100644
--- a/spec/glossary.md
+++ b/spec/glossary.md
@@ -199,14 +199,19 @@ CREATED cell: Second part of a handshake, sent by the responder.
 
 EXTEND message: (also known as a RELAY_EXTEND message) First part of a
 handshake, tunneled through an existing circuit.  The last relay
-in the circuit so far will decrypt this cell and send the
-payload in a CREATED cell to the chosen next hop relay.
+in the circuit so far will process this message by
+decoding it,
+and sending the appropriate handshake
+in a CREATED cell to the client's chosen next-hop relay.
 
 EXTENDED cell: (also known as a RELAY_EXTENDED message) Second part
 of a handshake, tunneled through an existing circuit.  The last
 relay in the circuit so far receives the CREATED cell from the
-new last hop relay and encrypts the payload in an EXTENDED message
-to tunnel back to the client.
+new last-hop relay,
+encodes that cell's body in in an EXTENDED message,
+and uses a RELAY cell to deliver the message back to the client.
+Upon receiving the EXTENDED message,
+the client's circuit is one hop longer.
 
 Onion skin: The body of a CREATE/CREATE2 cell or an EXTEND/EXTEND2 message.
 It contains the first part of the TAP or ntor key establishment
diff --git a/spec/padding-spec/circuit-level-padding.md b/spec/padding-spec/circuit-level-padding.md
index 85f9137..66caa2f 100644
--- a/spec/padding-spec/circuit-level-padding.md
+++ b/spec/padding-spec/circuit-level-padding.md
@@ -69,7 +69,7 @@ the circuit. It is used to disambiguate shutdown requests.
 
 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
+in the body of a relay message with command number 42 (see tor-spec.txt
 section 6.1), as follows:
 
 ```text
diff --git a/spec/rend-spec/introduction-protocol.md b/spec/rend-spec/introduction-protocol.md
index cb7debf..fe59a1d 100644
--- a/spec/rend-spec/introduction-protocol.md
+++ b/spec/rend-spec/introduction-protocol.md
@@ -185,7 +185,7 @@ and the introduction point should ignore the other parameter.
 If the burst is lower than the rate,
 the introduction point SHOULD ignore the extension.
 
-> Using this extension extends the payload of the ESTABLISH_INTRO message by 19
+> Using this extension extends the body of the ESTABLISH_INTRO message by 19
 > bytes bringing it from 134 bytes to 155 bytes.
 
 When this extension is not _sent_,
@@ -219,7 +219,7 @@ In this older protocol, an ESTABLISH_INTRO message contains:
         KEY_LEN        [2 bytes]
         KEY            [KEY_LEN bytes]
         HANDSHAKE_AUTH [20 bytes]
-        SIG            [variable, up to end of relay payload]
+        SIG            [variable, up to end of relay message body]
 
    The KEY_LEN variable determines the length of the KEY field.
 ```
@@ -313,7 +313,7 @@ should be of the form:
        EXT_FIELD_TYPE [1 byte]
        EXT_FIELD_LEN  [1 byte]
        EXT_FIELD      [EXT_FIELD_LEN bytes]
-     ENCRYPTED        [Up to end of relay payload]
+     ENCRYPTED        [Up to end of relay message body]
 ```
 
 The `ENCRYPTED` field is described in the \[PROCESS_INTRO2\] section.
@@ -381,7 +381,8 @@ Other versions may have a different format.
 A correctly functioning client only submits solutions with a version and seed which were advertised by the server and have not yet expired.
 An extension with an unknown version or expired seed is suspicious and SHOULD result in introduction failure.
 
-This will increase the INTRODUCE1 payload size by 43 bytes since the extension type and length is 2 extra bytes, the N_EXTENSIONS field is always present and currently set to 0 and the EXT_FIELD is 41 bytes.
+This will increase the INTRODUCE1 message body size by 43 bytes
+since the extension type and length is 2 extra bytes, the N_EXTENSIONS field is always present and currently set to 0 and the EXT_FIELD is 41 bytes.
 According to ticket #33650, INTRODUCE1 messages currently have more than 200 bytes available.
 
 Introduced in tor-0.4.8.1-alpha.
@@ -522,7 +523,7 @@ configured with congestion control.
 
      \[01\] -- Congestion Control Request.
 
-This field is has zero payload length. Its presence signifies that the client
+This field is has zero body length. Its presence signifies that the client
 wants to use congestion control. The client MUST NOT set this field, or use
 ntorv3, if the service did not list "2" in the `FlowCtrl` line in the
 descriptor. The client SHOULD NOT provide this field if the consensus parameter
diff --git a/spec/rend-spec/rendezvous-protocol.md b/spec/rend-spec/rendezvous-protocol.md
index 2b14934..0f6d4e9 100644
--- a/spec/rend-spec/rendezvous-protocol.md
+++ b/spec/rend-spec/rendezvous-protocol.md
@@ -127,8 +127,8 @@ The behavior of ESTABLISH_RENDEZVOUS is unchanged from older versions
 of this protocol, except that relays should now ignore unexpected
 bytes at the end.
 
-Old versions of Tor required that RENDEZVOUS message payloads be exactly
-168 bytes long. All shorter rendezvous payloads should be padded to
+Old versions of Tor required that RENDEZVOUS message bodies be exactly
+168 bytes long. All shorter rendezvous bodies should be padded to
 this length with random bytes, to make them difficult to distinguish from
 older protocols at the rendezvous point.
 
diff --git a/spec/tor-spec/cell-packet-format.md b/spec/tor-spec/cell-packet-format.md
index 8f2174d..cfc7f36 100644
--- a/spec/tor-spec/cell-packet-format.md
+++ b/spec/tor-spec/cell-packet-format.md
@@ -27,7 +27,7 @@ since no version has yet been negotiated.
 |-----------|-------------------|-------|
 | `CircID`  | [`CIRCID_LEN(v)`] |       |
 | `Command` | 1                 |       |
-| `Payload` | [`PAYLOAD_LEN`]   | Padded to fit |
+| `Body`    | [`CELL_BODY_LEN`] | Padded to fit |
 
 The value of `CIRCID_LEN` depends on the negotiated link protocol.
 
@@ -41,10 +41,10 @@ A variable-length cell has this format:
 | `CircID`  | `CIRCID_LEN(v)` |       |
 | `Command` | 1               |       |
 | `Length`  | 2               | A big-endian integer |
-| `Payload` | `Length`        |       |
+| `Body`    | `Length`        |       |
 
 [`CIRCID_LEN(v)`]: ./preliminaries.md#msg-len
-[`PAYLOAD_LEN`]: ./preliminaries.md#msg-len
+[`CELL_BODY_LEN`]: ./preliminaries.md#msg-len
 [`VERSIONS` cells]: ./negotiating-channels.md#VERSIONS-cells
 
 Fixed-length and variable-length cells are distinguished
@@ -159,34 +159,38 @@ and MAY terminate the channel with an error.
 > under the assumption that the command was sent
 > by a more up-to-date version of Tor.
 
-## Interpreting the fields: Payload {#payload}
+## Interpreting the fields: Cell Body {#body}
 
-The interpretation of Payload depends on the cell's command.
+<!-- deprecated target --><a id="payload"></a>
+
+The interpretation of a cell's Body depends on the cell's command.
 see the links in the command descriptions above
 for more information on each command.
 
-## Padding fixed-length cell payloads {#payload-padding}
+## Padding fixed-length cell bodies {#body-padding}
+
+<!-- deprecated target --><a id="payload-padding"></a>
 
 Often, the amount of information to be sent
 in a fixed-length cell
-is less than [`PAYLOAD_LEN`] bytes.
+is less than [`CELL_BODY_LEN`] bytes.
 When this happens,
-the sender MUST fill the unused part of the payload
+the sender MUST fill the unused part of the cell's body
 with zero-valued bytes.
 
 Recipients MUST ignore padding bytes.
 
-> [RELAY] and [RELAY_EARLY] cell payloads
+> [RELAY] and [RELAY_EARLY] cells' bodies
 > contain encrypted data,
 > and are always full
 > from the point of the view of the channel layer.
 >
 > The _plaintext_ of these cells' contents may be padded;
 > this uses a [different mechanism](./relay-cells.md#relay-cell-padding)
-> and does not interact with channel payload padding.
+> and does not interact with cell body padding.
 
 Variable-length cells never have extra space,
-so there is no need to pad their payloads.
+so there is no need to pad their bodies.
 Unless otherwise specified,
 variable-length cells have no padding.
 
diff --git a/spec/tor-spec/closing-streams.md b/spec/tor-spec/closing-streams.md
index 6bbcaeb..1d65b6d 100644
--- a/spec/tor-spec/closing-streams.md
+++ b/spec/tor-spec/closing-streams.md
@@ -9,7 +9,7 @@ an edge node receives a 'RELAY_END' message for any stream, it closes
 the TCP connection completely, and sends nothing more along the
 circuit for that stream.
 
-The payload of a RELAY_END message begins with a single 'reason' byte to
+The body of a RELAY_END message begins with a single 'reason' byte to
 describe why the stream is closing.  For some reasons, it contains
 additional data (depending on the reason.)  The values are:
 
diff --git a/spec/tor-spec/create-created-cells.md b/spec/tor-spec/create-created-cells.md
index a9b7a12..3208909 100644
--- a/spec/tor-spec/create-created-cells.md
+++ b/spec/tor-spec/create-created-cells.md
@@ -123,7 +123,7 @@ randomly chosen CircID values are all in use (today's Tor stops after 64).
 To extend an existing circuit, the client sends an EXTEND or EXTEND2
 message, in a RELAY_EARLY cell, to the last node in the circuit.
 
-An EXTEND2 message's relay payload contains:
+The body of an EXTEND2 message contains:
 
 | Field          | Description               | Size                           |
 | -----          | -----------               | ----                           |
@@ -155,7 +155,7 @@ For purposes of indistinguishability, implementations SHOULD send
 these link specifiers, if using them, in this order: \[00\], \[02\], \[03\],
 \[01\].
 
-The relay payload for an EXTEND relay message consists of:
+The body for an EXTEND relay message consists of:
 
 | Field                | Size
 | -----                | ----
@@ -194,10 +194,10 @@ CREATE/CREATE2 cell from the contents of the EXTEND/EXTEND2 message.
 See [Creating circuits](./creating-circuits.md#creating-circuits)
 for details.
 
-The payload of an EXTENDED message is the same as the payload of a
+The body of an EXTENDED message is the same as the body of a
 CREATED cell.
 
-The payload of an EXTENDED2 message is the same as the payload of a
+The body of an EXTENDED2 message is the same as the body of a
 CREATED2 cell.
 
 \[Support for EXTEND2/EXTENDED2 was added in Tor 0.2.4.8-alpha.\]
@@ -228,7 +228,7 @@ Authentication Protocol".)
 Define `TAP_C_HANDSHAKE_LEN` as `DH_LEN+KEY_LEN+KP_PAD_LEN`.
 Define `TAP_S_HANDSHAKE_LEN` as `DH_LEN+HASH_LEN`.
 
-The payload for a CREATE cell is an 'onion skin', which consists of
+The body for a CREATE cell is an 'onion skin', which consists of
 the first step of the DH handshake data (also known as `g^x`).  This
 value is encrypted using the "legacy hybrid encryption" algorithm
 (see ["Preliminaries » A bad hybrid encryption algorithm..."](./preliminaries.md#legacy-hybrid-encryption))
@@ -243,8 +243,8 @@ to the server's onion key, giving a client handshake:
 | Symmetrically encrypted
 | - Second part of `g^x`   | `DH_LEN-(KP_ENC_LEN-KP_PAD_LEN-KEY_LEN)` bytes
 
-The payload for a CREATED cell, or the relay payload for an
-EXTENDED message, contains:
+The body for a CREATED cell, or the body for an
+EXTENDED relay message, contains:
 
 | Field                      | Size
 | -----                      | ----
@@ -599,7 +599,7 @@ Currently supported extensions are:
 
  * 1 -- `CC_FIELD_REQUEST` \[Client to server\]
   
-   Contains an empty payload.  Signifies that the client
+   Contains an empty body.  Signifies that the client
    wants to use the extended congestion control described
    in [proposal 324].
   
diff --git a/spec/tor-spec/creating-circuits.md b/spec/tor-spec/creating-circuits.md
index 10e23b4..deb6b83 100644
--- a/spec/tor-spec/creating-circuits.md
+++ b/spec/tor-spec/creating-circuits.md
@@ -44,11 +44,11 @@ these steps:
 
 When an onion router receives an EXTEND relay message, it sends a CREATE
 cell to the next onion router, with the enclosed onion skin as its
-payload.
+body.
 
 When an onion router receives an EXTEND2 relay message, it sends a CREATE2
 cell to the next onion router, with the enclosed HLEN, HTYPE, and HDATA
-as its payload. The initiating onion router chooses some circID not yet
+as its body. The initiating onion router chooses some circID not yet
 used on the connection between the two onion routers. (But see section
 ["Choosing circuit IDs in create  cells"](./create-created-cells.md#choosing-circid))
 
@@ -69,7 +69,7 @@ circuit on the given connection with the given circID, it drops the
 cell. Otherwise, after receiving the CREATE/CREATE2 cell, it completes
 the specified handshake, and replies with a CREATED/CREATED2 cell.
 
-Upon receiving a CREATED/CREATED2 cell, an onion router packs it payload
+Upon receiving a CREATED/CREATED2 cell, an onion router packs its body
 into an [EXTENDED/EXTENDED2](./create-created-cells.md#EXTEND) relay message, and sends
 that message up the circuit. Upon receiving the EXTENDED/EXTENDED2 relay
 message, the OP can retrieve the handshake material.
diff --git a/spec/tor-spec/flow-control.md b/spec/tor-spec/flow-control.md
index 8c3bcce..9ecc5da 100644
--- a/spec/tor-spec/flow-control.md
+++ b/spec/tor-spec/flow-control.md
@@ -34,7 +34,7 @@ information. See [proposal 111] for details.
 
 Link padding can be created by sending PADDING or VPADDING cells
 along the connection; relay messages of type "DROP" can be used for
-long-range padding.  The payloads of PADDING cells, VPADDING cells, or DROP
+long-range padding.  The bodies of PADDING cells, VPADDING cells, or DROP
 message are filled with padding bytes.
 See [Cell Packet format](./cell-packet-format.md#cell-packet-format).
 
@@ -146,7 +146,7 @@ version to emit and accept.
 If a RELAY_SENDME version is received that is below the minimum accepted
 version, the circuit should be closed.
 
-The RELAY_SENDME payload contains the following:
+The body of a RELAY_SENDME message contains the following:
 
 ```text
       VERSION     [1 byte]
@@ -157,7 +157,7 @@ The RELAY_SENDME payload contains the following:
 The VERSION tells us what is expected in the DATA section of length
 DATA_LEN and how to handle it. The recognized values are:
 
-0x00: The rest of the payload should be ignored.
+0x00: The rest of the message should be ignored.
 
 0x01: Authenticated SENDME. The DATA section MUST contain:
 
@@ -193,7 +193,7 @@ DATA-bearing cells
 (500) per stream, and increment the window by a fixed value (50)
 upon receiving a RELAY_SENDME message. Edge nodes initiate RELAY_SENDME
 messages when both a) the window is \<= 450, and b) there are less than
-ten cell payloads remaining to be flushed at that edge.
+ten cells' worth of data remaining to be flushed at that edge.
 
 Stream-level RELAY_SENDME messages are distinguished by having nonzero
 StreamID. They are still empty; the body still SHOULD be ignored.
diff --git a/spec/tor-spec/negotiating-channels.md b/spec/tor-spec/negotiating-channels.md
index 4c1ae1c..571a1be 100644
--- a/spec/tor-spec/negotiating-channels.md
+++ b/spec/tor-spec/negotiating-channels.md
@@ -99,7 +99,7 @@ Once the TLS handshake is complete,
 both parties send a VERSIONS cell
 to negotiate which one they will use.
 
-The payload in a VERSIONS cell is a series of big-endian two-byte
+The body in a VERSIONS cell is a series of big-endian two-byte
 integers.
 Both parties MUST select as the link protocol version the
 highest number contained both in the VERSIONS cell they sent and in the
@@ -108,7 +108,7 @@ If they have no such version in common,
 they cannot communicate and MUST close the connection.
 Either party MUST
 close the connection if the VERSIONS cell is not well-formed (for example,
-if the payload contains an odd number of bytes).
+if the body contains an odd number of bytes).
 
 Any VERSIONS cells sent after the first VERSIONS cell MUST be ignored.
 (To be interpreted correctly, later VERSIONS cells MUST have a CIRCID_LEN
@@ -145,7 +145,7 @@ and provides certificates to authenticate that those keys
 belong, ultimately, to one or more
 [identity keys](./relay-keys.md#identity).
 
-CERTS is a variable-length cell.  Its payload format is:
+CERTS is a variable-length cell.  Its body format is:
 
 | Field         | Size | Description                    |
 | -----         | ---- | ------------------------------ |
@@ -441,7 +441,7 @@ To finish the handshake,
 each party sends the other
 a NETINFO cell.
 
-The cell's payload is:
+A NETINFO cell's body is:
 
 | Field            | Description                   | Size
 | -----            | -----------                   | ----
diff --git a/spec/tor-spec/opening-streams.md b/spec/tor-spec/opening-streams.md
index 8e63a62..81e1616 100644
--- a/spec/tor-spec/opening-streams.md
+++ b/spec/tor-spec/opening-streams.md
@@ -7,8 +7,8 @@
 To open a new anonymized TCP connection, the OP chooses an open
 circuit to an exit that may be able to connect to the destination
 address, selects an arbitrary StreamID not yet used on that circuit,
-and constructs a RELAY_BEGIN message with a payload encoding the address
-and port of the destination host.  The payload format is:
+and constructs a RELAY_BEGIN message with a body encoding the address
+and port of the destination host.  The body format is:
 
 ```text
          ADDRPORT [nul-terminated string]
@@ -33,7 +33,7 @@ the MSB of a 4-byte value is the MSB of the first byte, and the LSB
 of a 4-byte value is the LSB of its last byte.)
 
 If FLAGS is absent, its value is 0.  Whenever 0 would be sent for
-FLAGS, FLAGS is omitted from the message payload.
+FLAGS, FLAGS is omitted from the message body.
 
 ```text
      bit   meaning
@@ -54,7 +54,7 @@ address cannot be resolved, or a connection can't be established, the
 exit node replies with a RELAY_END message.  (See
 ["Closing streams"](./closing-streams.md#closing-streams).)
 Otherwise, the exit node replies with a RELAY_CONNECTED message, whose
-payload is in one of the following formats:
+body is in one of the following formats:
 
 ```text
        The IPv4 address to which the connection was made [4 octets]
@@ -129,13 +129,13 @@ Directory servers may be:
 If the Tor relay is not running a directory service, it should respond
 with a REASON_NOTDIRECTORY RELAY_END message.
 
-Clients MUST generate an all-zero payload for RELAY_BEGIN_DIR message,
-and relays MUST ignore the payload.
+Clients MUST generate a empty body for RELAY_BEGIN_DIR message;
+relays MUST ignore the the body of a RELAY_BEGIN_DIR message.
 
 In response to a RELAY_BEGIN_DIR message, relays respond either with a
-RELAY_CONNECTED message on success, or a RELAY_END message on failure. They
-MUST send a RELAY_CONNECTED message all-zero payload, and clients MUST ignore
-the payload.
+RELAY_CONNECTED message on success, or a RELAY_END message on failure.
+They MUST send a RELAY_CONNECTED message with an empty body;
+clients MUST ignore the body.
 
 \[RELAY_BEGIN_DIR was not supported before Tor 0.1.2.2-alpha; clients
 SHOULD NOT send it to routers running earlier versions of Tor.\]
diff --git a/spec/tor-spec/preliminaries.md b/spec/tor-spec/preliminaries.md
index e69d47e..15cacf3 100644
--- a/spec/tor-spec/preliminaries.md
+++ b/spec/tor-spec/preliminaries.md
@@ -47,13 +47,15 @@ for these, the link protocol is denoted in this table with `v`.
 
 | Name | Length in bytes | Meaning |
 | ---- | --------------- | ------- |
-| `PAYLOAD_LEN` | 509 | The longest payload for a [fixed-length cell](./cell-packet-format.md#fixed-length-cell). |
+| `CELL_BODY_LEN` | 509 | The body length for a [fixed-length cell](./cell-packet-format.md#fixed-length-cell). |
 | `CIRCID_LEN(v)`, `v` < 4 | 2 | The length of a [circuit ID](./cell-packet-format.md#circid) |
 | `CIRCID_LEN(v)`, `v` ≥ 4 | 4 |  |
 | `CELL_LEN(v)`, `v` < 4 | 512 | The length of a [fixed-length cell](./cell-packet-format.md). |
 | `CELL_LEN(v)`, `v` ≥ 4 | 514 |  |
 
-Note that for all `v`, `CELL_LEN(v) = 1 + CIRCID_LEN(v) + PAYLOAD_LEN`.
+Note that for all `v`, `CELL_LEN(v) = 1 + CIRCID_LEN(v) + CELL_BODY_LEN`.
+
+> Formerly `CELL_BODY_LEN` was called sometimes called `PAYLOAD_LEN`.
 
 <a id="tor-spec.txt-0.3"></a>
 
diff --git a/spec/tor-spec/relay-cells.md b/spec/tor-spec/relay-cells.md
index 346899b..a6c6b1c 100644
--- a/spec/tor-spec/relay-cells.md
+++ b/spec/tor-spec/relay-cells.md
@@ -13,7 +13,7 @@ End nodes that accept streams may be:
 - directory servers (RELAY_BEGIN_DIR, anonymous or non-anonymous),
 - onion services (RELAY_BEGIN, anonymous via a rendezvous point).
 
-The payload of each unencrypted relay cell consists of an
+The body of each unencrypted relay cell consists of an
 enveloped relay message, encoded as follows:
 
 | Field         | Size
@@ -24,7 +24,7 @@ enveloped relay message, encoded as follows:
 | Digest        | 4 bytes
 | Length        | 2 bytes
 | Data          | Length bytes
-| Padding       | PAYLOAD_LEN - 11 - Length bytes
+| Padding       | CELL_BODY_LEN - 11 - Length bytes
 
 > TODO: When we implement [prop340](../proposals/340-packed-and-fragmented.md),
 > we should clarify which parts of the above are about
@@ -78,12 +78,12 @@ that we should relay, the 'recognized' field will usually be nonzero,
 but will accidentally be zero with P=2^-16.
 
 When handling a relay cell, if the 'recognized' in field in a
-decrypted relay payload is zero, the 'digest' field is computed as
+decrypted relay cell is zero, the 'digest' field is computed as
 the first four bytes of the running digest of all the bytes that have
 been destined for this hop of the circuit or originated from this hop
 of the circuit, seeded from Df or Db respectively (obtained in
 [Setting circuit keys](./setting-circuit-keys.md#setting-circuit-keys)),
-and including this relay cell's entire payload
+and including this relay cell's entire body
 (taken with the digest field set to zero).  Note that these digests
 _do_ include the padding bytes at the end of the cell, not only those up
 to "Len".  If the digest is correct, the cell is considered "recognized"
@@ -106,8 +106,10 @@ can include a StreamID or not depending on their purpose -- see
 [Flow control](./flow-control.md#flow-control).)
 
 The 'Length' field of a relay cell contains the number of bytes in
-the relay payload which contain real payload data. The remainder of
-the unencrypted payload is padded with padding bytes. Implementations
+the relay cell's body which contain the body of the message.
+The remainder of
+the unencrypted relay cell's body is padded with padding bytes.
+Implementations
 handle padding bytes of unencrypted relay cells as they do padding
 bytes for other cell types; see [Cell Packet format](./cell-packet-format.md#cell-packet-format).
 
diff --git a/spec/tor-spec/routing-relay-cells.md b/spec/tor-spec/routing-relay-cells.md
index a9e3c49..66d5625 100644
--- a/spec/tor-spec/routing-relay-cells.md
+++ b/spec/tor-spec/routing-relay-cells.md
@@ -28,7 +28,7 @@ are sent.
 
 ### Routing from the Origin
 
-When a relay cell is sent from an OP, the OP encrypts the payload
+When a relay cell is sent from an OP, the OP encrypts the cell's body
 with the stream cipher as follows:
 
 ```text
@@ -42,7 +42,7 @@ OP sends relay cell:
 
 ### Relaying Forward at Onion Routers
 
-When a forward relay cell is received by an OR, it decrypts the payload
+When a forward relay cell is received by an OR, it decrypts the cell's body
 with the stream cipher, as follows:
 
 ```text
@@ -51,7 +51,7 @@ with the stream cipher, as follows:
 ```
 
 The OR then decides whether it recognizes the relay cell, by
-inspecting the payload as described in [Relay cells](./relay-cells.md#relay-cells).  If the OR
+inspecting the cell as described in [Relay cells](./relay-cells.md#relay-cells).  If the OR
 recognizes the cell, it processes the contents of the relay cell.
 Otherwise, it passes the decrypted relay cell along the circuit if
 the circuit continues.  If the OR at the end of the circuit
@@ -72,7 +72,7 @@ CREATE/CREATE2 cells.
 
 ### Relaying Backward at Onion Routers
 
-When a backward relay cell is received by an OR, it encrypts the payload
+When a backward relay cell is received by an OR, it encrypts the cell's body
 with the stream cipher, as follows:
 
 ```text
@@ -84,16 +84,16 @@ with the stream cipher, as follows:
 
 ## Routing to the Origin
 
-When a relay cell arrives at an OP, the OP decrypts the payload
+When a relay cell arrives at an OP, the OP decrypts the cell's body
 with the stream cipher as follows:
 
 ```text
 OP receives relay cell from node 1:
    For I=1...N, where N is the final node on the circuit:
        Decrypt with Kb_I.
-       If the payload is recognized (see [1]), then:
+       If the cell is recognized (see [1]), then:
            The sending node is I.
-           Stop and process the payload.
+           Stop and process the cell.
 ```
 
 \[1\]: ["Relay cells"](./relay-cells.md#relay-cells)
diff --git a/spec/tor-spec/tearing-down-circuits.md b/spec/tor-spec/tearing-down-circuits.md
index fadd1fc..3fde693 100644
--- a/spec/tor-spec/tearing-down-circuits.md
+++ b/spec/tor-spec/tearing-down-circuits.md
@@ -78,7 +78,7 @@ towards the client, not RELAY_TRUNCATED.
      behavior created queuing pressure on the intermediary ORs.
 ```
 
-The payload of a DESTROY cell or RELAY_TRUNCATED message contains a single
+The body of a DESTROY cell or RELAY_TRUNCATED message contains a single
 octet, describing the reason that the circuit was
 closed. RELAY_TRUNCATED message, and DESTROY cells sent \_towards the
 client, should contain the actual reason from the list of error codes