[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] fix erroneous header numbering punctuation
commit a3fd19302312d44257f175bded3551bc1397ced6
Author: Hans-Christoph Steiner <hans@xxxxxxx>
Date: Tue Nov 26 20:58:54 2019 +0100
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
---
bandwidth-file-spec.txt | 4 ++--
cert-spec.txt | 2 +-
control-spec.txt | 2 +-
dir-list-spec.txt | 6 +++---
dir-spec.txt | 4 ++--
gettor-spec.txt | 6 +++---
glossary.txt | 34 +++++++++++++++++-----------------
padding-spec.txt | 2 +-
path-spec.txt | 2 +-
pt-spec.txt | 2 +-
srv-spec.txt | 4 ++--
tor-fw-helper-spec.txt | 2 +-
tor-spec.txt | 2 +-
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.
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits