[dcc2] Hi all :)

[Szymon Stefanek]

Hi all :)

During the KVirc development years I have tried to get beyond the DCC protocol limitations
by adding the GET,RECV,RSEND and VOICE extensions and I absolutely agree that a new standard is
required.
I have readed the first draft and I'm really glad to see that it already
pinpoints some important parts of the negotiation.

Here are some random ideas that comed into my mind while reading:

- The "SID=" token.
	The session identifier is an important part of the negotiation. The assumption of the session
	identification based on the ip:port is obviously useless since the protocol will probably
	allow more than one message to be exchanged between the clients without estabilishing
	a real connection (see the NAT option for example). I think that the session identifier should
	be explicitly marked as mandatory in the protocol specification and simply placed as a positional
	parameter.

		<dcc2-publish> = 'DCC2' <space> <dcc2-command> <space> <dcc2-sid> <dcc2-command-parameters>
		<dcc2-sid> = 1*(<alpha> | <digit>)
	
	... it could be even placed before the <dcc2-command> command since the clients
	will probably first inspect the SID in order to find out the current negotiation state
	and then look at the command. This would lead to the following (even nicer from my point of view) definition:

		<dcc2-publish> = 'DCC2'  <space> <dcc2-sid> <space> <dcc2-message>
		<dcc2-sid> = 1*(<alpha> | <digit>)
		<dcc2-message> = <dcc2-command> <dcc2-parameters>
		....
	
	The nice side of this definition is that the part with "fixed semantics" is separated
	from the "variable semantics" (dcc2-message) one.

- LIST and GET transactions
	Many IRC clients/scripts are trying to use DCC as a complete file sharing protocol.
	Most advanced scripts implement the XDCC LIST command that allows the listing
	of the files available for download and 
	Every one is going its own way and obviously actually it is a complete mess :D
	For this reason I think that also the "list" and "get" transactions should be somewhat
	standardized.

- An interesting idea could be to introduce some sort of (basic and optional) authentication method.
	The common "authentication" method based on the irc masks is unreliable and not flexible enough.
	Even a plain AUTH=<password> token could allow the clients to provide interesting
	services to the user. Think of "pre-scheduled" downloads for authenticated users or
	personalized responses to the DCC LIST request.

- DCC VOICE and DCC VIDEO are interesting sub-protocols that could be explored in a later phase.
	DCC VIDEO is just a dream but DCC VOICE has been already succesfully implemented in many clients.


Just my first 2 cents :)


-- 

Szymon Stefanek

------------------------------------------------------------------------------
-
- I don't live in fantasy, I only work there.
-
------------------------------------------------------------------------------