Update more things that looked like html tags in the markdown

3 files changed, 21 insertions, 17 deletions

diff --git a/spec/dir-spec/directory-cache-operation.md b/spec/dir-spec/directory-cache-operation.md
index 6003d64..ed14fc2 100644
--- a/spec/dir-spec/directory-cache-operation.md
+++ b/spec/dir-spec/directory-cache-operation.md
@@ -62,12 +62,12 @@ descriptor seemed newest.)
 Directory mirrors should fetch, cache, and serve each microdescriptor
 from the authorities.
 
-The microdescriptors with base64 hashes <D1>,<D2>,<D3> are available
+The microdescriptors with base64 hashes `<D1>`, `<D2>`, `<D3>` are available
 at:
 
-http://<hostname>/tor/micro/d/<D1>-<D2>-<D3>[.z]
+`http://<hostname>/tor/micro/d/<D1>-<D2>-<D3>[.z]`
 
-<Dn> are base64 encoded with trailing =s omitted for size and for
+`<Dn>` are base64 encoded with trailing =s omitted for size and for
 consistency with the microdescriptor consensus format.  -s are used
 instead of +s to separate items, since the + character is used in
 base64 encoding.
@@ -143,8 +143,10 @@ send that diff instead of the specified consensus.
 
 Caches also serve diffs from the URIs:
 
+```
 /tor/status-vote/current/consensus/diff/<HASH>/<FPRLIST>.z
 /tor/status-vote/current/consensus-<FLAVOR>/diff/<HASH>/<FPRLIST>.z
+```
 
 where FLAVOR is the consensus flavor, defaulting to "ns", and
 FPRLIST is +-separated list of recognized authority identity
diff --git a/spec/dir-spec/exchanging-votes.md b/spec/dir-spec/exchanging-votes.md
index 7c42ad4..4bc6740 100644
--- a/spec/dir-spec/exchanging-votes.md
+++ b/spec/dir-spec/exchanging-votes.md
@@ -22,11 +22,11 @@ An authority SHOULD publish its vote immediately at the start of each voting
 period (minus VoteSeconds+DistSeconds).  It does this by making it
 available at
 
-http://<hostname>/tor/status-vote/next/authority.z
+`http://<hostname>/tor/status-vote/next/authority.z`
 
 and sending it in an HTTP POST request to each other authority at the URL
 
-http://<hostname>/tor/post/vote
+`http://<hostname>/tor/post/vote`
 
 If, at the start of the voting period, minus DistSeconds, an authority
 does not have a current statement from another authority, the first
@@ -35,14 +35,14 @@ authority downloads the other's statement.
 Once an authority has a vote from another authority, it makes it available
 at
 
-http://<hostname>/tor/status-vote/next/<fp>.z
+`http://<hostname>/tor/status-vote/next/<fp>.z`
 
 where <fp> is the fingerprint of the other authority's identity key.
 And at
 
-http://<hostname>/tor/status-vote/next/d/<d>.z
+`http://<hostname>/tor/status-vote/next/d/<d>.z`
 
-where <d> is the digest of the vote document.
+where `<d>` is the digest of the vote document.
 
 Also, once an authority receives a vote from another authority, it
 examines it for new descriptors and fetches them from that authority.
diff --git a/spec/dir-spec/serving-bandwidth-list-files.md b/spec/dir-spec/serving-bandwidth-list-files.md
index 8e7f970..531dc2b 100644
--- a/spec/dir-spec/serving-bandwidth-list-files.md
+++ b/spec/dir-spec/serving-bandwidth-list-files.md
@@ -4,7 +4,7 @@
 If an authority has used a bandwidth list file to generate a vote
 document it SHOULD make it available at
 
-http://<hostname>/tor/status-vote/next/bandwidth.z
+`http://<hostname>/tor/status-vote/next/bandwidth.z`
 
 at the start of each voting period.
 
@@ -15,7 +15,7 @@ authorities available.
 If an authority makes this file available, it MUST be the bandwidth file
 used to create the vote document available at
 
-http://<hostname>/tor/status-vote/next/authority.z
+`http://<hostname>/tor/status-vote/next/authority.z`
 
 To avoid inconsistent reads, authorities SHOULD only read the bandwidth
 file once per voting period. Further processing and serving SHOULD use a
@@ -84,7 +84,7 @@ Given a set of votes, authorities compute the contents of the consensus.
 The consensus status, along with as many signatures as the server
 currently knows (see section 3.10 below), should be available at
 
-http://<hostname>/tor/status-vote/next/consensus.z
+`http://<hostname>/tor/status-vote/next/consensus.z`
 
 The contents of the consensus document are as follows:
 
@@ -150,7 +150,7 @@ vote's dir-source line.
           of the authorities who care about that flag.
 
         * Two router entries are "the same" if they have the same
-          <descriptor digest, published time, nickname, IP, ports> tuple.
+          (descriptor digest, published time, nickname, IP, ports> tuple.
           We choose the tuple for a given router as whichever tuple appears
           for that router in the most votes.  We break ties first in favor of
           the more recently published, then in favor of smaller server
@@ -758,14 +758,14 @@ Once an authority has computed and signed a consensus network status, it
 should send its detached signature to each other authority in an HTTP POST
 request to the URL:
 
-http://<hostname>/tor/post/consensus-signature
+`http://<hostname>/tor/post/consensus-signature`
 
 [XXX Note why we support push-and-then-pull.]
 
 All of the detached signatures it knows for consensus status should be
 available at:
 
-http://<hostname>/tor/status-vote/next/consensus-signatures.z
+`http://<hostname>/tor/status-vote/next/consensus-signatures.z`
 
 Assuming full connectivity, every authority should compute and sign the
 same consensus including any flavors in each period.  Therefore, it
@@ -835,11 +835,11 @@ The voting period ends at the valid-after time. If the consensus has
 been signed by a majority of authorities, these documents are made
 available at
 
-http://<hostname>/tor/status-vote/current/consensus.z
+`http://<hostname>/tor/status-vote/current/consensus.z`
 
 and
 
-http://<hostname>/tor/status-vote/current/consensus-signatures.z
+`http://<hostname>/tor/status-vote/current/consensus-signatures.z`
 
 ```text
    [XXX current/consensus-signatures is not currently implemented, as it
@@ -849,20 +849,22 @@ http://<hostname>/tor/status-vote/current/consensus-signatures.z
     consensuses.]
 
    The other vote documents are analogously made available under
-```
 
 http://<hostname>/tor/status-vote/current/authority.z
 http://<hostname>/tor/status-vote/current/<fp>.z
 http://<hostname>/tor/status-vote/current/d/<d>.z
 http://<hostname>/tor/status-vote/current/bandwidth.z
+```
 
 once the voting period ends, regardless of the number of signatures.
 
 The authorities serve another consensus of each flavor "F" from the
 locations
 
+```
 /tor/status-vote/(current|next)/consensus-F.z. and
 /tor/status-vote/(current|next)/consensus-F/<FP1>+....z.
+```
 
 The standard URLs for bandwidth list files first-appeared in Tor 0.3.5.