updates.
[silc.git] / TODO
diff --git a/TODO b/TODO
index 966e812bcfa735511a2209c5fcbc685405834e6a..361ea7a895b88955b770e48dd91cc5e706ce3165 100644 (file)
--- a/TODO
+++ b/TODO
@@ -30,16 +30,7 @@ TODO/bugs in Irssi SILC client
 TODO/bugs In SILC Client Library
 ================================
 
 TODO/bugs In SILC Client Library
 ================================
 
- o Process the NO_SUCH_CLIENT_ID for WHOIS and IDENTIFY, since it can
-   be received for example after sending MSG to non-existent client.
-   It actually should be done always when it is received and the old
-   entry should be removed.
-
-   Doing this now however causes that /msg nick might give "no such nick"
-   for the first time, and then after the entry is removed /msg nick
-   may actually to go any nick client, which is not desired behaviour.
-   The /msg must be fixed to use the specific nickname user typed 
-   (nick must not match nick@host).
+ o N/A
 
 
 TODO/bugs In SILC Server
 
 
 TODO/bugs In SILC Server
@@ -84,7 +75,38 @@ TODO/bugs In SILC Libraries
    than on Unix.  Do it with threads on WIN32.  The function works but
    is not actually async currently.
 
    than on Unix.  Do it with threads on WIN32.  The function works but
    is not actually async currently.
 
- o Do not let the silcdefs.h lay around in distributions.
+
+TODO in SILC Protocol
+=====================
+
+ o Add "request parameters" or similar to the WHOIS command, which can
+   be used to request various parameters (something not returned by
+   standard WHOIS command) about clients (info that could be fetched
+   even from clients).  Additional specification (or appendix) should 
+   be done to define the payload and the parameters.  It could be used
+   to make the WHOIS command support various search conditions as well.
+   This would be the way to extend the WHOIS command to support various
+   new features without always making the command incompatible to previous
+   version.  To be included in protocol version 1.1.
+
+ o Re-define the Status Payload: it is now 16 bits, split it into two
+   8 bits fields.  First field includes status types from 0 - 9 and
+   10 - n *if* it is not an list of errors.  If it is list of errors then
+   the first field includes 1, 2 and/or 3, and the second field includes
+   the error status 10 - n.  This way it is possible to send multiple
+   errors (list of errors) and we have a way to tell the receiver that
+   there will be other errors as well.  The second field is used only
+   if there is list of errors.  If normal status, or normal (single)
+   error status the second field is set to zero, and must be ignored.
+   Hence, the status works same way as now except for list of errors.
+   To be included in protocol version 1.1.
+
+ o Define that WHOIS and IDENTIFY commands must send list of errors
+   if multiple Client ID (or Channel ID and Server ID for IDENTIFY) was
+   requested and was not found.  Each unfound entry must cause an error
+   command reply to the sender.  Also define that errors must be sent
+   *after* sending successfully found entries (this way receiver may
+   ignore them).  To be included in protocol version 1.1.
 
 
 TODO After 1.0
 
 
 TODO After 1.0