aboutsummaryrefslogtreecommitdiff
path: root/spec/control-spec/implementation-notes.md
diff options
context:
space:
mode:
Diffstat (limited to 'spec/control-spec/implementation-notes.md')
-rw-r--r--spec/control-spec/implementation-notes.md18
1 files changed, 9 insertions, 9 deletions
diff --git a/spec/control-spec/implementation-notes.md b/spec/control-spec/implementation-notes.md
index e69f755..37ce9d6 100644
--- a/spec/control-spec/implementation-notes.md
+++ b/spec/control-spec/implementation-notes.md
@@ -16,7 +16,7 @@ to another file specified in the 'CookieAuthFile' option). To
authenticate, the controller must demonstrate that it can read the
contents of the cookie file:
-* Current versions of Tor support cookie authentication
+- Current versions of Tor support cookie authentication
```text
using the "COOKIE" authentication method: the controller sends the
@@ -101,7 +101,7 @@ Generally, these options make Tor unusable by disabling a portion of Tor's
normal operations. Unless a controller provides replacement functionality
to fill this gap, Tor will not correctly handle user requests.
-__AllDirActionsPrivate
+\_\_AllDirActionsPrivate
```text
If true, Tor will try to launch all directory operations through
@@ -214,8 +214,8 @@ fails.
Bootstrap phases can be viewed as belonging to one of three stages:
1. Initial connection to a Tor relay or bridge
-2. Obtaining directory information
-3. Building an application circuit
+1. Obtaining directory information
+1. Building an application circuit
Tor doesn't specifically enter Stage 1; that is a side effect of
other actions that Tor is taking. Tor could be making a connection
@@ -240,7 +240,7 @@ of Tor building circuits for some purpose or other. In a typical
client, Tor builds predicted circuits to provide lower latency for
application connection requests. In Stage 3, Tor might make new
connections to relays or bridges that it did not connect to in Stage
-1.
+1\.
<a id="control-spec.txt-5.5.2"></a>
@@ -540,7 +540,7 @@ as indicated above. When bootstrap completes, Tor will be ready to handle
an application requesting an internal circuit to hidden services at
".onion" addresses.
-If a future consensus contains Exits, exit circuits may become available.]
+If a future consensus contains Exits, exit circuits may become available.\]
Phase 0:
tag=starting summary="Starting"
@@ -649,7 +649,7 @@ indicate partial steps.
```
Phase 80:
-tag=conn_or summary="Connecting to the Tor network[ internally]"
+tag=conn_or summary="Connecting to the Tor network\[ internally\]"
Once we have a valid consensus and enough relay descriptors, we choose
entry guard(s) and start trying to build some circuits. This step
@@ -685,7 +685,7 @@ handshake with a Tor relay.
```
Phase 90:
-tag=circuit_create summary="Establishing a[n internal] Tor circuit"
+tag=circuit_create summary="Establishing a\[n internal\] Tor circuit"
Once we've finished our TLS handshake with the first hop of a circuit,
we will set about trying to make some 3-hop circuits in case we need them
@@ -718,4 +718,4 @@ as indicated above. At this stage, Tor will be ready to handle an
application requesting an internal circuit to hidden services at ".onion"
addresses.
-If a future consensus contains Exits, exit circuits may become available.]
+If a future consensus contains Exits, exit circuits may become available.\]