-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, 

I haven't done any work ont the specification since June/July of this year.
Well I started abit earlier this week on an updated draft. I haven't finished 
it yet, and I think I'll go back a few steps on some of the points I've 
outlined and perhaps make them optional (Channels and message board for 
instance) by the draft so hubs can choose not to use them.

If you'd like a preview on the command reference I'm working on, here is an 
updated link for you: http://murdoc.extatic.org/dctng_commands.php
(I put the commands into an SQL database for it to be easier to edit)

Many of these things are addressed. Like the search function.
Putting a timezone in the INFO-command is interresting, I'll take a note of 
that.
The connect (CONN) and RCON is necessary, but not complete. I'll also add a 
"magic token" there so nobody can initialize a p2p session without knowing 
the token (which again must be sent via a hub). Call it an extra 
RIAA-protection if you like... then they have to be on your hub to be able to 
download from you. :)
Another cool feature with this CONN-command is that it supports different p2p 
protocols. Imagine setting up an IP-telephony call by right clicking on a 
user, or videoconferencing by starting up Netmeeting?

I also added a "CAPA" command, similar to the POP3's CAPA, and provides the 
same functionality of the $Supports command today.
I have some example client-hub interactions, but they are not finished.

Cheers


- -janvidar-

On Thursday 04 December 2003 23:37, you wrote:

> 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

- -- 
- -janvidar-

Dj Offset / QuickDC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/0DxgMLjmoUcyZAoRAiY+AJ9AlQtEPbRfiW4BYi9mdJeH8/dg1QCfSDjP
mxn+jR15wFJWVDa55SYqFjU=
=btJG
-----END PGP SIGNATURE-----

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