[dcc2] Hi all :)

[Dan Smith]

Hi Szymon!

At 03:53 AM 2/10/2004 +0100, you wrote:

>- The "SID=" token.

I agree that the SID must be present in each negotiation, but I am not sure 
about making positional parameters.  In fact it may be better to have no 
positional parameters, and just use boolean tokens and name=value pairs, 
even for the dcc2-command token.  We can still make the token required as 
you suggest without specifying a position, and the parsing may be even 
easier (tokenize on whitespace, then equals).

This may be a better approach if, aside from the DCC2 ctcp message, we wish 
to also create a historic DCC backward compatibility.  Jesse suggested (for 
historic dcc send and chat requests) we can append all the DCC2 tokens 
after the command, and if the client supports DCC2 then negotiation could 
take place with DCC2 ACCEPT.  If not, then we would follow the historic 
procedure for connection.  This would mean our clients would support both 
the new DCC2 and historic dcc with a DCC2 compatibility layer.

Of course the ultimate goal will be to slowly phase out use of historic dcc 
as more clients implement DCC2 :)


>- LIST and GET transactions

Yes!  A way to specify shared files would be quite useful, but should we 
keep the DCC2 namespace only for connection negotiation?  We could define 
these in some other location that might be more fitting in the CTCP 
framework, perhaps CTCP LIST or OOB in a direct connection?

Also, a solution to this might be the MULTI file sharing that is specified 
in a draft on dcc2.org.  This allows for sending multiple files and 
directories, but since the receiving client specifies which files to send 
from the XML list, it could easily be seen as a file listing and requesting 
mechanism! :)  It would also support file metadata, transfer privacy, and 
integrity checks plus anything else we want to add to the multi schema.


>- An interesting idea could be to introduce some sort of (basic and 
>optional) authentication method.

That is a neat idea!  Exchanging auth passwords is still in plaintext if 
done over irc and there is a possibility of snooping.  Would it be better 
to do this out of band over a direct connection?  maybe an 
AUTHTYPE=basicpass DCC2 token to allow for different standardized 
authentication types and a handshake over a direct(encrypted) connection 
could be possible.  Perhaps we can incorporate this into MULTI. Any ideas 
on that?


>- DCC VOICE and DCC VIDEO are interesting sub-protocols that could be 
>explored in a later phase.

Yes, many protocols could be established.  I was thinking it might also be 
useful to allow clients to specify no-protocol, and just get negotiated 
connection information.  This could be very useful for launching other 
network programs outside of IRC, such as video conferencing or multiplayer 
games.  Perhaps a TYPE=IRCCHAT, TYPE=IRCFILE (dcc send, we can change the 
name to be more descriptive), TYPE=SOMEVIDEOPROTO TYPE=SOMEVOICEPROTOCAL, 
TYPE=CONNECTION, etc...

Cheers!
Dan


---------------------------
Dan Smith (dan at algenta.com)
+1 608-213-2867
Algenta Technologies, LLC