updates.
[silc.git] / TODO
diff --git a/TODO b/TODO
index 00e588d83f157dab93afd359fccdec21cfc4a7df..361ea7a895b88955b770e48dd91cc5e706ce3165 100644 (file)
--- a/TODO
+++ b/TODO
@@ -13,11 +13,6 @@ TODO/bugs in Irssi SILC client
    that the user has.  And a local command to dump the contents of the
    public key to the screen.  Something like LISTKEYS, SHOWKEY...
 
- o The JOIN command's HELP is generated from Irssi IRCs JOIN help and
-   the syntax is not same in SILC.  This must be fixed.  Most likely
-   we must forget the Irssi's JOIN command and mimic it to get our
-   required syntax for it too.
-
  o We should get rid of the clientconfig.[ch] in Irssi SILC and move the
    cipher, hash, hmac and pkcs configuration to the Irssi SILC's config
    file.
@@ -35,55 +30,17 @@ TODO/bugs in Irssi SILC client
 TODO/bugs In SILC Client Library
 ================================
 
- o JOIN command's argument handling is buggy.  See the XXX in the code.
+ o N/A
 
 
 TODO/bugs In SILC Server
 ========================
 
- o XXXXXXXXX cannot join +a channel from other servers
-
- o Implement the <founder auth> and founder privileges gaining to
-   the JOIN command.  This will bypass invite-only mode as well for
-   the client who got the founder mode during JOIN.
-
- o Optimize the WHOIS and IDENTIFY commands to check if the request
-   includes an ID or multiple IDs, then they are checked from local cache
-   first, and not sent directly to router.  This is because if they
-   are found in the local cache there's no need to send them to the
-   router.  Only if some ID is not found, or an found entry is 
-   incomplete it can be queried from the router.  This way these
-   commands become faster, and for example JOIN command becomes a lot
-   faster since the server ends up resolving the same information only
-   once, as opposed to resolve it everytime JOIN command is issued, like
-   it does now.
-
-   The same thing can be done with WHOWAS command as well.
-
-   It is important to send these requests to router only if they can be
-   expanded to many results (as when doing WHOIS for nickname).  If
-   they are explicit (like requesting by ID) the local cache MUST be
-   searched before sending it to router.
-
- o Announcements are incomplete: channel topics are not announced,
-   user modes (UMODE) are not announced.
-
- o Change the server to connect to another server from low ports (706)
-   and not from high ports.  Currently we cannot do incoming connection
-   checking by remote port because the port is not fixed.
-
  o Backup router related issues
 
-       o After backup resume protocol the TOPIC_SET was not handled
-         correctly by all (unknown Channel ID).
-
        o Channel user mode changes are notified unnecessarely when
          switching to backup router on router crash.
 
- 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!
-
  o Add a timeout to handling incoming JOIN commands.  It should be 
    enforced that JOIN command is executed only once in a second or two
    seconds.  Now it is possible to accept n incoming JOIN commands
@@ -106,9 +63,9 @@ 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!
 
 
 TODO/bugs In SILC Libraries
@@ -119,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
 ==============