-TODO/bugs in Irssi SILC client
-==============================
+TODO for 1.1
+============
- o /cumode for unknown nick does not give any error message (Fix this to
- 1.0).
+NOTE: Any item that doesn't have (***DONE) in it, isn't done yet. The
+(***TESTING NEEDED) means that the item has been done but not yet properly
+tested.
-TODO/bugs In SILC Client Library
-================================
-
- 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
- (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
- TODO entry 1.
-
-
-TODO/bugs In SILC Server
-========================
-
- o Configuration file additions (Do this to 0.8.x):
-
- o Add incoming connection frequency, incoming connection frequency
- for single IP address, key exchange frequency, key exchange
- frequency for single IP. Add also frequency base.
-
- o If server send CUMODE_CHANGE notify (like setting founder) to router
- and router does not have founder on channel (founder is left or there's
- no founder on channel at all), the router will accept the server's
- founder mode change, even though it perhaps should not do that (Fix
- this to 0.9).
-
- o The router should check for validity of received notify packets from
- routers (fix this to 0.9). Following NOTIFYs needs to be verified:
-
- o JOIN (check that joining is allowed)
- o SIGNOFF (maybe should check that notifier owns the client)
-
- o Backup router related issues (Fix this to 1.0):
-
- o Channel user mode changes are notified unnecessarely when
- switching to backup router on router crash.
-
- 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
- and process them without any timeouts. THis must be employed because
- each JOIN command will create and distribute the new channel key
- to everybody on the channel (Fix this to 1.0).
-
- o Lots of statistics updating is missing around the server.
-
- 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
+apps/silcd, The SILC Server ****PARTLY DONE****
===========================
- 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 (Fix this to 1.0).
-
-
-TODO in Toolkit Documentation
-=============================
-
-Stuff that needs to be done in order to complete the Tooolkit Reference
-Manual (Do these to 0.9 and 1.0).
-
- o ROBOdoc documenting missing from lib/silcutil/silcbuffer.h.
-
- o ROBOdoc documenting missing from lib/silcutil/silcdlist.h.
-
- o ROBOdoc documenting missing from lib/silcutil/silcfileutil.h.
-
- o ROBOdoc documenting missing from lib/silccrypt/silchash.h.
-
- o ROBOdoc documenting missing from lib/silccrypt/silccipher.h.
-
- o ROBOdoc documenting missing from lib/silccrypt/silcpkcs.h.
-
- o Write "Programming with Toolkit" document, describing how to build
- Toolkit, how the build system works, where is everything, how
- new (external) projects can be glued into Toolkit (use irssi as an
- example), and how external projects can use Toolkit without gluing into
- it (how to link etc), debugging, architecture, types, etc.
-
- o Write "Platform Implementations" document to describe what platforms
- Toolkit support, what has been implemented, what has not been, what
- works differently etc.
-
-
-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.
-
- 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.
+ o Rewrite rehash, HUP.
- 17. Cell wide channel founder support, and permanent channels when
- founder mode set.
- 18. Describe the SSH public key, X509, OpenPGP and SPKI certificates
- encoding format in SKE (from their respective definitions).
+SILC Client
+===========
- 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/
+lib/silcclient, The Client Library
+==================================