Commit 397f7c87 authored by Roger Dingledine's avatar Roger Dingledine
Browse files

fix some typos in our spec files

parent 184e7aa7
Loading
Loading
Loading
Loading
+2 −2
Original line number Diff line number Diff line
@@ -1285,7 +1285,7 @@
        selection. 

        Additionally, the Measured= keyword is present in votes by 
        participating bandwidth measurement authorites to indicate
        participating bandwidth measurement authorities to indicate
        a measured bandwidth currently produced by measuring stream 
        capacities. 

@@ -1436,7 +1436,7 @@
   by multiplying the previous published consensus bandwidth by the 
   ratio of the measured average node stream capacity to the network 
   average. If 3 or more authorities provide a Measured= keyword for 
   a router, the authorites produce a consensus containing a "w" 
   a router, the authorities produce a consensus containing a "w" 
   Bandwidth= keyword equal to the median of the Measured= votes.

   The ports listed in a "p" line should be taken as those ports for
+10 −10
Original line number Diff line number Diff line
@@ -20,7 +20,7 @@ see tor-design.pdf.

   PK -- a public key.
   SK -- a private key.
   K  -- a key for a symmetric cypher.
   K  -- a key for a symmetric cipher.

   a|b -- concatenation of 'a' and 'b'.

@@ -171,8 +171,8 @@ see tor-design.pdf.
   In "renegotiation", the connection initiator sends no certificates, and
   the responder sends a single connection certificate.  Once the TLS
   handshake is complete, the initiator renegotiates the handshake, with each
   parties sending a two-certificate chain as in "certificates up-front".
   The initiator's ClientHello MUST include at least once ciphersuite not in
   party sending a two-certificate chain as in "certificates up-front".
   The initiator's ClientHello MUST include at least one ciphersuite not in
   the list above.  The responder SHOULD NOT select any ciphersuite besides
   those in the list above.
     [The above "should not" is because some of the ciphers that
@@ -201,8 +201,8 @@ see tor-design.pdf.

   In all of the above handshake variants, certificates sent in the clear
   SHOULD NOT include any strings to identify the host as a Tor server. In
   the "renegotation" and "backwards-compatible renegotiation", the
   initiator SHOULD chose a list of ciphersuites and TLS extensions chosen
   the "renegotiation" and "backwards-compatible renegotiation" steps, the
   initiator SHOULD choose a list of ciphersuites and TLS extensions
   to mimic one used by a popular web browser.

   Responders MUST NOT select any TLS ciphersuite that lacks ephemeral keys,
@@ -288,7 +288,7 @@ see tor-design.pdf.
         6 -- CREATED_FAST (Circuit created, no PK) (See Sec 5.1)
         7 -- VERSIONS    (Negotiate proto version) (See Sec 4)
         8 -- NETINFO     (Time and address info)   (See Sec 4)
         9 -- RELAY_EARLY (End-to-end data; limited) (See sec 5.6)
         9 -- RELAY_EARLY (End-to-end data; limited)(See Sec 5.6)

   The interpretation of 'Payload' depends on the type of the cell.
      PADDING: Payload is unused.
@@ -356,7 +356,7 @@ see tor-design.pdf.

   The address format is a type/length/value sequence as given in section
   6.4 below.  The timestamp is a big-endian unsigned integer number of
   seconds since the unix epoch.
   seconds since the Unix epoch.

   Implementations MAY use the timestamp value to help decide if their
   clocks are skewed.  Initiators MAY use "other OR's address" to help
@@ -398,7 +398,7 @@ see tor-design.pdf.
         Onion skin                    [DH_LEN+KEY_LEN+PK_PAD_LEN bytes]
         Identity fingerprint          [HASH_LEN bytes]

   The port and address field denote the IPV4 address and port of the next
   The port and address field denote the IPv4 address and port of the next
   onion router in the circuit; the public key hash is the hash of the PKCS#1
   ASN1 encoding of the next onion router's identity (signing) key.  (See 0.3
   above.)  Including this hash allows the extending OR verify that it is
@@ -885,7 +885,7 @@ see tor-design.pdf.
6.4. Remote hostname lookup

   To find the address associated with a hostname, the OP sends a
   RELAY_RESOLVE cell containing the hostname to be resolved with a nul
   RELAY_RESOLVE cell containing the hostname to be resolved with a NUL
   terminating byte. (For a reverse lookup, the OP sends a RELAY_RESOLVE
   cell containing an in-addr.arpa address.) The OR replies with a
   RELAY_RESOLVED cell containing a status byte, and any number of