fix erroneous header numbering punctuation

The clear standard is trailing "." after each numeric section.  This fixes
the small handful of outliers.  This makes it easy to convert these headers
to common markup formats, for example:
http://hyperpolyglot.org/lightweight-markup

13 files changed, 36 insertions, 36 deletions

diff --git a/bandwidth-file-spec.txt b/bandwidth-file-spec.txt
index 7564c4c..5a2954c 100644
--- a/bandwidth-file-spec.txt
+++ b/bandwidth-file-spec.txt
@@ -33,7 +33,7 @@
     Nick Mathewson (nickm)
     Iain Learmonth (irl)
 
-1.3 Outline
+1.3. Outline
 
   The Tor directory protocol (dir-spec.txt [3]) sections 3.4.1
   and 3.4.2, use the term bandwidth measurements, to refer to what
@@ -644,7 +644,7 @@
 
 2.4. Implementation details
 
-2.4.1 Writing bandwidth files atomically
+2.4.1. Writing bandwidth files atomically
 
   To avoid inconsistent reads, implementations SHOULD write bandwidth files
   atomically. If the file is transferred from another host, it SHOULD be
diff --git a/cert-spec.txt b/cert-spec.txt
index 9dde874..e96188b 100644
--- a/cert-spec.txt
+++ b/cert-spec.txt
@@ -23,7 +23,7 @@
    signed document is prefixed with a personalization string, which
    will be different in each case.
 
-1.2 Integer encoding
+1.2. Integer encoding
 
    Network byte order (big-endian) is used to encode all integer values
    in Ed25519 certificates unless explicitly specified otherwise.
diff --git a/control-spec.txt b/control-spec.txt
index e4d6783..ec43516 100644
--- a/control-spec.txt
+++ b/control-spec.txt
@@ -3932,7 +3932,7 @@
   0.4.0.x): Tor could report having internal paths only; see Section
   5.6]
 
-5.6 Bootstrap phases reported by older versions of Tor
+5.6. Bootstrap phases reported by older versions of Tor
 
   These phases were reported by Tor older than 0.4.0.x.  For newer
   versions of Tor, see Section 5.5.
diff --git a/dir-list-spec.txt b/dir-list-spec.txt
index 56ee0e6..e152c2d 100644
--- a/dir-list-spec.txt
+++ b/dir-list-spec.txt
@@ -162,7 +162,7 @@
    The list header consists of a number of key-value pairs, embedded in
    C-style comments.
 
-2.2.1 List Header Format
+2.2.1. List Header Format
 
      "/*" SP+ "type=" Keyword SP+ "*/" SP* NL
 
@@ -234,7 +234,7 @@
    Future releases may arbitrarily change the content of this section.
    Parsers MUST NOT rely on a version increment when the format changes.
 
-2.3.1 List Generation Format
+2.3.1. List Generation Format
 
    In general, parsers MUST NOT rely on the format of this section.
 
@@ -261,7 +261,7 @@
    these lists after parsing them, and applies the DirAuthorityFallbackRate
    to their weights.)
 
-2.4.1 Directory Entry Format
+2.4.1. Directory Entry Format
 
      If a directory entry does not conform to this format, the entry SHOULD
      be ignored by parsers.
diff --git a/dir-spec.txt b/dir-spec.txt
index 2a38d3b..6fa24f1 100644
--- a/dir-spec.txt
+++ b/dir-spec.txt
@@ -2674,7 +2674,7 @@
    IPv4 addresses (two /8 networks) were blocked.  The list is encoded
    as described in section 3.8.2.
 
-3.4.3 Serving bandwidth list files
+3.4.3. Serving bandwidth list files
 
    If an authority has used a bandwidth list file to generate a vote
    document it SHOULD make it available at
@@ -2969,7 +2969,7 @@
     half of the total authorities, and we do not already have it listed with
     some <id-Ed>, include it, but do not consider its Ed identity canonical.
 
-3.8.0.2 Deciding which descriptors to include
+3.8.0.2. Deciding which descriptors to include
 
    Deciding which descriptors to include.
 
diff --git a/gettor-spec.txt b/gettor-spec.txt
index 5255b76..f40b298 100644
--- a/gettor-spec.txt
+++ b/gettor-spec.txt
@@ -30,7 +30,7 @@
  GetTor instance.  Security and privacy considerations should be described on a
  per transport basis.
 
-2.1 Reference implementation
+2.1. Reference implementation
 
  We have implemented[0] a compliant GetTor that supports SMTP as a transport.
 
@@ -43,14 +43,14 @@
  it should offer the software as a list of packages and their subsequent
  descriptions.
 
-3.1 SMTP transport security considerations
+3.1. SMTP transport security considerations
 
  Any GetTor instance that offers SMTP as a transport should optionally
  implement the checking of DKIM signatures to ensure that email is not forged.
  Optionally GetTor should take an OpenPGP key from the user and encrypt the
  response with a blinded message.
 
-3.2 SMTP transport privacy considerations
+3.2. SMTP transport privacy considerations
 
  Any GetTor instance that offers SMTP as a transport must at least store the
  requester's address for the time that it takes to process a response. This
diff --git a/glossary.txt b/glossary.txt
index 767080d..6debe20 100644
--- a/glossary.txt
+++ b/glossary.txt
@@ -18,18 +18,18 @@ citing them authoritatively. ;)
       "OPTIONAL" in this document are to be interpreted as described in
       RFC 2119.
 
-1.0 Commonly used Tor configuration terms
+1.0. Commonly used Tor configuration terms
 
    ORPort  - Onion Router Port
    DirPort - Directory Port
 
-2.0 Tor network components
+2.0. Tor network components
 
-   2.1 Relays, aka OR (onion router)
+2.1. Relays, aka OR (onion router)
 
     [Style guide: prefer the term "Relay"]
 
-    2.1.1 Specific roles
+2.1.1. Specific roles
 
       Exit relay: The final hop in an exit circuit before traffic leaves
       the Tor network to connect to external servers.
@@ -57,11 +57,11 @@ citing them authoritatively. ;)
       Each party builds a three-hop circuit, meeting at the
       rendezvous point.
 
-   2.2 Client, aka OP (onion proxy)
+2.2. Client, aka OP (onion proxy)
 
     [Style: the "OP" and "onion proxy" terms are deprecated.]
 
-   2.3 Authorities:
+2.3. Authorities:
 
     Directory Authority: Nine total in the Tor network, operated by
     trusted individuals. Directory authorities define and serve the
@@ -79,7 +79,7 @@ citing them authoritatively. ;)
     the client can ask any directory cache that's listed in the directory
     information it has.)
 
-   2.4 Hidden Service:
+2.4. Hidden Service:
 
    A hidden service is a server that will only accept incoming
    connections via the hidden service protocol. Connection
@@ -87,7 +87,7 @@ citing them authoritatively. ;)
    service, allowing the hidden service to receive incoming connections,
    serve content, etc, while preserving its location anonymity.
 
-   2.5 Circuit:
+2.5. Circuit:
 
    An established path through the network, where cryptographic keys
    are negotiated using the ntor protocol or TAP (Tor Authentication
@@ -104,29 +104,29 @@ citing them authoritatively. ;)
     network. For example, a client could connect to a hidden service via
     an internal circuit.
 
-   2.6 Edge connection:
+2.6. Edge connection:
 
-   2.7 Consensus: The state of the Tor network, published every hour,
+2.7. Consensus: The state of the Tor network, published every hour,
      decided by a vote from the network's directory authorities. Clients
      fetch the consensus from directory authorities, fallback
      directories, or directory caches.
 
-   2.8 Descriptor: Each descriptor represents information about one
+2.8. Descriptor: Each descriptor represents information about one
     relay in the Tor network. The descriptor includes the relay's IP
     address, public keys, and other data. Relays send
     descriptors to directory authorities, who vote and publish a
     summary of them in the network consensus.
 
-3.0 Tor network protocols
+3.0. Tor network protocols
 
-    3.1 Link handshake
+3.1. Link handshake
 
       The link handshake establishes the TLS connection over which two
       Tor participants will send Tor cells.  This handshake also
       authenticates the participants to each other, possibly using Tor
       cells.
 
-    3.2 Circuit handshake
+3.2. Circuit handshake
 
       Circuit handshakes establish the hop-by-hop onion encryption
       that clients use to tunnel their application traffic.  The
@@ -155,12 +155,12 @@ citing them authoritatively. ;)
       contains the first part of the TAP or ntor key establishment
       handshake.
 
-    3.3 Hidden Service Protocol
+3.3. Hidden Service Protocol
 
-    3.4 Directory Protocol
+3.4. Directory Protocol
 
 
-4.0 General network definitions
+4.0. General network definitions
 
    Leaky Pipe Topology: The ability for the origin of a circuit to address
    relay cells to be addressed to any hop in the path of a circuit. In Tor,
diff --git a/padding-spec.txt b/padding-spec.txt
index fe9464c..b3e401a 100644
--- a/padding-spec.txt
+++ b/padding-spec.txt
@@ -406,7 +406,7 @@ the anonymity and load-balancing implications of their choices.
   depend on the type of guard used and are not an effective fingerprint for a
   network/guard-level adversary.
 
-3.3.2 Client-side onion service introduction circuit obfuscation
+3.3.2. Client-side onion service introduction circuit obfuscation
 
   Two circuit padding machines work to hide client-side introduction circuits:
   one machine at the origin, and one machine at the second hop of the circuit.
diff --git a/path-spec.txt b/path-spec.txt
index 15d9a3b..a79a4d6 100644
--- a/path-spec.txt
+++ b/path-spec.txt
@@ -363,7 +363,7 @@ of their choices.
    Since version 0.2.2.8-alpha, Tor attempts to learn when to give up on
    circuits based on network conditions.
 
-2.4.1 Distribution choice and parameter estimation
+2.4.1. Distribution choice and parameter estimation
 
    Based on studies of build times, we found that the distribution of
    circuit build times appears to be a Frechet distribution. However,
diff --git a/pt-spec.txt b/pt-spec.txt
index 121b8c2..bd4aec6 100644
--- a/pt-spec.txt
+++ b/pt-spec.txt
@@ -626,7 +626,7 @@ Table of Contents
 
       LOG SEVERITY=debug MESSAGE="Connected to bridge A"
 
-3.3.5 Pluggable Transport Status Message
+3.3.5. Pluggable Transport Status Message
 
    This message is for a client or server PT to be able to signal back to the
    parent process via stdout or stderr any status messages.
diff --git a/srv-spec.txt b/srv-spec.txt
index eaf2bda..6916020 100644
--- a/srv-spec.txt
+++ b/srv-spec.txt
@@ -224,7 +224,7 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt.
 
    Now we go through the phases of the protocol:
 
-3.1 Commitment Phase [COMMITMENTPHASE]
+3.1. Commitment Phase [COMMITMENTPHASE]
 
    The commit phase lasts from 00:00UTC to 12:00UTC.
 
@@ -257,7 +257,7 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt.
    authoritative commits they have received from each authority. Only one commit
    per authority must be considered trusted and active at a given time.
 
-3.2 Reveal Phase
+3.2. Reveal Phase
 
    The reveal phase lasts from 12:00UTC to 00:00UTC.
 
diff --git a/tor-fw-helper-spec.txt b/tor-fw-helper-spec.txt
index fdc34b1..f842953 100644
--- a/tor-fw-helper-spec.txt
+++ b/tor-fw-helper-spec.txt
@@ -20,7 +20,7 @@
  tor-fw-helper is a program that implements basic port forwarding requests; it
  may be used alone or called from Tor itself.
 
-2.1 Output format
+2.1. Output format
 
 2.1.1. Motivation
 
diff --git a/tor-spec.txt b/tor-spec.txt
index 21abfdf..0d8ca10 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -1907,7 +1907,7 @@ see tor-design.pdf.
    RELAY_DATA cell within one increment window. In other word, every 100 cells
    (increment), random bytes should be introduced in at least one cell.
 
-7.3.1 SENDME Cell Format
+7.3.1. SENDME Cell Format
 
    A circuit-level RELAY_SENDME cell always has its StreamID=0.