From de5c7788667bcd6509eed40b94dc898a8517f679 Mon Sep 17 00:00:00 2001 From: neersighted Date: Tue, 28 Feb 2012 18:52:34 -0800 Subject: [PATCH] DOC changes, permissions --- DOCUMENTATION | 0 docs/THIS SHIT NEEDS IMPROVMENT | 0 docs/bots | 26 - docs/interface | 21 - docs/plugins | 29 - docs/rfc/ctcp.txt | 914 ------- docs/rfc/rfc1459_irc.txt | 3108 ------------------------ docs/rfc/rfc2810_architecture.txt | 455 ---- docs/rfc/rfc2811_channelmanagement.txt | 866 ------- docs/rfc/rfc2812_ircclient.txt | 2918 ---------------------- docs/rfc/rfc2813_ircserver.txt | 1176 --------- plugins/ctcp.py | 0 12 files changed, 9513 deletions(-) mode change 100644 => 100755 DOCUMENTATION delete mode 100755 docs/THIS SHIT NEEDS IMPROVMENT delete mode 100755 docs/bots delete mode 100755 docs/interface delete mode 100755 docs/plugins delete mode 100755 docs/rfc/ctcp.txt delete mode 100755 docs/rfc/rfc1459_irc.txt delete mode 100755 docs/rfc/rfc2810_architecture.txt delete mode 100755 docs/rfc/rfc2811_channelmanagement.txt delete mode 100755 docs/rfc/rfc2812_ircclient.txt delete mode 100755 docs/rfc/rfc2813_ircserver.txt mode change 100644 => 100755 plugins/ctcp.py diff --git a/DOCUMENTATION b/DOCUMENTATION old mode 100644 new mode 100755 diff --git a/docs/THIS SHIT NEEDS IMPROVMENT b/docs/THIS SHIT NEEDS IMPROVMENT deleted file mode 100755 index e69de29..0000000 diff --git a/docs/bots b/docs/bots deleted file mode 100755 index 9c8bc08..0000000 --- a/docs/bots +++ /dev/null @@ -1,26 +0,0 @@ -Other bots we should "borrow" ideas from: - -supybot http://supybot.com/ - - horribly bloated plugin structure, each plugin has its own directory and 4 files (unit testing for plugins what) - -phenny http://inamidst.com/phenny/ - - inspiration for skybot, too much magic and not easy enough to change - -pyfibot http://code.google.com/p/pyfibot/ - - interesting, but lots of magic - -rbot http://linuxbrit.co.uk/rbot/ - - ruby - - lots of plugins - -pyirc http://www.k-pdt.net/pyirc/ - - very simple, not multithreaded - - poor use of regexes, CloudBot has much better parsing, but it implements many more irc control codes - - can convert irc colors to vt100 escape codes -- should implement this - - autoreconnect - -pybot http://labix.org/pybot - - can handle multiple servers, but not multithreaded - - ugly modules - - too many external dependencies - - attempt at NLP diff --git a/docs/interface b/docs/interface deleted file mode 100755 index a9af4fb..0000000 --- a/docs/interface +++ /dev/null @@ -1,21 +0,0 @@ -GOALS: -* simplicity -* as little boilerplate and magic as possible -* multithreaded dispatch - -plugins are located in plugins/ - -input: - -nick -- string, the nickname of whoever sent the message -channel -- string, the channel the message was sent on. Equal to nick if it's a private message. -msg -- string, the line that was sent -raw -- string, the raw full line that was sent -re -- the result of doing re.match(hook, msg) - -attributes and methods of bot: - -say(msg): obvious -reply(msg): say(input.nick + ": " + msg) -msg(target, msg): sends msg to target -(other irc commands, like mode, topic, etc) diff --git a/docs/plugins b/docs/plugins deleted file mode 100755 index 9c481ef..0000000 --- a/docs/plugins +++ /dev/null @@ -1,29 +0,0 @@ -All plugins need to 'from util import hook' if they want to be callable. - -There are three ways to set when a plugin is called using -decorators. - -@hook.command causes it to be callable using normal command -syntax; an argument will register it under that name (so if my function is -called foo and I use @hook.command, .foo will work; if I use -@hook.command("bar"), .bar will work but not .foo). The first argument, inp, -will be the text that occurs after the command. (e.g., "bar" in ".foo bar"). - -@hook.regex takes an argument corresponding to the regex string (not the -compiled regex), followed by optional flags. It will attempt to match the regex -on all inputs; if so, the hooked function will be called with the match object. - -@hook.event requires a parameter; if it's '*", it will trigger on every line. If -it's 'PRIVMSG', it'll trigger on only actual lines of chat (not -nick-changes). The first argument in these cases will be a two-element list of -the form ["#channel", "text"]; I don't know what it's like for NICK or other -'commands'. - -@hook.singlethread indicates that the command should run in its own thread; this -means that you can't use the existing database connection object! - -In addition to the standard argument, plugins can take other arguments; db is -the database object; input corresponds to the triggering line of text, and bot -is the bot itself. - -TODO: describe what can be done with db, input, and bot. \ No newline at end of file diff --git a/docs/rfc/ctcp.txt b/docs/rfc/ctcp.txt deleted file mode 100755 index 87d2e69..0000000 --- a/docs/rfc/ctcp.txt +++ /dev/null @@ -1,914 +0,0 @@ - Ed. Note: The following note is from the author's original email - announcing this CTCP specification file. All of this came after the - original RFC 1459 for the IRC protocol. -Jolo - - From: ben@gnu.ai.mit.edu - Subject: REVISED AND UPDATED CTCP SPECIFICATION - Date: Fri, 12 Aug 94 00:21:54 edt - - As part of documenting the ZenIRC client, I expanded, revised, and - merged two text files that have been around on IRC archive sites for - some time: ctcp.doc, and dcc.protocol. The file "ctcp.doc" by Klaus - Zeuge described the basic CTCP protocol, and most of the CTCP commands - other than DCC. The file Troy Rollo wrote, "dcc.protocol", contained - a description of the CTCP DCC messages as well as the protocols used - by DCC CHAT and DCC file transfers. I have merged the two documents to - produce this one, edited them for clarity, and expanded on them where I - found them unclear while implementing CTCP in the ZenIRC client. - - --Ben - - ---------------------------------------------------------------------- - - The Client-To-Client Protocol (CTCP) - - Klaus Zeuge - Troy Rollo - Ben Mesander - - - The Client-To-Client Protocol is meant to be used as a way to - 1/ in general send structured data (such as graphics, - voice and different font information) between users - clients, and in a more specific case: - 2/ place a query to a users client and getting an answer. - - ***************************************** - BASIC PROTOCOL BETWEEN CLIENTS AND SERVER - ***************************************** - - Characters between an Internet Relay Chat (IRC) client and server are - 8 bit bytes (also known as octets) and can have numeric values from - octal \000 to \377 inclusive (0 to 255 decimal). Some characters are - special: - - CHARS ::= '\000' .. '\377' - NUL ::= '\000' - NL ::= '\n' - CR ::= '\r' - - Note: `\' followed by three digits is used to denote an octal value in this - paper. `\' followed by an alphabetic character is used to denote a C - language style special character, and `..' denotes a range of characters. - - A line sent to a server, or received from a server (here called "low - level messages") consist or zero or more octets (expcept NUL, NL or - CR) with either a NL or CR appended. - - L-CHARS ::= '\001' .. '\011' | '\013' | '\014' | - '\016' .. '\377' - L-LINE ::= L-CHARS* CR LF - - Note: The `*' is used here to denote "zero or more of the preceding class of - characters", and the `|' is used to denote alternation. - - A NUL is never sent to the server. - - ***************** - LOW LEVEL QUOTING - ***************** - - Even though messages to and from IRC servers cannot contain NUL, NL, - or CR, it still might be desirable to send ANY character (in so called - "middle level messages") between clients. In order for this to be - possible, those three characters have to be quoted. Therefore a quote - character is needed. Of course, the quote character itself has to be - quoted too, since it is in-band. - - M-QUOTE ::= '\020' - - (Ie a CNTRL/P). - - When sending a middle level message, if there is a character in the - set { NUL, NL, CR, M-QUOTE } present in the message, that character is - replaced by a two character sequence according to the following table: - - NUL --> M-QUOTE '0' - NL --> M-QUOTE 'n' - CR --> M-QUOTE 'r' - M-QUOTE --> M-QUOTE M-QUOTE - - When receiving a low level message, if there is a M-QUOTE, look at the - next character, and replace those two according to the following table - to get the corresponding middle level message: - - M-QUOTE '0' --> NUL - M-QUOTE 'n' --> NL - M-QUOTE 'r' --> CR - M-QUOTE M-QUOTE --> M-QUOTE - - If the character following M-QUOTE is not any of the listed - characters, that is an error, so drop the M-QUOTE character from the - message, optionally warning the user about it. For example, a string - 'x' M-QUOTE 'y' 'z' from a server dequotes into 'x 'y' 'z'. - - Before low level quoting, a message to the server (and in the opposite - direction: after low level dequoting, a message from the server) looks - like: - - M-LINE ::= CHARS* - - *********** - TAGGED DATA - *********** - - To send both extended data and query/reply pairs between clients, an - extended data format is needed. The extended data are sent in the text - part of a middle level message (and after low level quoting, in the - text part of the low level message). - - To send extended data inside the middle level message, we need some - way to delimit it. This is done by starting and ending extended data - with a delimiter character, defined as: - - X-DELIM ::= '\001' - - As both the starting and ending delimiter looks the same, the first - X-DELIM is called the odd delimiter, and the one that follows, the - even delimiter. The next one after that, an odd delimiter, then and - even, and so on. - - When data are quoted (and conversely, before being dequoted) any number - of characters of any kind except X-DELIM can be used in the extended - data inside the X-DELIM pair. - - X-CHR ::= '\000' | '\002' .. '\377' - - An extended message is either empty (nothing between the odd and even - delimiter), has one or more non-space characters (any character but - '\040') or has one or more non-space characters followed by a space - followed by zero or more characters. - - X-N-AS ::= '\000' | '\002' .. '\037' | '\041' .. '\377' - SPC ::= '\040' - X-MSG ::= | X-N-AS+ | X-N-AS+ SPC X-CHR* - - Note: Here `+' is used to denote "one or more of the previous class of - characters", and `*' is used to denote "zero or more of the previous - class of characters". - - The characters up until the first SPC (or if no SPC, all of the X-MSG) - is called the tag of the extended message. The tag is used to denote - what kind of extended data is used. - - The tag can be *any* string of characters, and if it contains - alphabetics, it is case sensitive, so upper and lower case matters. - - Extended data is only valid in PRIVMSG and NOTICE commands. If the - extended data is a reply to a query, it is sent in a NOTICE, otherwise - it is sent in a PRIVMSG. Both PRIVMSG and NOTICE to a user and to a - channel may contain extended data. - - The text part of a PRIVMSG or NOTICE might contain zero or more - extended messages, intermixed with zero or more chunks of non-extended - data. - - ****************** - CTCP LEVEL QUOTING - ****************** - - In order to be able to send the delimiter X-DELIM inside an extended - data message, it has to be quoted. This introduces another quote - character (which differs from the low level quote character so it - won't have to be quoted yet again). - - X-QUOTE ::= '\134' - - (a back slash - `\'). - - When quoting on the CTCP level, only the actual CTCP message (extended - data, queries, replies) are quoted. This enables users to actually - send X-QUOTE characters at will. The following translations should be - used: - - X-DELIM --> X-QUOTE 'a' - X-QUOTE --> X-QUOTE X-QUOTE - - and when dequoting on the CTCP level, only CTCP messages are dequoted - whereby the following table is used. - - X-QUOTE 'a' --> X-DELIM - X-QUOTE X-QUOTE --> X-QUOTE - - If an X-QUOTE is seen with a character following it other than the - ones above, that is an error and the X-QUOTE character should be - dropped. For example the CTCP-quoted string 'x' X-QUOTE 'y' 'z' - becomes after dequoting, the three character string 'x' 'y' 'z'. - - If a X-DELIM is found outside a CTCP message, the message will contain - the X-DELIM. (This should only happen with the last X-DELIM when there - are an odd number of X-DELIM's in a middle level message.) - - **************** - QUOTING EXAMPLES - **************** - - There are three levels of messages. The highest level (H) is the text - on the user-to-client level. The middle layer (M) is on the level - where CTCP quoting has been applied to the H-level message. The lowest - level (L) is on the client-to-server level, where low level quoting - has been applied to the M-level message. - - The following relations are true, with lowQuote(message) being a - function doing the low level quoting, lowDequote(message) the low - level dequoting function, ctcpQuote(message) the CTCP level quoting - function, ctcpDequote(message) the CTCP level dequoting function, and - ctcpExtract(message) the function which removes all CTCP messages from - a message: - - L = lowQuote(M) - M = ctcpDequote(L) - - M = ctcpQuote(H) - H = ctcpDequote(ctcpExtract(M)) - - When sending a CTCP message embedded in normal text: - - M = ctcpQuote(H1) || '\001' || ctcpQuote(X) || '\001' || ctcpQuote(H2) - - Note: The operator || denotes string concatenation. - - Of course, there might be zero or more normal text messages and zero - or more CTCP messages mixed. - - - --- Example 1 ----------------------------------------------------------------- - - A user (called actor) wanting to send the string: - - Hi there!\nHow are you? - - to user victim, i.e. a message where the user has entered an inline - newline (how this is done, if at all, differs from client to client), - will result internaly in the client in the command: - - PRIVMSG victim :Hi there!\nHow are you? \K? - - which will be CTCP quoted into: - - PRIVMSG victim :Hi there!\nHow are you? \\K? - - which in turn will be low level quoted into: - - PRIVMSG victim :Hi there!\020nHow are you? \\K? - - and sent to the server after appending a newline at the end. - - This will arrive on victim's side as: - - :actor PRIVMSG victim :Hi there!\020nHow are you? \\K? - - (where the \\K would look similar to OK in SIS D47 et. al.) which after - low level dequoting becomes: - - :actor PRIVMSG victim :Hi there!\nHow are you? \\K? - - and after CTCP dequoting: - - :actom PRIVMSG victim :Hi there!\nHow are you? \K? - - How this is displayed differs from client to client, but it suggested - that a line break should occour between the words "there" and "How". - - - --- Example 2 ----------------------------------------------------------------- - - If actor's client wants to send the string "Emacs wins" this might - become the string "\n\t\big\020\001\000\\:" when being SED-encrypted - [SED is a simple encryption protocol between IRC clients implemented - with CTCP. I don't have any reference for it -- Ben] using some key, - so the client starts by CTCP-quoting this string into the string - "\n\t\big\020\\a\000\\\\:" and builds the M-level message: - - PRIVMSG victim :\001SED \n\t\big\020\\a\000\\\\:\001 - - which after low level quoting becomes: - - PRIVMSG victim :\001SED \020n\t\big\020\020\\a\0200\\\\:\001 - - which will be sent to the server, with a newline tacked on. - - On victim's side, the string: - - :actor PRIVMSG victim :\001SED \020n\t\big\020\020\\a\0200\\\\:\001 - - will be received from the server and low level dequoted into: - - :actor PRIVMSG victim :\001SED \n\t\big\020\\a\000\\\\:\001 - - whereafter the string "\n\t\big\020\\a\000\\\\:" will be extracted - and first CTCP dequoted into "\n\t\big\020\001\000\\:" and then - SED decoded getting back "Emacs wins" when using the same key. - - - --- Example 3 ----------------------------------------------------------------- - - If the user actor wants to query the USERINFO of user victim, and is - in the middle of a conversation, the client may decide to tack on - USERINFO request on the end of a normal text message. Let's say actor - wants to send the textmessage "Say hi to Ron\n\t/actor" and the CTCP - request "USERINFO" to victim: - - PRIVMSG victim :Say hi to Ron\n\t/actor - - plus: - - USERINFO - - which after CTCP quoting become: - - PRIVMSG victim :Say hi to Ron\n\t/actor - - plus: - - USERINFO - - which gets merged into: - - PRIVMSG victim :Say hi to Ron\n\t/actor\001USERINFO\001 - - and after low level quoting: - - PRIVMSG victim :Say hi to Ron\020n\t/actor\001USERINFO\001 - - and sent off to the server. - - On victim's side, the message: - - :actor PRIVMSG victim :Say hi to Ron\020n\t/actor\001USERINFO\001 - - arrives. This gets low level dequoted into: - - :actor PRIVMSG victim :Say hi to Ron\n\t/actor\001USERINFO\001 - - and thereafter split up into: - - :actor PRIVMSG victim :Say hi to Ron\n\t/actor - - plus: - - USERINFO - - After CTCP dequoting both, the message: - - :actor PRIVMSG victim :Say hi to Ron\n\t/actor - - gets displayed, while the CTCP command: - - USERINFO - - gets replied to. The reply might be: - - USERINFO :CS student\n\001test\001 - - which gets CTCP quoted into: - - USERINFO :CS student\n\\atest\\a - - and sent in a NOTICE as it is a reply: - - NOTICE actor :\001USERINFO :CS student\n\\atest\\a\001 - - and low level quoted into: - - NOTICE actor :\001USERINFO :CS student\020n\\atest\\a\001 - - after which is it sent to victim's server. - - When arriving on actor's side, the message: - - :victim NOTICE actor :\001USERINFO :CS student\020n\\atest\\a\001 - - gets low level dequoted into: - - :victim NOTICE actor :\001USERINFO :CS student\n\\atest\\a\001 - - At this point, all CTCP replies get extracted, giving 1 CTCP reply and - no normal NOTICE: - - USERINFO :CS student\n\\atest\\a - - The remaining reply gets CTCP dequoted into: - - USERINFO :CS student\n\001test\001 - - and presumly displayed to user actor. - - ******************* - KNOWN EXTENDED DATA - ******************* - - Extended data passed between clients can be used to pass structured - information between them. Currently known extended data types are: - - ACTION - Used to simulate "role playing" on IRC. - DCC - Negotiates file transfers and direct tcp chat - connections between clients. - SED - Used to send encrypted messages between clients. - - ACTION - ====== - This is used by losers on IRC to simulate "role playing" games. An - action message looks like the following: - - \001ACTION barfs on the floor.\001 - - Clients that recieve such a message should format them to indicate the - user who did this is performing an "action". For example, if the user - "actor" sent the above message to the channel "#twilight_zone", other - users clients might display the message as: - - [ACTION] actor->#twilight_zone: barfs on the floor. - - Presumably other users on the channel are suitably impressed. - - DCC - === - DCC stands for something like "Direct Client Connection". CTCP DCC - extended data messages are used to negotiate file transfers between - clients and to negotiate chat connections over tcp connections between - two clients, with no IRC server involved. Connections between clients - involve protocols other than the usual IRC protocol. Due to this - complexity, a full description of the DCC protocol is included - separately at the end of this document in Appendix A. - - SED - === - SED probably stands for something like "Simple Encryption D???". It is - used by clients to exchange encrypted messages between clients. A - message encoded by SED probably looks something like: - - \001SED encrypted-text-goes-here\001 - - Clients which accept such messages should display them in decrypted - form. It would be nice if someone documented this, and included the - encryption scheme in an Appendix B. - - ************************* - KNOWN REQUEST/REPLY PAIRS - ************************* - - A request/reply pair is sent between the two clients in two phases. - The first phase is to send the request. This is done with a "privmsg" - command (either to a nick or to a channel -- it doesn't matter). - - The second phase is to send a reply. This is done with a "notice" - command. - - The known request/reply pairs are for the following commands. - - FINGER - Returns the user's full name, and idle time. - VERSION - The version and type of the client. - SOURCE - Where to obtain a copy of a client. - USERINFO - A string set by the user (never the client coder) - CLIENTINFO - Dynamic master index of what a client knows. - ERRMSG - Used when an error needs to be replied with. - PING - Used to measure the delay of the IRC network - between clients. - TIME - Gets the local date and time from other clients. - - FINGER - ====== - This is used to get a user's real name, and perhaps also the idle time - of the user (this usage has been obsoleted by enhancements to the IRC - protocol. The request is in a "privmsg" and looks like - - \001FINGER\001 - - while the reply is in a "notice" and looks like - - \001FINGER :#\001 - - where the # denotes contains information about the users real name, - login name at clientmachine and idle time and is of type X-N-AS. - - VERSION - ======= - This is used to get information about the name of the other client and - the version of it. The request in a "privmsg" is simply - - \001VERSION\001 - - and the reply - - \001VERSION #:#:#\001 - - where the first # denotes the name of the client, the second # denotes - the version of the client, the third # the enviroment the client is - running in. - - Using - - X-N-CLN ::= '\000' .. '\071' | '\073' .. '\377' - - the client name is a string of type X-N-CLN saying things like "Kiwi" - or "ircII", the version saying things like "5.2" or "2.1.5c", the - enviroment saying things like "GNU Emacs 18.57.19 under SunOS 4.1.1 on - Sun SLC" or "Compiled with gcc -ansi under Ultrix 4.0 on VAX-11/730". - - - SOURCE - - This is used to get information about where to get a copy of the - client. The request in a "privmsg" is simply - - \001SOURCE\001 - - and the reply is zero or more CTCP replies of the form - - \001SOURCE #:#:#\001 - - followed by an end marker - - \001SOURCE\001 - - where the first # is the name of an Internet host where the client can - be gotten from with anonymous FTP the second # a directory names, and - the third # a space separated list of files to be gotten from that - directory. - - Using - - X-N-SPC ::= '\000' .. '\037' | '\041' .. '\377' - - the name of the FTP site is to be given by name like "cs.bu.edu" or - "funic.funet.fi". - - The file name field is a directory specification optionally followed - by one or more file names, delimited by spaces. If only a directory - name is given, all files in that directory should be copied when - retrieving the clients source. If some files are given, only those - files in that directpry should be copied. Note that the spcification - allows for all characters but space in the names, this includes - allowing :. Examples are "pub/emacs/irc/" to get all files in - directory pub/emacs/irc/, the client should be able to first login as - user "ftp" and the give the command "CD pub/emacs/irc/", followed by - the command "mget *". (It of course has to take care of binary and - prompt mode too). Another example is "/pub/irc Kiwi.5.2.el.Z" in which - case a "CD /pub/irc" and "get Kiwi.5.2.el.Z" is what should be done. - - - USERINFO - ======== - This is used to transmit a string which is settable by the user (and - never should be set by the client). The query is simply - - \001USERINFO\001 - - with the reply - - \001USERINFO :#\001 - - where the # is the value of the string the client's user has set. - - CLIENTINFO - ========== - This is for client developers use to make it easier to show other - client hackers what a certain client knows when it comes to CTCP. The - replies should be fairly verbose explaining what CTCP commands are - understood, what arguments are expected of what type, and what replies - might be expected from the client. - - The query is the word CLIENTINFO in a "privmsg" optionally followed by - a colon and one or more specifying words delimited by spaces, where - the word CLIENTINFO by itself, - - \001CLIENTINFO\001 - - should be replied to by giving a list of known tags (see above in - section TAGGED DATA). This is only intended to be read by humans. - - With one argument, the reply should be a description of how to use - that tag. With two arguments, a description of how to use that - tag's subcommand. And so on. - - ERRMSG - ====== - This is used as a reply whenever an unknown query is seen. Also, when - used as a query, the reply should echo back the text in the query, - together with an indication that no error has happened. Should the - query form be used, it is - - \001ERRMSG #\001 - - where # is a string containing any character, with the reply - - \001ERRMSG # :#\001 - - where the first # is the same string as in the query and the second # - a short text notifying the user that no error has occurred. - - A normal ERRMSG reply which is sent when a corrupted query or some - corrupted extended data is received, looks like - - \001ERRMSG # :#\001 - - where the first # is the the failed query or corrupted extended data - and the second # a text explaining what the problem is, like "unknown - query" or "failed decrypting text". - - PING - ==== - Ping is used to measure the time delay between clients on the IRC - network. A ping query is encoded in a privmsg, and has the form: - - \001PING timestamp\001 - - where `timestamp' is the current time encoded in any form the querying - client finds convienent. The replying client sends back an identical - message inside a notice: - - \001PING timestamp\001 - - The querying client can then subtract the recieved timestamp from the - current time to obtain the delay between clients over the IRC network. - - TIME - ==== - Time queries are used to determine what time it is where another - user's client is running. This can be useful to determine if someone - is probably awake or not, or what timezone they are in. A time query - has the form: - - \001TIME\001 - - On reciept of such a query in a privmsg, clients should reply with a - notice of the form: - - \001TIME :human-readable-time-string\001 - - For example: - - \001TIME :Thu Aug 11 22:52:51 1994 CST\001 - - ******** - EXAMPLES - ******** - - - Sending - - PRIVMSG victim :\001FINGER\001 - - might return - - :victim NOTICE actor :\001FINGER :Please check my USERINFO - instead :Klaus Zeuge (sojge@mizar) 1 second has passed since - victim gave a command last.\001 - - (this is only one line) or why not - - :victim NOTICE actor :\001FINGER :Please check my USERINFO - instead :Klaus Zeuge (sojge@mizar) 427 seconds (7 minutes and - 7 seconds) have passed since victim gave a command last.\001 - - if Klaus Zeuge happens to be lazy? :-) - - Sending - - PRIVMSG victim :\001CLIENTINFO\001 - - might return - - :victim NOTICE actor :\001CLIENTINFO :You can request help of the - commands CLIENTINFO ERRMSG FINGER USERINFO VERSION by giving - an argument to CLIENTINFO.\001 - - Sending - - PRIVMSG victim :\001CLIENTINFO CLIENTINFO\001 - - might return - - :victim NOTICE actor :\001CLIENTINFO :CLIENTINFO with 0 - arguments gives a list of known client query keywords. With 1 - argument, a description of the client query keyword is - returned.\001 - - while sending - - PRIVMSG victim :\001clientinfo clientinfo\001 - - probably will return something like - - :victim NOTICE actor :\001ERRMSG clientinfo clientinfo :Query is - unknown\001 - - as tag "clientinfo" isn't known. - - Sending - - PRIVMSG victim :\001CLIENTINFO ERRMSG\001 - - might return - - :victim NOTICE actor :\001CLIENTINFO :ERRMSG is the given answer - on seeing an unknown keyword. When seeing the keyword ERRMSG, - it works like an echo.\001 - - Sending - - PRIVMSG victim :\001USERINFO\001 - - might return the somewhat pathetically long - - :victim NOTICE actor :\001USERINFO :I'm studying computer - science in Uppsala, I'm male (somehow, that seems to be an - important matter on IRC:-) and I speak fluent swedish, decent - german, and some english.\001 - - Sending - - PRIVMSG victim :\001VERSION\001 - - might return: - - :victim NOTICE actor :\001VERSION Kiwi:5.2:GNU Emacs - 18.57.19 under SunOS 4.1.1 on Sun - SLC:FTP.Lysator.LiU.SE:/pub/emacs Kiwi-5.2.el.Z - Kiwi.README\001 - - if the client is named Kiwi of version 5.2 and is used under GNU Emacs - 18.57.19 running on a Sun SLCwith SunOS 4.1.1. The client claims a - copy of it can be found with anonymous FTP on FTP.Lysator.LiU.SE after - giving the FTP command "cd /pub/emacs/". There, one should get files - Kiwi-5.2.el.Z and Kiwi.README; presumably one of the files tells how to - proceed with building the client after having gotten the files. - - - ---------------------------------------------------------------------- - - - ********************************************************************** - Appendix A -- A description of the DCC protocol - ********************************************************************** - - By Troy Rollo (troy@plod.cbme.unsw.oz.au) - Revised by Ben Mesander (ben@gnu.ai.mit.edu) - - Troy Rollo, the original implementor of the DCC protocol, said - that the DCC protocol was never designed to be portable to clients - other than IRCII. However, time has shown that DCC is useable in - environments other than IRCII. IRC clients in diverse languages, such - as ksh, elisp, C, and perl have all had DCC implementations. - - Why DCC? - ======== - - DCC allows the user to overcome some limitations of the IRC - server network and to have a somewhat more secure chat connection - while still in an IRC-oriented protocol. - - DCC uses direct TCP connections between the clients taking - part to carry data. There is no flood control, so packets can be sent - at full speed, and there is no dependance on server links (or load - imposed on them). In addition, since only the initial handshake for - DCC conections is passed through the IRC network, it makes it harder - for operators with cracked servers to spy on personal messages. - - How? - ==== - - The initial socket for a DCC connection is created - by the side that initiates (Offers) the connection. This socket - should be a TCP socket bound to INADDR_ANY, listening for - connections. - - The Initiating client, on creating the socket, should - send its details to the target client using the CTCP command - DCC. This command takes the form: - - DCC type argument address port [size] - - type - The connection type. - argument - The connectin type dependant argument. - address - The host address of the initiator as an integer. - port - The port or the socket on which the initiator expects - to receive the connection. - size - If the connection type is "SEND" (see below), then size - will indicate the size of the file being offered. Obsolete - IRCII clients do not send this, so be prepared if this is - not present. - - The address, port, and size should be sent as ASCII representations of - the decimal integer formed by converting the values to host byte order - and treating them as an unsigned long, unsigned short, and unsigned - long respectively. - - Implementations of the DCC protocol should be prepared to - accept further arguments in a CTCP DCC message. There has been some - discussion of adding another argument that would specify the type of - file being transferred - text, binary, and perhaps others if DCC is - implemented on operating systems other than UNIX. If additional - arguments are added to the protocol, they should have semantics such - that clients which ignore them will interoperate with clients that - don't in a sensible way. - - The following DCC connection types are defined: - - Type Purpose Argument - CHAT To carry on a semi-secure conversation the string "chat" - SEND To send a file to the recipient the file name - - Although the following subcommand is included in the IRCII DCC command, - it does _not_ transmit a DCC request via IRC, and thus is not - discussed in this document: - - TALK Establishes a TALK connection - - - Implementation - ============== - - The CHAT and SEND connection types should not be - accepted automatically as this would create the potential for - terrorism. Instead, they should notify the user that an - offer has been made, and allow the user to accept it. - - The recipient should have the opportunity to rename a file - offered with the DCC SEND command prior to retrieving it. It is also - desirable to ensure that the offered file will not overwrite an - existing file. - - Older IRCII clients send the entire pathname of the file being - transmitted. This is annoying, and newer clients should simply send - the filename portion of the file being transmitted. - - The port number should be scrutinized - if the port number is - in the UNIX reserved port range, the connection should only be - accepted with caution. - - If it is not possible in the client implementation language to - handle a 32-bit integer (for instance emacs 18 elisp and ksh 88), then - it is often possible to use the hostname in the originating PRIVMSG. - - The following are the steps which should occur in the clients - (this description assumes use of the BSD socket interface on a UNIX - system). - - Initiator: - DCC command issued. - Create a socket, bind it to INADDR_ANY, port 0, and - make it passive (a listening socket). - Send the recipient a DCC request via CTCP supplying - the address and port of the socket. (This - is ideally taken from the address of the local - side of the socket which is connected to a - server. This is presumably the interface on - the host which is closest to the rest of - the net, and results in one less routing hop - in the case of gateway nodes). - Continue normally until a connection is received. - - On a connection: - Accept the connection. - Close the original passive socket. - Conduct transaction on the new socket. - - Acceptor: - CTCP DCC request received. - Record information on the DCC request and notify the user. - - At this point, the USER should be able to abort (close) the - request, or accept it. The request should be accepted with - a command specifying the sender, type, and argument, or - a subset of these where no ambiguity exists. - - If accepted, create a TCP socket. - Connect the new socket to the address and port supplied. - Conduct the transaction over the socket. - - - Type specific details. - ====================== - - CHAT Data sent across a CHAT connection should be sent line-by-line - without any prefixes or commands. A CHAT connection ends when - one party issues the DCC CLOSE command to their clients, which - causes the socket to be closed and the information on the connection - to be discarded. The terminating character of each line is a - newline character, '\n'. - - FILE Data is sent in packets, rather than dumped in a stream manner. - This allows the DCC SEND connection to survive where an FTP - connection might fail. The size of the packets is up to the - client, and may be set by the user. Smaller packets result - in a higher probability of survival over bad links. - The recipient should acknowledge each packet by transmitting - the total number of bytes received as an unsigned, 4 byte - integer in network byte order. The sender should not continue - to transmit until the recipient has acknowledged all data - already transmitted. Additionally, the sender should not - close the connection until the last byte has been - acknowledged by the recipient. - - Older IRCII clients do not send the file size of the file - being transmitted via DCC. For those clients, note that it is - not possible for the recipient to tell if the entire file has - been received - only the sender has that information, although - IRCII does not report it. Users generally verify the transfer - by checking file sizes. Authors of clients are urged to use - the size feature. - - Note also that no provision is made for text translation. - - The original block size used by IRCII was 1024. Other clients - have adopted this. Note, however, that an implementation should accept - any blocksize. IRCII currently allows a user-settable blocksize. diff --git a/docs/rfc/rfc1459_irc.txt b/docs/rfc/rfc1459_irc.txt deleted file mode 100755 index b2a7c7b..0000000 --- a/docs/rfc/rfc1459_irc.txt +++ /dev/null @@ -1,3108 +0,0 @@ - RFC 1459 - Internet Relay Chat Protocol - - ---------------------------------------------------------------------- - - - Network Working Group J. Oikarinen - Request for Comments: 1459 D. Reed - May 1993 - - Internet Relay Chat Protocol - - Status of This Memo - - This memo defines an Experimental Protocol for the Internet - community. Discussion and suggestions for improvement are requested. - Please refer to the current edition of the "IAB Official Protocol - Standards" for the standardization state and status of this protocol. - Distribution of this memo is unlimited. - - Abstract - - The IRC protocol was developed over the last 4 years since it was - first implemented as a means for users on a BBS to chat amongst - themselves. Now it supports a world-wide network of servers and - clients, and is stringing to cope with growth. Over the past 2 years, - the average number of users connected to the main IRC network has - grown by a factor of 10. - - The IRC protocol is a text-based protocol, with the simplest client - being any socket program capable of connecting to the server. - - Table of Contents - - 1. INTRODUCTION ............................................... 4 - 1.1 Servers ................................................ 4 - 1.2 Clients ................................................ 5 - 1.2.1 Operators .......................................... 5 - 1.3 Channels ................................................ 5 - 1.3.1 Channel Operators .................................... 6 - 2. THE IRC SPECIFICATION ....................................... 7 - 2.1 Overview ................................................ 7 - 2.2 Character codes ......................................... 7 - 2.3 Messages ................................................ 7 - 2.3.1 Message format in 'pseudo' BNF .................... 8 - 2.4 Numeric replies ......................................... 10 - 3. IRC Concepts ................................................ 10 - 3.1 One-to-one communication ................................ 10 - 3.2 One-to-many ............................................. 11 - 3.2.1 To a list .......................................... 11 - 3.2.2 To a group (channel) ............................... 11 - 3.2.3 To a host/server mask .............................. 12 - 3.3 One to all .............................................. 12 - 3.3.1 Client to Client ................................... 12 - 3.3.2 Clients to Server .................................. 12 - 3.3.3 Server to Server ................................... 12 - 4. MESSAGE DETAILS ............................................. 13 - 4.1 Connection Registration ................................. 13 - 4.1.1 Password message ................................... 14 - 4.1.2 Nickname message ................................... 14 - 4.1.3 User message ....................................... 15 - 4.1.4 Server message ..................................... 16 - 4.1.5 Operator message ................................... 17 - 4.1.6 Quit message ....................................... 17 - 4.1.7 Server Quit message ................................ 18 - 4.2 Channel operations ...................................... 19 - 4.2.1 Join message ....................................... 19 - 4.2.2 Part message ....................................... 20 - 4.2.3 Mode message ....................................... 21 - 4.2.3.1 Channel modes ................................. 21 - 4.2.3.2 User modes .................................... 22 - 4.2.4 Topic message ...................................... 23 - 4.2.5 Names message ...................................... 24 - 4.2.6 List message ....................................... 24 - 4.2.7 Invite message ..................................... 25 - 4.2.8 Kick message ....................................... 25 - 4.3 Server queries and commands ............................. 26 - 4.3.1 Version message .................................... 26 - 4.3.2 Stats message ...................................... 27 - 4.3.3 Links message ...................................... 28 - 4.3.4 Time message ....................................... 29 - 4.3.5 Connect message .................................... 29 - 4.3.6 Trace message ...................................... 30 - 4.3.7 Admin message ...................................... 31 - 4.3.8 Info message ....................................... 31 - 4.4 Sending messages ........................................ 32 - 4.4.1 Private messages ................................... 32 - 4.4.2 Notice messages .................................... 33 - 4.5 User-based queries ...................................... 33 - 4.5.1 Who query .......................................... 33 - 4.5.2 Whois query ........................................ 34 - 4.5.3 Whowas message ..................................... 35 - 4.6 Miscellaneous messages .................................. 35 - 4.6.1 Kill message ....................................... 36 - 4.6.2 Ping message ....................................... 37 - 4.6.3 Pong message ....................................... 37 - 4.6.4 Error message ...................................... 38 - 5. OPTIONAL MESSAGES ........................................... 38 - 5.1 Away message ............................................ 38 - 5.2 Rehash command .......................................... 39 - 5.3 Restart command ......................................... 39 - 5.4 Summon message .......................................... 40 - 5.5 Users message ........................................... 40 - 5.6 Operwall command ........................................ 41 - 5.7 Userhost message ........................................ 42 - 5.8 Ison message ............................................ 42 - 6. REPLIES ..................................................... 43 - 6.1 Error Replies ........................................... 43 - 6.2 Command responses ....................................... 48 - 6.3 Reserved numerics ....................................... 56 - 7. Client and server authentication ............................ 56 - 8. Current Implementations Details ............................. 56 - 8.1 Network protocol: TCP ................................... 57 - 8.1.1 Support of Unix sockets ............................ 57 - 8.2 Command Parsing ......................................... 57 - 8.3 Message delivery ........................................ 57 - 8.4 Connection 'Liveness' ................................... 58 - 8.5 Establishing a server-client connection ................. 58 - 8.6 Establishing a server-server connection ................. 58 - 8.6.1 State information exchange when connecting ......... 59 - 8.7 Terminating server-client connections ................... 59 - 8.8 Terminating server-server connections ................... 59 - 8.9 Tracking nickname changes ............................... 60 - 8.10 Flood control of clients ............................... 60 - 8.11 Non-blocking lookups ................................... 61 - 8.11.1 Hostname (DNS) lookups ............................ 61 - 8.11.2 Username (Ident) lookups .......................... 61 - 8.12 Configuration file ..................................... 61 - 8.12.1 Allowing clients to connect ....................... 62 - 8.12.2 Operators ......................................... 62 - 8.12.3 Allowing servers to connect ....................... 62 - 8.12.4 Administrivia ..................................... 63 - 8.13 Channel membership ..................................... 63 - 9. Current problems ............................................ 63 - 9.1 Scalability ............................................. 63 - 9.2 Labels .................................................. 63 - 9.2.1 Nicknames .......................................... 63 - 9.2.2 Channels ........................................... 64 - 9.2.3 Servers ............................................ 64 - 9.3 Algorithms .............................................. 64 - 10. Support and availability ................................... 64 - 11. Security Considerations .................................... 65 - 12. Authors' Addresses ......................................... 65 - - 1. INTRODUCTION - - The IRC (Internet Relay Chat) protocol has been designed over a - number of years for use with text based conferencing. This document - describes the current IRC protocol. - - The IRC protocol has been developed on systems using the TCP/IP - network protocol, although there is no requirement that this remain - the only sphere in which it operates. - - IRC itself is a teleconferencing system, which (through the use of - the client-server model) is well-suited to running on many machines - in a distributed fashion. A typical setup involves a single process - (the server) forming a central point for clients (or other servers) - to connect to, performing the required message delivery/multiplexing - and other functions. - - 1.1 Servers - - The server forms the backbone of IRC, providing a point to which - clients may connect to to talk to each other, and a point for other - servers to connect to, forming an IRC network. The only network - configuration allowed for IRC servers is that of a spanning tree [see - Fig. 1] where each server acts as a central node for the rest of the - net it sees. - - [ Server 15 ] [ Server 13 ] [ Server 14] - / \ / - / \ / - [ Server 11 ] ------ [ Server 1 ] [ Server 12] - / \ / - / \ / - [ Server 2 ] [ Server 3 ] - / \ \ - / \ \ - [ Server 4 ] [ Server 5 ] [ Server 6 ] - / | \ / - / | \ / - / | \____ / - / | \ / - [ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ] - - : - [ etc. ] - : - - [ Fig. 1. Format of IRC server network ] - - 1.2 Clients - - A client is anything connecting to a server that is not another - server. Each client is distinguished from other clients by a unique - nickname having a maximum length of nine (9) characters. See the - protocol grammar rules for what may and may not be used in a - nickname. In addition to the nickname, all servers must have the - following information about all clients: the real name of the host - that the client is running on, the username of the client on that - host, and the server to which the client is connected. - - 1.2.1 Operators - - To allow a reasonable amount of order to be kept within the IRC - network, a special class of clients (operators) is allowed to perform - general maintenance functions on the network. Although the powers - granted to an operator can be considered as 'dangerous', they are - nonetheless required. Operators should be able to perform basic - network tasks such as disconnecting and reconnecting servers as - needed to prevent long-term use of bad network routing. In - recognition of this need, the protocol discussed herein provides for - operators only to be able to perform such functions. See sections - 4.1.7 (SQUIT) and 4.3.5 (CONNECT). - - A more controversial power of operators is the ability to remove a - user from the connected network by 'force', i.e. operators are able - to close the connection between any client and server. The - justification for this is delicate since its abuse is both - destructive and annoying. For further details on this type of - action, see section 4.6.1 (KILL). - - 1.3 Channels - - A channel is a named group of one or more clients which will all - receive messages addressed to that channel. The channel is created - implicitly when the first client joins it, and the channel ceases to - exist when the last client leaves it. While channel exists, any - client can reference the channel using the name of the channel. - - Channels names are strings (beginning with a '&' or '#' character) of - length up to 200 characters. Apart from the the requirement that the - first character being either '&' or '#'; the only restriction on a - channel name is that it may not contain any spaces (' '), a control G - (^G or ASCII 7), or a comma (',' which is used as a list item - separator by the protocol). - - There are two types of channels allowed by this protocol. One is a - distributed channel which is known to all the servers that are - - connected to the network. These channels are marked by the first - character being a only clients on the server where it exists may join - it. These are distinguished by a leading '&' character. On top of - these two types, there are the various channel modes available to - alter the characteristics of individual channels. See section 4.2.3 - (MODE command) for more details on this. - - To create a new channel or become part of an existing channel, a user - is required to JOIN the channel. If the channel doesn't exist prior - to joining, the channel is created and the creating user becomes a - channel operator. If the channel already exists, whether or not your - request to JOIN that channel is honoured depends on the current modes - of the channel. For example, if the channel is invite-only, (+i), - then you may only join if invited. As part of the protocol, a user - may be a part of several channels at once, but a limit of ten (10) - channels is recommended as being ample for both experienced and - novice users. See section 8.13 for more information on this. - - If the IRC network becomes disjoint because of a split between two - servers, the channel on each side is only composed of those clients - which are connected to servers on the respective sides of the split, - possibly ceasing to exist on one side of the split. When the split - is healed, the connecting servers announce to each other who they - think is in each channel and the mode of that channel. If the - channel exists on both sides, the JOINs and MODEs are interpreted in - an inclusive manner so that both sides of the new connection will - agree about which clients are in the channel and what modes the - channel has. - - 1.3.1 Channel Operators - - The channel operator (also referred to as a "chop" or "chanop") on a - given channel is considered to 'own' that channel. In recognition of - this status, channel operators are endowed with certain powers which - enable them to keep control and some sort of sanity in their channel. - As an owner of a channel, a channel operator is not required to have - reasons for their actions, although if their actions are generally - antisocial or otherwise abusive, it might be reasonable to ask an IRC - operator to intervene, or for the usersjust leave and go elsewhere - and form their own channel. - - The commands which may only be used by channel operators are: - - KICK - Eject a client from the channel - MODE - Change the channel's mode - INVITE - Invite a client to an invite-only channel (mode +i) - TOPIC - Change the channel topic in a mode +t channel - - A channel operator is identified by the '@' symbol next to their - nickname whenever it is associated with a channel (ie replies to the - NAMES, WHO and WHOIS commands). - - 2. The IRC Specification - - 2.1 Overview - - The protocol as described herein is for use both with server to - server and client to server connections. There are, however, more - restrictions on client connections (which are considered to be - untrustworthy) than on server connections. - - 2.2 Character codes - - No specific character set is specified. The protocol is based on a a - set of codes which are composed of eight (8) bits, making up an - octet. Each message may be composed of any number of these octets; - however, some octet values are used for control codes which act as - message delimiters. - - Regardless of being an 8-bit protocol, the delimiters and keywords - are such that protocol is mostly usable from USASCII terminal and a - telnet connection. - - Because of IRC's scandanavian origin, the characters {}| are - considered to be the lower case equivalents of the characters []\, - respectively. This is a critical issue when determining the - equivalence of two nicknames. - - 2.3 Messages - - Servers and clients send eachother messages which may or may not - generate a reply. If the message contains a valid command, as - described in later sections, the client should expect a reply as - specified but it is not advised to wait forever for the reply; client - to server and server to server communication is essentially - asynchronous in nature. - - Each IRC message may consist of up to three main parts: the prefix - (optional), the command, and the command parameters (of which there - may be up to 15). The prefix, command, and all parameters are - separated by one (or more) ASCII space character(s) (0x20). - - The presence of a prefix is indicated with a single leading ASCII - colon character (':', 0x3b), which must be the first character of the - message itself. There must be no gap (whitespace) between the colon - and the prefix. The prefix is used by servers to indicate the true - - origin of the message. If the prefix is missing from the message, it - is assumed to have originated from the connection from which it was - received. Clients should not use prefix when sending a message from - themselves; if they use a prefix, the only valid prefix is the - registered nickname associated with the client. If the source - identified by the prefix cannot be found from the server's internal - database, or if the source is registered from a different link than - from which the message arrived, the server must ignore the message - silently. - - The command must either be a valid IRC command or a three (3) digit - number represented in ASCII text. - - IRC messages are always lines of characters terminated with a CR-LF - (Carriage Return - Line Feed) pair, and these messages shall not - exceed 512 characters in length, counting all characters including - the trailing CR-LF. Thus, there are 510 characters maximum allowed - for the command and its parameters. There is no provision for - continuation message lines. See section 7 for more details about - current implementations. - - 2.3.1 Message format in 'pseudo' BNF - - The protocol messages must be extracted from the contiguous stream of - octets. The current solution is to designate two characters, CR and - LF, as message separators. Empty messages are silently ignored, - which permits use of the sequence CR-LF between messages - without extra problems. - - The extracted message is parsed into the components , - and list of parameters matched either by or - components. - - The BNF representation for this is: - - ::= [':' ] - ::= | [ '!' ] [ '@' ] - ::= { } | - ::= ' ' { ' ' } - ::= [ ':' | ] - - ::= - ::= - - ::= CR LF - - NOTES: - - 1) is consists only of SPACE character(s) (0x20). - Specially notice that TABULATION, and all other control - characters are considered NON-WHITE-SPACE. - - 2) After extracting the parameter list, all parameters are equal, - whether matched by or . is just - a syntactic trick to allow SPACE within parameter. - - 3) The fact that CR and LF cannot appear in parameter strings is - just artifact of the message framing. This might change later. - - 4) The NUL character is not special in message framing, and - basically could end up inside a parameter, but as it would - cause extra complexities in normal C string handling. Therefore - NUL is not allowed within messages. - - 5) The last parameter may be an empty string. - - 6) Use of the extended prefix (['!' ] ['@' ]) must - not be used in server to server communications and is only - intended for server to client messages in order to provide - clients with more useful information about who a message is - from without the need for additional queries. - - Most protocol messages specify additional semantics and syntax for - the extracted parameter strings dictated by their position in the - list. For example, many server commands will assume that the first - parameter after the command is the list of targets, which can be - described with: - - ::= [ "," ] - ::= | '@' | | - ::= ('#' | '&') - ::= - ::= see RFC 952 [DNS:4] for details on allowed hostnames - ::= { | | } - ::= ('#' | '$') - ::= - - Other parameter syntaxes are: - - ::= { } - ::= 'a' ... 'z' | 'A' ... 'Z' - ::= '0' ... '9' - ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}' - - ::= - - 2.4 Numeric replies - - Most of the messages sent to the server generate a reply of some - sort. The most common reply is the numeric reply, used for both - errors and normal replies. The numeric reply must be sent as one - message consisting of the sender prefix, the three digit numeric, and - the target of the reply. A numeric reply is not allowed to originate - from a client; any such messages received by a server are silently - dropped. In all other respects, a numeric reply is just like a normal - message, except that the keyword is made up of 3 numeric digits - rather than a string of letters. A list of different replies is - supplied in section 6. - - 3. IRC Concepts. - - This section is devoted to describing the actual concepts behind the - organization of the IRC protocol and how the current - implementations deliver different classes of messages. - - 1--\ - A D---4 - 2--/ \ / - B----C - / \ - 3 E - - Servers: A, B, C, D, E Clients: 1, 2, 3, 4 - - [ Fig. 2. Sample small IRC network ] - - 3.1 One-to-one communication - - Communication on a one-to-one basis is usually only performed by - clients, since most server-server traffic is not a result of servers - talking only to each other. To provide a secure means for clients to - talk to each other, it is required that all servers be able to send a - message in exactly one direction along the spanning tree in order to - reach any client. The path of a message being delivered is the - shortest path between any two points on the spanning tree. - - The following examples all refer to Figure 2 above. - - Example 1: - A message between clients 1 and 2 is only seen by server A, which - sends it straight to client 2. - - Example 2: - A message between clients 1 and 3 is seen by servers A & B, and - client 3. No other clients or servers are allowed see the message. - - Example 3: - A message between clients 2 and 4 is seen by servers A, B, C & D - and client 4 only. - - 3.2 One-to-many - - The main goal of IRC is to provide a forum which allows easy and - efficient conferencing (one to many conversations). IRC offers - several means to achieve this, each serving its own purpose. - - 3.2.1 To a list - - The least efficient style of one-to-many conversation is through - clients talking to a 'list' of users. How this is done is almost - self explanatory: the client gives a list of destinations to which - the message is to be delivered and the server breaks it up and - dispatches a separate copy of the message to each given destination. - This isn't as efficient as using a group since the destination list - is broken up and the dispatch sent without checking to make sure - duplicates aren't sent down each path. - - 3.2.2 To a group (channel) - - In IRC the channel has a role equivalent to that of the multicast - group; their existence is dynamic (coming and going as people join - and leave channels) and the actual conversation carried out on a - channel is only sent to servers which are supporting users on a given - channel. If there are multiple users on a server in the same - channel, the message text is sent only once to that server and then - sent to each client on the channel. This action is then repeated for - each client-server combination until the original message has fanned - out and reached each member of the channel. - - The following examples all refer to Figure 2. - - Example 4: - Any channel with 1 client in it. Messages to the channel go to the - server and then nowhere else. - - Example 5: - 2 clients in a channel. All messages traverse a path as if they - were private messages between the two clients outside a channel. - - Example 6: - Clients 1, 2 and 3 in a channel. All messages to the channel are - sent to all clients and only those servers which must be traversed - by the message if it were a private message to a single client. If - client 1 sends a message, it goes back to client 2 and then via - server B to client 3. - - 3.2.3 To a host/server mask - - To provide IRC operators with some mechanism to send messages to a - large body of related users, host and server mask messages are - provided. These messages are sent to users whose host or server - information match that of the mask. The messages are only sent to - locations where users are, in a fashion similar to that of channels. - - 3.3 One-to-all - - The one-to-all type of message is better described as a broadcast - message, sent to all clients or servers or both. On a large network - of users and servers, a single message can result in a lot of traffic - being sent over the network in an effort to reach all of the desired - destinations. - - For some messages, there is no option but to broadcast it to all - servers so that the state information held by each server is - reasonably consistent between servers. - - 3.3.1 Client-to-Client - - There is no class of message which, from a single message, results in - a message being sent to every other client. - - 3.3.2 Client-to-Server - - Most of the commands which result in a change of state information - (such as channel membership, channel mode, user status, etc) must be - sent to all servers by default, and this distribution may not be - changed by the client. - - 3.3.3 Server-to-Server. - - While most messages between servers are distributed to all 'other' - servers, this is only required for any message that affects either a - user, channel or server. Since these are the basic items found in - - IRC, nearly all messages originating from a server are broadcast to - all other connected servers. - - 4. Message details - - On the following pages are descriptions of each message recognized by - the IRC server and client. All commands described in this section - must be implemented by any server for this protocol. - - Where the reply ERR_NOSUCHSERVER is listed, it means that the - parameter could not be found. The server must not send any - other replies after this for that command. - - The server to which a client is connected is required to parse the - complete message, returning any appropriate errors. If the server - encounters a fatal error while parsing a message, an error must be - sent back to the client and the parsing terminated. A fatal error - may be considered to be incorrect command, a destination which is - otherwise unknown to the server (server, nick or channel names fit - this category), not enough parameters or incorrect privileges. - - If a full set of parameters is presented, then each must be checked - for validity and appropriate responses sent back to the client. In - the case of messages which use parameter lists using the comma as an - item separator, a reply must be sent for each item. - - In the examples below, some messages appear using the full format: - - :Name COMMAND parameter list - - Such examples represent a message from "Name" in transit between - servers, where it is essential to include the name of the original - sender of the message so remote servers may send back a reply along - the correct path. - - 4.1 Connection Registration - - The commands described here are used to register a connection with an - IRC server as either a user or a server as well as correctly - disconnect. - - A "PASS" command is not required for either client or server - connection to be registered, but it must precede the server message - or the latter of the NICK/USER combination. It is strongly - recommended that all server connections have a password in order to - give some level of security to the actual connections. The - recommended order for a client to register is as follows: - - 1. Pass message - 2. Nick message - 3. User message - - 4.1.1 Password message - - Command: PASS - Parameters: - - The PASS command is used to set a 'connection password'. The - password can and must be set before any attempt to register the - connection is made. Currently this requires that clients send a PASS - command before sending the NICK/USER combination and servers *must* - send a PASS command before any SERVER command. The password supplied - must match the one contained in the C/N lines (for servers) or I - lines (for clients). It is possible to send multiple PASS commands - before registering but only the last one sent is used for - verification and it may not be changed once registered. Numeric - Replies: - - ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED - - Example: - - PASS secretpasswordhere - - 4.1.2 Nick message - - Command: NICK - Parameters: [ ] - - NICK message is used to give user a nickname or change the previous - one. The parameter is only used by servers to indicate - how far away a nick is from its home server. A local connection has - a hopcount of 0. If supplied by a client, it must be ignored. - - If a NICK message arrives at a server which already knows about an - identical nickname for another client, a nickname collision occurs. - As a result of a nickname collision, all instances of the nickname - are removed from the server's database, and a KILL command is issued - to remove the nickname from all other server's database. If the NICK - message causing the collision was a nickname change, then the - original (old) nick must be removed as well. - - If the server recieves an identical NICK from a client which is - directly connected, it may issue an ERR_NICKCOLLISION to the local - client, drop the NICK command, and not generate any kills. - - Numeric Replies: - - ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME - ERR_NICKNAMEINUSE ERR_NICKCOLLISION - - Example: - - NICK Wiz ; Introducing new nick "Wiz". - - :WiZ NICK Kilroy ; WiZ changed his nickname to Kilroy. - - 4.1.3 User message - - Command: USER - Parameters: - - The USER message is used at the beginning of connection to specify - the username, hostname, servername and realname of s new user. It is - also used in communication between servers to indicate new user - arriving on IRC, since only after both USER and NICK have been - received from a client does a user become registered. - - Between servers USER must to be prefixed with client's NICKname. - Note that hostname and servername are normally ignored by the IRC - server when the USER command comes from a directly connected client - (for security reasons), but they are used in server to server - communication. This means that a NICK must always be sent to a - remote server when a new user is being introduced to the rest of the - network before the accompanying USER is sent. - - It must be noted that realname parameter must be the last parameter, - because it may contain space characters and must be prefixed with a - colon (':') to make sure this is recognised as such. - - Since it is easy for a client to lie about its username by relying - solely on the USER message, the use of an "Identity Server" is - recommended. If the host which a user connects from has such a - server enabled the username is set to that as in the reply from the - "Identity Server". - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED - - Examples: - - USER guest tolmoon tolsun :Ronnie Reagan - - ; User registering themselves with a - username of "guest" and real name - "Ronnie Reagan". - - :testnick USER guest tolmoon tolsun :Ronnie Reagan - ; message between servers with the - nickname for which the USER command - belongs to - - 4.1.4 Server message - - Command: SERVER - Parameters: - - The server message is used to tell a server that the other end of a - new connection is a server. This message is also used to pass server - data over whole net. When a new server is connected to net, - information about it be broadcast to the whole network. - is used to give all servers some internal information on how far away - all servers are. With a full server list, it would be possible to - construct a map of the entire server tree, but hostmasks prevent this - from being done. - - The SERVER message must only be accepted from either (a) a connection - which is yet to be registered and is attempting to register as a - server, or (b) an existing connection to another server, in which - case the SERVER message is introducing a new server behind that - server. - - Most errors that occur with the receipt of a SERVER command result in - the connection being terminated by the destination host (target - SERVER). Error replies are usually sent using the "ERROR" command - rather than the numeric since the ERROR command has several useful - properties which make it useful here. - - If a SERVER message is parsed and attempts to introduce a server - which is already known to the receiving server, the connection from - which that message must be closed (following the correct procedures), - since a duplicate route to a server has formed and the acyclic nature - of the IRC tree broken. - - Numeric Replies: - - ERR_ALREADYREGISTRED - - Example: - - SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server - ; New server test.oulu.fi introducing - itself and attempting to register. The - name in []'s is the hostname for the - host running test.oulu.fi. - - :tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server - ; Server tolsun.oulu.fi is our uplink - for csd.bu.edu which is 5 hops away. - - 4.1.5 Oper - - Command: OPER - Parameters: - - OPER message is used by a normal user to obtain operator privileges. - The combination of and are required to gain - Operator privileges. - - If the client sending the OPER command supplies the correct password - for the given user, the server then informs the rest of the network - of the new operator by issuing a "MODE +o" for the clients nickname. - - The OPER message is client-server only. - - Numeric Replies: - - ERR_NEEDMOREPARAMS RPL_YOUREOPER - ERR_NOOPERHOST ERR_PASSWDMISMATCH - - Example: - - OPER foo bar ; Attempt to register as an operator - using a username of "foo" and "bar" as - the password. - - 4.1.6 Quit - - Command: QUIT - Parameters: [] - - A client session is ended with a quit message. The server must close - the connection to a client which sends a QUIT message. If a "Quit - Message" is given, this will be sent instead of the default message, - the nickname. - - When netsplits (disconnecting of two servers) occur, the quit message - - is composed of the names of two servers involved, separated by a - space. The first name is that of the server which is still connected - and the second name is that of the server that has become - disconnected. - - If, for some other reason, a client connection is closed without the - client issuing a QUIT command (e.g. client dies and EOF occurs - on socket), the server is required to fill in the quit message with - some sort of message reflecting the nature of the event which - caused it to happen. - - Numeric Replies: - - None. - - Examples: - - QUIT :Gone to have lunch ; Preferred message format. - - 4.1.7 Server quit message - - Command: SQUIT - Parameters: - - The SQUIT message is needed to tell about quitting or dead servers. - If a server wishes to break the connection to another server it must - send a SQUIT message to the other server, using the the name of the - other server as the server parameter, which then closes its - connection to the quitting server. - - This command is also available operators to help keep a network of - IRC servers connected in an orderly fashion. Operators may also - issue an SQUIT message for a remote server connection. In this case, - the SQUIT must be parsed by each server inbetween the operator and - the remote server, updating the view of the network held by each - server as explained below. - - The should be supplied by all operators who execute a SQUIT - for a remote server (that is not connected to the server they are - currently on) so that other operators are aware for the reason of - this action. The is also filled in by servers which may - place an error or similar message here. - - Both of the servers which are on either side of the connection being - closed are required to to send out a SQUIT message (to all its other - server connections) for all other servers which are considered to be - behind that link. - - Similarly, a QUIT message must be sent to the other connected servers - rest of the network on behalf of all clients behind that link. In - addition to this, all channel members of a channel which lost a - member due to the split must be sent a QUIT message. - - If a server connection is terminated prematurely (e.g. the server on - the other end of the link died), the server which detects - this disconnection is required to inform the rest of the network - that the connection has closed and fill in the comment field - with something appropriate. - - Numeric replies: - - ERR_NOPRIVILEGES ERR_NOSUCHSERVER - - Example: - - SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has - been terminated because of "Bad Link". - - :Trillian SQUIT cm22.eng.umd.edu :Server out of control - ; message from Trillian to disconnect - "cm22.eng.umd.edu" from the net - because "Server out of control". - - 4.2 Channel operations - - This group of messages is concerned with manipulating channels, their - properties (channel modes), and their contents (typically clients). - In implementing these, a number of race conditions are inevitable - when clients at opposing ends of a network send commands which will - ultimately clash. It is also required that servers keep a nickname - history to ensure that wherever a parameter is given, the - server check its history in case it has recently been changed. - - 4.2.1 Join message - - Command: JOIN - Parameters: {,} [{,}] - - The JOIN command is used by client to start listening a specific - channel. Whether or not a client is allowed to join a channel is - checked only by the server the client is connected to; all other - servers automatically add the user to the channel when it is received - from other servers. The conditions which affect this are as follows: - - 1. the user must be invited if the channel is invite-only; - - 2. the user's nick/username/hostname must not match any - active bans; - - 3. the correct key (password) must be given if it is set. - - These are discussed in more detail under the MODE command (see - section 4.2.3 for more details). - - Once a user has joined a channel, they receive notice about all - commands their server receives which affect the channel. This - includes MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. The - JOIN command needs to be broadcast to all servers so that each server - knows where to find the users who are on the channel. This allows - optimal delivery of PRIVMSG/NOTICE messages to the channel. - - If a JOIN is successful, the user is then sent the channel's topic - (using RPL_TOPIC) and the list of users who are on the channel (using - RPL_NAMREPLY), which must include the user joining. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN - ERR_INVITEONLYCHAN ERR_BADCHANNELKEY - ERR_CHANNELISFULL ERR_BADCHANMASK - ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS - RPL_TOPIC - - Examples: - - JOIN #foobar ; join channel #foobar. - - JOIN &foo fubar ; join channel &foo using key "fubar". - - JOIN #foo,&bar fubar ; join channel #foo using key "fubar" - and &bar using no key. - - JOIN #foo,#bar fubar,foobar ; join channel #foo using key "fubar". - and channel #bar using key "foobar". - - JOIN #foo,#bar ; join channels #foo and #bar. - - :WiZ JOIN #Twilight_zone ; JOIN message from WiZ - - 4.2.2 Part message - - Command: PART - Parameters: {,} - - The PART message causes the client sending the message to be removed - from the list of active users for all given channels listed in the - parameter string. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL - ERR_NOTONCHANNEL - - Examples: - - PART #twilight_zone ; leave channel "#twilight_zone" - - PART #oz-ops,&group5 ; leave both channels "&group5" and - "#oz-ops". - - 4.2.3 Mode message - - Command: MODE - - The MODE command is a dual-purpose command in IRC. It allows both - usernames and channels to have their mode changed. The rationale for - this choice is that one day nicknames will be obsolete and the - equivalent property will be the channel. - - When parsing MODE messages, it is recommended that the entire message - be parsed first and then the changes which resulted then passed on. - - 4.2.3.1 Channel modes - - Parameters: {[+|-]|o|p|s|i|t|n|b|v} [] [] - [] - - The MODE command is provided so that channel operators may change the - characteristics of `their' channel. It is also required that servers - be able to change channel modes so that channel operators may be - created. - - The various modes available for channels are as follows: - - o - give/take channel operator privileges; - p - private channel flag; - s - secret channel flag; - i - invite-only channel flag; - t - topic settable by channel operator only flag; - n - no messages to channel from clients on the outside; - m - moderated channel; - l - set the user limit to channel; - b - set a ban mask to keep users out; - v - give/take the ability to speak on a moderated channel; - k - set a channel key (password). - - When using the 'o' and 'b' options, a restriction on a total of three - per mode command has been imposed. That is, any combination of 'o' - and - - 4.2.3.2 User modes - - Parameters: {[+|-]|i|w|s|o} - - The user MODEs are typically changes which affect either how the - client is seen by others or what 'extra' messages the client is sent. - A user MODE command may only be accepted if both the sender of the - message and the nickname given as a parameter are both the same. - - The available modes are as follows: - - i - marks a users as invisible; - s - marks a user for receipt of server notices; - w - user receives wallops; - o - operator flag. - - Additional modes may be available later on. - - If a user attempts to make themselves an operator using the "+o" - flag, the attempt should be ignored. There is no restriction, - however, on anyone `deopping' themselves (using "-o"). Numeric - Replies: - - ERR_NEEDMOREPARAMS RPL_CHANNELMODEIS - ERR_CHANOPRIVSNEEDED ERR_NOSUCHNICK - ERR_NOTONCHANNEL ERR_KEYSET - RPL_BANLIST RPL_ENDOFBANLIST - ERR_UNKNOWNMODE ERR_NOSUCHCHANNEL - ERR_USERSDONTMATCH RPL_UMODEIS - ERR_UMODEUNKNOWNFLAG - - Examples: - - Use of Channel Modes: - - MODE #Finnish +im ; Makes #Finnish channel moderated and - 'invite-only'. - - MODE #Finnish +o Kilroy ; Gives 'chanop' privileges to Kilroy on - - channel #Finnish. - - MODE #Finnish +v Wiz ; Allow WiZ to speak on #Finnish. - - MODE #Fins -s ; Removes 'secret' flag from channel - #Fins. - - MODE #42 +k oulu ; Set the channel key to "oulu". - - MODE #eu-opers +l 10 ; Set the limit for the number of users - on channel to 10. - - MODE &oulu +b ; list ban masks set for channel. - - MODE &oulu +b *!*@* ; prevent all users from joining. - - MODE &oulu +b *!*@*.edu ; prevent any user from a hostname - matching *.edu from joining. - - Use of user Modes: - - :MODE WiZ -w ; turns reception of WALLOPS messages - off for WiZ. - - :Angel MODE Angel +i ; Message from Angel to make themselves - invisible. - - MODE WiZ -o ; WiZ 'deopping' (removing operator - status). The plain reverse of this - command ("MODE WiZ +o") must not be - allowed from users since would bypass - the OPER command. - - 4.2.4 Topic message - - Command: TOPIC - Parameters: [] - - The TOPIC message is used to change or view the topic of a channel. - The topic for channel is returned if there is no - given. If the parameter is present, the topic for that - channel will be changed, if the channel modes permit this action. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL - RPL_NOTOPIC RPL_TOPIC - ERR_CHANOPRIVSNEEDED - - Examples: - - :Wiz TOPIC #test :New topic ;User Wiz setting the topic. - - TOPIC #test :another topic ;set the topic on #test to "another - topic". - - TOPIC #test ; check the topic for #test. - - 4.2.5 Names message - - Command: NAMES - Parameters: [{,}] - - By using the NAMES command, a user can list all nicknames that are - visible to them on any channel that they can see. Channel names - which they can see are those which aren't private (+p) or secret (+s) - or those which they are actually on. The parameter - specifies which channel(s) to return information about if valid. - There is no error reply for bad channel names. - - If no parameter is given, a list of all channels and their - occupants is returned. At the end of this list, a list of users who - are visible but either not on any channel or not on a visible channel - are listed as being on `channel' "*". - - Numerics: - - RPL_NAMREPLY RPL_ENDOFNAMES - - Examples: - - NAMES #twilight_zone,#42 ; list visible users on #twilight_zone - and #42 if the channels are visible to - you. - - NAMES ; list all visible channels and users - - 4.2.6 List message - - Command: LIST - Parameters: [{,} []] - - The list message is used to list channels and their topics. If the - parameter is used, only the status of that channel - is displayed. Private channels are listed (without their - topics) as channel "Prv" unless the client generating the query is - actually on that channel. Likewise, secret channels are not listed - - at all unless the client is a member of the channel in question. - - Numeric Replies: - - ERR_NOSUCHSERVER RPL_LISTSTART - RPL_LIST RPL_LISTEND - - Examples: - - LIST ; List all channels. - - LIST #twilight_zone,#42 ; List channels #twilight_zone and #42 - - 4.2.7 Invite message - - Command: INVITE - Parameters: - - The INVITE message is used to invite users to a channel. The - parameter is the nickname of the person to be invited to - the target channel . There is no requirement that the - channel the target user is being invited to must exist or be a valid - channel. To invite a user to a channel which is invite only (MODE - +i), the client sending the invite must be recognised as being a - channel operator on the given channel. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_NOSUCHNICK - ERR_NOTONCHANNEL ERR_USERONCHANNEL - ERR_CHANOPRIVSNEEDED - RPL_INVITING RPL_AWAY - - Examples: - - :Angel INVITE Wiz #Dust ; User Angel inviting WiZ to channel - #Dust - - INVITE Wiz #Twilight_Zone ; Command to invite WiZ to - #Twilight_zone - - 4.2.8 Kick command - - Command: KICK - Parameters: [] - - The KICK command can be used to forcibly remove a user from a - channel. It 'kicks them out' of the channel (forced PART). - - Only a channel operator may kick another user out of a channel. - Each server that receives a KICK message checks that it is valid - (ie the sender is actually a channel operator) before removing - the victim from the channel. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL - ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED - ERR_NOTONCHANNEL - - Examples: - - KICK &Melbourne Matthew ; Kick Matthew from &Melbourne - - KICK #Finnish John :Speaking English - ; Kick John from #Finnish using - "Speaking English" as the reason - (comment). - - :WiZ KICK #Finnish John ; KICK message from WiZ to remove John - from channel #Finnish - - NOTE: - It is possible to extend the KICK command parameters to the - following: - - {,} {,} [] - - 4.3 Server queries and commands - - The server query group of commands has been designed to return - information about any server which is connected to the network. All - servers connected must respond to these queries and respond - correctly. Any invalid response (or lack thereof) must be considered - a sign of a broken server and it must be disconnected/disabled as - soon as possible until the situation is remedied. - - In these queries, where a parameter appears as "", it will - usually mean it can be a nickname or a server or a wildcard name of - some sort. For each parameter, however, only one query and set of - replies is to be generated. - - 4.3.1 Version message - - Command: VERSION - Parameters: [] - - The VERSION message is used to query the version of the server - program. An optional parameter is used to query the version - of the server program which a client is not directly connected to. - - Numeric Replies: - - ERR_NOSUCHSERVER RPL_VERSION - - Examples: - - :Wiz VERSION *.se ; message from Wiz to check the version - of a server matching "*.se" - - VERSION tolsun.oulu.fi ; check the version of server - "tolsun.oulu.fi". - - 4.3.2 Stats message - - Command: STATS - Parameters: [ []] - - The stats message is used to query statistics of certain server. If - parameter is omitted, only the end of stats reply is sent - back. The implementation of this command is highly dependent on the - server which replies, although the server must be able to supply - information as described by the queries below (or similar). - - A query may be given by any single letter which is only checked by - the destination server (if given as the parameter) and is - otherwise passed on by intermediate servers, ignored and unaltered. - The following queries are those found in the current IRC - implementation and provide a large portion of the setup information - for that server. Although these may not be supported in the same way - by other versions, all servers should be able to supply a valid reply - to a STATS query which is consistent with the reply formats currently - used and the purpose of the query. - - The currently supported queries are: - - c - returns a list of servers which the server may connect - to or allow connections from; - h - returns a list of servers which are either forced to be - treated as leaves or allowed to act as hubs; - i - returns a list of hosts which the server allows a client - to connect from; - k - returns a list of banned username/hostname combinations - for that server; - l - returns a list of the server's connections, showing how - - long each connection has been established and the traffic - over that connection in bytes and messages for each - direction; - m - returns a list of commands supported by the server and - the usage count for each if the usage count is non zero; - o - returns a list of hosts from which normal clients may - become operators; - y - show Y (Class) lines from server's configuration file; - u - returns a string showing how long the server has been up. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_STATSCLINE RPL_STATSNLINE - RPL_STATSILINE RPL_STATSKLINE - RPL_STATSQLINE RPL_STATSLLINE - RPL_STATSLINKINFO RPL_STATSUPTIME - RPL_STATSCOMMANDS RPL_STATSOLINE - RPL_STATSHLINE RPL_ENDOFSTATS - - Examples: - - STATS m ; check the command usage for the server - you are connected to - - :Wiz STATS c eff.org ; request by WiZ for C/N line - information from server eff.org - - 4.3.3 Links message - - Command: LINKS - Parameters: [[] ] - - With LINKS, a user can list all servers which are known by the server - answering the query. The returned list of servers must match the - mask, or if no mask is given, the full list is returned. - - If is given in addition to , the LINKS - command is forwarded to the first server found that matches that name - (if any), and that server is then required to answer the query. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_LINKS RPL_ENDOFLINKS - - Examples: - - LINKS *.au ; list all servers which have a name - that matches *.au; - - :WiZ LINKS *.bu.edu *.edu ; LINKS message from WiZ to the first - server matching *.edu for a list of - servers matching *.bu.edu. - - 4.3.4 Time message - - Command: TIME - Parameters: [] - - The time message is used to query local time from the specified - server. If the server parameter is not given, the server handling the - command must reply to the query. - - Numeric Replies: - - ERR_NOSUCHSERVER RPL_TIME - - Examples: - - TIME tolsun.oulu.fi ; check the time on the server - "tolson.oulu.fi" - - Angel TIME *.au ; user angel checking the time on a - server matching "*.au" - - 4.3.5 Connect message - - Command: CONNECT - Parameters: [ []] - - The CONNECT command can be used to force a server to try to establish - a new connection to another server immediately. CONNECT is a - privileged command and is to be available only to IRC Operators. If - a remote server is given then the CONNECT attempt is made by that - server to and . - - Numeric Replies: - - ERR_NOSUCHSERVER ERR_NOPRIVILEGES - ERR_NEEDMOREPARAMS - - Examples: - - CONNECT tolsun.oulu.fi ; Attempt to connect a server to - tolsun.oulu.fi - - :WiZ CONNECT eff.org 6667 csd.bu.edu - ; CONNECT attempt by WiZ to get servers - eff.org and csd.bu.edu connected on port - 6667. - - 4.3.6 Trace message - - Command: TRACE - Parameters: [] - - TRACE command is used to find the route to specific server. Each - server that processes this message must tell the sender about it by - sending a reply indicating it is a pass-through link, forming a chain - of replies similar to that gained from using "traceroute". After - sending this reply back, it must then send the TRACE message to the - next server until given server is reached. If the parameter - is omitted, it is recommended that TRACE command send a message to - the sender telling which servers the current server has direct - connection to. - - If the destination given by "" is an actual server, then the - destination server is required to report all servers and users which - are connected to it, although only operators are permitted to see - users present. If the destination given by is a nickname, - they only a reply for that nickname is given. - - Numeric Replies: - - ERR_NOSUCHSERVER - - If the TRACE message is destined for another server, all intermediate - servers must return a RPL_TRACELINK reply to indicate that the TRACE - passed through it and where its going next. - - RPL_TRACELINK - A TRACE reply may be composed of any number of the following numeric - replies. - - RPL_TRACECONNECTING RPL_TRACEHANDSHAKE - RPL_TRACEUNKNOWN RPL_TRACEOPERATOR - RPL_TRACEUSER RPL_TRACESERVER - RPL_TRACESERVICE RPL_TRACENEWTYPE - RPL_TRACECLASS - - Examples: - - TRACE *.oulu.fi ; TRACE to a server matching *.oulu.fi - - :WiZ TRACE AngelDust ; TRACE issued by WiZ to nick AngelDust - - 4.3.7 Admin command - - Command: ADMIN - Parameters: [] - - The admin message is used to find the name of the administrator of - the given server, or current server if parameter is omitted. - Each server must have the ability to forward ADMIN messages to other - servers. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_ADMINME RPL_ADMINLOC1 - RPL_ADMINLOC2 RPL_ADMINEMAIL - - Examples: - - ADMIN tolsun.oulu.fi ; request an ADMIN reply from - tolsun.oulu.fi - - :WiZ ADMIN *.edu ; ADMIN request from WiZ for first - server found to match *.edu. - - 4.3.8 Info command - - Command: INFO - Parameters: [] - - The INFO command is required to return information which describes - the server: its version, when it was compiled, the patchlevel, when - it was started, and any other miscellaneous information which may be - considered to be relevant. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_INFO RPL_ENDOFINFO - - Examples: - - INFO csd.bu.edu ; request an INFO reply from - csd.bu.edu - - :Avalon INFO *.fi ; INFO request from Avalon for first - server found to match *.fi. - - INFO Angel ; request info from the server that - Angel is connected to. - - 4.4 Sending messages - - The main purpose of the IRC protocol is to provide a base for clients - to communicate with each other. PRIVMSG and NOTICE are the only - messages available which actually perform delivery of a text message - from one client to another - the rest just make it possible and try - to ensure it happens in a reliable and structured manner. - - 4.4.1 Private messages - - Command: PRIVMSG - Parameters: {,} - - PRIVMSG is used to send private messages between users. - is the nickname of the receiver of the message. can also - be a list of names or channels separated with commas. - - The parameter may also me a host mask (#mask) or server - mask ($mask). In both cases the server will only send the PRIVMSG - to those who have a server or host matching the mask. The mask must - have at least 1 (one) "." in it and no wildcards following the - last ".". This requirement exists to prevent people sending messages - to "#*" or "$*", which would broadcast to all users; from - experience, this is abused more than used responsibly and properly. - Wildcards are the '*' and '?' characters. This extension to - the PRIVMSG command is only available to Operators. - - Numeric Replies: - - ERR_NORECIPIENT ERR_NOTEXTTOSEND - ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL - ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS - ERR_NOSUCHNICK - RPL_AWAY - - Examples: - - :Angel PRIVMSG Wiz :Hello are you receiving this message ? - ; Message from Angel to Wiz. - - PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ; - Message to Angel. - - PRIVMSG jto@tolsun.oulu.fi :Hello ! - ; Message to a client on server - - tolsun.oulu.fi with username of "jto". - - PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting. - ; Message to everyone on a server which - has a name matching *.fi. - - PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions - ; Message to all users who come from a - host which has a name matching *.edu. - - 4.4.2 Notice - - Command: NOTICE - Parameters: - - The NOTICE message is used similarly to PRIVMSG. The difference - between NOTICE and PRIVMSG is that automatic replies must never be - sent in response to a NOTICE message. This rule applies to servers - too - they must not send any error reply back to the client on - receipt of a notice. The object of this rule is to avoid loops - between a client automatically sending something in response to - something it received. This is typically used by automatons (clients - with either an AI or other interactive program controlling their - actions) which are always seen to be replying lest they end up in a - loop with another automaton. - - See PRIVMSG for more details on replies and examples. - - 4.5 User based queries - - User queries are a group of commands which are primarily concerned - with finding details on a particular user or group users. When using - wildcards with any of these commands, if they match, they will only - return information on users who are 'visible' to you. The visibility - of a user is determined as a combination of the user's mode and the - common set of channels you are both on. - - 4.5.1 Who query - - Command: WHO - Parameters: [ []] - - The WHO message is used by a client to generate a query which returns - a list of information which 'matches' the parameter given by - the client. In the absence of the parameter, all visible - (users who aren't invisible (user mode +i) and who don't have a - common channel with the requesting client) are listed. The same - result can be achieved by using a of "0" or any wildcard which - - will end up matching every entry possible. - - The passed to WHO is matched against users' host, server, real - name and nickname if the channel cannot be found. - - If the "o" parameter is passed only operators are returned according - to the name mask supplied. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_WHOREPLY RPL_ENDOFWHO - - Examples: - - WHO *.fi ; List all users who match against - "*.fi". - - WHO jto* o ; List all users with a match against - "jto*" if they are an operator. - - 4.5.2 Whois query - - Command: WHOIS - Parameters: [] [,[,...]] - - This message is used to query information about particular user. The - server will answer this message with several numeric messages - indicating different statuses of each user which matches the nickmask - (if you are entitled to see them). If no wildcard is present in the - , any information about that nick which you are allowed to - see is presented. A comma (',') separated list of nicknames may be - given. - - The latter version sends the query to a specific server. It is - useful if you want to know how long the user in question has been - idle as only local server (ie. the server the user is directly - connected to) knows that information, while everything else is - globally known. - - Numeric Replies: - - ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN - RPL_WHOISUSER RPL_WHOISCHANNELS - RPL_WHOISCHANNELS RPL_WHOISSERVER - RPL_AWAY RPL_WHOISOPERATOR - RPL_WHOISIDLE ERR_NOSUCHNICK - RPL_ENDOFWHOIS - - Examples: - - WHOIS wiz ; return available user information - about nick WiZ - - WHOIS eff.org trillian ; ask server eff.org for user - information about trillian - - 4.5.3 Whowas - - Command: WHOWAS - Parameters: [ []] - - Whowas asks for information about a nickname which no longer exists. - This may either be due to a nickname change or the user leaving IRC. - In response to this query, the server searches through its nickname - history, looking for any nicks which are lexically the same (no wild - card matching here). The history is searched backward, returning the - most recent entry first. If there are multiple entries, up to - replies will be returned (or all of them if no - parameter is given). If a non-positive number is passed as being - , then a full search is done. - - Numeric Replies: - - ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK - RPL_WHOWASUSER RPL_WHOISSERVER - RPL_ENDOFWHOWAS - - Examples: - - WHOWAS Wiz ; return all information in the nick - history about nick "WiZ"; - - WHOWAS Mermaid 9 ; return at most, the 9 most recent - entries in the nick history for - "Mermaid"; - - WHOWAS Trillian 1 *.edu ; return the most recent history for - "Trillian" from the first server found - to match "*.edu". - - 4.6 Miscellaneous messages - - Messages in this category do not fit into any of the above categories - but are nonetheless still a part of and required by the protocol. - - 4.6.1 Kill message - - Command: KILL - Parameters: - - The KILL message is used to cause a client-server connection to be - closed by the server which has the actual connection. KILL is used - by servers when they encounter a duplicate entry in the list of valid - nicknames and is used to remove both entries. It is also available - to operators. - - Clients which have automatic reconnect algorithms effectively make - this command useless since the disconnection is only brief. It does - however break the flow of data and can be used to stop large amounts - of being abused, any user may elect to receive KILL messages - generated for others to keep an 'eye' on would be trouble spots. - - In an arena where nicknames are required to be globally unique at all - times, KILL messages are sent whenever 'duplicates' are detected - (that is an attempt to register two users with the same nickname) in - the hope that both of them will disappear and only 1 reappear. - - The comment given must reflect the actual reason for the KILL. For - server-generated KILLs it usually is made up of details concerning - the origins of the two conflicting nicknames. For users it is left - up to them to provide an adequate reason to satisfy others who see - it. To prevent/discourage fake KILLs from being generated to hide - the identify of the KILLer, the comment also shows a 'kill-path' - which is updated by each server it passes through, each prepending - its name to the path. - - Numeric Replies: - - ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS - ERR_NOSUCHNICK ERR_CANTKILLSERVER - - KILL David (csd.bu.edu <- tolsun.oulu.fi) - ; Nickname collision between csd.bu.edu - and tolson.oulu.fi - - NOTE: - It is recommended that only Operators be allowed to kill other users - with KILL message. In an ideal world not even operators would need - to do this and it would be left to servers to deal with. - - 4.6.2 Ping message - - Command: PING - Parameters: [] - - The PING message is used to test the presence of an active client at - the other end of the connection. A PING message is sent at regular - intervals if no other activity detected coming from a connection. If - a connection fails to respond to a PING command within a set amount - of time, that connection is closed. - - Any client which receives a PING message must respond to - (server which sent the PING message out) as quickly as possible with - an appropriate PONG message to indicate it is still there and alive. - Servers should not respond to PING commands but rely on PINGs from - the other end of the connection to indicate the connection is alive. - If the parameter is specified, the PING message gets - forwarded there. - - Numeric Replies: - - ERR_NOORIGIN ERR_NOSUCHSERVER - - Examples: - - PING tolsun.oulu.fi ; server sending a PING message to - another server to indicate it is still - alive. - - PING WiZ ; PING message being sent to nick WiZ - - 4.6.3 Pong message - - Command: PONG - Parameters: [] - - PONG message is a reply to ping message. If parameter is - given this message must be forwarded to given daemon. The - parameter is the name of the daemon who has responded to PING message - and generated this message. - - Numeric Replies: - - ERR_NOORIGIN ERR_NOSUCHSERVER - - Examples: - - PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to - - tolsun.oulu.fi - - 4.6.4 Error - - Command: ERROR - Parameters: - - The ERROR command is for use by servers when reporting a serious or - fatal error to its operators. It may also be sent from one server to - another but must not be accepted from any normal unknown clients. - - An ERROR message is for use for reporting errors which occur with a - server-to-server link only. An ERROR message is sent to the server - at the other end (which sends it to all of its connected operators) - and to all operators currently connected. It is not to be passed - onto any other servers by a server if it is received from a server. - - When a server sends a received ERROR message to its operators, the - message should be encapsulated inside a NOTICE message, indicating - that the client was not responsible for the error. - - Numerics: - - None. - - Examples: - - ERROR :Server *.fi already exists; ERROR message to the other server - which caused this error. - - NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists - ; Same ERROR message as above but sent - to user WiZ on the other server. - - 5. OPTIONALS - - This section describes OPTIONAL messages. They are not required in a - working server implementation of the protocol described herein. In - the absence of the option, an error reply message must be generated - or an unknown command error. If the message is destined for another - server to answer then it must be passed on (elementary parsing - required) The allocated numerics for this are listed with the - messages below. - - 5.1 Away - - Command: AWAY - Parameters: [message] - - With the AWAY message, clients can set an automatic reply string for - any PRIVMSG commands directed at them (not to a channel they are on). - The automatic reply is sent by the server to client sending the - PRIVMSG command. The only replying server is the one to which the - sending client is connected to. - - The AWAY message is used either with one parameter (to set an AWAY - message) or with no parameters (to remove the AWAY message). - - Numeric Replies: - - RPL_UNAWAY RPL_NOWAWAY - - Examples: - - AWAY :Gone to lunch. Back in 5 ; set away message to "Gone to lunch. - Back in 5". - - :WiZ AWAY ; unmark WiZ as being away. - - 5.2 Rehash message - - Command: REHASH - Parameters: None - - The rehash message can be used by the operator to force the server to - re-read and process its configuration file. - - Numeric Replies: - - RPL_REHASHING ERR_NOPRIVILEGES - - Examples: - - REHASH ; message from client with operator - status to server asking it to reread its - configuration file. - - 5.3 Restart message - - Command: RESTART - Parameters: None - - The restart message can only be used by an operator to force a server - restart itself. This message is optional since it may be viewed as a - risk to allow arbitrary people to connect to a server as an operator - and execute this command, causing (at least) a disruption to service. - - The RESTART command must always be fully processed by the server to - which the sending client is connected and not be passed onto other - connected servers. - - Numeric Replies: - - ERR_NOPRIVILEGES - - Examples: - - RESTART ; no parameters required. - - 5.4 Summon message - - Command: SUMMON - Parameters: [] - - The SUMMON command can be used to give users who are on a host - running an IRC server a message asking them to please join IRC. This - message is only sent if the target server (a) has SUMMON enabled, (b) - the user is logged in and (c) the server process can write to the - user's tty (or similar). - - If no parameter is given it tries to summon from the - server the client is connected to is assumed as the target. - - If summon is not enabled in a server, it must return the - ERR_SUMMONDISABLED numeric and pass the summon message onwards. - - Numeric Replies: - - ERR_NORECIPIENT ERR_FILEERROR - ERR_NOLOGIN ERR_NOSUCHSERVER - RPL_SUMMONING - - Examples: - - SUMMON jto ; summon user jto on the server's host - - SUMMON jto tolsun.oulu.fi ; summon user jto on the host which a - server named "tolsun.oulu.fi" is - running. - - 5.5 Users - - Command: USERS - Parameters: [] - - The USERS command returns a list of users logged into the server in a - similar format to who(1), rusers(1) and finger(1). Some people - may disable this command on their server for security related - reasons. If disabled, the correct numeric must be returned to - indicate this. - - Numeric Replies: - - ERR_NOSUCHSERVER ERR_FILEERROR - RPL_USERSSTART RPL_USERS - RPL_NOUSERS RPL_ENDOFUSERS - ERR_USERSDISABLED - - Disabled Reply: - - ERR_USERSDISABLED - - Examples: - - USERS eff.org ; request a list of users logged in on - server eff.org - - :John USERS tolsun.oulu.fi ; request from John for a list of users - logged in on server tolsun.oulu.fi - - 5.6 Operwall message - - Command: WALLOPS - Parameters: Text to be sent to all operators currently online - - Sends a message to all operators currently online. After - implementing WALLOPS as a user command it was found that it was - often and commonly abused as a means of sending a message to a lot - of people (much similar to WALL). Due to this it is recommended - that the current implementation of WALLOPS be used as an - example by allowing and recognising only servers as the senders of - WALLOPS. - - Numeric Replies: - - ERR_NEEDMOREPARAMS - - Examples: - - :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua; WALLOPS - message from csd.bu.edu announcing a - CONNECT message it received and acted - upon from Joshua. - - 5.7 Userhost message - - Command: USERHOST - Parameters: {} - - The USERHOST command takes a list of up to 5 nicknames, each - separated by a space character and returns a list of information - about each nickname that it found. The returned list has each reply - separated by a space. - - Numeric Replies: - - RPL_USERHOST ERR_NEEDMOREPARAMS - - Examples: - - USERHOST Wiz Michael Marty p ;USERHOST request for information on - nicks "Wiz", "Michael", "Marty" and "p" - - 5.8 Ison message - - Command: ISON - Parameters: {} - - The ISON command was implemented to provide a quick and efficient - means to get a response about whether a given nickname was currently - on IRC. ISON only takes one (1) parameter: a space-separated list of - nicks. For each nickname in the list that is present, the server - adds that to its reply string. Thus the reply string may return - empty (none of the given nicks are present), an exact copy of the - parameter string (all of them present) or as any other subset of the - set of nicks given in the parameter. The only limit on the number - of nicks that may be checked is that the combined length must not be - too large as to cause the server to chop it off so it fits in 512 - characters. - - ISON is only be processed by the server local to the client sending - the command and thus not passed onto other servers for further - processing. - - Numeric Replies: - - RPL_ISON ERR_NEEDMOREPARAMS - - Examples: - - ISON phone trillian WiZ jarlek Avalon Angel Monstah - ; Sample ISON request for 7 nicks. - - 6. REPLIES - - The following is a list of numeric replies which are generated in - response to the commands given above. Each numeric is given with its - number, name and reply string. - - 6.1 Error Replies. - - 401 ERR_NOSUCHNICK - " :No such nick/channel" - - - Used to indicate the nickname parameter supplied to a - command is currently unused. - - 402 ERR_NOSUCHSERVER - " :No such server" - - - Used to indicate the server name given currently - doesn't exist. - - 403 ERR_NOSUCHCHANNEL - " :No such channel" - - - Used to indicate the given channel name is invalid. - - 404 ERR_CANNOTSENDTOCHAN - " :Cannot send to channel" - - - Sent to a user who is either (a) not on a channel - which is mode +n or (b) not a chanop (or mode +v) on - a channel which has mode +m set and is trying to send - a PRIVMSG message to that channel. - - 405 ERR_TOOMANYCHANNELS - " :You have joined too many \ - channels" - - Sent to a user when they have joined the maximum - number of allowed channels and they try to join - another channel. - - 406 ERR_WASNOSUCHNICK - " :There was no such nickname" - - - Returned by WHOWAS to indicate there is no history - information for that nickname. - - 407 ERR_TOOMANYTARGETS - " :Duplicate recipients. No message \ - - delivered" - - - Returned to a client which is attempting to send a - PRIVMSG/NOTICE using the user@host destination format - and for a user@host which has several occurrences. - - 409 ERR_NOORIGIN - ":No origin specified" - - - PING or PONG message missing the originator parameter - which is required since these commands must work - without valid prefixes. - - 411 ERR_NORECIPIENT - ":No recipient given ()" - 412 ERR_NOTEXTTOSEND - ":No text to send" - 413 ERR_NOTOPLEVEL - " :No toplevel domain specified" - 414 ERR_WILDTOPLEVEL - " :Wildcard in toplevel domain" - - - 412 - 414 are returned by PRIVMSG to indicate that - the message wasn't delivered for some reason. - ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that - are returned when an invalid use of - "PRIVMSG $" or "PRIVMSG #" is attempted. - - 421 ERR_UNKNOWNCOMMAND - " :Unknown command" - - - Returned to a registered client to indicate that the - command sent is unknown by the server. - - 422 ERR_NOMOTD - ":MOTD File is missing" - - - Server's MOTD file could not be opened by the server. - - 423 ERR_NOADMININFO - " :No administrative info available" - - - Returned by a server in response to an ADMIN message - when there is an error in finding the appropriate - information. - - 424 ERR_FILEERROR - ":File error doing on " - - - Generic error message used to report a failed file - operation during the processing of a message. - - 431 ERR_NONICKNAMEGIVEN - ":No nickname given" - - - Returned when a nickname parameter expected for a - command and isn't found. - - 432 ERR_ERRONEUSNICKNAME - " :Erroneus nickname" - - - Returned after receiving a NICK message which contains - characters which do not fall in the defined set. See - section x.x.x for details on valid nicknames. - - 433 ERR_NICKNAMEINUSE - " :Nickname is already in use" - - - Returned when a NICK message is processed that results - in an attempt to change to a currently existing - nickname. - - 436 ERR_NICKCOLLISION - " :Nickname collision KILL" - - - Returned by a server to a client when it detects a - nickname collision (registered of a NICK that - already exists by another server). - - 441 ERR_USERNOTINCHANNEL - " :They aren't on that channel" - - - Returned by the server to indicate that the target - user of the command is not on the given channel. - - 442 ERR_NOTONCHANNEL - " :You're not on that channel" - - - Returned by the server whenever a client tries to - perform a channel effecting command for which the - client isn't a member. - - 443 ERR_USERONCHANNEL - " :is already on channel" - - - Returned when a client tries to invite a user to a - channel they are already on. - - 444 ERR_NOLOGIN - " :User not logged in" - - - Returned by the summon after a SUMMON command for a - user was unable to be performed since they were not - logged in. - - 445 ERR_SUMMONDISABLED - ":SUMMON has been disabled" - - - Returned as a response to the SUMMON command. Must be - returned by any server which does not implement it. - - 446 ERR_USERSDISABLED - ":USERS has been disabled" - - - Returned as a response to the USERS command. Must be - returned by any server which does not implement it. - - 451 ERR_NOTREGISTERED - ":You have not registered" - - - Returned by the server to indicate that the client - must be registered before the server will allow it - to be parsed in detail. - - 461 ERR_NEEDMOREPARAMS - " :Not enough parameters" - - - Returned by the server by numerous commands to - indicate to the client that it didn't supply enough - parameters. - - 462 ERR_ALREADYREGISTRED - ":You may not reregister" - - - Returned by the server to any link which tries to - change part of the registered details (such as - password or user details from second USER message). - - 463 ERR_NOPERMFORHOST - ":Your host isn't among the privileged" - - - Returned to a client which attempts to register with - a server which does not been setup to allow - connections from the host the attempted connection - is tried. - - 464 ERR_PASSWDMISMATCH - ":Password incorrect" - - - Returned to indicate a failed attempt at registering - a connection for which a password was required and - was either not given or incorrect. - - 465 ERR_YOUREBANNEDCREEP - ":You are banned from this server" - - - Returned after an attempt to connect and register - yourself with a server which has been setup to - explicitly deny connections to you. - - 467 ERR_KEYSET - " :Channel key already set" - 471 ERR_CHANNELISFULL - " :Cannot join channel (+l)" - 472 ERR_UNKNOWNMODE - " :is unknown mode char to me" - 473 ERR_INVITEONLYCHAN - " :Cannot join channel (+i)" - 474 ERR_BANNEDFROMCHAN - " :Cannot join channel (+b)" - 475 ERR_BADCHANNELKEY - " :Cannot join channel (+k)" - 481 ERR_NOPRIVILEGES - ":Permission Denied- You're not an IRC operator" - - - Any command requiring operator privileges to operate - must return this error to indicate the attempt was - unsuccessful. - - 482 ERR_CHANOPRIVSNEEDED - " :You're not channel operator" - - - Any command requiring 'chanop' privileges (such as - MODE messages) must return this error if the client - making the attempt is not a chanop on the specified - channel. - - 483 ERR_CANTKILLSERVER - ":You cant kill a server!" - - - Any attempts to use the KILL command on a server - are to be refused and this error returned directly - to the client. - - 491 ERR_NOOPERHOST - ":No O-lines for your host" - - - If a client sends an OPER message and the server has - not been configured to allow connections from the - client's host as an operator, this error must be - returned. - - 501 ERR_UMODEUNKNOWNFLAG - ":Unknown MODE flag" - - - Returned by the server to indicate that a MODE - message was sent with a nickname parameter and that - the a mode flag sent was not recognized. - - 502 ERR_USERSDONTMATCH - ":Cant change mode for other users" - - - Error sent to any user trying to view or change the - user mode for a user other than themselves. - - 6.2 Command responses. - - 300 RPL_NONE - Dummy reply number. Not used. - - 302 RPL_USERHOST - ":[{}]" - - - Reply format used by USERHOST to list replies to - the query list. The reply string is composed as - follows: - - ::= ['*'] '=' <'+'|'-'> - - The '*' indicates whether the client has registered - as an Operator. The '-' or '+' characters represent - whether the client has set an AWAY message or not - respectively. - - 303 RPL_ISON - ":[ {}]" - - - Reply format used by ISON to list replies to the - query list. - - 301 RPL_AWAY - " :" - - 305 RPL_UNAWAY - ":You are no longer marked as being away" - 306 RPL_NOWAWAY - ":You have been marked as being away" - - - These replies are used with the AWAY command (if - allowed). RPL_AWAY is sent to any client sending a - PRIVMSG to a client which is away. RPL_AWAY is only - sent by the server to which the client is connected. - Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the - client removes and sets an AWAY message. - - 311 RPL_WHOISUSER - " * :" - 312 RPL_WHOISSERVER - " :" - 313 RPL_WHOISOPERATOR - " :is an IRC operator" - 317 RPL_WHOISIDLE - " :seconds idle" - 318 RPL_ENDOFWHOIS - " :End of /WHOIS list" - 319 RPL_WHOISCHANNELS - " :{[@|+]}" - - - Replies 311 - 313, 317 - 319 are all replies - generated in response to a WHOIS message. Given that - there are enough parameters present, the answering - server must either formulate a reply out of the above - numerics (if the query nick is found) or return an - error reply. The '*' in RPL_WHOISUSER is there as - the literal character and not as a wild card. For - each reply set, only RPL_WHOISCHANNELS may appear - more than once (for long lists of channel names). - The '@' and '+' characters next to the channel name - indicate whether a client is a channel operator or - has been granted permission to speak on a moderated - channel. The RPL_ENDOFWHOIS reply is used to mark - the end of processing a WHOIS message. - - 314 RPL_WHOWASUSER - " * :" - 369 RPL_ENDOFWHOWAS - " :End of WHOWAS" - - - When replying to a WHOWAS message, a server must use - the replies RPL_WHOWASUSER, RPL_WHOISSERVER or - ERR_WASNOSUCHNICK for each nickname in the presented - - list. At the end of all reply batches, there must - be RPL_ENDOFWHOWAS (even if there was only one reply - and it was an error). - - 321 RPL_LISTSTART - "Channel :Users Name" - 322 RPL_LIST - " <# visible> :" - 323 RPL_LISTEND - ":End of /LIST" - - - Replies RPL_LISTSTART, RPL_LIST, RPL_LISTEND mark - the start, actual replies with data and end of the - server's response to a LIST command. If there are - no channels available to return, only the start - and end reply must be sent. - - 324 RPL_CHANNELMODEIS - " " - - 331 RPL_NOTOPIC - " :No topic is set" - 332 RPL_TOPIC - " :" - - - When sending a TOPIC message to determine the - channel topic, one of two replies is sent. If - the topic is set, RPL_TOPIC is sent back else - RPL_NOTOPIC. - - 341 RPL_INVITING - " " - - - Returned by the server to indicate that the - attempted INVITE message was successful and is - being passed onto the end client. - - 342 RPL_SUMMONING - " :Summoning user to IRC" - - - Returned by a server answering a SUMMON message to - indicate that it is summoning that user. - - 351 RPL_VERSION - ". :" - - - Reply by the server showing its version details. - The is the version of the software being - - used (including any patchlevel revisions) and the - is used to indicate if the server is - running in "debug mode". - - The "comments" field may contain any comments about - the version or further version details. - - 352 RPL_WHOREPLY - " \ - [*][@|+] : " - 315 RPL_ENDOFWHO - " :End of /WHO list" - - - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used - to answer a WHO message. The RPL_WHOREPLY is only - sent if there is an appropriate match to the WHO - query. If there is a list of parameters supplied - with a WHO message, a RPL_ENDOFWHO must be sent - after processing each list item with being - the item. - - 353 RPL_NAMREPLY - " :[[@|+] [[@|+] [...]]]" - 366 RPL_ENDOFNAMES - " :End of /NAMES list" - - - To reply to a NAMES message, a reply pair consisting - of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the - server back to the client. If there is no channel - found as in the query, then only RPL_ENDOFNAMES is - returned. The exception to this is when a NAMES - message is sent with no parameters and all visible - channels and contents are sent back in a series of - RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark - the end. - - 364 RPL_LINKS - " : " - 365 RPL_ENDOFLINKS - " :End of /LINKS list" - - - In replying to the LINKS message, a server must send - replies back using the RPL_LINKS numeric and mark the - end of the list using an RPL_ENDOFLINKS reply. - - 367 RPL_BANLIST - " " - 368 RPL_ENDOFBANLIST - - " :End of channel ban list" - - - When listing the active 'bans' for a given channel, - a server is required to send the list back using the - RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate - RPL_BANLIST is sent for each active banid. After the - banids have been listed (or if none present) a - RPL_ENDOFBANLIST must be sent. - - 371 RPL_INFO - ":" - 374 RPL_ENDOFINFO - ":End of /INFO list" - - - A server responding to an INFO message is required to - send all its 'info' in a series of RPL_INFO messages - with a RPL_ENDOFINFO reply to indicate the end of the - replies. - - 375 RPL_MOTDSTART - ":- Message of the day - " - 372 RPL_MOTD - ":- " - 376 RPL_ENDOFMOTD - ":End of /MOTD command" - - - When responding to the MOTD message and the MOTD file - is found, the file is displayed line by line, with - each line no longer than 80 characters, using - RPL_MOTD format replies. These should be surrounded - by a RPL_MOTDSTART (before the RPL_MOTDs) and an - RPL_ENDOFMOTD (after). - - 381 RPL_YOUREOPER - ":You are now an IRC operator" - - - RPL_YOUREOPER is sent back to a client which has - just successfully issued an OPER message and gained - operator status. - - 382 RPL_REHASHING - " :Rehashing" - - - If the REHASH option is used and an operator sends - a REHASH message, an RPL_REHASHING is sent back to - the operator. - - 391 RPL_TIME - - " :" - - - When replying to the TIME message, a server must send - the reply using the RPL_TIME format above. The string - showing the time need only contain the correct day and - time there. There is no further requirement for the - time string. - - 392 RPL_USERSSTART - ":UserID Terminal Host" - 393 RPL_USERS - ":%-8s %-9s %-8s" - 394 RPL_ENDOFUSERS - ":End of users" - 395 RPL_NOUSERS - ":Nobody logged in" - - - If the USERS message is handled by a server, the - replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and - RPL_NOUSERS are used. RPL_USERSSTART must be sent - first, following by either a sequence of RPL_USERS - or a single RPL_NOUSER. Following this is - RPL_ENDOFUSERS. - - 200 RPL_TRACELINK - "Link \ - " - 201 RPL_TRACECONNECTING - "Try. " - 202 RPL_TRACEHANDSHAKE - "H.S. " - 203 RPL_TRACEUNKNOWN - "???? []" - 204 RPL_TRACEOPERATOR - "Oper " - 205 RPL_TRACEUSER - "User " - 206 RPL_TRACESERVER - "Serv S C \ - @" - 208 RPL_TRACENEWTYPE - " 0 " - 261 RPL_TRACELOG - "File " - - - The RPL_TRACE* are all returned by the server in - response to the TRACE message. How many are - returned is dependent on the the TRACE message and - - whether it was sent by an operator or not. There - is no predefined order for which occurs first. - Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and - RPL_TRACEHANDSHAKE are all used for connections - which have not been fully established and are either - unknown, still attempting to connect or in the - process of completing the 'server handshake'. - RPL_TRACELINK is sent by any server which handles - a TRACE message and has to pass it on to another - server. The list of RPL_TRACELINKs sent in - response to a TRACE command traversing the IRC - network should reflect the actual connectivity of - the servers themselves along that path. - RPL_TRACENEWTYPE is to be used for any connection - which does not fit in the other categories but is - being displayed anyway. - - 211 RPL_STATSLINKINFO - " \ - \ -