Run mdformat on the spec files.

5 files changed, 86 insertions, 86 deletions

diff --git a/spec/control-spec/commands.md b/spec/control-spec/commands.md
index f59a548..d087473 100644
--- a/spec/control-spec/commands.md
+++ b/spec/control-spec/commands.md
@@ -52,7 +52,7 @@ its default value (if any), and then assign the String provided.
 Typically the String is left empty, to simply set an option back to
 its default. The syntax is:
 
-"RESETCONF" 1*(SP keyword ["=" String]) CRLF
+"RESETCONF" 1\*(SP keyword \["=" String\]) CRLF
 
 Otherwise it behaves like SETCONF above.
 
@@ -63,7 +63,7 @@ Otherwise it behaves like SETCONF above.
 Request the value of zero or more configuration variable(s).
 The syntax is:
 
-"GETCONF" *(SP keyword) CRLF
+"GETCONF" \*(SP keyword) CRLF
 
 If all of the listed keywords exist in the Tor configuration, Tor replies
 with a series of reply lines of the form:
@@ -101,9 +101,9 @@ HiddenServiceVersion, and HiddenserviceAuthorizeClient option settings.
 Request the server to inform the client about interesting events.  The
 syntax is:
 
-"SETEVENTS" [SP "EXTENDED"] *(SP EventCode) CRLF
+"SETEVENTS" \[SP "EXTENDED"\] \*(SP EventCode) CRLF
 
-EventCode = 1*(ALPHA / "_")  (see section 4.1.x for event types)
+EventCode = 1\*(ALPHA / "\_")  (see section 4.1.x for event types)
 
 Any events _not_ listed in the SETEVENTS line are turned off; thus, sending
 SETEVENTS with an empty body turns off all event reporting.
@@ -127,7 +127,7 @@ Each event is described in more detail in Section 4.1.
 
 Sent from the client to the server.  The syntax is:
 
-"AUTHENTICATE" [ SP 1*HEXDIG / QuotedString ] CRLF
+"AUTHENTICATE" \[ SP 1\*HEXDIG / QuotedString \] CRLF
 
 This command is used to authenticate to the server. The provided string is
 one of the following:
@@ -174,7 +174,7 @@ connection after an authentication failure.)
 
 Sent from the client to the server.  The syntax is:
 
-"SAVECONF" [SP "FORCE"] CRLF
+"SAVECONF" \[SP "FORCE"\] CRLF
 
 Instructs the server to write out its config options into its torrc. Server
 returns "250 OK" if successful, or "551 Unable to write configuration
@@ -252,7 +252,7 @@ signal that have them.
 
 Sent from the client to the server.  The syntax is:
 
-"MAPADDRESS" 1*(Address "=" Address SP) CRLF
+"MAPADDRESS" 1\*(Address "=" Address SP) CRLF
 
 The first address in each pair is an "original" address; the second is a
 "replacement" address.  The client sends this message to the server in
@@ -339,7 +339,7 @@ Example:
 
 Sent from the client to the server.  The syntax is as for GETCONF:
 
-"GETINFO" 1*(SP keyword) CRLF
+"GETINFO" 1\*(SP keyword) CRLF
 
 Unlike GETCONF, this message is used for data that are not stored in the Tor
 configuration file, and that may be longer than a single line.  On success,
@@ -1034,7 +1034,7 @@ historical interest.
 
 Sent from the client to the server.  The syntax is:
 
-"ATTACHSTREAM" SP StreamID SP CircuitID [SP "HOP=" HopNum] CRLF
+"ATTACHSTREAM" SP StreamID SP CircuitID \[SP "HOP=" HopNum\] CRLF
 
 This message informs the server that the specified stream should be
 associated with the specified circuit.  Each stream may be associated with
@@ -1061,8 +1061,8 @@ that turns out to be a problem.}
 
 {Implementation note: By default, Tor automatically attaches streams to
 circuits itself, unless the configuration variable
-"__LeaveStreamsUnattached" is set to "1".  Attempting to attach streams
-via TC when "__LeaveStreamsUnattached" is false may cause a race between
+"\_\_LeaveStreamsUnattached" is set to "1".  Attempting to attach streams
+via TC when "\_\_LeaveStreamsUnattached" is false may cause a race between
 Tor and the controller, as both attempt to attach streams to circuits.}
 
 {Implementation note: You can try to attachstream to a stream that
@@ -1105,7 +1105,7 @@ is added, Tor replies with "250 OK".
 
 Sent from the client to the server. The syntax is:
 
-"REDIRECTSTREAM" SP StreamID SP Address [SP Port] CRLF
+"REDIRECTSTREAM" SP StreamID SP Address \[SP Port\] CRLF
 
 Tells the server to change the exit address on the specified stream.  If
 Port is specified, changes the destination port as well.  No remapping
@@ -1123,7 +1123,7 @@ Tor replies with "250 OK" on success.
 
 Sent from the client to the server.  The syntax is:
 
-"CLOSESTREAM" SP StreamID SP Reason *(SP Flag) CRLF
+"CLOSESTREAM" SP StreamID SP Reason \*(SP Flag) CRLF
 
 Tells the server to close the specified stream.  The reason should be one
 of the Tor RELAY_END reasons given in tor-spec.txt, as a decimal.  Flags is
@@ -1227,7 +1227,7 @@ request (or reverse lookup if "mode=reverse" is specified).  Note that the
 request is done in the background: to see the answers, your controller will
 need to listen for ADDRMAP events; see 4.1.7 below.
 
-[Added in Tor 0.2.0.3-alpha]
+\[Added in Tor 0.2.0.3-alpha\]
 
 <a id="control-spec.txt-3.21"></a>
 
@@ -1235,11 +1235,11 @@ need to listen for ADDRMAP events; see 4.1.7 below.
 
 The syntax is:
 
-"PROTOCOLINFO" *(SP PIVERSION) CRLF
+"PROTOCOLINFO" \*(SP PIVERSION) CRLF
 
 The server reply format is:
 
-"250-PROTOCOLINFO" SP PIVERSION CRLF *InfoLine "250 OK" CRLF
+"250-PROTOCOLINFO" SP PIVERSION CRLF \*InfoLine "250 OK" CRLF
 
 InfoLine = AuthLine / VersionLine / OtherLine
 
@@ -1301,10 +1301,10 @@ a future version of Tor.
 
 The VERSION line contains the Tor version.
 
-[Unlike other commands besides AUTHENTICATE, PROTOCOLINFO may be used (but
-only once!) before AUTHENTICATE.]
+\[Unlike other commands besides AUTHENTICATE, PROTOCOLINFO may be used (but
+only once!) before AUTHENTICATE.\]
 
-[PROTOCOLINFO was not supported before Tor 0.2.0.5-alpha.]
+\[PROTOCOLINFO was not supported before Tor 0.2.0.5-alpha.\]
 
 <a id="control-spec.txt-3.22"></a>
 
@@ -1318,7 +1318,7 @@ This command allows a controller to upload the text of a config file
 to Tor over the control port.  This config file is then loaded as if
 it had been read from disk.
 
-[LOADCONF was added in Tor 0.2.1.1-alpha.]
+\[LOADCONF was added in Tor 0.2.1.1-alpha.\]
 
 <a id="control-spec.txt-3.23"></a>
 
@@ -1340,7 +1340,7 @@ want to ensure a clean shutdown--and you should!--then send "SIGNAL
 SHUTDOWN" and wait for the Tor process to close.)
 
 This command is intended to be used with the
-__OwningControllerProcess configuration option.  A controller that
+\_\_OwningControllerProcess configuration option.  A controller that
 starts a Tor process which the user cannot easily control or stop
 should 'own' that Tor process:
 
@@ -1422,10 +1422,10 @@ will accept is:
                 CookieString | ClientNonce | ServerNonce)
 ```
 
-[Unlike other commands besides AUTHENTICATE, AUTHCHALLENGE may be
-used (but only once!) before AUTHENTICATE.]
+\[Unlike other commands besides AUTHENTICATE, AUTHCHALLENGE may be
+used (but only once!) before AUTHENTICATE.\]
 
-[AUTHCHALLENGE was added in Tor 0.2.3.13-alpha.]
+\[AUTHCHALLENGE was added in Tor 0.2.3.13-alpha.\]
 
 <a id="control-spec.txt-3.25"></a>
 
@@ -1440,7 +1440,7 @@ lightly; it can increase vulnerability to tracking attacks over time.
 
 Tor replies with "250 OK" on success.
 
-[DROPGUARDS was added in Tor 0.2.5.2-alpha.]
+\[DROPGUARDS was added in Tor 0.2.5.2-alpha.\]
 
 <a id="control-spec.txt-3.26"></a>
 
@@ -1496,8 +1496,8 @@ Examples are:
      S: 250 OK
 ```
 
-[HSFETCH was added in Tor 0.2.7.1-alpha]
-[HS v3 support added 0.4.1.1-alpha]
+\[HSFETCH was added in Tor 0.2.7.1-alpha\]
+\[HS v3 support added 0.4.1.1-alpha\]
 
 <a id="control-spec.txt-3.27"></a>
 
@@ -1620,14 +1620,14 @@ RSAPrivateKey, with all newlines removed. For a "ED25519-V3" key is
 the Base64 encoding of the concatenation of the 32-byte ed25519 secret
 scalar in little-endian and the 32-byte ed25519 PRF secret.)
 
-[Note: The ED25519-V3 format is not the same as, e.g., SUPERCOP
+\[Note: The ED25519-V3 format is not the same as, e.g., SUPERCOP
 ed25519/ref, which stores the concatenation of the 32-byte ed25519
 hash seed concatenated with the 32-byte public key, and which derives
 the secret scalar and PRF secret by expanding the hash seed with
 SHA-512.  Our key blinding scheme is incompatible with storing
 private keys as seeds, so we store the secret scalar alongside the
 PRF secret, and just pay the cost of recomputing the public key when
-importing an ED25519-V3 key.]
+importing an ED25519-V3 key.\]
 
 Examples:
 
@@ -1675,12 +1675,12 @@ Examples:
      S: 250 OK
 ```
 
-[ADD_ONION was added in Tor 0.2.7.1-alpha.]
-[MaxStreams and MaxStreamsCloseCircuit were added in Tor 0.2.7.2-alpha]
-[ClientAuth was added in Tor 0.2.9.1-alpha. It is v2 only.]
-[NonAnonymous was added in Tor 0.2.9.3-alpha.]
-[HS v3 support added 0.3.3.1-alpha]
-[ClientV3Auth support added 0.4.6.1-alpha]
+\[ADD_ONION was added in Tor 0.2.7.1-alpha.\]
+\[MaxStreams and MaxStreamsCloseCircuit were added in Tor 0.2.7.2-alpha\]
+\[ClientAuth was added in Tor 0.2.9.1-alpha. It is v2 only.\]
+\[NonAnonymous was added in Tor 0.2.9.3-alpha.\]
+\[HS v3 support added 0.3.3.1-alpha\]
+\[ClientV3Auth support added 0.4.6.1-alpha\]
 
 <a id="control-spec.txt-3.28"></a>
 
@@ -1711,8 +1711,8 @@ removed via "DEL_ONION".
 Tor replies with "250 OK" on success, or a 512 if there are an invalid
 number of arguments, or a 552 if it doesn't recognize the ServiceID.
 
-[DEL_ONION was added in Tor 0.2.7.1-alpha.]
-[HS v3 support added 0.3.3.1-alpha]
+\[DEL_ONION was added in Tor 0.2.7.1-alpha.\]
+\[HS v3 support added 0.3.3.1-alpha\]
 
 <a id="control-spec.txt-3.29"></a>
 
@@ -1836,7 +1836,7 @@ On success "250 OK" is returned. Otherwise, the following error codes exist:
 
 The syntax is:
 
-"ONION_CLIENT_AUTH_VIEW" [SP HSAddress] CRLF
+"ONION_CLIENT_AUTH_VIEW" \[SP HSAddress\] CRLF
 
 Tells the connected Tor to list all the stored client-side v3 client auth
 credentials for "HSAddress". If no "HSAddress" is provided, list all the
@@ -1869,7 +1869,7 @@ On success "250 OK" is returned. Otherwise, the following error codes exist:
 
 512 - Syntax error in "HSAddress".
 
-[ONION_CLIENT_AUTH_VIEW was added in Tor 0.4.3.1-alpha]
+\[ONION_CLIENT_AUTH_VIEW was added in Tor 0.4.3.1-alpha\]
 
 <a id="control-spec.txt-3.33"></a>
 
@@ -1890,7 +1890,7 @@ does nothing.
 The controller can call TAKEOWNERSHIP again to re-establish
 ownership.
 
-[DROPOWNERSHIP was added in Tor 0.4.0.0-alpha]
+\[DROPOWNERSHIP was added in Tor 0.4.0.0-alpha\]
 
 <a id="control-spec.txt-3.34"></a>
 
@@ -1907,4 +1907,4 @@ lightly; it can increase vulnerability to tracking attacks over time.
 Tor replies with "250 OK" on success. Tor also emits the BUILDTIMEOUT_SET
 RESET event right after this "250 OK".
 
-[DROPTIMEOUTS was added in Tor 0.4.5.0-alpha.]
+\[DROPTIMEOUTS was added in Tor 0.4.5.0-alpha.\]
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.\]
diff --git a/spec/control-spec/message-format.md b/spec/control-spec/message-format.md
index 2e3115b..5a1a6ad 100644
--- a/spec/control-spec/message-format.md
+++ b/spec/control-spec/message-format.md
@@ -13,7 +13,7 @@ We use the following nonterminals from RFC 2822: atom, qcontent
 
 We define the following general-use nonterminals:
 
-QuotedString = DQUOTE *qcontent DQUOTE
+QuotedString = DQUOTE \*qcontent DQUOTE
 
 There are explicitly no limits on line length.  All 8-bit characters
 are permitted unless explicitly disallowed.  In QuotedStrings,
@@ -28,13 +28,13 @@ Controllers SHOULD always send CRLF.
 
 ### Notes on an escaping bug
 
-CString = DQUOTE *qcontent DQUOTE
+CString = DQUOTE \*qcontent DQUOTE
 
 Note that although these nonterminals have the same grammar, they
 are interpreted differently.  In a QuotedString, a backslash
 followed by any character represents that character.  But
-in a CString, the escapes "\n", "\t", "\r", and the octal escapes
-"\0" ... "\377" represent newline, tab, carriage return, and the
+in a CString, the escapes "\\n", "\\t", "\\r", and the octal escapes
+"\\0" ... "\\377" represent newline, tab, carriage return, and the
 256 possible octet values respectively.
 
 The use of CString in this document reflects a bug in Tor;
@@ -101,11 +101,11 @@ Tor to the controller are guaranteed to share the same status
 code. Specific replies are mentioned below in section 3, and
 described more fully in section 4.
 
-[Compatibility note:  versions of Tor before 0.2.0.3-alpha sometimes
-generate AsyncReplies of the form "*(MidReplyLine / DataReplyLine)".
+\[Compatibility note:  versions of Tor before 0.2.0.3-alpha sometimes
+generate AsyncReplies of the form "\*(MidReplyLine / DataReplyLine)".
 This is incorrect, but controllers that need to work with these
 versions of Tor should be prepared to get multi-line AsyncReplies with
-the final line (usually "650 OK") omitted.]
+the final line (usually "650 OK") omitted.\]
 
 <a id="control-spec.txt-2.4"></a>
 
@@ -132,13 +132,13 @@ CRLF = CR LF
 ; The tokens that implement the above follow:
 
 ServerSpec = LongName / Nickname
-LongName   = Fingerprint [ "~" Nickname ]
+LongName   = Fingerprint \[ "~" Nickname \]
 
 ; For tors older than 0.3.1.3-alpha, LongName may have included an equal
 ; sign ("=") in lieu of a tilde ("~").  The presence of an equal sign
 ; denoted that the OR possessed the "Named" flag:
 
-LongName   = Fingerprint [ ( "=" / "~" ) Nickname ]
+LongName   = Fingerprint \[ ( "=" / "~" ) Nickname \]
 
 Fingerprint = "$" 40*HEXDIG
 NicknameChar = "a"-"z" / "A"-"Z" / "0" - "9"
@@ -167,7 +167,7 @@ Address = ip4-address / ip6-address / hostname   (XXXX Define these)
 CmdData = *DataLine "." CRLF
 DataLine = CRLF / "." 1*LineItem CRLF / NonDotItem *LineItem CRLF
 LineItem = NonCR / 1*CR NonCRLF
-NonDotItem = NonDotCR / 1*CR NonCRLF
+NonDotItem = NonDotCR / 1\*CR NonCRLF
 
 ; ISOTime, ISOTime2, and ISOTime2Frac are time formats as specified in
 ; ISO8601.
@@ -178,8 +178,8 @@ IsoDatePart = 4*DIGIT "-" 2*DIGIT "-" 2*DIGIT
 IsoTimePart = 2*DIGIT ":" 2*DIGIT ":" 2*DIGIT
 ISOTime  = IsoDatePart " " IsoTimePart
 ISOTime2 = IsoDatePart "T" IsoTimePart
-ISOTime2Frac = IsoTime2 [ "." 1*DIGIT ]
+ISOTime2Frac = IsoTime2 \[ "." 1\*DIGIT \]
 
 ; Numbers
 LeadingDigit = "1" - "9"
-UInt = LeadingDigit *Digit
+UInt = LeadingDigit \*Digit
diff --git a/spec/control-spec/protocol-outline.md b/spec/control-spec/protocol-outline.md
index feeef1b..0329b1d 100644
--- a/spec/control-spec/protocol-outline.md
+++ b/spec/control-spec/protocol-outline.md
@@ -33,7 +33,7 @@ where servers speaking a future version of this protocol may insert
 new data, and note that clients should/must "tolerate" unexpected
 elements in these places.  There are two ways that we do this:
 
-* Adding a new field to a message:
+- Adding a new field to a message:
 
 ```text
     For example, we might say "This message has three space-separated
diff --git a/spec/control-spec/replies.md b/spec/control-spec/replies.md
index c55635c..c7b1ab7 100644
--- a/spec/control-spec/replies.md
+++ b/spec/control-spec/replies.md
@@ -121,11 +121,11 @@ Tor 0.2.2.x and later), then each event line as specified below may be
 followed by additional arguments and additional lines.  Additional
 lines will be of the form:
 
-"650" ("-"/" ") KEYWORD ["=" ARGUMENTS] CRLF
+"650" ("-"/" ") KEYWORD \["=" ARGUMENTS\] CRLF
 
 Additional arguments will be of the form
 
-SP KEYWORD ["=" ( QuotedString / * NonSpDquote ) ]
+SP KEYWORD \["=" ( QuotedString / * NonSpDquote ) \]
 
 Clients MUST tolerate events with arguments and keywords they do not
 recognize, and SHOULD process those events as if any unrecognized
@@ -542,9 +542,9 @@ The syntax is:
      Num = 1*DIGIT
 ```
 
-BytesRead and BytesWritten are the totals. [In a future Tor version,
+BytesRead and BytesWritten are the totals. \[In a future Tor version,
 we may also include a breakdown of the connection types that used
-bandwidth this second (not implemented yet).]
+bandwidth this second (not implemented yet).\]
 
 <a id="control-spec.txt-4.1.5"></a>
 
@@ -615,7 +615,7 @@ Syntax:
 
 Error and UTCExpiry are only provided if extended events are enabled.
 The values for Error are mostly useless.  Future values will be
-chosen to match 1*(ALNUM / "_"); the "Unable to launch resolve request"
+chosen to match 1\*(ALNUM / "\_"); the "Unable to launch resolve request"
 value is a bug in Tor before 0.2.4.7-alpha.
 
 Expiry is expressed as the local time (rather than UTC).  This is a bug,
@@ -632,7 +632,7 @@ the address was resolved.
 
 ### Descriptors uploaded to us in our role as authoritative dirserver
 
-[NOTE: This feature was removed in Tor 0.3.2.1-alpha.]
+\[NOTE: This feature was removed in Tor 0.3.2.1-alpha.\]
 
 Tor generates this event when it's a directory authority, and
 somebody has just uploaded a server descriptor.
@@ -662,7 +662,7 @@ Syntax:
 
 "650" SP "DESCCHANGED" CRLF
 
-[First added in 0.1.2.2-alpha.]
+\[First added in 0.1.2.2-alpha.\]
 
 <a id="control-spec.txt-4.1.10"></a>
 
@@ -1151,7 +1151,7 @@ The Status values are:
 
 Syntax:
 
-"650" "+" "NS" CRLF 1*NetworkStatus "." CRLF "650" SP "OK" CRLF
+"650" "+" "NS" CRLF 1\*NetworkStatus "." CRLF "650" SP "OK" CRLF
 
 The event is used whenever our local view of a relay status changes.
 This happens when we get a new v3 consensus (in which case the entries
@@ -1159,7 +1159,7 @@ we see are a duplicate of what we see in the NEWCONSENSUS event,
 below), but it also happens when we decide to mark a relay as up or
 down in our local status, for example based on connection attempts.
 
-[First added in 0.1.2.3-alpha]
+\[First added in 0.1.2.3-alpha\]
 
 <a id="control-spec.txt-4.1.13"></a>
 
@@ -1243,7 +1243,7 @@ every relay in the consensus. NEWCONSENSUS is a separate event from the
 NS event, because the list here represents every usable relay: so any
 relay *not* mentioned in this list is implicitly no longer recommended.
 
-[First added in 0.2.1.13-alpha]
+\[First added in 0.2.1.13-alpha\]
 
 <a id="control-spec.txt-4.1.16"></a>
 
@@ -1285,7 +1285,7 @@ of build times Tor stores (NCIRCUITS_TO_OBSERVE).
 The Timeout itself is provided in milliseconds. Internally, Tor rounds
 this value to the nearest second before using it.
 
-[First added in 0.2.2.7-alpha]
+\[First added in 0.2.2.7-alpha\]
 
 <a id="control-spec.txt-4.1.17"></a>
 
@@ -1309,7 +1309,7 @@ semantics of the signals here.
 Note that the HALT (SIGTERM) and SHUTDOWN (SIGINT) signals do not currently
 generate any event.
 
-[First added in 0.2.3.1-alpha]
+\[First added in 0.2.3.1-alpha\]
 
 <a id="control-spec.txt-4.1.18"></a>
 
@@ -1317,7 +1317,7 @@ generate any event.
 
 The syntax is:
 
-StartReplyLine *(MidReplyLine) EndReplyLine
+StartReplyLine \*(MidReplyLine) EndReplyLine
 
 ```text
      StartReplyLine = "650-CONF_CHANGED" CRLF
@@ -1356,7 +1356,7 @@ purpose.
 
 Other fields are as specified in section 4.1.1 above.
 
-[First added in 0.2.3.11-alpha]
+\[First added in 0.2.3.11-alpha\]
 
 <a id="control-spec.txt-4.1.20"></a>
 
@@ -1407,7 +1407,7 @@ These events are generated about once per second per connection; no
 events are generated for connections that have not read or written.
 These events are only generated if TestingTorNetwork is set.
 
-[First added in 0.2.5.2-alpha]
+\[First added in 0.2.5.2-alpha\]
 
 <a id="control-spec.txt-4.1.22"></a>
 
@@ -1477,12 +1477,12 @@ These events are generated about once per second per circuit; no events
 are generated for circuits that had no attached stream writing or
 reading.
 
-[First added in 0.2.5.2-alpha]
+\[First added in 0.2.5.2-alpha\]
 
-[DELIVERED_READ, OVERHEAD_READ, DELIVERED_WRITTEN, and OVERHEAD_WRITTEN
-were added in Tor 0.3.4.0-alpha]
+\[DELIVERED_READ, OVERHEAD_READ, DELIVERED_WRITTEN, and OVERHEAD_WRITTEN
+were added in Tor 0.3.4.0-alpha\]
 
-[SS, CWND, RTT, and MIN_RTT were added in Tor 0.4.7.5-alpha]
+\[SS, CWND, RTT, and MIN_RTT were added in Tor 0.4.7.5-alpha\]
 
 <a id="control-spec.txt-4.1.23"></a>
 
@@ -1554,7 +1554,7 @@ These events are generated about once per second per circuit; no
 events are generated for circuits that have not added or processed any
 cell.  These events are only generated if TestingTorNetwork is set.
 
-[First added in 0.2.5.2-alpha]
+\[First added in 0.2.5.2-alpha\]
 
 <a id="control-spec.txt-4.1.24"></a>
 
@@ -1603,7 +1603,7 @@ at LastRefill in order not to report empty times more than once.
 
 These events are only generated if TestingTorNetwork is set.
 
-[First added in 0.2.5.2-alpha]
+\[First added in 0.2.5.2-alpha\]
 
 <a id="control-spec.txt-4.1.25"></a>
 
@@ -1714,8 +1714,8 @@ takes to fetch something over the Tor network. This can be between a
 couple of seconds up to 60 seconds (not a hard limit). But, in any cases,
 this event will reply either the descriptor's content or an empty one.
 
-[HS_DESC_CONTENT was added in Tor 0.2.7.1-alpha]
-[HS v3 support added 0.3.3.1-alpha]
+\[HS_DESC_CONTENT was added in Tor 0.2.7.1-alpha\]
+\[HS v3 support added 0.3.3.1-alpha\]
 
 <a id="control-spec.txt-4.1.27"></a>