updates.

[silc.git] / TODO

diff --git a/TODO b/TODO
index 56d4abfeba1e97f11eb83a3b378c717ba469ecf3..26c7660513134fde66ca703bd48721f9a2be9dfe 100644 (file)
--- a/TODO
+++ b/TODO
@@ -14,6 +14,8 @@ TODO/bugs In SILC Client Library
    set the key only if application wishes to set (accept the key) it
    (Do this to 1.0).
 
+ o Remove conn->current_channel.
+
  o Additions to do after protocol version 1.1:
 
        o Add support for list of errors in command replies.  Protocol
@@ -133,27 +135,22 @@ describe new stuff to be added to protocol versions 1.x.
     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.
-
- 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.
-
- 11. Change the wording in Private Message Key Payload definition to
-     describe the problems of trusting the payload, and to indicate that
-     the receiver may not accept the key in the payload, and to describe
-     other means of distributing a key.
-
- 16. Add STATS command after all to the protocol for providing practically
-     same information client gets when connects to a server.  Normal
-     server would send this to router always when received from client.
-
  17. Cell wide channel founder support, and permanent channels when
      founder mode set.
 
- 18. UTF-8 requirement checkings for all specifications, when strings
-     are sent.
+ 18. Describe the SSH public key, X509, OpenPGP and SPKI certificates
+     encoding format in SKE (from their respective definitions).
+
+ o Inviting and banning by public key should be made possible.  To be
+   included in protocol version 1.2.
+
+ o UTF-8 support/requirement for nicknames & channel names.  UTF-8 support
+   in terminals and OS's are so hazy that this matter is left for
+   consideration in next version of the protocol (1.2).  For good UTF-8
+   reference and tutorial see: http://www.cl.cam.ac.uk/~mgk25/unicode.html.
+   What should CLI application do if it receives nickname that it cannot
+   display without messing up the terminal?  If UTF-8 is mandatory in
+   SILC then SILC clients cannot be allowed to start on terminals that do
+   not support UTF-8 (which renders 98% of users unable to use CLI SILC
+   app without hacking their environment).  See also site
+   http://gratrix.net/unicode/