apply contrib/checkSpace.pl to our spec files too.

svn:r5941

doc/control-spec-v0.txt

@@ -235,7 +235,6 @@ the message.
 
                 Message [NUL-terminated]
 
-
 3.8. AUTHENTICATE (Type 0x0007)
 
   Sent from the client to the server.  Contains a 'magic cookie' to prove

doc/control-spec.txt

@@ -88,7 +88,6 @@ $Id$
 
   Address = ip4-address / ip6-address / hostname   (XXXX Define these)
 
-
   ; A "Data" section is a sequence of octets concluded by the terminating
   ; sequence CRLF "." CRLF.  The terminating sequence may not appear in the
   ; body of the data.  Leading periods on lines in the data are escaped with
@@ -250,9 +249,10 @@ $Id$
     250-OldAddress1=NewAddress1
     250 OldAddress2=NewAddress2
 
-  containing the source and destination addresses.  If request is malformed,
-  the server replies with "512 syntax error in command argument".  If the server
-  can't fulfill the request, it replies with "451 resource exhausted."
+  containing the source and destination addresses.  If request is
+  malformed, the server replies with "512 syntax error in command
+  argument".  If the server can't fulfill the request, it replies with
+  "451 resource exhausted."
 
   The client may decline to provide a body for the original address, and
   instead send a special null address ("0.0.0.0" for IPv4, "::0" for IPv6, or
@@ -326,15 +326,17 @@ $Id$
     "addr-mappings/all"
     "addr-mappings/config"
     "addr-mappings/cache"
-    "addr-mappings/control" -- a space-separated list of address mappings, each
-      in the form of "from-address=to-address".  The 'config' key
-      returns those address mappings set in the configuration; the 'cache'
-      key returns the mappings in the client-side DNS cache; the 'control'
-      key returns the mappings set via the control interface; the 'all'
-      target returns the mappings set through any mechanism.
+    "addr-mappings/control" -- a space-separated list of address
+      mappings, each in the form of "from-address=to-address".
+      The 'config' key returns those address mappings set in the
+      configuration; the 'cache' key returns the mappings in the
+      client-side DNS cache; the 'control' key returns the mappings set
+      via the control interface; the 'all' target returns the mappings
+      set through any mechanism.
 
     "circuit-status"
-      A series of lines as for a circuit status event. Each line is of the form:
+      A series of lines as for a circuit status event. Each line is of
+      the form:
          CircuitID SP CircStatus SP Path CRLF
 
     "stream-status"
@@ -694,7 +696,8 @@ $Id$
 4.1.8. Descriptors uploaded to us in our role as authoritative dirserver
 
   Syntax:
-     "650" "+" "AUTHDIR_NEWDESCS" CRLF Action CRLF Message CRLF Descriptor CRLF "." CRLF
+     "650" "+" "AUTHDIR_NEWDESCS" CRLF Action CRLF Message CRLF
+       Descriptor CRLF "." CRLF
      Action = "ACCEPTED" / "DROPPED" / "REJECTED"
      Message = Text
 
@@ -739,3 +742,4 @@ $Id$
   should send the sequence [00 00 0D 0A].  This is a valid and unrecognized
   command in both protocol versions, and implementations can detect which
   error they have received.
+

doc/dir-spec.txt

@@ -511,3 +511,4 @@ TODO:
       vice versa).  But what about when the client connects to A and B but in
       a different order?  How bad can it be partitioned based on its
       knowledge?
+

doc/socks-extensions.txt

@@ -58,3 +58,4 @@ References:
  [1] http://archive.socks.permeo.com/protocol/socks4.protocol
  [2] http://archive.socks.permeo.com/protocol/socks4a.protocol
  [3] SOCKS5: RFC1928
+

doc/tor-spec.txt

@@ -318,7 +318,6 @@ when do we rotate which keys (tls, link, etc)?
    derivative key data as
        K = H(K0 | [00]) | H(K0 | [01]) | H(K0 | [02]) | ...
 
-
    The first HASH_LEN bytes of K form KH; the next HASH_LEN form the forward
    digest Df; the next HASH_LEN 41-60 form the backward digest Db; the next
    KEY_LEN 61-76 form Kf, and the final KEY_LEN form Kb.  Excess bytes from K
@@ -1024,7 +1023,6 @@ A.1. Differences between spec and implementation
 
 B. Things that should change in a later version of the Tor protocol
 
-
 B.1. ... but which will require backward-incompatible change
 
   - Circuit IDs should be longer.

doc/version-spec.txt

@@ -21,7 +21,6 @@ say, "0.0.8".  Our first pre-release would be "0.0.8pre1", followed by
 0.0.8.  The stable CVS branch would then be versioned "0.0.8.1-cvs",
 and any eventual bugfix release would be "0.0.8.1".
 
-
 The New Way
 -----------
 
@@ -44,3 +43,4 @@ Eventually, we release 0.1.1.6.  The next patch release is 0.1.1.7.
 
 Between these releases, CVS is versioned with a -cvs tag: after
 0.1.1.1-alpha comes 0.1.1.1-alpha-cvs, and so on.
+