Fix typos, XHTML errors and warnings

www.i2p2/pages/common_structures_spec.html

@@ -286,12 +286,11 @@ certificate :: Certificate
                length -> >= 3 bytes
 
 {% endfilter %}
+</pre>
 
 <h4>Notes</h4>
 The certificate for a RouterIdentity is currently unused and is always NULL.
 
-</pre>
-
 <h4><a href="http://docs.i2p2.de/core/net/i2p/data/RouterIdentity.html">Javadoc</a></h4>
 
 <h2 id="struct_Destination">Destination</h2>
@@ -388,7 +387,6 @@ end_date :: Date
   <a href="#struct_Destination">Destination</a>, followed by a <a href="#type_PublicKey">PublicKey</a> for encryption, then a <a href="#type_SigningPublicKey">SigningPublicKey</a> which can be used to revoke this version of the <a href="#struct_LeaseSet">LeaseSet</a>,
   then a 1 byte <a href="#type_Integer">Integer</a> specifying how many <a href="#struct_Lease">Lease</a> structures are in the set, followed by the actual <a href="#struct_Lease">Lease</a> structures and finally a <a href="#type_Signature">Signature</a>  of the previous
   bytes signed by the <a href="#struct_Destination">Destination's</a> <a href="#type_SigningPrivateKey">SigningPrivateKey</a>
-<p/>
 <pre>
 {% filter escape %}
 +----+----+----+----+----+----+----+----+

www.i2p2/pages/how.html

@@ -48,7 +48,7 @@ HTTP Proxy
 </li><li>
 IRC Proxy
 </li><li>
-<td align="center"><a href="sam.html">SAM</a> API
+<a href="sam.html">SAM</a> API
 </li><li>
 <a href="samv2.html">SAMv2</a> API
 </li><li>
@@ -62,7 +62,7 @@ BOB Javadoc
 </li></ul>
 
 <h3>End-to-End Transport API and Protocols</h3>
-The end-to-end protocols used by clients for reliable and unreliable commuication.
+The end-to-end protocols used by clients for reliable and unreliable communication.
 <ul><li>
 <a href="streaming.html">Streaming Library</a>
 </li><li>
@@ -125,7 +125,7 @@ Selecting peers, requesting tunnels through those peers, and encrypting and rout
 <li><a href="how_garlicrouting.html">Garlic routing</a></li>
 <li><a href="tunnel-alt.html">Tunnel building and encryption</a></li>
 <li><a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a> for build request encryption</li>
-<li><a href="how_cryptography.html">ElGamal and AES cryptography details</li>
+<li><a href="how_cryptography.html">ElGamal and AES cryptography details</a></li>
 <li><a href="tunnel-alt-creation.html">Tunnel building specification</a></li>
 <li><a href="tunnel_message_spec.html">Low-level tunnel message specification</a></li>
 </ul>
@@ -141,9 +141,9 @@ The protocols for direct (point-to-point) router to router communication.
 </li><li>
 <a href="udp_spec.html">SSU specification</a>
 </li><li>
-<li><a href="how_cryptography.html#tcp">NTCP transport encryption</li>
+<a href="how_cryptography.html#tcp">NTCP transport encryption</a>
 </li><li>
-<li><a href="how_cryptography.html#udp">SSU transport encryption</li>
+<a href="how_cryptography.html#udp">SSU transport encryption</a>
 </li><li>
 <a href="http://docs.i2p2.i2p/router/net/i2p/router/transport/package-summary.html">Transport Javadoc</a>
 </li><li>

www.i2p2/pages/how_garlicrouting.html

@@ -17,7 +17,7 @@ contained, instead of just a single message.
 In addition to the cloves, each unwrapped garlic message contains a sender
 specified amount of padding data, allowing the sender to take active countermeasures 
 against traffic analysis.
-<p>
+
 <H2>Uses within I2P</H2>
 
 <p>
@@ -33,14 +33,14 @@ I2P uses garlic routing in three places:
 <p>
 There are also significant ways that this technique can be used to improve the performance of the network, 
 exploiting transport latency/throughput tradeoffs, and branching data through redundant paths to increase reliability.  
-<p>
+
 <H2>Encryption</H2>
 
 <p>
 The encryption of each layer in the garlic message uses the <a href="how_elgamalaes">ElGamal/AES+SessionTag</a> algorithm, 
 which avoids the cost of a full 2048bit ElGamal encryption for subsequent messages (using instead a random previously 
 specified SessionTag plus 256bit AES encryption).
-<p>
+
 <H2>References</H2>
 
 <p>

www.i2p2/pages/how_intro.html

@@ -62,7 +62,7 @@ allocation ("lease") of some tunnels that will be used for sending and receiving
 network.  I2P has its own internal <a href="how_networkdatabase">network database</a> (using a modification of 
 the Kademlia algorithm) for scalable distributing routing and contact information securely.</p>
 
-<p><center><div class="box"><img src="_static/images/net.png" alt="Network topology example" title="Network topology example" /></div></center></p><br>
+<center><div class="box"><img src="_static/images/net.png" alt="Network topology example" title="Network topology example" /></div></center><br/>
 
 
 <p>In the above, Alice, Bob, Charlie, and Dave are all running routers with a single Destination on their 
@@ -101,7 +101,7 @@ Notice the different use of terms! All data from a to h is end-to-end encrypted,
 between the I2P router and the applications is not end-to-end encrypted!
 A and h are the routers of Alice and Bob, while Alice and Bob in following chart are the applications running atop of I2P.</p>
 
-<center><div class="box"><img src="_static/images/endToEndEncryption.png" alt="End to end layered encryption" title="End to end layered encryption." /></div></center><br>
+<center><div class="box"><img src="_static/images/endToEndEncryption.png" alt="End to end layered encryption" title="End to end layered encryption." /></div></center><br/>
 
 <p>The specific use of these algorithms are outlined <a href="how_cryptography">elsewhere</a>.</p>
 

www.i2p2/pages/i2np_spec.html

@@ -292,7 +292,7 @@ Certificate :: Always NULL in the current implementation (3 bytes total, all zer
 <li>
   See also the <a href="how_garlicrouting.html">garlic routing specification</a>.
 <li>
-  See also <a href="tunnel_message_spec.html#delivery">Delvery Instructions definition</a>
+  See also <a href="tunnel_message_spec.html#delivery">Delivery Instructions definition</a>
 <li>
   In the future, the certificate could possibly be used for a HashCash to "pay" for the routing.
 </ul>
@@ -586,7 +586,7 @@ from:
 <h3 id="msg_DeliveryStatus">DeliveryStatus</h3>
 <h4>Description</h4>
 <p>
-  A simple message acknowledgement. Generally created by the message originator, and wrapped
+  A simple message acknowledgment. Generally created by the message originator, and wrapped
   in a Garlic Message with the message itself, to be returned by the destination.
 </p>
 <h4>Contents</h4>
@@ -668,7 +668,7 @@ length:
 
 data:
      $length bytes
-     elgamal encrypted data
+     ElGamal encrypted data
 
 
 Unencrypted data:
@@ -700,7 +700,6 @@ Expiration :: Date (8 bytes)
 <li>
   In the future, the certificate could possibly be used for a HashCash to "pay" for the routing.
 </ul>
-</p>
 
 
 <h3 id="msg_TunnelData">TunnelData</h3>

www.i2p2/pages/roadmap.html

@@ -2,7 +2,7 @@
 {% block title %}Roadmap{% endblock %}
 {% block content %}
 
-<h2 id="0.9">0.9</h2>
+<h2 id="v0.9">0.9</h2>
 <ul>
 <li>Include some seed data in the distribution so a central reseed location isn't required?
 <li>Reachability Mapping / handle peers partially reachable / enhanced <a href="todo.html#fullRestrictedRoutes">restricted routes</a></li>
@@ -12,19 +12,19 @@
 <li>Iterative floodfill lookups</li>
 </ul>
 
-<h2 id="1.0">1.0</h2>
+<h2 id="v1.0">1.0</h2>
 <ul>
 <li>Full review of anonymity issues and other vulnerabilities</li>
 <li>Reduce memory usage, remove debugging overhead, make it run better on slow and embedded machines</li>
 <li>Docs</li>
 </ul>
 
-<h2 id="2.0">2.0</h2>
+<h2 id="v2.0">2.0</h2>
 <ul>
 <li>Full restricted routes</li>
 </ul>
 
-<h2 id="3.0">3.0</h2>
+<h2 id="v3.0">3.0</h2>
 <ul>
 <li>Tunnel mixing and padding</li>
 <li>User defined message delays</li>