updates.
[silc.git] / TODO
diff --git a/TODO b/TODO
index 966e812bcfa735511a2209c5fcbc685405834e6a..6f8aa18b77122547cde72e38a6b8bd59ff9afce9 100644 (file)
--- a/TODO
+++ b/TODO
@@ -30,21 +30,39 @@ TODO/bugs in Irssi SILC client
 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.
+ o The PRIVATE_MESSAGE_KEY packet is not handled (it is implemented 
+   though).  This should be added and perhaps new client operation
+   should be added to notify application that it was received and
+   set the key only if application wishes to set (accept the key) it.
 
-   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 should /nick nick and /nick Nick cause the Nick to be Nick@host becase
+   it used to be nick??
+
+ o When changing own nickname and there exists a same nickname the library
+   can give the client now nickname in format nick@host.  This is new
+   behaviour and maybe should be removed.  The changer should always
+   get the one it wants and not have the formatted nickname.
+
+ o Remove the command destructor all together from the client, it is
+   not needed and its usage is buggy when the context is registered
+   to multiple pending commands.
+
+ o Additions to do after protocol version 1.1:
+
+       o Fix the NICK_CHANGE notify handling not to create new entry
+         for the changed client, but take the nickname from the notify
+         (removes need for resolving as well).  Protocol TODO entry 3.
+
+       o Add support for list of errors in command replies.  Protocol
+         TODO entry 1.
 
 
 TODO/bugs In SILC Server
 ========================
 
+ o strerror messages from premature EOF's to signoff messages.
+   (add perhaps a socket error thingy to SilcSockeConnection).
+
  o Backup router related issues
 
        o Channel user mode changes are notified unnecessarely when
@@ -80,11 +98,73 @@ TODO/bugs In SILC Server
 TODO/bugs In SILC Libraries
 ===========================
 
+ o make install copies the symblic links from lib/silcsim/ and not
+   modules.
+
  o WIN32 silc_net_create_connection_async does not work the same way
    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.
+ o Rewrite the lib/silcsim/silcsim.h.  The SilcSimContext should be
+   private and silc_sim_alloc should take necessary arguments.
+
+
+TODO in SILC Protocol
+=====================
+
+Current protocol version is 1.0.  However, it is far from being perfect,
+and needs to include additional features.  Following protocol TODO entries
+describe new stuff to be added to protocol versions 1.x.
+
+ 1. 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.
+
+ 2. 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.
+
+ 3. Define the NICK_CHANGE notify to send the changed nickname as a new
+    third argument.  This will make the NICK_CHANGE notify handling easier
+    in the receiver's end (client primarily) since it removes the
+    requirement that receiver must resolve (using IDENTIFY or WHOIS) the
+    new Client ID received in the notify (because of the new nickname is
+    unknown).  To be included in protocol version 1.1.
+
+ 4. 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.
+
+ 5. Inviting and banning by public key should be made possible.  To be
+    included in protocol version 1.x.
+
+ 6. Add perhaps SILENCE_USERS, SILENCE_OPERS channel user modes which
+    can be used to silence (moderate) normal users and opers (this set
+    only by founder).  To be included in protocol version 1.1.
+
+ 7. Channel Message Payload needs slight redesining to include the IV
+    field to the MAC generation of the payload.  It is authenticated
+    by the packet's MAC but not by the payload's MAC.  Since the IV
+    belongs to the payload, its integrity should be protected by the
+    payload MAC and not alone by packet MAC.  To be included in protocol 
+    version 1.1.
 
 
 TODO After 1.0