Jan Vidar Krey,

I read through the current DC-TNG standard, and I had some comments
which I would like to share with you:

1. For the "Info" command, you had specified the context as "Client to
   server immediately after login and server to client at any later
   time". Don't you think that the client should be able to update its
   status later? Also, I was wondering what "Proxy mode" was supposed
   to be. Doesn't Proxy mode and Active mode essentially look the same
   to other network nodes?

2. For the "Search" command, you might want to look at the stuff that
   eric and I have been discussing these latest days. Also, I believe
   that there should be an error message indicating that the hub has
   dropped the request (since the client has been trying to search too
   often).

3. Is both "Connect" and "ReqConnect" really necessary? Since they
   offer no kind of protection, can't the IP addresses (or other means
   of contacting) of clients simply be published in the user list? I
   think that only "Connect" should be available in case you want some
   passive mode user to connect to you, and it should only take one
   GUID (for the user you want to connect to you). The hub should
   change that into sender's GUID when it transmits the request to the
   target user.

4. I think there should be a "Welcome" command that the server sends
   to the client when the client is fully authenticated and allowed to
   use all commands.

5. You have not yet presented a "Chat" command. How about:
   
	Chat STRING TARGET SPECIFIER...

   STRING is the chat string to be sent. TARGET is the type of
   transfer: 0 for a chat directed to a chat room, 1 if directed to
   another user. If directed to a chat root, SPECIFIER is the name of
   the room, and if to a user, SPECIFIER is the user's GUID. SPECIFIER
   can be repeated an arbitrary number of times for multiple
   recievers.

6. Shouldn't users be able to switch charsets? For example, chats in
   Japanese (or other East Asian languages) would benefit much more
   from EUC-JP or UTF-16 than from UTF-8. Chats in Cyrillic would also
   benefit from eg. KOI8. Of course, UTF-8 would be the standard. If a
   message cannot be encoded with the selected charset, the hub could
   replace invalid characters with eg. question marks to indicate that
   the user should switch charset to be able to recieve messages
   correctly. Another possibility is to only allow switching between
   different UTF-x charsets, so that all characters still can be
   encoded, only with different levels of bandwidth wastage. A third
   possibility is to be able to MIME encode messages to temporarily
   switch charsets, like =?UTF-8?Q?=E3=81=82?= to include a Japanese
   "あ" even though the user's current charset is KOI8.

7. I think there should be a greater distinction between commands and
   replies, instead of defining commands that are used as replies. The
   replies should still be transmitted in the same way as commands, so
   their namespaces cannot overlap, but I think that, for example,
   every command should acknowledged by an "OK" reply. That way there
   is less confusion, and the client<->client protocol (which is
   really P2P) will be easier to design, IMHO.

What do you think?

Fredrik Tolf

-- 
DC Developers mailinglist
http://3jane.ashpool.org/cgi-bin/mailman/listinfo/dcdev