diff --git a/www.i2p2/pages/common_structures_spec.html b/www.i2p2/pages/common_structures_spec.html index 69c5c69d..ce84fde1 100644 --- a/www.i2p2/pages/common_structures_spec.html +++ b/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

Data types Specification

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.

  • +The encoding allows duplicate keys, however in any usage where the mapping is signed, +duplicates may cause a signature failure. +
  • 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.
  • Mappings contained in an I2CP SessionConfig must be sorted by key so that the signature will be invariant. +Duplicate keys are not allowed. +
  • +While it is application-dependent, keys and values are generally case-sensitive.
  • Key and value string length limits are 255 bytes (not characters) each, plus the length byte. Length byte may be 0.
  • @@ -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. +
  • +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".
    • @@ -696,10 +707,15 @@ signature :: Signature

    Notes

    +

    Javadoc

    diff --git a/www.i2p2/pages/i2cp.html b/www.i2p2/pages/i2cp.html index f1401b6f..9c41fa48 100644 --- a/www.i2p2/pages/i2cp.html +++ b/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

    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 SessionConfig contained in a < of sending a MessageStatus and awaiting a ReceiveMessageBegin. As of 0.9.4 explicitPeers  nullComma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only -i2cp.usernamestring  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. -i2cp.passwordstring  For authorization, if required by the router (since 0.8.2). +i2cp.usernamestring  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. +i2cp.passwordstring   crypto.tagsToSend 1-12840Number 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. crypto.lowTagThreshold 1-12830Minimum number of ElGamal/AES Session Tags before we send more (since 0.9.2).