[tor-commits] [torspec/master] easy typo/grammar/etc fixes on prop#224

[arma at torproject.org]

commit 13bb5f4a9460c3a7e465c2f384f7dc8baec69b60
Author: Roger Dingledine <arma at torproject.org>
Date:   Sun May 8 20:40:24 2016 -0400

    easy typo/grammar/etc fixes on prop#224
---
 proposals/224-rend-spec-ng.txt | 27 ++++++++++++++-------------
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index bad3a47..d732b27 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -80,8 +80,8 @@ Status: Draft
      1. A sequence of two-digit hexadecimal values in square brackets,
         as in [AB AD 1D EA].
 
-     2. A string of characters enclosed in quotes, as in "Hello". These
-        characters in these string are encoded in their ascii
+     2. A string of characters enclosed in quotes, as in "Hello". The
+        characters in these strings are encoded in their ascii
         representations; strings are NOT nul-terminated unless
         explicitly described as NUL terminated.
 
@@ -118,7 +118,7 @@ Status: Draft
 
       * A public key agreement system "PK", providing
         PK_KEYGEN()->seckey, pubkey; PK_VALID(pubkey) -> {"OK", "BAD"};
-        and PK_HANDHAKE(seckey, pubkey)->output; where secret keys are
+        and PK_HANDSHAKE(seckey, pubkey)->output; where secret keys are
         of length PK_SECKEY_LEN bytes, public keys are of length
         PK_PUBKEY_LEN bytes, and the handshake produces outputs of
         length PK_OUTPUT_LEN bytes.
@@ -409,8 +409,8 @@ Status: Draft
    collaboratively generated random value. (See section 2.3 for a
    description of how to incorporate this value into the voting
    practice; generating the value is described in other proposals,
-   including [TODO: add a reference])  That value, combined with hidden service
-   directories' public identity keys, determines each HSDirs' position
+   including [SHAREDRANDOM-REFS].) That value, combined with hidden service
+   directories' public identity keys, determines each HSDir's position
    in the hash ring for descriptors made in that period.
 
    Each hidden service's descriptors are placed into the ring in
@@ -476,7 +476,7 @@ Status: Draft
 
    To avoid replays of an introduction request by an introduction point,
    a hidden service host must never accept the same request
-   twice. Earlier versions of the hidden service design used a
+   twice. Earlier versions of the hidden service design used an
    authenticated timestamp here, but including a view of the current
    time can create a problematic fingerprint. (See proposal 222 for more
    discussion.)
@@ -497,7 +497,7 @@ Status: Draft
         address according to [NAMING].
 
       Blinded signing key -- A keypair derived from the identity key,
-        used to sign descriptor signing keys. Changes periodically for
+        used to sign descriptor signing keys. It changes periodically for
         each service. Clients who know a 'credential' consisting of the
         service's public identity key and an optional secret can derive
         the public blinded identity key for a service.  This key is used
@@ -809,7 +809,7 @@ Status: Draft
 2.3. Publishing shared random values [PUB-SHAREDRANDOM]
 
    Our design for limiting the predictability of HSDir upload locations
-   relies on a shared random value that isn't predictable in advance or
+   relies on a shared random value (SRV) that isn't predictable in advance or
    too influenceable by an attacker. The authorities must run a protocol
    to generate such a value at least once per hsdir period. Here we
    describe how they publish these values; the procedure they use to
@@ -926,7 +926,7 @@ Status: Draft
    Before encryption, the plaintext must be padded to a multiple of ???
    bytes with NUL bytes. The plaintext must not be longer than ???
    bytes.  [TODO: how much? Should this be a parameter?  What values in
-   practice is needed to hide how many intro points we have, and how
+   practice are needed to hide how many intro points we have, and how
    many might be legacy ones? Note that Single Onion Services add extend
    intro points as well. ]
 
@@ -1005,7 +1005,7 @@ Status: Draft
    First, a hidden service host builds an anonymous circuit to a Tor
    node and registers that circuit as an introduction point.
 
-        [Between these steps, the hidden service publishes its
+        [After 'First' and before 'Second', the hidden service publishes its
         introduction points and associated keys, and the client fetches
         them as described in section [HSDIR] above.]
 
@@ -1021,7 +1021,7 @@ Status: Draft
 3.1.1. Extensible ESTABLISH_INTRO protocol. [EST_INTRO]
 
    When a hidden service is establishing a new introduction point, it
-   sends a ESTABLISH_INTRO cell with the following contents:
+   sends an ESTABLISH_INTRO cell with the following contents:
 
      AUTH_KEY_TYPE    [1 byte]
      AUTH_KEY_LEN     [1 byte]
@@ -1036,7 +1036,7 @@ Status: Draft
      SIG              [SIGLEN bytes]
 
    The AUTH_KEY_TYPE field indicates the type of the introduction point
-   authentication key and the type of the MAC to use in for
+   authentication key and the type of the MAC to use in
    HANDSHAKE_AUTH. Recognized types are:
 
        [00, 01] -- Reserved for legacy introduction cells; see
@@ -1499,7 +1499,7 @@ Status: Draft
    use on an existing circuit, the rendezvous point should reject it and
    destroy the circuit.
 
-   Upon receiving a ESTABLISH_RENDEZVOUS cell, the rendezvous point
+   Upon receiving an ESTABLISH_RENDEZVOUS cell, the rendezvous point
    associates the cookie with the circuit on which it was sent. It
    replies to the client with an empty RENDEZVOUS_ESTABLISHED cell to
    indicate success.  [TODO: make this extensible]
@@ -1767,3 +1767,4 @@ Appendix E. Reserved numbers
            public key. (Section 2.5)
 
   [XXXX list more]
+