diff options
| author | tpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da> | 2010-02-24 02:13:59 +0000 |
|---|---|---|
| committer | tpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da> | 2010-02-24 02:13:59 +0000 |
| commit | a6d58bb6052ac8cb01805a48c4ad2f129126116f (patch) | |
| tree | dd867a099fcbb263a8009a9fb22695b87855dad6 /data/doctemplates | |
| download | kvirc-a6d58bb6052ac8cb01805a48c4ad2f129126116f.tar.gz kvirc-a6d58bb6052ac8cb01805a48c4ad2f129126116f.zip | |
Added KDE3 version of kvirc
git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/applications/kvirc@1095341 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Diffstat (limited to 'data/doctemplates')
| -rw-r--r-- | data/doctemplates/Makefile.am | 1 | ||||
| -rw-r--r-- | data/doctemplates/ircintro.template | 60 | ||||
| -rw-r--r-- | data/doctemplates/kvircintro.template | 67 | ||||
| -rw-r--r-- | data/doctemplates/rfc2812.template | 3312 |
4 files changed, 3440 insertions, 0 deletions
diff --git a/data/doctemplates/Makefile.am b/data/doctemplates/Makefile.am new file mode 100644 index 00000000..edd47224 --- /dev/null +++ b/data/doctemplates/Makefile.am @@ -0,0 +1 @@ +EXTRA_DIST = rfc2812.template kvircintro.template ircintro.template diff --git a/data/doctemplates/ircintro.template b/data/doctemplates/ircintro.template new file mode 100644 index 00000000..9b514856 --- /dev/null +++ b/data/doctemplates/ircintro.template @@ -0,0 +1,60 @@ +/* + @doc: ircintro + @title: + Introduction to IRC + @short: + Introduction to IRC + @keyterms: + irc,channel,channels,channel operator,irc server,server,irc network,irc user,irc users,irc client,internet relay chat,nickname,nicknames,irc etiquette + @body: + [big]What is IRC ?[/big][br] + Internet Relay Chat (IRC) is one of the most popular and most interactive services on the Internet. + When you've been wondering 'where the others are?', then IRC is what you're looking for. + IRC allows real-time conversations with people from the whole planet, 24-hours a day, worldwide. + [br] + [big]How does it work ?[/big][br] + IRC consists of various separate networks (or "nets") of IRC servers: machines that allow users to connect to IRC. + The largest nets are EFnet (the original IRC net, often having more than 32,000 people at once), Undernet, IRCnet, DALnet, and NewNet. + Generally, the user (such as you) runs a program (called "irc client") to connect to a server on one of the IRC nets. + The server will relay the informations between you and the "rest" of the network (obviously including the other irc users). + Each user is known on IRC by a nickname (or "nick"), such as smartgal or FunGuy. + To avoid conflicts with other users, it is best to use a nick that is not too common, e.g., "john" is a poor choice. + Some networks allow the registration of nicknames: once you have registered a nickname noone else will be able to use it. + Once connected to an IRC server on an IRC network, you will usually join one or more [b]channels[/b] and converse with other irc users. + On EFnet, there often are more than 12,000 channels, each one devoted to a different topic. + [br] + [big]Channels[/big][br] + Channel names usually begin with a #, as in #irchelp. + The same channels are shared among all IRC servers on the same net, so you do not have to be on the same IRC server as your friends. + Each channel can be joined by a "virtually" unlimited number of users and every word spoken "to the channel" is + seen by all the users that have joined it. + Each channel has a topic that usually describes the ideas being exchanged between users in that moment. + It is a good idea to take a look at the topic before starting to talk "randomly" :). + Channels are run by channel operators, or just "ops" for short, who can control the channel by choosing who may join (by "banning" some users), + who must leave (by "kicking" them out), and even who may speak (by making the channel "moderated")! + Channel ops have complete control over their channel, and their decisions are final. + If you are banned from a channel, send a /msg to a channel op and ask nicely to be let in + (see the /who command in the next section to learn how to find ops). + If they ignore you or /who gives no response because the channel is in secret mode (+s), + just go somewhere else where you are more welcome. + Some IRC networks have a richer hierarchy of channel users and you may find half-operators, channel administrators or + channel owners. + [br] + [big]Just a bit of IRC Etiquette...[/big][br] + You'll find all kinds of people on IRC. Some nice, and some not so nice. + Simply behave as you would in the real world. Most people will be friendly and considerate, if you are as well. + When you join a channel, say hello. Don't expect to get hello's back from everyone, + especially when there are lots of people on the channel. + If you've never visited the channel before and have no idea what to expect, + just sit back and watch for awhile to get a feel for the flow of the channel (thats called "lurking"). + [br] + [big]Finding more info[/big][br] + The web is full of informations about IRC: it's just a matter of typing "IRC" in a search engine. + An user-friendly site to start from might be www.irchelp.org: you will find a huge list of + documents and links that will hopefully answer to all your questions. + You may also give a short read to the [doc:kvircintro]Introduction to KVIrc[/doc] which will + give you an idea of what an IRC client is. + [br] + [big]Well...[/big][br] + Have fun :) +*/ diff --git a/data/doctemplates/kvircintro.template b/data/doctemplates/kvircintro.template new file mode 100644 index 00000000..149590af --- /dev/null +++ b/data/doctemplates/kvircintro.template @@ -0,0 +1,67 @@ +/* + @doc: kvircintro + @title: + Introduction to KVIrc + @short: + Introduction to KVIrc + @keyterms: + KVIrc + @body: + [big]Introduction[/big] + + In really simple words KVIrc is a Chat client: you use it to talk to other + people over the internet. More specifically KVIrc is an IRC client + and if you haven't readed it yet please take a look at the [doc:ircintro]IRC introduction[/doc] + then come back here. Now that you know what IRC is then you already know + that an IRC client acts as a relay for the informations that you + exchange with your IRC server. KVIrc also acts as a filter and provides + an user-friendly interface for the communication protocol that is a bit complex + and rude when seen in its original form (by using telnet for example). + KVIrc also contains a sophisticated scripting language that allows you to + implement automated reactions to the network events. This is something similar + to creating a robot that acts spontaneously after you have told him what to do. + The scripting language allows you to enchance the KVIrc's interface and + to handle special IRC network features that KVIrc itself isn't aware of. + + [big]History[/big] + + The original meaning of the name "KVIrc" was, more or less, "K Visual IRC Client". + The initial K is a common prefix for the applications written for the KDE + desktop environment: this was the case of the initial versions of KVIrc. + Starting from version 2.0.0 the absolute KDE dependancy has been dropped (for several + valid reasons) and the support became optional.[br] + "Visual" was (and is) one of the client goals: having an user-friendly interface to the IRC world. + Many extreme-unix users have misinterpreted the "user-friendly" interface and have tagged + KVIrc as a client for "newbies". Well... that is partially true: KVIrc is ALSO a client for newbies: + A total IRC novice should be able to "chat" in few minutes after installing the program, + preferably without bothering to read any manual. Yes ,I know that it is not in "unix"-style. + On the other side, KVIrc contains a whole bunch of compex features that can be discovered + only by reading the documentation and experimenting. I bet that you can also + find a lot of undocumented tricks :) + + [big]A bit of "philosophy"[/big] + + At the time of writing (Feb 2005) KVIrc approaches release 3.2.0. The small + [b]one-man-project[/b] has grown to the level of a small [b]community[/b]. + People from around the world have joined our development efforts and are + constantly donating their time, eyes and bandwidth in order to make KVIrc + a really good IRC client. Besides of simply giving you a free (as in freedom!) and nice + program for chatting, they are giving you the great opportunity to see what's behind + the scenes: you have the source code for the whole application. + In practical terms this means more or less 300.000 lines of tested, debugged and + commented C++ code, several perl scripts, dozens of makefiles and all the means + that you need to produce a working KVIrc executable on all the supported platforms. + There is a lot of knowledge (some people call it "technology" because it sells better) + inside, ready to be acquired by an attentive reader. Don't forget that the freedom of + building your own executable from the sources gives you the opportunity + of verifying the source itself: for example you might be interested in verifying + that KVIrc will not run any malware code on your machine nor will collect + your private data and sell it to someone while you're happily chatting with a friend. + [b]We call it freedom, please respect it.[/b] + + [big]Well...[/big] + + Have fun :)[br] + [br] + Szymon Stefanek and The KVIrc Development Team +*/ diff --git a/data/doctemplates/rfc2812.template b/data/doctemplates/rfc2812.template new file mode 100644 index 00000000..9d81a1c8 --- /dev/null +++ b/data/doctemplates/rfc2812.template @@ -0,0 +1,3312 @@ +/* + @doc: rfc2812 + @title: + RFC2812 + @short: + The IRC protocol specification (revised) + @keyterms: + irc, protocol, bnf, irc user, irc channel, server protocol, + server messages, server replies, numeric messages + @body: + +[table] + +[tr][td][pre] +Network Working Group, C.Kalt, April 2000 +Request for Comments: 2812 +Updates: 1459 +Category: Informational +[/pre][/td][/tr] + +[tr][td] +[center][big]Internet Relay Chat: Client Protocol[/big][/center] +[/td][/tr] + +[tr][td] +[b]Status of this Memo[/b] +[/td][/tr] + +[tr][td] +This memo provides information for the Internet community. It does +not specify an Internet standard of any kind. Distribution of this +memo is unlimited. +[/td][/tr] + +[tr][td] +[b]Copyright Notice[/b] +[/td][/tr] + +[tr][td] +Copyright (C) The Internet Society (2000). All Rights Reserved. +[/td][/tr] + +[tr][td] +[b]IESG NOTE:[/b] +[/td][/tr] + +[tr][td] +The IRC protocol itself enables several possibilities of transferring +data between clients, and just like with other transfer mechanisms +like email, the receiver of the data has to be careful about how the +data is handled. For more information on security issues with the IRC +protocol, see for example http://www.irchelp.org/irchelp/security/. +[/td][/tr] + +[tr][td] +[b]Abstract[/b] +[/td][/tr] + +[tr][td] +The IRC (Internet Relay Chat) protocol is for use with text based +conferencing; the simplest client being any socket program capable of +connecting to the server. +[p] +This document defines the Client Protocol, and assumes that the +reader is familiar with the IRC Architecture [IRC-ARCH]. +[/td][/tr] + +[tr][td] +[b]Table of Contents[/b] +[/td][/tr] + +[tr][td] +[ul] +[li]1. Labels[/li] +[ul] +[li]1.1 Servers[/li] +[li]1.2 Clients[/li] +[ul] +[li]1.2.1 Users[/li] +[ul] +[li]1.2.1.1 Operators[/li] +[/ul] +[li]1.2.2 Services[/li] +[/ul] +[li]1.3 Channels[/li] +[/ul] +[li]2. The IRC Client Specification[/li] +[ul] +[li]2.1 Overview[/li] +[li]2.2 Character codes[/li] +[li]2.3 Messages[/li] +[ul] +[li]2.3.1 Message format in Augmented BNF[/li] +[/ul] +[li]2.4 Numeric replies[/li] +[li]2.5 Wildcard expressions[/li] +[/ul] +[li]3. Message Details[/li] +[ul] +[li]3.1 Connection Registration[/li] +[ul] +[li]3.1.1 Password message[/li] +[li]3.1.2 Nick message[/li] +[li]3.1.3 User message[/li] +[li]3.1.4 Oper message[/li] +[li]3.1.5 User mode message[/li] +[li]3.1.6 Service message[/li] +[li]3.1.7 Quit[/li] +[li]3.1.8 Squit[/li] +[/ul] +[li]3.2 Channel operations[/li] +[ul] +[li]3.2.1 Join message[/li] +[li]3.2.2 Part message[/li] +[li]3.2.3 Channel mode message[/li] +[li]3.2.4 Topic message[/li] +[li]3.2.5 Names message[/li] +[li]3.2.6 List message[/li] +[li]3.2.7 Invite message[/li] +[li]3.2.8 Kick command[/li] +[/ul] +[li]3.3 Sending messages[/li] +[ul] +[li]3.3.1 Private messages[/li] +[li]3.3.2 Notice[/li] +[/ul] +[li]3.4 Server queries and commands[/li] +[ul] +[li]3.4.1 Motd message[/li] +[li]3.4.2 Lusers message[/li] +[li]3.4.3 Version message[/li] +[li]3.4.4 Stats message[/li] +[li]3.4.5 Links message[/li] +[li]3.4.6 Time message[/li] +[li]3.4.7 Connect message[/li] +[li]3.4.8 Trace message[/li] +[li]3.4.9 Admin command[/li] +[li]3.4.10 Info command[/li] +[/ul] +[li]3.5 Service Query and Commands[/li] +[ul] +[li]3.5.1 Servlist message[/li] +[li]3.5.2 Squery[/li] +[/ul] +[li]3.6 User based queries[/li] +[ul] +[li]3.6.1 Who query[/li] +[li]3.6.2 Whois query[/li] +[li]3.6.3 Whowas[/li] +[/ul] +[li]3.7 Miscellaneous messages[/li] +[ul] +[li]3.7.1 Kill message[/li] +[li]3.7.2 Ping message[/li] +[li]3.7.3 Pong message[/li] +[li]3.7.4 Error[/li] +[/ul] +[/ul] +[li]4. Optional features[/li] +[ul] +[li]4.1 Away[/li] +[li]4.2 Rehash message[/li] +[li]4.3 Die message[/li] +[li]4.4 Restart message[/li] +[li]4.5 Summon message[/li] +[li]4.6 Users[/li] +[li]4.7 Operwall message[/li] +[li]4.8 Userhost message[/li] +[li]4.9 Ison message[/li] +[/ul] +[li]5. Replies[/li] +[ul] +[li]5.1 Command responses[/li] +[li]5.2 Error Replies[/li] +[li]5.3 Reserved numerics[/li] +[/ul] +[li]6. Current implementations[/li] +[li]7. Current problems[/li] +[ul] +[li]7.1 Nicknames[/li] +[li]7.2 Limitation of wildcards[/li] +[li]7.3 Security considerations[/li] +[/ul] +[li]8. Current support and availability[/li] +[li]9. Acknowledgements[/li] +[li]10. References[/li] +[li]11. Author's Address[/li] +[li]12. Full Copyright Statement[/li] +[/ul] +[/td][/tr] + +[tr][td] +[b]1. Labels[/b] +[/td][/tr] + +[tr][td] +This section defines the identifiers used for the various components +of the IRC protocol. +[/td][/tr] + +[tr][td] +[b]1.1 Servers[/b] +[/td][/tr] + +[tr][td] +Servers are uniquely identified by their name, which has a maximum +length of sixty three (63) characters. See the protocol grammar +rules (section 2.3.1) for what may and may not be used in a server +name. +[/td][/tr] + +[tr][td] +[b]1.2 Clients[/b] +[/td][/tr] + +[tr][td] +For each client all servers MUST have the following information: a +netwide unique identifier (whose format depends on the type of +client) and the server which introduced the client. +[/td][/tr] + +[tr][td] +[b]1.2.1 Users[/b] +[/td][/tr] + +[tr][td] +Each user is distinguished from other users by a unique nickname +having a maximum length of nine (9) characters. See the protocol +grammar rules (section 2.3.1) for what may and may not be used in a +nickname. +[p] +While the maximum length is limited to nine characters, clients +SHOULD accept longer strings as they may become used in future +evolutions of the protocol. +[/td][/tr] + +[tr][td] +[b]1.2.1.1 Operators[/b] +[/td][/tr] + +[tr][td] +To allow a reasonable amount of order to be kept within the IRC +network, a special class of users (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 often necessary. Operators SHOULD be able to perform +basic network tasks such as disconnecting and reconnecting servers as +needed. In recognition of this need, the protocol discussed herein +provides for operators only to be able to perform such functions. +See sections 3.1.8 (SQUIT) and 3.4.7 (CONNECT).[br] +[p] +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 very delicate since its abuse is both +destructive and annoying, and its benefits close to inexistent. For +further details on this type of action, see section 3.7.1 (KILL). +[/td][/tr] + +[tr][td] +[b]1.2.2 Services[/b] +[/td][/tr] + +[tr][td] +Each service is distinguished from other services by a service name +composed of a nickname and a server name. As for users, the nickname +has a maximum length of nine (9) characters. See the protocol +grammar rules (section 2.3.1) for what may and may not be used in a +nickname. +[/td][/tr] + +[tr][td] +[b]1.3 Channels[/b] +[/td][/tr] + +[tr][td] +Channels names are strings (beginning with a '&', '#', '+' or '!' +character) of length up to fifty (50) characters. Apart from the +requirement that the first character is either '&', '#', '+' or '!', +the only restriction on a channel name is that it SHALL NOT contain +any spaces (' '), a control G (^G or ASCII 7), a comma (','). Space +is used as parameter separator and command is used as a list item +separator by the protocol). A colon (':') can also be used as a +delimiter for the channel mask. Channel names are case insensitive. +See the protocol grammar rules (section 2.3.1) for the exact syntax +of a channel name.[br] +[p] +Each prefix characterizes a different channel type. The definition +of the channel types is not relevant to the client-server protocol +and thus it is beyond the scope of this document. More details can +be found in "Internet Relay Chat: Channel Management" [IRC-CHAN]. +[/td][/tr] + +[tr][td] +[b]2. The IRC Client Specification[/b] +[/td][/tr] + +[tr][td] +[b]2.1 Overview[/b] +[/td][/tr] + +[tr][td] +The protocol as described herein is for use only with client to +server connections when the client registers as a user. +[/td][/tr] + +[tr][td] +[b]2.2 Character codes[/b] +[/td][/tr] + +[tr][td] +No specific character set is specified. The protocol is based on 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.[br] +[p] +Regardless of being an 8-bit protocol, the delimiters and keywords +are such that protocol is mostly usable from US-ASCII terminal and a +telnet connection. +[p] +Because of IRC's Scandinavian 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 or channel names. +[/td][/tr] + +[tr][td] +[b]2.3 Messages[/b] +[/td][/tr] + +[tr][td] +Servers and clients send each other 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 by nature. +[p] +Each IRC message may consist of up to three main parts: the prefix +(OPTIONAL), the command, and the command parameters (maximum of +fifteen (15)). The prefix, command, and all parameters are separated +by one ASCII space character (0x20) each. +[p] +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 from. Clients SHOULD NOT use a prefix when sending a +message; if they use one, the only valid prefix is the registered +nickname associated with the client. +[p] +The command MUST either be a valid IRC command or a three (3) digit +number represented in ASCII text. +[p] +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 of message lines. See section 6 for more details about +current implementations. +[/td][/tr] + +[tr][td] +[b]2.3.1 Message format in Augmented BNF[/b] +[/td][/tr] + +[tr][td] +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. +[p] +The extracted message is parsed into the components <prefix>, +<command> and list of parameters (<params>). +[p] +[pre] + The Augmented BNF representation for this is: + + message = [ ":" prefix SPACE ] command [ params ] crlf + prefix = servername / ( nickname [ [ "!" user ] "@" host ] ) + command = 1*letter / 3digit + params = *14( SPACE middle ) [ SPACE ":" trailing ] + =/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ] + + nospcrlfcl = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF + ; any octet except NUL, CR, LF, " " and ":" + middle = nospcrlfcl *( ":" / nospcrlfcl ) + trailing = *( ":" / " " / nospcrlfcl ) + + SPACE = %x20 ; space character + crlf = %x0D %x0A ; "carriage return" "linefeed" + + NOTES: + 1) After extracting the parameter list, all parameters are equal + whether matched by <middle> or <trailing>. <trailing> is just a + syntactic trick to allow SPACE within the parameter. + + 2) The NUL (%x00) character is not special in message framing, and + basically could end up inside a parameter, but it would cause + extra complexities in normal C string handling. Therefore, NUL + is not allowed within messages. + + 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: + + target = nickname / server + msgtarget = msgto *( "," msgto ) + msgto = channel / ( user [ "%" host ] "@" servername ) + msgto =/ ( user "%" host ) / targetmask + msgto =/ nickname / ( nickname "!" user "@" host ) + channel = ( "#" / "+" / ( "!" channelid ) / "&" ) chanstring + [ ":" chanstring ] + servername = hostname + host = hostname / hostaddr + hostname = shortname *( "." shortname ) + shortname = ( letter / digit ) *( letter / digit / "-" ) + *( letter / digit ) + ; as specified in RFC 1123 [HNAME] + hostaddr = ip4addr / ip6addr + ip4addr = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit + ip6addr = 1*hexdigit 7( ":" 1*hexdigit ) + ip6addr =/ "0:0:0:0:0:" ( "0" / "FFFF" ) ":" ip4addr + nickname = ( letter / special ) *8( letter / digit / special / "-" ) + targetmask = ( "$" / "#" ) mask + ; see details on allowed masks in section 3.3.1 + chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B + chanstring =/ %x2D-39 / %x3B-FF + ; any octet except NUL, BELL, CR, LF, " ", "," and ":" + channelid = 5( %x41-5A / digit ) ; 5( A-Z / 0-9 ) + + Other parameter syntaxes are: + + user = 1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF ) + ; any octet except NUL, CR, LF, " " and "@" + key = 1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F ) + ; any 7-bit US_ASCII character, + ; except NUL, CR, LF, FF, h/v TABs, and " " + letter = %x41-5A / %x61-7A ; A-Z / a-z + digit = %x30-39 ; 0-9 + hexdigit = digit / "A" / "B" / "C" / "D" / "E" / "F" + special = %x5B-60 / %x7B-7D + ; "[", "]", "\", "`", "_", "^", "{", "|", "}" + + NOTES: + 1) The <hostaddr> syntax is given here for the sole purpose of + indicating the format to follow for IP addresses. This + reflects the fact that the only available implementations of + this protocol uses TCP/IP as underlying network protocol but is + not meant to prevent other protocols to be used. + + 2) <hostname> has a maximum length of 63 characters. This is a + limitation of the protocol as internet hostnames (in + particular) can be longer. Such restriction is necessary + because IRC messages are limited to 512 characters in length. + Clients connecting from a host which name is longer than 63 + characters are registered using the host (numeric) address + instead of the host name. + + 3) Some parameters used in the following sections of this + documents are not defined here as there is nothing specific + about them besides the name that is used for convenience. + These parameters follow the general syntax defined for + <params>. +[/pre] +[/td][/tr] + +[tr][td] +[b]2.4 Numeric replies[/b] +[/td][/tr] + +[tr][td] +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. 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 5 (Replies). +[/td][/tr] + +[tr][td] +[b]2.5 Wildcard expressions[/b] +[/td][/tr] + +[tr][td] +When wildcards are allowed in a string, it is referred as a "mask". +[p] +For string matching purposes, the protocol allows the use of two +special characters: '?' (%x3F) to match one and only one character, +and '*' (%x2A) to match any number of any characters. These two +characters can be escaped using the character '\' (%x5C). +[p] +[pre] + The Augmented BNF syntax for this is: + + mask = *( nowild / noesc wildone / noesc wildmany ) + wildone = %x3F + wildmany = %x2A + nowild = %x01-29 / %x2B-3E / %x40-FF + ; any octet except NUL, "*", "?" + noesc = %x01-5B / %x5D-FF + ; any octet except NUL and "\" + matchone = %x01-FF + ; matches wildone + matchmany = *matchone + ; matches wildmany + + Examples: + + a?c ; Matches any string of 3 characters in length starting + with "a" and ending with "c" + + a*c ; Matches any string of at least 2 characters in length + starting with "a" and ending with "c" +[/pre] +[/td][/tr] + +[tr][td] +[b]3. Message Details[/b] +[/td][/tr] + +[tr][td] +On the following pages there 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. +[p] +Where the reply ERR_NOSUCHSERVER is returned, it means that the +target of the message could not be found. The server MUST NOT send +any other replies after this error for that command. +[p] +The server to which a client is connected is required to parse the +complete message, and return any appropriate errors. +[p] +If multiple parameters is presented, then each MUST be checked for +validity and appropriate responses MUST be sent back to the client. +In the case of incorrect messages which use parameter lists with +comma as an item separator, a reply MUST be sent for each item. +[/td][/tr] + +[tr][td] +[b]3.1 Connection Registration[/b] +[/td][/tr] + +[tr][td] +The commands described here are used to register a connection with an +IRC server as a user as well as to correctly disconnect. +[p] +A "PASS" command is not required for a client connection to be +registered, but it MUST precede the latter of the NICK/USER +combination (for a user connection) or the SERVICE command (for a +service connection). The RECOMMENDED order for a client to register +is as follows: +[p] +[pre] + 1. Pass message + 2. Nick message 2. Service message + 3. User message +[/pre] +[p] +Upon success, the client will receive an RPL_WELCOME (for users) or +RPL_YOURESERVICE (for services) message indicating that the +connection is now registered and known the to the entire IRC network. +The reply message MUST contain the full client identifier upon which +it was registered. +[/td][/tr] + +[tr][td] +[b]3.1.1 Password message[/b] +[/td][/tr] + +[tr][td][pre] +Command: PASS +Parameters: <password> + +The PASS command is used to set a 'connection password'. The +optional password can and MUST be set before any attempt to register +the connection is made. Currently this requires that user send a +PASS command before sending the NICK/USER combination. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED + + Example: + + PASS secretpasswordhere +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.1.2 Nick message[/b] +[/pre][/td][/tr] + + +[tr][td][pre] +Command: NICK +Parameters: <nickname> + +NICK command is used to give user a nickname or change the existing +one. + + Numeric Replies: + + ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME + ERR_NICKNAMEINUSE ERR_NICKCOLLISION + ERR_UNAVAILRESOURCE ERR_RESTRICTED + + Examples: + + NICK Wiz ; Introducing new nick "Wiz" if session is + still unregistered, or user changing his + nickname to "Wiz" + + :[email protected] NICK Kilroy + ; Server telling that WiZ changed his + nickname to Kilroy. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.1.3 User message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: USER +Parameters: <user> <mode> <unused> <realname> + +The USER command is used at the beginning of connection to specify +the username, hostname and realname of a new user. + +The <mode> parameter should be a numeric, and can be used to +automatically set user modes when registering with the server. This +parameter is a bitmask, with only 2 bits having any signification: if +the bit 2 is set, the user mode 'w' will be set and if the bit 3 is +set, the user mode 'i' will be set. (See Section 3.1.5 "User +Modes"). + +The <realname> may contain space characters. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED + + Example: + + USER guest 0 * :Ronnie Reagan ; User registering themselves with a + username of "guest" and real name + "Ronnie Reagan". + + USER guest 8 * :Ronnie Reagan ; User registering themselves with a + username of "guest" and real name + "Ronnie Reagan", and asking to be set + invisible. +[/pre][/td][/tr] + + +[tr][td][pre] +[b]3.1.4 Oper message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: OPER +Parameters: <name> <password> + +A normal user uses the OPER command to obtain operator privileges. +The combination of <name> and <password> are REQUIRED to gain +Operator privileges. Upon success, the user will receive a MODE +message (see section 3.1.5) indicating the new user modes. + + 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. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.1.5 User mode message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: MODE +Parameters: <nickname> +*( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) ) + +The user MODE's 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 MUST only be accepted if both the sender of the +message and the nickname given as a parameter are both the same. If +no other parameter is given, then the server will return the current +settings for the nick. + + The available modes are as follows: + + a - user is flagged as away; + i - marks a users as invisible; + w - user receives wallops; + r - restricted user connection; + o - operator flag; + O - local operator flag; + s - marks a user for receipt of server notices. + +Additional modes may be available later on. +The flag 'a' SHALL NOT be toggled by the user using the MODE command, +instead use of the AWAY command is REQUIRED. + +If a user attempts to make themselves an operator using the "+o" or +"+O" flag, the attempt SHOULD be ignored as users could bypass the +authentication mechanisms of the OPER command. There is no +restriction, however, on anyone `deopping' themselves (using "-o" or +"-O"). + +On the other hand, if a user attempts to make themselves unrestricted +using the "-r" flag, the attempt SHOULD be ignored. There is no +restriction, however, on anyone `deopping' themselves (using "+r"). +This flag is typically set by the server upon connection for +administrative reasons. While the restrictions imposed are left up +to the implementation, it is typical that a restricted user not be +allowed to change nicknames, nor make use of the channel operator +status on channels. + +The flag 's' is obsolete but MAY still be used. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_USERSDONTMATCH + ERR_UMODEUNKNOWNFLAG RPL_UMODEIS + + Examples: + + MODE WiZ -w ; Command by WiZ to turn off + reception of WALLOPS messages. + + MODE Angel +i ; Command from Angel to make herself + invisible. + + MODE WiZ -o ; WiZ 'deopping' (removing operator + status). +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.1.6 Service message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: SERVICE +Parameters: <nickname> <reserved> <distribution> <type> +<reserved> <info> + +The SERVICE command to register a new service. Command parameters +specify the service nickname, distribution, type and info of a new +service. +The <distribution> parameter is used to specify the visibility of a +service. The service may only be known to servers which have a name +matching the distribution. For a matching server to have knowledge +of the service, the network path between that server and the server +on which the service is connected MUST be composed of servers which +names all match the mask. + +The <type> parameter is currently reserved for future usage. + + Numeric Replies: + + ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS + ERR_ERRONEUSNICKNAME + RPL_YOURESERVICE RPL_YOURHOST + RPL_MYINFO + + Example: + + SERVICE dict * *.fr 0 0 :French Dictionary ; Service registering + itself with a name of "dict". This + service will only be available on + servers which name matches "*.fr". +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.1.7 Quit[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: QUIT +Parameters: [ <Quit Message> ] + +A client session is terminated with a quit message. The server +acknowledges this by sending an ERROR message to the client. + + Numeric Replies: + + None. + + Example: + + QUIT :Gone to have lunch ; Preferred message format. + + :[email protected] QUIT :Gone to have lunch ; User + syrk has quit IRC to have lunch. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.1.8 Squit[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: SQUIT +Parameters: <server> <comment> + +The SQUIT command is available only to operators. It is used to +disconnect server links. Also servers can generate SQUIT messages on +error conditions. A SQUIT message may also target a remote server +connection. In this case, the SQUIT message will simply be sent to +the remote server without affecting the servers in between the +operator and the remote server. + +The <comment> SHOULD be supplied by all operators who execute a SQUIT +for a remote server. The server ordered to disconnect its peer +generates a WALLOPS message with <comment> included, so that other +users may be aware of the reason of this action. + + Numeric replies: + + ERR_NOPRIVILEGES ERR_NOSUCHSERVER + ERR_NEEDMOREPARAMS + + Examples: + + SQUIT tolsun.oulu.fi :Bad Link ? ; Command to uplink of the server + tolson.oulu.fi to terminate its + connection with comment "Bad Link". + + :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; Command + from Trillian from to disconnect + "cm22.eng.umd.edu" from the net with + comment "Server out of control". +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.2 Channel operations[/b] +[/pre][/td][/tr] + +[tr][td][pre] +This group of messages is concerned with manipulating channels, their +properties (channel modes), and their contents (typically users). +For this reason, these messages SHALL NOT be made available to +services. + +All of these messages are requests which will or will not be granted +by the server. The server MUST send a reply informing the user +whether the request was granted, denied or generated an error. When +the server grants the request, the message is typically sent back +(eventually reformatted) to the user with the prefix set to the user +itself. + +The rules governing how channels are managed are enforced by the +servers. These rules are beyond the scope of this document. More +details are found in "Internet Relay Chat: Channel Management" [IRC- +CHAN]. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.2.1 Join message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: JOIN +Parameters: ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] ) +/ "0" + +The JOIN command is used by a user to request to start listening to +the specific channel. Servers MUST be able to parse arguments in the +form of a list of target, but SHOULD NOT use lists when sending JOIN +messages to clients. + +Once a user has joined a channel, he receives information about +all commands his server receives affecting the channel. This +includes JOIN, MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. +This allows channel members to keep track of the other channel +members, as well as channel modes. + +If a JOIN is successful, the user receives a JOIN message as +confirmation and 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. + +Note that this message accepts a special argument ("0"), which is +a special request to leave all channels the user is currently a member +of. The server will process this message as if the user had sent +a PART command (See Section 3.2.2) for each channel he is a member +of. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN + ERR_INVITEONLYCHAN ERR_BADCHANNELKEY + ERR_CHANNELISFULL ERR_BADCHANMASK + ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS + ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE + RPL_TOPIC + + Examples: + + JOIN #foobar ; Command to join channel #foobar. + + JOIN &foo fubar ; Command to join channel &foo using + key "fubar". + + JOIN #foo,&bar fubar ; Command to join channel #foo using + key "fubar" and &bar using no key. + + JOIN #foo,#bar fubar,foobar ; Command to join channel #foo using + key "fubar", and channel #bar using + key "foobar". + + JOIN #foo,#bar ; Command to join channels #foo and + #bar. + + JOIN 0 ; Leave all currently joined + channels. + + :[email protected] JOIN #Twilight_zone ; JOIN message from WiZ + on channel #Twilight_zone +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.2.2 Part message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: PART +Parameters: <channel> *( "," <channel> ) [ <Part Message> ] + +The PART command causes the user sending the message to be removed +from the list of active members for all given channels listed in the +parameter string. If a "Part Message" is given, this will be sent +instead of the default message, the nickname. This request is always +granted by the server. + +Servers MUST be able to parse arguments in the form of a list of +target, but SHOULD NOT use lists when sending PART messages to +clients. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL + ERR_NOTONCHANNEL + + Examples: + + PART #twilight_zone ; Command to leave channel + "#twilight_zone" + + PART #oz-ops,&group5 ; Command to leave both channels + "&group5" and "#oz-ops". + + :[email protected] PART #playzone :I lost + ; User WiZ leaving channel + "#playzone" with the message "I + lost". +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.2.3 Channel mode message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: MODE +Parameters: <channel> *( ( "-" / "+" ) *<modes> *<modeparams> ) + +The MODE command is provided so that users may query and change the +characteristics of a channel. For more details on available modes +and their uses, see "Internet Relay Chat: Channel Management" [IRC- +CHAN]. Note that there is a maximum limit of three (3) changes per +command for modes that take a parameter. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_KEYSET + ERR_NOCHANMODES ERR_CHANOPRIVSNEEDED + ERR_USERNOTINCHANNEL ERR_UNKNOWNMODE + RPL_CHANNELMODEIS + RPL_BANLIST RPL_ENDOFBANLIST + RPL_EXCEPTLIST RPL_ENDOFEXCEPTLIST + RPL_INVITELIST RPL_ENDOFINVITELIST + RPL_UNIQOPIS + + The following examples are given to help understanding the syntax of + the MODE command, but refer to modes defined in "Internet Relay Chat: + Channel Management" [IRC-CHAN]. + + Examples: + + MODE #Finnish +imI *!*@*.fi ; Command to make #Finnish channel + moderated and 'invite-only' with user + with a hostname matching *.fi + automatically invited. + + MODE #Finnish +o Kilroy ; Command to give 'chanop' privileges + to Kilroy on channel #Finnish. + + MODE #Finnish +v Wiz ; Command to allow WiZ to speak on + #Finnish. + + MODE #Fins -s ; Command to remove 'secret' flag + from channel #Fins. + + MODE #42 +k oulu ; Command to set the channel key to + "oulu". + + MODE #42 -k oulu ; Command to remove the "oulu" + channel key on channel "#42". + + MODE #eu-opers +l 10 ; Command to set the limit for the + number of users on channel + "#eu-opers" to 10. + + :[email protected] MODE #eu-opers -l + ; User "WiZ" removing the limit for + the number of users on channel "#eu- + opers". + + MODE &oulu +b ; Command to list ban masks set for + the channel "&oulu". + + MODE &oulu +b *!*@* ; Command to prevent all users from + joining. + + MODE &oulu +b *!*@*.edu +e *!*@*.bu.edu + ; Command to prevent any user from a + hostname matching *.edu from joining, + except if matching *.bu.edu + + MODE #bu +be *!*@*.edu *!*@*.bu.edu + ; Comment to prevent any user from a + hostname matching *.edu from joining, + except if matching *.bu.edu + + MODE #meditation e ; Command to list exception masks set + for the channel "#meditation". + + MODE #meditation I ; Command to list invitations masks + set for the channel "#meditation". + + MODE !12345ircd O ; Command to ask who the channel + creator for "!12345ircd" is +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.2.4 Topic message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: TOPIC +Parameters: <channel> [ <topic> ] + +The TOPIC command is used to change or view the topic of a channel. +The topic for channel <channel> is returned if there is no <topic> +given. If the <topic> parameter is present, the topic for that +channel will be changed, if this action is allowed for the user +requesting it. If the <topic> parameter is an empty string, the +topic for that channel will be removed. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL + RPL_NOTOPIC RPL_TOPIC + ERR_CHANOPRIVSNEEDED ERR_NOCHANMODES + + Examples: + + :[email protected] TOPIC #test :New topic ; User Wiz setting the + topic. + + TOPIC #test :another topic ; Command to set the topic on #test + to "another topic". + + TOPIC #test : ; Command to clear the topic on + #test. + + TOPIC #test ; Command to check the topic for + #test. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.2.5 Names message[/b] + +Command: NAMES +Parameters: [ <channel> *( "," <channel> ) [ <target> ] ] + +By using the NAMES command, a user can list all nicknames that are +visible to him. For more details on what is visible and what is not, +see "Internet Relay Chat: Channel Management" [IRC-CHAN]. The +<channel> parameter specifies which channel(s) to return information +about. There is no error reply for bad channel names. + +If no <channel> 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' "*". + +If the <target> parameter is specified, the request is forwarded to +that server which will generate the reply. + +Wildcards are allowed in the <target> parameter. + + Numerics: + + ERR_TOOMANYMATCHES ERR_NOSUCHSERVER + RPL_NAMREPLY RPL_ENDOFNAMES + + Examples: + + NAMES #twilight_zone,#42 ; Command to list visible users on + #twilight_zone and #42 + + NAMES ; Command to list all visible + channels and users +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.2.6 List message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: LIST +Parameters: [ <channel> *( "," <channel> ) [ <target> ] ] + +The list command is used to list channels and their topics. If the +<channel> parameter is used, only the status of that channel is +displayed. + +If the <target> parameter is specified, the request is forwarded to +that server which will generate the reply. + +Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + ERR_TOOMANYMATCHES ERR_NOSUCHSERVER + RPL_LIST RPL_LISTEND + + Examples: + + LIST ; Command to list all channels. + + LIST #twilight_zone,#42 ; Command to list channels + #twilight_zone and #42 +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.2.7 Invite message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: INVITE +Parameters: <nickname> <channel> + +The INVITE command is used to invite a user to a channel. The +parameter <nickname> is the nickname of the person to be invited to +the target channel <channel>. There is no requirement that the +channel the target user is being invited to must exist or be a valid +channel. However, if the channel exists, only members of the channel +are allowed to invite other users. When the channel has invite-only +flag set, only channel operators may issue INVITE command. +Only the user inviting and the user being invited will receive +notification of the invitation. Other channel members are not +notified. (This is unlike the MODE changes, and is occasionally the +source of trouble for users.) + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOSUCHNICK + ERR_NOTONCHANNEL ERR_USERONCHANNEL + ERR_CHANOPRIVSNEEDED + RPL_INVITING RPL_AWAY + + Examples: + + :[email protected] INVITE Wiz #Dust + + ; Message to WiZ when he has been + invited by user Angel to channel + #Dust + + INVITE Wiz #Twilight_Zone ; Command to invite WiZ to + #Twilight_zone +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.2.8 Kick command[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: KICK +Parameters: <channel> *( "," <channel> ) <user> *( "," <user> ) +[<comment>] + +The KICK command can be used to request the forced removal of a user +from a channel. It causes the <user> to PART from the <channel> by +force. For the message to be syntactically correct, there MUST be +either one channel parameter and multiple user parameter, or as many +channel parameters as there are user parameters. If a "comment" is +given, this will be sent instead of the default message, the nickname +of the user issuing the KICK. + +The server MUST NOT send KICK messages with multiple channels or +users to clients. This is necessarily to maintain backward +compatibility with old client software. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL + ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED + ERR_USERNOTINCHANNEL ERR_NOTONCHANNEL + + Examples: + + KICK &Melbourne Matthew ; Command to kick Matthew from + &Melbourne + + KICK #Finnish John :Speaking English + ; Command to kick John from #Finnish + using "Speaking English" as the + reason (comment). + + :[email protected] KICK #Finnish John + ; KICK message on channel #Finnish + from WiZ to remove John from channel +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.3 Sending messages[/b] +[/pre][/td][/tr] + +[tr][td][pre] +The main purpose of the IRC protocol is to provide a base for clients +to communicate with each other. PRIVMSG, NOTICE and SQUERY +(described in Section 3.5 on Service Query and Commands) 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. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.3.1 Private messages[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: PRIVMSG +Parameters: <msgtarget> <text to be sent> + +PRIVMSG is used to send private messages between users, as well as to +send messages to channels. <msgtarget> is usually the nickname of +the recipient of the message, or a channel name. + +The <msgtarget> parameter may also be 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. 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: + + :[email protected] PRIVMSG Wiz :Are you receiving this message ? + ; Message from Angel to Wiz. + + PRIVMSG Angel :yes I'm receiving it ! + ; Command to send a message to Angel. + + PRIVMSG [email protected] :Hello ! + ; Command to send a message to a user + on server tolsun.oulu.fi with + username of "jto". + + PRIVMSG kalt%[email protected] :Are you a frog? + ; Message to a user on server + irc.stealth.net with username of + "kalt", and connected from the host + millennium.stealth.net. + + PRIVMSG kalt%millennium.stealth.net :Do you like cheese? + ; Message to a user on the local + server with username of "kalt", and + connected from the host + millennium.stealth.net. + + PRIVMSG [email protected] :Hello ! + ; Message to the user with nickname + Wiz who is connected from the host + tolsun.oulu.fi and has the username + "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. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.3.2 Notice[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: NOTICE +Parameters: <msgtarget> <text> + +The NOTICE command 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 clients automatically sending something in response to +something it received. + +This command is available to services as well as users. + +This is typically used by services, and automatons (clients with +either an AI or other interactive program controlling their actions). + +See PRIVMSG for more details on replies and examples. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.4 Server queries and commands[/b] +[/pre][/td][/tr] + +[tr][td][pre] +The server query group of commands has been designed to return +information about any server which is connected to the network. + +In these queries, where a parameter appears as <target>, wildcard +masks are usually valid. For each parameter, however, only one query +and set of replies is to be generated. In most cases, if a nickname +is given, it will mean the server to which the user is connected. + +These messages typically have little value for services, it is +therefore RECOMMENDED to forbid services from using them. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.4.1 Motd message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: MOTD +Parameters: [ <target> ] + +The MOTD command is used to get the "Message Of The Day" of the given +server, or current server if <target> is omitted. + +Wildcards are allowed in the <target> parameter. + + Numeric Replies: + RPL_MOTDSTART RPL_MOTD + RPL_ENDOFMOTD ERR_NOMOTD +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.4.2 Lusers message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: LUSERS +Parameters: [ <mask> [ <target> ] ] + +The LUSERS command is used to get statistics about the size of the +IRC network. If no parameter is given, the reply will be about the +whole net. If a <mask> is specified, then the reply will only +concern the part of the network formed by the servers matching the +mask. Finally, if the <target> parameter is specified, the request +is forwarded to that server which will generate the reply. + +Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + RPL_LUSERCLIENT RPL_LUSEROP + RPL_LUSERUNKOWN RPL_LUSERCHANNELS + RPL_LUSERME ERR_NOSUCHSERVER +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.4.3 Version message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: VERSION +Parameters: [ <target> ] + +The VERSION command is used to query the version of the server +program. An optional parameter <target> is used to query the version +of the server program which a client is not directly connected to. + +Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + ERR_NOSUCHSERVER RPL_VERSION + + Examples: + + VERSION tolsun.oulu.fi ; Command to check the version of + server "tolsun.oulu.fi". +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.4.4 Stats message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: STATS +Parameters: [ <query> [ <target> ] ] + +The stats command is used to query statistics of certain server. If +<query> parameter is omitted, only the end of stats reply is sent +back. + +A query may be given for any single letter which is only checked by +the destination server and is otherwise passed on by intermediate +servers, ignored and unaltered. + +Wildcards are allowed in the <target> parameter. +Except for the ones below, the list of valid queries is +implementation dependent. The standard queries below SHOULD be +supported by the 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 Kbytes and messages for + each direction; + m - returns the usage count for each of commands supported + by the server; commands for which the usage count is + zero MAY be omitted; + o - returns a list of configured privileged users, + operators; + u - returns a string showing how long the server has been + up. + +It is also RECOMMENDED that client and server access configuration be +published this way. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_STATSLINKINFO RPL_STATSUPTIME + RPL_STATSCOMMANDS RPL_STATSOLINE + RPL_ENDOFSTATS + + Examples: + + STATS m ; Command to check the command usage + for the server you are connected to +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.4.5 Links message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: LINKS +Parameters: [ [ <remote server> ] <server mask> ] + +With LINKS, a user can list all servernames, 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 <remote server> is given in addition to <server mask>, 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_LINKSRPL_ENDOFLINKS + +Examples: + +LINKS *.au ; Command to list all servers which + have a name that matches *.au; + +LINKS *.edu *.bu.edu; Command to list servers matching + *.bu.edu as seen by the first server + matching *.edu. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.4.6 Time message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: TIME +Parameters: [ <target> ] + +The time command is used to query local time from the specified +server. If the <target> parameter is not given, the server receiving +the command must reply to the query. + +Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + ERR_NOSUCHSERVER RPL_TIME + + Examples: + TIME tolsun.oulu.fi ; check the time on the server + "tolson.oulu.fi" +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.4.7 Connect message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: CONNECT +Parameters: <target server> <port> [ <remote server> ] + +The CONNECT command can be used to request a server to try to +establish a new connection to another server immediately. CONNECT is +a privileged command and SHOULD be available only to IRC Operators. +If a <remote server> is given and its mask doesn't match name of the +parsing server, the CONNECT attempt is sent to the first match of +remote server. Otherwise the CONNECT attempt is made by the server +processing the request. + +The server receiving a remote CONNECT command SHOULD generate a +WALLOPS message describing the source and target of the request. + + Numeric Replies: + + ERR_NOSUCHSERVER ERR_NOPRIVILEGES + ERR_NEEDMOREPARAMS + + Examples: + + CONNECT tolsun.oulu.fi 6667 ; Command to attempt to connect local + server to tolsun.oulu.fi on port 6667 +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.4.8 Trace message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: TRACE +Parameters: [ <target> ] + +TRACE command is used to find the route to specific server and +information about its peers. Each server that processes this command +MUST report to the sender about it. The replies from pass-through +links form a chain, which shows route to destination. After sending +this reply back, the query MUST be sent to the next server until +given <target> server is reached. + +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. After sending this reply back, it MUST then send the +TRACE message to the next server until given server is reached. If +the <target> parameter is omitted, it is RECOMMENDED that TRACE +command sends a message to the sender telling which servers the local +server has direct connection to. + +If the destination given by <target> is an actual server, the +destination server is REQUIRED to report all servers, services and +operators which are connected to it; if the command was issued by an +operator, the server MAY also report all users which are connected to +it. If the destination given by <target> is a nickname, then only a +reply for that nickname is given. If the <target> parameter is +omitted, it is RECOMMENDED that the TRACE command is parsed as +targeted to the processing server. + +Wildcards are allowed in the <target> parameter. + + 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 it is 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 RPL_TRACELOG + RPL_TRACEEND + + Examples: + + TRACE *.oulu.fi ; TRACE to a server matching + *.oulu.fi +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.4.9 Admin command[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: ADMIN +Parameters: [ <target> ] + +The admin command is used to find information about the administrator +of the given server, or current server if <target> parameter is +omitted. Each server MUST have the ability to forward ADMIN messages +to other servers. + +Wildcards are allowed in the <target> parameter. + + 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 + + ADMIN syrk ; ADMIN request for the server to + which the user syrk is connected +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.4.10 Info command[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: INFO +Parameters: [ <target> ] + +The INFO command is REQUIRED to return information describing 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. + +Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_INFO RPL_ENDOFINFO + + Examples: + + INFO csd.bu.edu ; request an INFO reply from + csd.bu.edu + + INFO Angel ; request info from the server that + Angel is connected to. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.5 Service Query and Commands[/b] +[/pre][/td][/tr] +[tr][td][pre] +The service query group of commands has been designed to return +information about any service which is connected to the network. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.5.1 Servlist message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: SERVLIST +Parameters: [ <mask> [ <type> ] ] + +The SERVLIST command is used to list services currently connected to +the network and visible to the user issuing the command. The +optional parameters may be used to restrict the result of the query +(to matching services names, and services type). + + Numeric Replies: + + RPL_SERVLIST RPL_SERVLISTEND +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.5.2 Squery[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: SQUERY +Parameters: <servicename> <text> + +The SQUERY command is used similarly to PRIVMSG. The only difference +is that the recipient MUST be a service. This is the only way for a +text message to be delivered to a service. + +See PRIVMSG for more details on replies and example. + + Examples: + + SQUERY irchelp :HELP privmsg + ; Message to the service with + nickname irchelp. + + SQUERY [email protected] :fr2en blaireau + ; Message to the service with name +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.6 User based queries[/b] +[/pre][/td][/tr] +[tr][td][pre] +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. + +Although services SHOULD NOT be using this class of message, they are +allowed to. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.6.1 Who query[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: WHO +Parameters: [ <mask> [ "o" ] ] + +The WHO command is used by a client to generate a query which returns +a list of information which 'matches' the <mask> parameter given by +the client. In the absence of the <mask> 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 <mask> of "0" or any wildcard which +will end up matching every visible user. + +The <mask> passed to WHO is matched against users' host, server, real +name and nickname if the channel <mask> cannot be found. +If the "o" parameter is passed only operators are returned according +to the <mask> supplied. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_WHOREPLY RPL_ENDOFWHO + + Examples: + + WHO *.fi ; Command to list all users who match + against "*.fi". + + WHO jto* o ; Command to list all users with a + match against "jto*" if they are an + operator. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.6.2 Whois query[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: WHOIS +Parameters: [ <target> ] <mask> *( "," <mask> ) + +This command is used to query information about particular user. +The server will answer this command with several numeric messages +indicating different statuses of each user which matches the mask (if +you are entitled to see them). If no wildcard is present in the +<mask>, any information about that nick which you are allowed to see +is presented. + +If the <target> parameter is specified, it 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 (i.e., the server the +user is directly connected to) knows that information, while +everything else is globally known. + +Wildcards are allowed in the <target> parameter. + + 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 +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.6.3 Whowas[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: WHOWAS +Parameters: <nickname> *( "," <nickname> ) [ <count> [ <target> ] ] + +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 +<count> replies will be returned (or all of them if no <count> +parameter is given). If a non-positive number is passed as being +<count>, then a full search is done. + +Wildcards are allowed in the <target> parameter. + + 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". +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.7 Miscellaneous messages[/b] +[/pre][/td][/tr] + +[tr][td][pre] +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. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.7.1 Kill message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: KILL +Parameters: <nickname> <comment> + +The KILL command is used to cause a client-server connection to be +closed by the server which has the actual connection. Servers +generate KILL messages on nickname collisions. It MAY also be +available available to users who have the operator status. + +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 'flooding' from abusive users or accidents. Abusive users usually +don't care as they will reconnect promptly and resume their abusive +behaviour. To prevent this command from 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. + +When a client is removed as the result of a KILL message, the server +SHOULD add the nickname to the list of unavailable nicknames in an +attempt to avoid clients to reuse this name immediately which is +usually the pattern of abusive behaviour often leading to useless +"KILL loops". See the "IRC Server Protocol" document [IRC-SERVER] +for more information on this procedure. + +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 + +NOTE: +It is RECOMMENDED that only Operators be allowed to kill other users +with KILL command. This command has been the subject of many +controversies over the years, and along with the above +recommendation, it is also widely recognized that not even operators +should be allowed to kill users on remote servers. +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.7.2 Ping message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: PING +Parameters: <server1> [ <server2> ] + +The PING command is used to test the presence of an active client or +server at the other end of the connection. Servers send a PING +message at regular intervals if no other activity detected coming +from a connection. If a connection fails to respond to a PING +message within a set amount of time, that connection is closed. A +PING message MAY be sent even if the connection is active. + +When a PING message is received, the appropriate PONG message MUST be +sent as reply to <server1> (server which sent the PING message out) +as soon as possible. If the <server2> parameter is specified, it +represents the target of the ping, and the message gets forwarded +there. + + Numeric Replies: + + ERR_NOORIGIN ERR_NOSUCHSERVER + + Examples: + + PING tolsun.oulu.fi ; Command to send a PING message to + server + + PING WiZ tolsun.oulu.fi ; Command from WiZ to send a PING + message to server "tolsun.oulu.fi" + + PING :irc.funet.fi ; Ping message sent by server + "irc.funet.fi" +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.7.3 Pong message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: PONG +Parameters: <server> [ <server2> ] + +PONG message is a reply to ping message. If parameter <server2> is +given, this message MUST be forwarded to given target. The <server> +parameter is the name of the entity who has responded to PING message +and generated this message. + + Numeric Replies: + + ERR_NOORIGIN ERR_NOSUCHSERVER + + Example: + + PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to + tolsun.oulu.fi +[/pre][/td][/tr] + +[tr][td][pre] +[b]3.7.4 Error[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: ERROR +Parameters: <error message> + +The ERROR command is for use by servers when reporting a serious or +fatal error to its peers. It may also be sent from one server to +another but MUST NOT be accepted from any normal unknown clients. + +Only an ERROR message SHOULD be used for reporting errors which occur +with a server-to-server link. An ERROR message is sent to the server +at the other end (which reports it to appropriate local users and +logs) and to appropriate local users and logs. It is not to be +passed onto any other servers by a server if it is received from a +server. + +The ERROR message is also used before terminating a client +connection. + +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. +[/pre][/td][/tr] + +[tr][td][pre] +[b]4. Optional features[/b] +[/pre][/td][/tr] + +[tr][td][pre] +This section describes OPTIONAL messages. They are not required in a +working server implementation of the protocol described herein. In +the absence of the feature, 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. + +From this section, only the USERHOST and ISON messages are available +to services. +[/pre][/td][/tr] + +[tr][td][pre] +[b]4.1 Away[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: AWAY +Parameters: [ <text> ] + +With the AWAY command, clients can set an automatic reply string for +any PRIVMSG commands directed at them (not to a channel they are on). +The server sends an automatic reply to the client sending the PRIVMSG +command. The only replying server is the one to which the sending +client is connected to. + +The AWAY command is used either with one parameter, to set an AWAY +message, or with no parameters, to remove the AWAY message. + +Because of its high cost (memory and bandwidth wise), the AWAY +message SHOULD only be used for client-server communication. A +server MAY choose to silently ignore AWAY messages received from +other servers. To update the away status of a client across servers, +the user mode 'a' SHOULD be used instead. (See Section 3.1.5) + + Numeric Replies: + + RPL_UNAWAY RPL_NOWAWAY + + Example: + + AWAY :Gone to lunch. Back in 5 ; Command to set away message to + "Gone to lunch. Back in 5". +[/pre][/td][/tr] + +[tr][td][pre] +[b]4.2 Rehash message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: REHASH +Parameters: None + +The rehash command is an administrative command which can be used by +an operator to force the server to re-read and process its +configuration file. + + Numeric Replies: + + RPL_REHASHING ERR_NOPRIVILEGES + + + Example: + + REHASH ; message from user with operator + status to server asking it to reread + its configuration file. +[/pre][/td][/tr] + +[tr][td][pre] +[b]4.3 Die message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: DIE +Parameters: None + +An operator can use the DIE command to shutdown the server. 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. + +The DIE command MUST always be fully processed by the server to which +the sending client is connected and MUST NOT be passed onto other +connected servers. + + Numeric Replies: + + ERR_NOPRIVILEGES + + Example: + + DIE ; no parameters required. +[/pre][/td][/tr] + +[tr][td][pre] +[b]4.4 Restart message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: RESTART +Parameters: None + +An operator can use the restart command to force the server to +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 MUST NOT be passed onto +other connected servers. + + Numeric Replies: + + ERR_NOPRIVILEGES + + Example: + + RESTART ; no parameters required. +[/pre][/td][/tr] + +[tr][td][pre] +[b]4.5 Summon message[/b] +[/pre][/td][/tr] + +[tr][td][pre] +Command: SUMMON +Parameters: <user> [ <target> [ <channel> ] ] + +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 <server> parameter is given it tries to summon <user> 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. + + Numeric Replies: + + ERR_NORECIPIENT ERR_FILEERROR + ERR_NOLOGIN ERR_NOSUCHSERVER + ERR_SUMMONDISABLED 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. +[/pre][/td][/tr] + +[tr][td] +[b]4.6 Users[/b] +[/td][/tr] + +[tr][td][pre] +Command: USERS +Parameters: [ <target> ] + +The USERS command returns a list of users logged into the server in a +format similar to the UNIX commands who(1), rusers(1) and finger(1). +If disabled, the correct numeric MUST be returned to indicate this. + +Because of the security implications of such a command, it SHOULD be +disabled by default in server implementations. Enabling it SHOULD +require recompiling the server or some equivalent change rather than +simply toggling an option and restarting the server. The procedure +to enable this command SHOULD also include suitable large comments. + + Numeric Replies: + + ERR_NOSUCHSERVER ERR_FILEERROR + RPL_USERSSTART RPL_USERS + RPL_NOUSERS RPL_ENDOFUSERS + ERR_USERSDISABLED + + Disabled Reply: + + ERR_USERSDISABLED + + Example: + + USERS eff.org ; request a list of users logged in + on server eff.org +[/pre][/td][/tr] + +[tr][td] +[b]4.7 Operwall message[/b] +[/td][/tr] + +[tr][td][pre] +Command: WALLOPS +Parameters: <Text to be sent> + +The WALLOPS command is used to send a message to all currently +connected users who have set the 'w' user mode for themselves. (See +Section 3.1.5 "User modes"). +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. Due to this, it is RECOMMENDED that the implementation of +WALLOPS allows and recognizes only servers as the originators of +WALLOPS. + + Numeric Replies: + + ERR_NEEDMOREPARAMS + + Example: + + :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua ; WALLOPS + message from csd.bu.edu announcing a + CONNECT message it received from + Joshua and acted upon. +[/pre][/td][/tr] + +[tr][td] +[b]4.8 Userhost message[/b] +[/td][/tr] + +[tr][td][pre] +Command: USERHOST +Parameters: <nickname> *( SPACE <nickname> ) + +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 + + Example: + + USERHOST Wiz Michael syrk ; USERHOST request for information on + nicks "Wiz", "Michael", and "syrk" + + :ircd.stealth.net 302 yournick :[email protected] + ; Reply for user syrk +[/pre][/td][/tr] + +[tr][td] +[b]4.9 Ison message[/b] +[/td][/tr] + +[tr][td][pre] +Command: ISON +Parameters: <nickname> *( SPACE <nickname> ) + +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) type of 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 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 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 + + Example: + + ISON phone trillian WiZ jarlek Avalon Angel Monstah syrk + ; Sample ISON request for 7 nicks. +[/pre][/td][/tr] + +[tr][td] +[b]5. Replies[/b] +[/td][/tr] + +[tr][td] +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. +[/td][/tr] + +[tr][td] +[b]5.1 Command responses[/b] +[/td][/tr] + +[tr][td] +Numerics in the range from 001 to 099 are used for client-server +connections only and should never travel between servers. Replies +generated in the response to commands are found in the range from 200 +to 399. +[p] +[pre] + 001 RPL_WELCOME + "Welcome to the Internet Relay Network + <nick>!<user>@<host>" + 002 RPL_YOURHOST + "Your host is <servername>, running version <ver>" + 003 RPL_CREATED + "This server was created <date>" + 004 RPL_MYINFO + "<servername> <version> <available user modes> + <available channel modes>" + + - The server sends Replies 001 to 004 to a user upon + successful registration. + + 005 RPL_BOUNCE + "Try server <server name>, port <port number>" + + - Sent by the server to a user to suggest an alternative + server. This is often used when the connection is + refused because the server is already full. + + 302 RPL_USERHOST + ":*1<reply> *( " " <reply> )" + + - Reply format used by USERHOST to list replies to + the query list. The reply string is composed as + follows: + + reply = nickname [ "*" ] "=" ( "+" / "-" ) hostname + + 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 + ":*1<nick> *( " " <nick> )" + + - Reply format used by ISON to list replies to the + query list. + + 301 RPL_AWAY + "<nick> :<away message>" + 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 + "<nick> <user> <host> * :<real name>" + 312 RPL_WHOISSERVER + "<nick> <server> :<server info>" + 313 RPL_WHOISOPERATOR + "<nick> :is an IRC operator + 317 RPL_WHOISIDLE + "<nick> <integer> :seconds idle" + 318 RPL_ENDOFWHOIS + "<nick> :End of WHOIS list" + 319 RPL_WHOISCHANNELS + "<nick> :*( ( "@" / "+" ) <channel> " " )" + + - 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 + "<nick> <user> <host> * :<real name>" + 369 RPL_ENDOFWHOWAS + "<nick> :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 + Obsolete. Not used. + + 322 RPL_LIST + "<channel> <# visible> :<topic>" + 323 RPL_LISTEND + ":End of LIST" + + - Replies RPL_LIST, RPL_LISTEND mark the 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 end reply MUST be sent. + + 325 RPL_UNIQOPIS + "<channel> <nickname>" + + 324 RPL_CHANNELMODEIS + "<channel> <mode> <mode params>" + + 331 RPL_NOTOPIC + "<channel> :No topic is set" + 332 RPL_TOPIC + "<channel> :<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 + "<channel> <nick>" + + - Returned by the server to indicate that the + attempted INVITE message was successful and is + being passed onto the end client. + + 342 RPL_SUMMONING + "<user> :Summoning user to IRC" + + - Returned by a server answering a SUMMON message to + indicate that it is summoning that user. + + 346 RPL_INVITELIST + "<channel> <invitemask>" + 347 RPL_ENDOFINVITELIST + "<channel> :End of channel invite list" + + - When listing the 'invitations masks' for a given channel, + a server is required to send the list back using the + RPL_INVITELIST and RPL_ENDOFINVITELIST messages. A + separate RPL_INVITELIST is sent for each active mask. + After the masks have been listed (or if none present) a + RPL_ENDOFINVITELIST MUST be sent. + + 348 RPL_EXCEPTLIST + "<channel> <exceptionmask>" + 349 RPL_ENDOFEXCEPTLIST + "<channel> :End of channel exception list" + + - When listing the 'exception masks' for a given channel, + a server is required to send the list back using the + RPL_EXCEPTLIST and RPL_ENDOFEXCEPTLIST messages. A + separate RPL_EXCEPTLIST is sent for each active mask. + After the masks have been listed (or if none present) + a RPL_ENDOFEXCEPTLIST MUST be sent. + + 351 RPL_VERSION + "<version>.<debuglevel> <server> :<comments>" + + - Reply by the server showing its version details. + The <version> is the version of the software being + used (including any patchlevel revisions) and the + <debuglevel> 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 + "<channel> <user> <host> <server> <nick> + ( "H" / "G" > ["*"] [ ( "@" / "+" ) ] + :<hopcount> <real name>" + + 315 RPL_ENDOFWHO + "<name> :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 <name> being + the item. + + 353 RPL_NAMREPLY + "( "=" / "*" / "@" ) <channel> + :[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> ) + - "@" is used for secret channels, "*" for private + channels, and "=" for others (public channels). + + 366 RPL_ENDOFNAMES + "<channel> :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 + "<mask> <server> :<hopcount> <server info>" + 365 RPL_ENDOFLINKS + "<mask> :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 + "<channel> <banmask>" + 368 RPL_ENDOFBANLIST + "<channel> :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 banmask. After the + banmasks have been listed (or if none present) a + RPL_ENDOFBANLIST MUST be sent. + + 371 RPL_INFO + ":<string>" + 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 + ":- <server> Message of the day - " + 372 RPL_MOTD + ":- <text>" + 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 MUST 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 + "<config file> :Rehashing" + + - If the REHASH option is used and an operator sends + a REHASH message, an RPL_REHASHING is sent back to + the operator. + + 383 RPL_YOURESERVICE + "You are service <servicename>" + + - Sent by the server to a service upon successful + registration. + + 391 RPL_TIME + "<server> :<string showing server's local 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 + ":<username> <ttyline> <hostname>" + 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 <version & debug level> <destination> + <next server> V<protocol version> + <link uptime in seconds> <backstream sendq> + <upstream sendq>" + 201 RPL_TRACECONNECTING + "Try. <class> <server>" + 202 RPL_TRACEHANDSHAKE + "H.S. <class> <server>" + 203 RPL_TRACEUNKNOWN + "???? <class> [<client IP address in dot form>]" + 204 RPL_TRACEOPERATOR + "Oper <class> <nick>" + 205 RPL_TRACEUSER + "User <class> <nick>" + 206 RPL_TRACESERVER + "Serv <class> <int>S <int>C <server> + <nick!user|*!*>@<host|server> V<protocol version>" + 207 RPL_TRACESERVICE + "Service <class> <name> <type> <active type>" + 208 RPL_TRACENEWTYPE + "<newtype> 0 <client name>" + 209 RPL_TRACECLASS + "Class <class> <count>" + 210 RPL_TRACERECONNECT + Unused. + 261 RPL_TRACELOG + "File <logfile> <debug level>" + 262 RPL_TRACEEND + "<server name> <version & debug level> :End of TRACE" + + - The RPL_TRACE* are all returned by the server in + response to the TRACE message. How many are + returned is dependent on 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. + RPL_TRACEEND is sent to indicate the end of the list. + + 211 RPL_STATSLINKINFO + "<linkname> <sendq> <sent messages> + <sent Kbytes> <received messages> + <received Kbytes> <time open>" + + - reports statistics on a connection. <linkname> + identifies the particular connection, <sendq> is + the amount of data that is queued and waiting to be + sent <sent messages> the number of messages sent, + and <sent Kbytes> the amount of data sent, in + Kbytes. <received messages> and <received Kbytes> + are the equivalent of <sent messages> and <sent + Kbytes> for received data, respectively. <time + open> indicates how long ago the connection was + opened, in seconds. + + 212 RPL_STATSCOMMANDS + "<command> <count> <byte count> <remote count>" + + - reports statistics on commands usage. + + 219 RPL_ENDOFSTATS + "<stats letter> :End of STATS report" + + 242 RPL_STATSUPTIME + ":Server Up %d days %d:%02d:%02d" + + - reports the server uptime. + + 243 RPL_STATSOLINE + "O <hostmask> * <name>" + + - reports the allowed hosts from where user may become IRC + operators. + + 221 RPL_UMODEIS + "<user mode string>" + + - To answer a query about a client's own mode, + RPL_UMODEIS is sent back. + + 234 RPL_SERVLIST + "<name> <server> <mask> <type> <hopcount> <info>" + + 235 RPL_SERVLISTEND + "<mask> <type> :End of service listing" + + - When listing services in reply to a SERVLIST message, + a server is required to send the list back using the + RPL_SERVLIST and RPL_SERVLISTEND messages. A separate + RPL_SERVLIST is sent for each service. After the + services have been listed (or if none present) a + RPL_SERVLISTEND MUST be sent. + + 251 RPL_LUSERCLIENT + ":There are <integer> users and <integer> + services on <integer> servers" + 252 RPL_LUSEROP + "<integer> :operator(s) online" + 253 RPL_LUSERUNKNOWN + "<integer> :unknown connection(s)" + 254 RPL_LUSERCHANNELS + "<integer> :channels formed" + 255 RPL_LUSERME + ":I have <integer> clients and <integer> + servers" + + - In processing an LUSERS message, the server + sends a set of replies from RPL_LUSERCLIENT, + RPL_LUSEROP, RPL_USERUNKNOWN, + RPL_LUSERCHANNELS and RPL_LUSERME. When + replying, a server MUST send back + RPL_LUSERCLIENT and RPL_LUSERME. The other + replies are only sent back if a non-zero count + is found for them. + + 256 RPL_ADMINME + "<server> :Administrative info" + 257 RPL_ADMINLOC1 + ":<admin info>" + 258 RPL_ADMINLOC2 + ":<admin info>" + 259 RPL_ADMINEMAIL + ":<admin info>" + + - When replying to an ADMIN message, a server + is expected to use replies RPL_ADMINME + through to RPL_ADMINEMAIL and provide a text + message with each. For RPL_ADMINLOC1 a + description of what city, state and country + the server is in is expected, followed by + details of the institution (RPL_ADMINLOC2) + and finally the administrative contact for the + server (an email address here is REQUIRED) + in RPL_ADMINEMAIL. + + 263 RPL_TRYAGAIN + "<command> :Please wait a while and try again." + + - When a server drops a command without processing it, + it MUST use the reply RPL_TRYAGAIN to inform the + originating client. +[/pre][/td][/tr] + +[tr][td] +[b]5.2 Error Replies[/b] +[/td][/tr] + +[tr][td][pre] + Error replies are found in the range from 400 to 599. + + 401 ERR_NOSUCHNICK + "<nickname> :No such nick/channel" + + - Used to indicate the nickname parameter supplied to a + command is currently unused. + + 402 ERR_NOSUCHSERVER + "<server name> :No such server" + + - Used to indicate the server name given currently + does not exist. + + 403 ERR_NOSUCHCHANNEL + "<channel name> :No such channel" + + - Used to indicate the given channel name is invalid. + + 404 ERR_CANNOTSENDTOCHAN + "<channel name> :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 or where the user is + banned and is trying to send a PRIVMSG message to + that channel. + + 405 ERR_TOOMANYCHANNELS + "<channel name> :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 + "<nickname> :There was no such nickname" + + - Returned by WHOWAS to indicate there is no history + information for that nickname. + + 407 ERR_TOOMANYTARGETS + "<target> :<error code> recipients. <abort message>" + + - 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. + + - Returned to a client which trying to send a + PRIVMSG/NOTICE to too many recipients. + + - Returned to a client which is attempting to JOIN a safe + channel using the shortname when there are more than one + such channel. + + 408 ERR_NOSUCHSERVICE + "<service name> :No such service" + + - Returned to a client which is attempting to send a SQUERY + to a service which does not exist. + + 409 ERR_NOORIGIN + ":No origin specified" + + - PING or PONG message missing the originator parameter. + + 411 ERR_NORECIPIENT + ":No recipient given (<command>)" + 412 ERR_NOTEXTTOSEND + ":No text to send" + 413 ERR_NOTOPLEVEL + "<mask> :No toplevel domain specified" + 414 ERR_WILDTOPLEVEL + "<mask> :Wildcard in toplevel domain" + 415 ERR_BADMASK + "<mask> :Bad Server/host mask" + + - 412 - 415 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 $<server>" or "PRIVMSG #<host>" is attempted. + + 421 ERR_UNKNOWNCOMMAND + "<command> :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 + "<server> :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 <file op> on <file>" + + - 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 + "<nick> :Erroneous nickname" + + - Returned after receiving a NICK message which contains + characters which do not fall in the defined set. See + section 2.3.1 for details on valid nicknames. + + 433 ERR_NICKNAMEINUSE + "<nick> :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 + "<nick> :Nickname collision KILL from <user>@<host>" + + - Returned by a server to a client when it detects a + nickname collision (registered of a NICK that + already exists by another server). + + 437 ERR_UNAVAILRESOURCE + "<nick/channel> :Nick/channel is temporarily unavailable" + + - Returned by a server to a user trying to join a channel + currently blocked by the channel delay mechanism. + + - Returned by a server to a user trying to change nickname + when the desired nickname is blocked by the nick delay + mechanism. + + 441 ERR_USERNOTINCHANNEL + "<nick> <channel> :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 + "<channel> :You're not on that channel" + + - Returned by the server whenever a client tries to + perform a channel affecting command for which the + client isn't a member. + + 443 ERR_USERONCHANNEL + "<user> <channel> :is already on channel" + + - Returned when a client tries to invite a user to a + channel they are already on. + + 444 ERR_NOLOGIN + "<user> :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 doesn't 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 + "<command> :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 + ":Unauthorized command (already registered)" + + - 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. + + 466 ERR_YOUWILLBEBANNED + + - Sent by a server to a user to inform that access to the + server will soon be denied. + + 467 ERR_KEYSET + "<channel> :Channel key already set" + 471 ERR_CHANNELISFULL + "<channel> :Cannot join channel (+l)" + 472 ERR_UNKNOWNMODE + "<char> :is unknown mode char to me for <channel>" + 473 ERR_INVITEONLYCHAN + "<channel> :Cannot join channel (+i)" + 474 ERR_BANNEDFROMCHAN + "<channel> :Cannot join channel (+b)" + 475 ERR_BADCHANNELKEY + "<channel> :Cannot join channel (+k)" + 476 ERR_BADCHANMASK + "<channel> :Bad Channel Mask" + 477 ERR_NOCHANMODES + "<channel> :Channel doesn't support modes" + 478 ERR_BANLISTFULL + "<channel> <char> :Channel list is full" + + 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 + "<channel> :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 can't 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. + + 484 ERR_RESTRICTED + ":Your connection is restricted!" + + - Sent by the server to a user upon connection to indicate + the restricted nature of the connection (user mode "+r"). + + 485 ERR_UNIQOPPRIVSNEEDED + ":You're not the original channel operator" + + - Any MODE requiring "channel creator" privileges MUST + return this error if the client making the attempt is not + a chanop on the specified channel. + + 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 + ":Cannot change mode for other users" + + - Error sent to any user trying to view or change the + user mode for a user other than themselves. +[/pre][/td][/tr] + +[tr][td] +[b]5.3 Reserved numerics[/b] +[/td][/tr] + +[tr][td][pre] + These numerics are not described above since they fall into one of + the following categories: + + 1. no longer in use; + + 2. reserved for future planned use; + + 3. in current use but are part of a non-generic 'feature' of + the current IRC server. + + 231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES + 233 RPL_SERVICE + 300 RPL_NONE 316 RPL_WHOISCHANOP + 361 RPL_KILLDONE 362 RPL_CLOSING + 363 RPL_CLOSEEND 373 RPL_INFOSTART + 384 RPL_MYPORTIS + + 213 RPL_STATSCLINE 214 RPL_STATSNLINE + 215 RPL_STATSILINE 216 RPL_STATSKLINE + 217 RPL_STATSQLINE 218 RPL_STATSYLINE + 240 RPL_STATSVLINE 241 RPL_STATSLLINE + 244 RPL_STATSHLINE 244 RPL_STATSSLINE + 246 RPL_STATSPING 247 RPL_STATSBLINE + 250 RPL_STATSDLINE + + 492 ERR_NOSERVICEHOST +[/pre][/td][/tr] + +[tr][td] +[b]6. Current implementations[/b] +[/td][/tr] + +[tr][td] +The IRC software, version 2.10 is the only complete implementation of +the IRC protocol (client and server). Because of the small amount of +changes in the client protocol since the publication of RFC 1459 +[IRC], implementations that follow it are likely to be compliant with +this protocol or to require a small amount of changes to reach +compliance. +[/td][/tr] + +[tr][td] +[b]7. Current problems[/b] +[/td][/tr] + +[tr][td] +There are a number of recognized problems with the IRC Client +Protocol, and more generally with the IRC Server Protocol. In order +to preserve backward compatibility with old clients, this protocol +has almost not evolved since the publication of RFC 1459 [IRC]. +[/td][/tr] + +[tr][td] +[b]7.1 Nicknames[/b] +[/td][/tr] + +[tr][td] +The idea of the nickname on IRC is very convenient for users to use +when talking to each other outside of a channel, but there is only a +finite nickname space and being what they are, it's not uncommon for +several people to want to use the same nick. If a nickname is chosen +by two people using this protocol, either one will not succeed or +both will removed by use of a server KILL (See Section 3.7.1). +[/td][/tr] + +[tr][td] +[b]7.2 Limitation of wildcards[/b] +[/td][/tr] + +[tr][td] +There is no way to escape the escape character "\" (%x5C). While +this isn't usually a problem, it makes it impossible to form a mask +with a backslash character ("\") preceding a wildcard. +[/td][/tr] + +[tr][td] +[b]7.3 Security considerations[/b] +[/td][/tr] + +[tr][td] +Security issues related to this protocol are discussed in the "IRC +Server Protocol" [IRC-SERVER] as they are mostly an issue for the +server side of the connection. +[/td][/tr] + +[tr][td] +[b]8. Current support and availability[/b] +[/td][/tr] + +[tr][td] +Mailing lists for IRC related discussion:[br] +General discussion: [email protected][br] +Protocol development: [email protected][br] +[p] +Software implementations:[br] +ftp://ftp.irc.org/irc/server[br] +ftp://ftp.funet.fi/pub/unix/irc[br] +ftp://ftp.irc.org/irc/clients[br] +[p] +Newsgroup: alt.irc +[/td][/tr] + +[tr][td] +[b]9. Acknowledgements[/b] +[/td][/tr] + +[tr][td] +Parts of this document were copied from the RFC 1459 [IRC] which +first formally documented the IRC Protocol. It has also benefited +from many rounds of review and comments. In particular, the +following people have made significant contributions to this +document: +[p] +Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa +Ruokonen, Magnus Tjernstrom, Stefan Zehl. +[/td][/tr] + +[tr][td] +[b]10. References[/b] +[/td][/tr] + +[tr][td][pre] + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [HNAME] Braden, R., "Requirements for Internet Hosts -- + Application and Support", STD 3, RFC 1123, October 1989. + + [IRC] Oikarinen, J. & D. Reed, "Internet Relay Chat Protocol", + RFC 1459, May 1993. + + [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, + April 2000. + + [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC + 2811, April 2000. + + [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC + 2813, April 2000. +[/pre][/td][/tr] + +[tr][td] +[b]11. Author's Address[/b] +[/td][/tr] + +[tr][td][pre] +Christophe Kalt +99 Teaneck Rd, Apt #117 +Ridgefield Park, NJ 07660 +USA + +EMail: [email protected] +[/pre][/td][/tr] + +[tr][td] +[b]12. Full Copyright Statement[/b] +[/td][/tr] + +[tr][td] +Copyright (C) The Internet Society (2000). All Rights Reserved. +[p] +This document and translations of it may be copied and furnished to +others, and derivative works that comment on or otherwise explain it +or assist in its implementation may be prepared, copied, published +and distributed, in whole or in part, without restriction of any +kind, provided that the above copyright notice and this paragraph are +included on all such copies and derivative works. However, this +document itself may not be modified in any way, such as by removing +the copyright notice or references to the Internet Society or other +Internet organizations, except as needed for the purpose of +developing Internet standards in which case the procedures for +copyrights defined in the Internet Standards process must be +followed, or as required to translate it into languages other than +English. +[p] +The limited permissions granted above are perpetual and will not be +revoked by the Internet Society or its successors or assigns. +[p] +This document and the information contained herein is provided on an +"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING +TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING +BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION +HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF +MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. +[/td][/tr] + +[tr][td] +[b]Acknowledgement[/b] +[/td][/tr] + +[tr][td] +Funding for the RFC Editor function is currently provided by the +Internet Society. +[/td][/tr] + +[/table] + +*/ |