updates.
[silc.git] / TODO
diff --git a/TODO b/TODO
index cf5768f04856d31df463d9817094502db83af791..361ea7a895b88955b770e48dd91cc5e706ce3165 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,9 +1,6 @@
 TODO/bugs in Irssi SILC client
 ==============================
 
- o Setting /away prints server/router operator modes as well.
-   Print modes that was just set only.
-
  o Add local command to switch the channel's private key when channel has
    several private keys.  Currently sending channel messages with many
    keys is not possible because changing the key is not possible by the
@@ -39,16 +36,6 @@ TODO/bugs In SILC Client Library
 TODO/bugs In SILC Server
 ========================
 
- o The LIST command reply should empty the global list because
-   it is possible there stay channels that does not exist anymore.
-   Empty it and put channels that server does not know about to 
-   global list.
-
- o Make the silc_server_command_pending_error_check function to
-   take all arguments it received and put them to the reply it is 
-   sending.  Otherwise for example WHOIS on normal server for bogus
-   nickname does not print anything in the client.
-
  o Backup router related issues
 
        o Channel user mode changes are notified unnecessarely when
@@ -76,10 +63,6 @@ TODO/bugs In SILC Server
        o IP address fields in configuration file should accept mask
          format as well, IP/MASK, and not just plain IP.
 
-       o Connection classes should be actually implemented in
-         serverconfig.c.  They can be defined but they are totally
-         ignored currently.  And they should be redefined also.
-
  o If client's public key is saved in the server (and doing public key
    authentication) then the hostname and the username information could
    be taken from the public key.  Should be a configuration option!
@@ -93,6 +76,39 @@ TODO/bugs In SILC Libraries
    is not actually async currently.
 
 
+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
 ==============