reverted fetching to a simpler and more robust algo

ii-doc.txt

@@ -32,8 +32,6 @@ and depend on the message contents hash (see the exact algorithm below).
 Station (node) HTTP API (as implemented in tii)
 -----------------------------------------------
 Every station must implement the following HTTP API calls.
-The tii codebase also implements some IDEC extenstions but they are entirely
-optional.
 In case of multi-line responses, the newline separator must be "\n" character
 (line feed, ASCII 10).
 
@@ -49,8 +47,6 @@ reported by nodes still should not be the basis for any client-side logic.
 - Listing messages in the echo(s) -
 
 Request: GET /u/e/echo.1.name/echo.2.name/...
-IDEC extended syntax: GET /u/e/echo.1.name/echo.2.name/.../offset:count
-(where offset can be negative)
 Response: newline-separated list of echo names and message IDs in the format:
 
 echo.1.name
@@ -82,15 +78,6 @@ Response: in case of success, must start with "msg ok"
 where base64_msgtext is the Base64-encoded Point-to-Node Message (see below).
 The maximum length of the tmsg field must be 87382 bytes.
 
-- Listing IDEC features (IDEC extension) -
-
-Request: GET /x/features
-Response: newline-separated list of supported non-standard URL paths
-(u/e, /list.txt etc)
-
-Note: if the /x/features path is unavailable, the client must assume that no
-IDEC extensions except /list.txt are supported by the server.
-
 Node-to-Point Message format
 ----------------------------
 The encoding must be UTF-8 and the newline separator must be "\n" (ASCII 10).