1 Newsgroups: alt.irc.ircii,alt.irc
2 Subject: REVISED AND UPDATED CTCP SPECIFICATION
4 --text follows this line--
5 As part of documenting the ZenIRC client, I expanded, revised, and
6 merged two text files that have been around on IRC archive sites for
7 some time: ctcp.doc, and dcc.protocol. The file "ctcp.doc" by Klaus
8 Zeuge described the basic CTCP protocol, and most of the CTCP commands
9 other than DCC. The file Troy Rollo wrote, "dcc.protocol", contained
10 a description of the CTCP DCC messages as well as the protocols used
11 by DCC CHAT and DCC file transfers. I have merged the two documents to
12 produce this one, edited them for clarity, and expanded on them where I
13 found them unclear while implementing CTCP in the ZenIRC client.
15 The result is still far from perfect, but I believe the result to be
16 more useful than the two original documents, therefore I am urging
17 maintainers of IRC archives to replace or supplement "ctcp.doc" and
18 "dcc.protocol" with this expanded and revised "ctcp.doc" file.
20 An alpha test version of the ZenIRC client is available from
21 alpha.gnu.ai.mit.edu in /zenirc/zenirc.tar.gz
23 Comments, criticism, suggestions directly to me; I don't read alt.irc* .
27 -----------------------------------[snip]-----------------------------------
28 ;;; hey emacs, this is -*-Text-*-
29 Klaus Zeuge <sojge@Minsk.DoCS.UU.SE>
30 Troy Rollo <troy@plod.cbme.unsw.oz.au>
31 Ben Mesander <ben@gnu.ai.mit.edu>
33 The Client-To-Client Protocol (CTCP)
35 The Client-To-Client Protocol is meant to be used as a way to
36 1/ in general send structured data (such as graphics,
37 voice and different font information) between users
38 clients, and in a more specific case:
39 2/ place a query to a users client and getting an answer.
41 *****************************************
42 BASIC PROTOCOL BETWEEN CLIENTS AND SERVER
43 *****************************************
45 Characters between an Internet Relay Chat (IRC) client and server are
46 8 bit bytes (also known as octets) and can have numeric values from
47 octal \000 to \377 inclusive (0 to 255 decimal). Some characters are
50 CHARS ::= '\000' .. '\377'
55 Note: `\' followed by three digits is used to denote an octal value in this
56 paper. `\' followed by an alphabetic character is used to denote a C
57 language style special character, and `..' denotes a range of characters.
59 A line sent to a server, or received from a server (here called "low
60 level messages") consist or zero or more octets (expcept NUL, NL or
61 CR) with either a NL or CR appended.
63 L-CHARS ::= '\001' .. '\011' | '\013' | '\014' |
65 L-LINE ::= L-CHARS* CR LF
67 Note: The `*' is used here to denote "zero or more of the preceding class of
68 characters", and the `|' is used to denote alternation.
70 A NUL is never sent to the server.
76 Even though messages to and from IRC servers cannot contain NUL, NL,
77 or CR, it still might be desirable to send ANY character (in so called
78 "middle level messages") between clients. In order for this to be
79 possible, those three characters have to be quoted. Therefore a quote
80 character is needed. Of course, the quote character itself has to be
81 quoted too, since it is in-band.
87 When sending a middle level message, if there is a character in the
88 set { NUL, NL, CR, M-QUOTE } present in the message, that character is
89 replaced by a two character sequence according to the following table:
94 M-QUOTE --> M-QUOTE M-QUOTE
96 When receiving a low level message, if there is a M-QUOTE, look at the
97 next character, and replace those two according to the following table
98 to get the corresponding middle level message:
103 M-QUOTE M-QUOTE --> M-QUOTE
105 If the character following M-QUOTE is not any of the listed
106 characters, that is an error, so drop the M-QUOTE character from the
107 message, optionally warning the user about it. For example, a string
108 'x' M-QUOTE 'y' 'z' from a server dequotes into 'x 'y' 'z'.
110 Before low level quoting, a message to the server (and in the opposite
111 direction: after low level dequoting, a message from the server) looks
120 To send both extended data and query/reply pairs between clients, an
121 extended data format is needed. The extended data are sent in the text
122 part of a middle level message (and after low level quoting, in the
123 text part of the low level message).
125 To send extended data inside the middle level message, we need some
126 way to delimit it. This is done by starting and ending extended data
127 with a delimiter character, defined as:
131 As both the starting and ending delimiter looks the same, the first
132 X-DELIM is called the odd delimiter, and the one that follows, the
133 even delimiter. The next one after that, an odd delimiter, then and
136 When data are quoted (and conversely, before being dequoted) any number
137 of characters of any kind except X-DELIM can be used in the extended
138 data inside the X-DELIM pair.
140 X-CHR ::= '\000' | '\002' .. '\377'
142 An extended message is either empty (nothing between the odd and even
143 delimiter), has one or more non-space characters (any character but
144 '\040') or has one or more non-space characters followed by a space
145 followed by zero or more characters.
147 X-N-AS ::= '\000' | '\002' .. '\037' | '\041' .. '\377'
149 X-MSG ::= | X-N-AS+ | X-N-AS+ SPC X-CHR*
151 Note: Here `+' is used to denote "one or more of the previous class of
152 characters", and `*' is used to denote "zero or more of the previous
153 class of characters".
155 The characters up until the first SPC (or if no SPC, all of the X-MSG)
156 is called the tag of the extended message. The tag is used to denote
157 what kind of extended data is used.
159 The tag can be *any* string of characters, and if it contains
160 alphabetics, it is case sensitive, so upper and lower case matters.
162 Extended data is only valid in PRIVMSG and NOTICE commands. If the
163 extended data is a reply to a query, it is sent in a NOTICE, otherwise
164 it is sent in a PRIVMSG. Both PRIVMSG and NOTICE to a user and to a
165 channel may contain extended data.
167 The text part of a PRIVMSG or NOTICE might contain zero or more
168 extended messages, intermixed with zero or more chunks of non-extended
175 In order to be able to send the delimiter X-DELIM inside an extended
176 data message, it has to be quoted. This introduces another quote
177 character (which differs from the low level quote character so it
178 won't have to be quoted yet again).
182 (a back slash - `\').
184 When quoting on the CTCP level, only the actual CTCP message (extended
185 data, queries, replies) are quoted. This enables users to actually
186 send X-QUOTE characters at will. The following translations should be
189 X-DELIM --> X-QUOTE 'a'
191 X-QUOTE --> X-QUOTE X-QUOTE
193 and when dequoting on the CTCP level, only CTCP messages are dequoted
194 whereby the following table is used.
196 X-QUOTE 'a' --> X-DELIM
197 X-QUOTE X-QUOTE --> X-QUOTE
199 If an X-QUOTE is seen with a character following it other than the
200 ones above, that is an error and the X-QUOTE character should be
201 dropped. For example the CTCP-quoted string 'x' X-QUOTE 'y' 'z'
202 becomes after dequoting, the three character string 'x' 'y' 'z'.
204 If a X-DELIM is found outside a CTCP message, the message will contain
205 the X-DELIM. (This should only happen with the last X-DELIM when there
206 are an odd number of X-DELIM's in a middle level message.)
212 There are three levels of messages. The highest level (H) is the text
213 on the user-to-client level. The middle layer (M) is on the level
214 where CTCP quoting has been applied to the H-level message. The lowest
215 level (L) is on the client-to-server level, where low level quoting
216 has been applied to the M-level message.
218 The following relations are true, with lowQuote(message) being a
219 function doing the low level quoting, lowDequote(message) the low
220 level dequoting function, ctcpQuote(message) the CTCP level quoting
221 function, ctcpDequote(message) the CTCP level dequoting function, and
222 ctcpExtract(message) the function which removes all CTCP messages from
229 H = ctcpDequote(ctcpExtract(M))
231 When sending a CTCP message embedded in normal text:
233 M = ctcpQuote(H1) || '\001' || ctcpQuote(X) || '\001' || ctcpQuote(H2)
235 Note: The operator || denotes string concatenation.
237 Of course, there might be zero or more normal text messages and zero
238 or more CTCP messages mixed.
240 - --- Example 1 -----------------------------------------------------------------
242 A user (called actor) wanting to send the string:
244 Hi there!\nHow are you?
246 to user victim, i.e. a message where the user has entered an inline
247 newline (how this is done, if at all, differs from client to client),
248 will result internally in the client in the command:
250 PRIVMSG victim :Hi there!\nHow are you? \K?
252 which will be CTCP quoted into:
254 PRIVMSG victim :Hi there!\nHow are you? \\K?
256 which in turn will be low level quoted into:
258 PRIVMSG victim :Hi there!\020nHow are you? \\K?
260 and sent to the server after appending a newline at the end.
262 This will arrive on victim's side as:
264 :actor PRIVMSG victim :Hi there!\020nHow are you? \\K?
266 (where the \\K would look similar to OK in SIS D47 et. al.) which after
267 low level dequoting becomes:
269 :actor PRIVMSG victim :Hi there!\nHow are you? \\K?
271 and after CTCP dequoting:
273 :actom PRIVMSG victim :Hi there!\nHow are you? \K?
275 How this is displayed differs from client to client, but it suggested
276 that a line break should occour between the words "there" and "How".
278 - --- Example 2 -----------------------------------------------------------------
280 If actor's client wants to send the string "Emacs wins" this might
281 become the string "\n\t\big\020\001\000\\:" when being SED-encrypted
282 [SED is a simple encryption protocol between IRC clients implemented
283 with CTCP. I don't have any reference for it -- Ben] using some key,
284 so the client starts by CTCP-quoting this string into the string
285 "\n\t\big\020\\a\000\\\\:" and builds the M-level message:
287 PRIVMSG victim :\001SED \n\t\big\020\\a\000\\\\:\001
289 which after low level quoting becomes:
291 PRIVMSG victim :\001SED \020n\t\big\020\020\\a\0200\\\\:\001
293 which will be sent to the server, with a newline tacked on.
295 On victim's side, the string:
297 :actor PRIVMSG victim :\001SED \020n\t\big\020\020\\a\0200\\\\:\001
299 will be received from the server and low level dequoted into:
301 :actor PRIVMSG victim :\001SED \n\t\big\020\\a\000\\\\:\001
303 whereafter the string "\n\t\big\020\\a\000\\\\:" will be extracted
304 and first CTCP dequoted into "\n\t\big\020\001\000\\:" and then
305 SED decoded getting back "Emacs wins" when using the same key.
307 - --- Example 3 -----------------------------------------------------------------
309 If the user actor wants to query the USERINFO of user victim, and is
310 in the middle of a conversation, the client may decide to tack on
311 USERINFO request on the end of a normal text message. Let's say actor
312 wants to send the textmessage "Say hi to Ron\n\t/actor" and the CTCP
313 request "USERINFO" to victim:
315 PRIVMSG victim :Say hi to Ron\n\t/actor
321 which after CTCP quoting become:
323 PRIVMSG victim :Say hi to Ron\n\t/actor
329 which gets merged into:
331 PRIVMSG victim :Say hi to Ron\n\t/actor\001USERINFO\001
333 and after low level quoting:
335 PRIVMSG victim :Say hi to Ron\020n\t/actor\001USERINFO\001
337 and sent off to the server.
339 On victim's side, the message:
341 :actor PRIVMSG victim :Say hi to Ron\020n\t/actor\001USERINFO\001
343 arrives. This gets low level dequoted into:
345 :actor PRIVMSG victim :Say hi to Ron\n\t/actor\001USERINFO\001
347 and thereafter split up into:
349 :actor PRIVMSG victim :Say hi to Ron\n\t/actor
355 After CTCP dequoting both, the message:
357 :actor PRIVMSG victim :Say hi to Ron\n\t/actor
359 gets displayed, while the CTCP command:
363 gets replied to. The reply might be:
365 USERINFO :CS student\n\001test\001
367 which gets CTCP quoted into:
369 USERINFO :CS student\n\\atest\\a
371 and sent in a NOTICE as it is a reply:
373 NOTICE actor :\001USERINFO :CS student\n\\atest\\a\001
375 and low level quoted into:
377 NOTICE actor :\001USERINFO :CS student\020n\\atest\\a\001
379 after which is it sent to victim's server.
381 When arriving on actor's side, the message:
383 :victim NOTICE actor :\001USERINFO :CS student\020n\\atest\\a\001
385 gets low level dequoted into:
387 :victim NOTICE actor :\001USERINFO :CS student\n\\atest\\a\001
389 At this point, all CTCP replies get extracted, giving 1 CTCP reply and
392 USERINFO :CS student\n\\atest\\a
394 The remaining reply gets CTCP dequoted into:
396 USERINFO :CS student\n\001test\001
398 and presumly displayed to user actor.
404 Extended data passed between clients can be used to pass structured
405 information between them. Currently known extended data types are:
407 ACTION - Used to simulate "role playing" on IRC.
408 DCC - Negotiates file transfers and direct tcp chat
409 connections between clients.
410 SED - Used to send encrypted messages between clients.
414 This is used by losers on IRC to simulate "role playing" games. An
415 action message looks like the following:
417 \001ACTION barfs on the floor.\001
419 Clients that recieve such a message should format them to indicate the
420 user who did this is performing an "action". For example, if the user
421 "actor" sent the above message to the channel "#twilight_zone", other
422 users clients might display the message as:
424 [ACTION] actor->#twilight_zone: barfs on the floor.
426 Presumably other users on the channel are suitably impressed.
430 DCC stands for something like "Direct Client Connection". CTCP DCC
431 extended data messages are used to negotiate file transfers between
432 clients and to negotiate chat connections over tcp connections between
433 two clients, with no IRC server involved. Connections between clients
434 involve protocols other than the usual IRC protocol. Due to this
435 complexity, a full description of the DCC protocol is included
436 separately at the end of this document in Appendix A.
440 SED probably stands for something like "Simple Encryption D???". It is
441 used by clients to exchange encrypted messages between clients. A
442 message encoded by SED probably looks something like:
444 \001SED encrypted-text-goes-here\001
446 Clients which accept such messages should display them in decrypted
447 form. It would be nice if someone documented this, and included the
448 encryption scheme in an Appendix B.
450 *************************
451 KNOWN REQUEST/REPLY PAIRS
452 *************************
454 A request/reply pair is sent between the two clients in two phases.
455 The first phase is to send the request. This is done with a "privmsg"
456 command (either to a nick or to a channel -- it doesn't matter).
458 The second phase is to send a reply. This is done with a "notice"
461 The known request/reply pairs are for the following commands.
463 FINGER - Returns the user's full name, and idle time.
464 VERSION - The version and type of the client.
465 SOURCE - Where to obtain a copy of a client.
466 USERINFO - A string set by the user (never the client coder)
467 CLIENTINFO - Dynamic master index of what a client knows.
468 ERRMSG - Used when an error needs to be replied with.
469 PING - Used to measure the delay of the IRC network
471 TIME - Gets the local date and time from other clients.
475 This is used to get a user's real name, and perhaps also the idle time
476 of the user (this usage has been obsoleted by enhancements to the IRC
477 protocol. The request is in a "privmsg" and looks like
481 while the reply is in a "notice" and looks like
485 where the # denotes contains information about the users real name,
486 login name at clientmachine and idle time and is of type X-N-AS.
490 This is used to get information about the name of the other client and
491 the version of it. The request in a "privmsg" is simply
497 \001VERSION #:#:#\001
499 where the first # denotes the name of the client, the second # denotes
500 the version of the client, the third # the enviroment the client is
505 X-N-CLN ::= '\000' .. '\071' | '\073' .. '\377'
507 the client name is a string of type X-N-CLN saying things like "Kiwi"
508 or "ircII", the version saying things like "5.2" or "2.1.5c", the
509 enviroment saying things like "GNU Emacs 18.57.19 under SunOS 4.1.1 on
510 Sun SLC" or "Compiled with gcc -ansi under Ultrix 4.0 on VAX-11/730".
515 This is used to get information about where to get a copy of the
516 client. The request in a "privmsg" is simply
520 and the reply is zero or more CTCP replies of the form
524 followed by an end marker
528 where the first # is the name of an Internet host where the client can
529 be gotten from with anonymous FTP the second # a directory names, and
530 the third # a space separated list of files to be gotten from that
535 X-N-SPC ::= '\000' .. '\037' | '\041' .. '\377'
537 the name of the FTP site is to be given by name like "cs.bu.edu" or
540 The file name field is a directory specification optionally followed
541 by one or more file names, delimited by spaces. If only a directory
542 name is given, all files in that directory should be copied when
543 retrieving the clients source. If some files are given, only those
544 files in that directpry should be copied. Note that the spcification
545 allows for all characters but space in the names, this includes
546 allowing :. Examples are "pub/emacs/irc/" to get all files in
547 directory pub/emacs/irc/, the client should be able to first login as
548 user "ftp" and the give the command "CD pub/emacs/irc/", followed by
549 the command "mget *". (It of course has to take care of binary and
550 prompt mode too). Another example is "/pub/irc Kiwi.5.2.el.Z" in which
551 case a "CD /pub/irc" and "get Kiwi.5.2.el.Z" is what should be done.
556 This is used to transmit a string which is settable by the user (and
557 never should be set by the client). The query is simply
565 where the # is the value of the string the client's user has set.
569 This is for client developers use to make it easier to show other
570 client hackers what a certain client knows when it comes to CTCP. The
571 replies should be fairly verbose explaining what CTCP commands are
572 understood, what arguments are expected of what type, and what replies
573 might be expected from the client.
575 The query is the word CLIENTINFO in a "privmsg" optionally followed by
576 a colon and one or more specifying words delimited by spaces, where
577 the word CLIENTINFO by itself,
581 should be replied to by giving a list of known tags (see above in
582 section TAGGED DATA). This is only intended to be read by humans.
584 With one argument, the reply should be a description of how to use
585 that tag. With two arguments, a description of how to use that
586 tag's subcommand. And so on.
590 This is used as a reply whenever an unknown query is seen. Also, when
591 used as a query, the reply should echo back the text in the query,
592 together with an indication that no error has happened. Should the
593 query form be used, it is
597 where # is a string containing any character, with the reply
601 where the first # is the same string as in the query and the second #
602 a short text notifying the user that no error has occurred.
604 A normal ERRMSG reply which is sent when a corrupted query or some
605 corrupted extended data is received, looks like
609 where the first # is the the failed query or corrupted extended data
610 and the second # a text explaining what the problem is, like "unknown
611 query" or "failed decrypting text".
615 Ping is used to measure the time delay between clients on the IRC
616 network. A ping query is encoded in a privmsg, and has the form:
618 \001PING timestamp\001
620 where `timestamp' is the current time encoded in any form the querying
621 client finds convienent. The replying client sends back an identical
622 message inside a notice:
624 \001PING timestamp\001
626 The querying client can then subtract the recieved timestamp from the
627 current time to obtain the delay between clients over the IRC network.
631 Time queries are used to determine what time it is where another
632 user's client is running. This can be useful to determine if someone
633 is probably awake or not, or what timezone they are in. A time query
638 On reciept of such a query in a privmsg, clients should reply with a
641 \001TIME :human-readable-time-string\001
645 \001TIME :Thu Aug 11 22:52:51 1994 CST\001
654 PRIVMSG victim :\001FINGER\001
658 :victim NOTICE actor :\001FINGER :Please check my USERINFO
659 instead :Klaus Zeuge (sojge@mizar) 1 second has passed since
660 victim gave a command last.\001
662 (this is only one line) or why not
664 :victim NOTICE actor :\001FINGER :Please check my USERINFO
665 instead :Klaus Zeuge (sojge@mizar) 427 seconds (7 minutes and
666 7 seconds) have passed since victim gave a command last.\001
668 if Klaus Zeuge happens to be lazy? :-)
672 PRIVMSG victim :\001CLIENTINFO\001
676 :victim NOTICE actor :\001CLIENTINFO :You can request help of the
677 commands CLIENTINFO ERRMSG FINGER USERINFO VERSION by giving
678 an argument to CLIENTINFO.\001
682 PRIVMSG victim :\001CLIENTINFO CLIENTINFO\001
686 :victim NOTICE actor :\001CLIENTINFO :CLIENTINFO with 0
687 arguments gives a list of known client query keywords. With 1
688 argument, a description of the client query keyword is
693 PRIVMSG victim :\001clientinfo clientinfo\001
695 probably will return something like
697 :victim NOTICE actor :\001ERRMSG clientinfo clientinfo :Query is
700 as tag "clientinfo" isn't known.
704 PRIVMSG victim :\001CLIENTINFO ERRMSG\001
708 :victim NOTICE actor :\001CLIENTINFO :ERRMSG is the given answer
709 on seeing an unknown keyword. When seeing the keyword ERRMSG,
710 it works like an echo.\001
714 PRIVMSG victim :\001USERINFO\001
716 might return the somewhat pathetically long
718 :victim NOTICE actor :\001USERINFO :I'm studying computer
719 science in Uppsala, I'm male (somehow, that seems to be an
720 important matter on IRC:-) and I speak fluent swedish, decent
721 german, and some english.\001
725 PRIVMSG victim :\001VERSION\001
729 :victim NOTICE actor :\001VERSION Kiwi:5.2:GNU Emacs
730 18.57.19 under SunOS 4.1.1 on Sun
731 SLC:FTP.Lysator.LiU.SE:/pub/emacs Kiwi-5.2.el.Z
734 if the client is named Kiwi of version 5.2 and is used under GNU Emacs
735 18.57.19 running on a Sun SLCwith SunOS 4.1.1. The client claims a
736 copy of it can be found with anonymous FTP on FTP.Lysator.LiU.SE after
737 giving the FTP command "cd /pub/emacs/". There, one should get files
738 Kiwi-5.2.el.Z and Kiwi.README; presumably one of the files tells how to
739 proceed with building the client after having gotten the files.
741 **********************************************************************
742 Appendix A -- A description of the DCC protocol
743 **********************************************************************
745 By Troy Rollo (troy@plod.cbme.unsw.oz.au)
746 Revised by Ben Mesander (ben@gnu.ai.mit.edu)
748 Troy Rollo, the original implementor of the DCC protocol, said
749 that the DCC protocol was never designed to be portable to clients
750 other than IRCII. However, time has shown that DCC is useable in
751 environments other than IRCII. IRC clients in diverse languages, such
752 as ksh, elisp, C, and perl have all had DCC implementations.
757 DCC allows the user to overcome some limitations of the IRC
758 server network and to have a somewhat more secure chat connection
759 while still in an IRC-oriented protocol.
761 DCC uses direct TCP connections between the clients taking
762 part to carry data. There is no flood control, so packets can be sent
763 at full speed, and there is no dependance on server links (or load
764 imposed on them). In addition, since only the initial handshake for
765 DCC conections is passed through the IRC network, it makes it harder
766 for operators with cracked servers to spy on personal messages.
771 The initial socket for a DCC connection is created
772 by the side that initiates (Offers) the connection. This socket
773 should be a TCP socket bound to INADDR_ANY, listening for
776 The Initiating client, on creating the socket, should
777 send its details to the target client using the CTCP command
778 DCC. This command takes the form:
780 DCC type argument address port [size]
782 type - The connection type.
783 argument - The connectin type dependant argument.
784 address - The host address of the initiator as an integer.
785 port - The port or the socket on which the initiator expects
786 to receive the connection.
787 size - If the connection type is "SEND" (see below), then size
788 will indicate the size of the file being offered. Obsolete
789 IRCII clients do not send this, so be prepared if this is
792 The address, port, and size should be sent as ASCII representations of
793 the decimal integer formed by converting the values to host byte order
794 and treating them as an unsigned long, unsigned short, and unsigned
797 Implementations of the DCC protocol should be prepared to
798 accept further arguments in a CTCP DCC message. There has been some
799 discussion of adding another argument that would specify the type of
800 file being transferred - text, binary, and perhaps others if DCC is
801 implemented on operating systems other than UNIX. If additional
802 arguments are added to the protocol, they should have semantics such
803 that clients which ignore them will interoperate with clients that
804 don't in a sensible way.
806 The following DCC connection types are defined:
808 Type Purpose Argument
809 CHAT To carry on a semi-secure conversation the string "chat"
810 SEND To send a file to the recipient the file name
812 Although the following subcommand is included in the IRCII DCC command,
813 it does _not_ transmit a DCC request via IRC, and thus is not
814 discussed in this document:
816 TALK Establishes a TALK connection
822 The CHAT and SEND connection types should not be
823 accepted automatically as this would create the potential for
824 terrorism. Instead, they should notify the user that an
825 offer has been made, and allow the user to accept it.
827 The recipient should have the opportunity to rename a file
828 offered with the DCC SEND command prior to retrieving it. It is also
829 desirable to ensure that the offered file will not overwrite an
832 Older IRCII clients send the entire pathname of the file being
833 transmitted. This is annoying, and newer clients should simply send
834 the filename portion of the file being transmitted.
836 The port number should be scrutinized - if the port number is
837 in the UNIX reserved port range, the connection should only be
838 accepted with caution.
840 If it is not possible in the client implementation language to
841 handle a 32-bit integer (for instance emacs 18 elisp and ksh 88), then
842 it is often possible to use the hostname in the originating PRIVMSG.
844 The following are the steps which should occur in the clients
845 (this description assumes use of the BSD socket interface on a UNIX
850 Create a socket, bind it to INADDR_ANY, port 0, and
851 make it passive (a listening socket).
852 Send the recipient a DCC request via CTCP supplying
853 the address and port of the socket. (This
854 is ideally taken from the address of the local
855 side of the socket which is connected to a
856 server. This is presumably the interface on
857 the host which is closest to the rest of
858 the net, and results in one less routing hop
859 in the case of gateway nodes).
860 Continue normally until a connection is received.
863 Accept the connection.
864 Close the original passive socket.
865 Conduct transaction on the new socket.
868 CTCP DCC request received.
869 Record information on the DCC request and notify the user.
871 At this point, the USER should be able to abort (close) the
872 request, or accept it. The request should be accepted with
873 a command specifying the sender, type, and argument, or
874 a subset of these where no ambiguity exists.
876 If accepted, create a TCP socket.
877 Connect the new socket to the address and port supplied.
878 Conduct the transaction over the socket.
881 Type specific details.
882 ======================
884 CHAT Data sent across a CHAT connection should be sent line-by-line
885 without any prefixes or commands. A CHAT connection ends when
886 one party issues the DCC CLOSE command to their clients, which
887 causes the socket to be closed and the information on the connection
888 to be discarded. The terminating character of each line is a
889 newline character, '\n'.
891 FILE Data is sent in packets, rather than dumped in a stream manner.
892 This allows the DCC SEND connection to survive where an FTP
893 connection might fail. The size of the packets is up to the
894 client, and may be set by the user. Smaller packets result
895 in a higher probability of survival over bad links.
896 The recipient should acknowledge each packet by transmitting
897 the total number of bytes received as an unsigned, 4 byte
898 integer in network byte order. The sender should not continue
899 to transmit until the recipient has acknowledged all data
900 already transmitted. Additionally, the sender should not
901 close the connection until the last byte has been
902 acknowledged by the recipient.
904 Older IRCII clients do not send the file size of the file
905 being transmitted via DCC. For those clients, note that it is
906 not possible for the recipient to tell if the entire file has
907 been received - only the sender has that information, although
908 IRCII does not report it. Users generally verify the transfer
909 by checking file sizes. Authors of clients are urged to use
912 Note also that no provision is made for text translation.
914 The original block size used by IRCII was 1024. Other clients
915 have adopted this. Note, however, that an implementation should accept
916 any blocksize. IRCII currently allows a user-settable blocksize.
917 -----------------------------------[snip]-----------------------------------