clarifications

www.i2p2/pages/common_structures_spec.html

@@ -1,7 +1,7 @@
 {% extends "_layout.html" %}
 {% block title %}Common structure Specification{% endblock %}
 {% block content %}
-Updated November 2013, current as of router version 0.9.9
+Updated December 2013, current as of router version 0.9.9
 <h1>Data types Specification</h1>
 <p>
   This document describes some data types common to all I2P protocols, like
@@ -259,11 +259,18 @@ Strings are defined to be UTF-8 but in the current implementation, I2CP uses UTF
 For example,
 UTF-8 strings in a RouterInfo options mapping in a I2NP Database Store Message will be corrupted.
 <li>
+The encoding allows duplicate keys, however in any usage where the mapping is signed,
+duplicates may cause a signature failure.
+<li>
 Mappings contained in I2NP messages (i.e. in a RouterAddress or RouterInfo)
 must be sorted by key so that the signature will be invariant.
+Duplicate keys are not allowed.
 <li>
 Mappings contained in an <a href="i2cp_spec.html#struct_SessionConfig">I2CP SessionConfig</a>
 must be sorted by key so that the signature will be invariant.
+Duplicate keys are not allowed.
+<li>
+While it is application-dependent, keys and values are generally case-sensitive.
 <li>
 Key and value string length limits are 255 bytes (not characters) each, plus the length byte. Length byte may be 0.
 <li>
@@ -582,7 +589,7 @@ cost :: Integer
         case 0 -> free
         case 255 -> expensive
 
-expiration :: Date
+expiration :: Date (must be all zeros, see notes below)
               length -> 8 bytes
 
               case null -> never expires
@@ -603,6 +610,10 @@ Expiration is currently unused, always null (all zeroes)).
 As of release 0.9.3, the expiration is assumed zero and not stored, so any non-zero expiration
 will fail in the RouterInfo signature verification.
 Implementing expiration (or another use for these bytes) will be a backwards-incompatible change.
+Routers MUST set this field to all zeros.
+</li><li>
+The following options, while not required, are standard and expected to be present in most router addresses:
+"host" (an IPv4 or IPv6 address or host name) and "port".
 </li></ul>
 
 
@@ -696,10 +707,15 @@ signature :: Signature
 </pre>
 
 <h4>Notes</h4>
+<ul><li>
 The peer_size Integer may be followed by a list of that many router hashes.
 This is currently unused. It was intended for a form of restricted routes, which is unimplemented.
-<p>
+</li><li>
 The signature may be verified using the signing public key of the router_ident.
+</li><li>
+See <a href="how_networkdatabase.html#routerInfo">the network database page</a>
+for standard options that are expected to be present in all router infos.
+</ul>
 
 <h4><a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/RouterInfo.html">Javadoc</a></h4>
 

www.i2p2/pages/i2cp.html

@@ -1,7 +1,7 @@
 {% extends "_layout.html" %}
 {% block title %}I2CP{% endblock %}
 {% block content %}
-Updated November 2012, current as of router version 0.9.3
+Updated December 2013, current as of router version 0.9.9
 
 <p>The I2P Client Protocol (I2CP) exposes a strong separation of concerns between
 the router and any client that wishes to communicate over the network.  It enables
@@ -118,10 +118,11 @@ a <a href="i2cp_spec.html#type_SessionConfig">SessionConfig</a> contained in a <
      of sending a MessageStatus and awaiting a ReceiveMessageBegin.
      As of 0.9.4
 <tr><td>explicitPeers<td>&nbsp;<td>&nbsp;<td>null<td>Comma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only
-<tr><td>i2cp.username<td>string<td>&nbsp;<td>&nbsp;<td>For authorization, if required by the router (since 0.8.2).
-        If the client is running in the same JVM as a router, this option is not required.
-<tr><td>i2cp.password<td>string<td>&nbsp;<td>&nbsp;<td>For authorization, if required by the router (since 0.8.2).
+<tr><td>i2cp.username<td>string<td>&nbsp;<td>&nbsp;<td rowspan="2">For authorization, if required by the router (since 0.8.2).
         If the client is running in the same JVM as a router, this option is not required.
+        Warning - username and password are sent in the clear to the router, unless using SSL (i2cp.SSL=true).
+        Authorization is only recommended when using SSL.
+<tr><td>i2cp.password<td>string<td>&nbsp;<td>&nbsp
 <tr><td>crypto.tagsToSend<td>&nbsp;<td>1-128<td>40<td>Number of ElGamal/AES Session Tags to send at a time (since 0.9.2).
         For clients with relatively low bandwidth per-client-pair (IRC, some UDP apps), this may be set lower.
 <tr><td>crypto.lowTagThreshold<td>&nbsp;<td>1-128<td>30<td>Minimum number of ElGamal/AES Session Tags before we send more (since 0.9.2).