Talk:Direct Client-to-Client Source: en.wikipedia.org/wiki/Talk:Direct_Client-to-Client

	This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:
IRC (inactive) This article is within the scope of WikiProject IRC, a project which is currently considered to be inactive.IRCWikipedia:WikiProject IRCTemplate:WikiProject IRCIRC

The contents of Secure Direct Client-to-Client was merged into Direct Client-to-Client on 2007-12-27. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. For the discussion at that location, see its talk page.

The contents of DCC SEND exploit was merged into Direct Client-to-Client on 2007-12-27. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. For the discussion at that location, see its talk page.

DCC2 is in the works (Slashdot Article on DCC2). While this might fall under the "extensions" of DCC, it looks like it's going to be a complete replacement. Perhaps it should be mentioned in the article? -- Kowh 01:53, 26 Apr 2004 (UTC)

I'm adding a note to the effect that DCC FSERVE is only available under mIRC. It doesn't exist in X-Chat or anywhere in the ircII family. --Cuervo 01:36, 9 Apr 2005 (UTC)

Correct me if I'm wrong, but I don't think FSERV is a separate service at the DCC level, but rather uses CHAT (or in place of that, CTCP) and SEND/XMIT together to create something else. This kind of scripting is not exclusive to mIRC either. I've updated the article to reflect this. --Andyluciano 22 Aug 2005, 05:33 (UTC)

That is correct. FSERV uses a DCC CHAT based interface for the user to find and request files, which are then send via a normal DCC SEND. And, yes, it has been implemented under other clients (in some cases as scripts, and in some (as with mIRC) as a built-in feature).

As for DCC2: it has been in the works for several years, and shows little sign of going anywhere. At the core, it is a good idea to completely scrap DCC—which is an atrocious, poorly (and barely) planned mess. I don't remember its particulars, but it would be better to replace it with a far more robust architecture, with a minimum (perhaps utilising scp or other existing secure tunneled protocol) rather than just a new handshaking method. (But i digress, and this is not the place.) —StationaryTraveller 14:03, 21 July 2006 (UTC)[reply]

Since the reply to a PRIVMSG should not be another PRIVMSG, a CTCP reply is implemented with a NOTICE. But is the DCC ACCEPT reply, which is a reply to a reply, a CTCP message or a CTCP reply? I guess that it should be a reply, and implemented with NOTICE, but it would be nice to have this confirmed.

The IRC part of the DCC handshake is done entirely as CTCP non-replies (i.e. PRIVMSG). Thus, the ACCEPT and RESUME messages disobey the RFC-1459 guidelines about automatic responses (intended to prevent runaway loops between robots). Automatic responses (of any kind) to NOTICE are also forbidden (which is why IRC servers don't complain if you send a NOTICE to a non-existant target). So dialogues between robots are limited to a single exchange. One of the basic stupidities of DCC is that it does too much via IRC, rather than getting to its direct connection ASAP, and finishing its handshaking there. —StationaryTraveller 14:15, 21 July 2006 (UTC)[reply]

The only specification I could find for XMIT was an old working draft, which expired long ago. Was XMIT never accepted as a standard?

"DCC standard" is an oxymoron ;) —StationaryTraveller 14:18, 21 July 2006 (UTC)[reply]

Shouldnt we include something about programming libraries avaliable to code such DCC stuffs??

The DCC Send Exploit is less than helpful to me, as I'm supposedly affected after being notified by IRC ops. In particular, this part, "Replacing [character argument] with a string of 14 or more characters ..." doesn't mean a thing; where is this [character argument] supposed to exist?

I feel the description here is ok except for that unexplained part, but a link with more details would be really helpful. —Preceding unsigned comment added by Jimcooncat (talk • contribs) 09:35, 6 February 2008 (UTC)[reply]

I believe this part isnt really even needed anymore at all in the case of mIRC, I have heard that the exploit does not exist any longer in the latest versions of mIRC. This is why I keep removing it, but others revert my changes, very annoying. --Speeddemon8803 (talk) 18:36, 14 May 2009 (UTC)[reply]