As per Relevance of the word internet, we have this rfc below:
Network Working Group J.
Request for Comments: 1459 D.
May 1993
Internet Relay Chat
Status of This
This memo defines an Experimental Protocol for the
community. Discussion and suggestions for improvement are requested
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
The IRC protocol was developed over the last 4 years since it
first implemented as a means for users on a BBS to chat
themselves. Now it supports a world-wide network of servers
clients, and is stringing to cope with growth. Over the past 2 years
the average number of users connected to the main IRC network
grown by a factor of 10.
The IRC protocol is a text-based protocol, with the simplest
being any socket program capable of connecting to the server
Table of
1. INTRODUCTION ............................................... 4
1.1 Servers ................................................ 4
1.2 Clients ................................................ 5
1.2.1 Operators .......................................... 5
1.3 Channels ................................................ 5
1.3.1 Channel Operators .................................... 6
2. THE IRC SPECIFICATION ....................................... 7
2.1 Overview ................................................ 7
2.2 Character codes ......................................... 7
2.3 Messages ................................................ 7
2.3.1 Message format in 'pseudo' BNF .................... 8
2.4 Numeric replies ......................................... 10
3. IRC Concepts ................................................ 10
3.1 One-to-one communication ................................ 10
3.2 One-to-many ............................................. 11
3.2.1 To a list .......................................... 11
3.2.2 To a group (channel) ............................... 11
3.2.3 To a host/server mask .............................. 12
3.3 One to all .............................................. 12
Oikarinen & Reed [Page 1]
RFC 1459 Internet Relay Chat Protocol May 1993
3.3.1 Client to Client ................................... 12
3.3.2 Clients to Server .................................. 12
3.3.3 Server to Server ................................... 12
4. MESSAGE DETAILS ............................................. 13
4.1 Connection Registration ................................. 13
4.1.1 Password message ................................... 14
4.1.2 Nickname message ................................... 14
4.1.3 User message ....................................... 15
4.1.4 Server message ..................................... 16
4.1.5 Operator message ................................... 17
4.1.6 Quit message ....................................... 17
4.1.7 Server Quit message ................................ 18
4.2 Channel operations ...................................... 19
4.2.1 Join message ....................................... 19
4.2.2 Part message ....................................... 20
4.2.3 Mode message ....................................... 21
4.2.3.1 Channel modes ................................. 21
4.2.3.2 User modes .................................... 22
4.2.4 Topic message ...................................... 23
4.2.5 Names message ...................................... 24
4.2.6 List message ....................................... 24
4.2.7 Invite message ..................................... 25
4.2.8 Kick message ....................................... 25
4.3 Server queries and commands ............................. 26
4.3.1 Version message .................................... 26
4.3.2 Stats message ...................................... 27
4.3.3 Links message ...................................... 28
4.3.4 Time message ....................................... 29
4.3.5 Connect message .................................... 29
4.3.6 Trace message ...................................... 30
4.3.7 Admin message ...................................... 31
4.3.8 Info message ....................................... 31
4.4 Sending messages ........................................ 32
4.4.1 Private messages ................................... 32
4.4.2 Notice messages .................................... 33
4.5 User-based queries ...................................... 33
4.5.1 Who query .......................................... 33
4.5.2 Whois query ........................................ 34
4.5.3 Whowas message ..................................... 35
4.6 Miscellaneous messages .................................. 35
4.6.1 Kill message ....................................... 36
4.6.2 Ping message ....................................... 37
4.6.3 Pong message ....................................... 37
4.6.4 Error message ...................................... 38
5. OPTIONAL MESSAGES ........................................... 38
5.1 Away message ............................................ 38
5.2 Rehash command .......................................... 39
5.3 Restart command ......................................... 39
Oikarinen & Reed [Page 2]
RFC 1459 Internet Relay Chat Protocol May 1993
5.4 Summon message .......................................... 40
5.5 Users message ........................................... 40
5.6 Operwall command ........................................ 41
5.7 Userhost message ........................................ 42
5.8 Ison message ............................................ 42
6. REPLIES ..................................................... 43
6.1 Error Replies ........................................... 43
6.2 Command responses ....................................... 48
6.3 Reserved numerics ....................................... 56
7. Client and server authentication ............................ 56
8. Current Implementations Details ............................. 56
8.1 Network protocol: TCP ................................... 57
8.1.1 Support of Unix sockets ............................ 57
8.2 Command Parsing ......................................... 57
8.3 Message delivery ........................................ 57
8.4 Connection 'Liveness' ................................... 58
8.5 Establishing a server-client connection ................. 58
8.6 Establishing a server-server connection ................. 58
8.6.1 State information exchange when connecting ......... 59
8.7 Terminating server-client connections ................... 59
8.8 Terminating server-server connections ................... 59
8.9 Tracking nickname changes ............................... 60
8.10 Flood control of clients ............................... 60
8.11 Non-blocking lookups ................................... 61
8.11.1 Hostname (DNS) lookups ............................ 61
8.11.2 Username (Ident) lookups .......................... 61
8.12 Configuration file ..................................... 61
8.12.1 Allowing clients to connect ....................... 62
8.12.2 Operators ......................................... 62
8.12.3 Allowing servers to connect ....................... 62
8.12.4 Administrivia ..................................... 63
8.13 Channel membership ..................................... 63
9. Current problems ............................................ 63
9.1 Scalability ............................................. 63
9.2 Labels .................................................. 63
9.2.1 Nicknames .......................................... 63
9.2.2 Channels ........................................... 64
9.2.3 Servers ............................................ 64
9.3 Algorithms .............................................. 64
10. Support and availability ................................... 64
11. Security Considerations .................................... 65
12. Authors' Addresses ......................................... 65
Oikarinen & Reed [Page 3]
RFC 1459 Internet Relay Chat Protocol May 1993
1.
The IRC (Internet Relay Chat) protocol has been designed over
number of years for use with text based conferencing. This
describes the current IRC protocol
The IRC protocol has been developed on systems using the TCP/
network protocol, although there is no requirement that this
the only sphere in which it operates
IRC itself is a teleconferencing system, which (through the use
the client-server model) is well-suited to running on many
in a distributed fashion. A typical setup involves a single
(the server) forming a central point for clients (or other servers
to connect to, performing the required message delivery/
and other functions
1.1
The server forms the backbone of IRC, providing a point to
clients may connect to to talk to each other, and a point for
servers to connect to, forming an IRC network. The only
configuration allowed for IRC servers is that of a spanning tree [
Fig. 1] where each server acts as a central node for the rest of
net it sees
[ Server 15 ] [ Server 13 ] [ Server 14]
/ \ /
/ \ /
[ Server 11 ] ------ [ Server 1 ] [ Server 12]
/ \ /
/ \ /
[ Server 2 ] [ Server 3 ]
/ \ \
/ \ \
[ Server 4 ] [ Server 5 ] [ Server 6 ]
/ | \ /
/ | \ /
/ | \____ /
/ | \ /
[ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ]
:
[ etc. ]
:
[ Fig. 1. Format of IRC server network ]
Oikarinen & Reed [Page 4]
RFC 1459 Internet Relay Chat Protocol May 1993
1.2
A client is anything connecting to a server that is not
server. Each client is distinguished from other clients by a
nickname having a maximum length of nine (9) characters. See
protocol grammar rules for what may and may not be used in
nickname. In addition to the nickname, all servers must have
following information about all clients: the real name of the
that the client is running on, the username of the client on
host, and the server to which the client is connected
1.2.1
To allow a reasonable amount of order to be kept within the
network, a special class of clients (operators) is allowed to
general maintenance functions on the network. Although the
granted to an operator can be considered as 'dangerous', they
nonetheless required. Operators should be able to perform
network tasks such as disconnecting and reconnecting servers
needed to prevent long-term use of bad network routing.
recognition of this need, the protocol discussed herein provides
operators only to be able to perform such functions. See
4.1.7 (SQUIT) and 4.3.5 (CONNECT).
A more controversial power of operators is the ability to remove
user from the connected network by 'force', i.e. operators are
to close the connection between any client and server.
justification for this is delicate since its abuse is
destructive and annoying. For further details on this type
action, see section 4.6.1 (KILL).
1.3
A channel is a named group of one or more clients which will
receive messages addressed to that channel. The channel is
implicitly when the first client joins it, and the channel ceases
exist when the last client leaves it. While channel exists,
client can reference the channel using the name of the channel
Channels names are strings (beginning with a '&' or '#' character)
length up to 200 characters. Apart from the the requirement that
first character being either '&' or '#'; the only restriction on
channel name is that it may not contain any spaces (' '), a control
(^G or ASCII 7), or a comma (',' which is used as a list
separator by the protocol).
There are two types of channels allowed by this protocol. One is
distributed channel which is known to all the servers that
Oikarinen & Reed [Page 5]
RFC 1459 Internet Relay Chat Protocol May 1993
connected to the network. These channels are marked by the
character being a only clients on the server where it exists may
it. These are distinguished by a leading '&' character. On top
these two types, there are the various channel modes available
alter the characteristics of individual channels. See section 4.2.3
(MODE command) for more details on this
To create a new channel or become part of an existing channel, a
is required to JOIN the channel. If the channel doesn't exist
to joining, the channel is created and the creating user becomes
channel operator. If the channel already exists, whether or not
request to JOIN that channel is honoured depends on the current
of the channel. For example, if the channel is invite-only, (+i),
then you may only join if invited. As part of the protocol, a
may be a part of several channels at once, but a limit of ten (10)
channels is recommended as being ample for both experienced
novice users. See section 8.13 for more information on this
If the IRC network becomes disjoint because of a split between
servers, the channel on each side is only composed of those
which are connected to servers on the respective sides of the split
possibly ceasing to exist on one side of the split. When the
is healed, the connecting servers announce to each other who
think is in each channel and the mode of that channel. If
channel exists on both sides, the JOINs and MODEs are interpreted
an inclusive manner so that both sides of the new connection
agree about which clients are in the channel and what modes
channel has
1.3.1 Channel
The channel operator (also referred to as a "chop" or "chanop") on
given channel is considered to 'own' that channel. In recognition
this status, channel operators are endowed with certain powers
enable them to keep control and some sort of sanity in their channel
As an owner of a channel, a channel operator is not required to
reasons for their actions, although if their actions are
antisocial or otherwise abusive, it might be reasonable to ask an
operator to intervene, or for the usersjust leave and go
and form their own channel
The commands which may only be used by channel operators are
KICK - Eject a client from the
MODE - Change the channel's
INVITE - Invite a client to an invite-only channel (mode +i
TOPIC - Change the channel topic in a mode +t
Oikarinen & Reed [Page 6]
RFC 1459 Internet Relay Chat Protocol May 1993
A channel operator is identified by the '@' symbol next to
nickname whenever it is associated with a channel (ie replies to
NAMES, WHO and WHOIS commands).
2. The IRC
2.1
The protocol as described herein is for use both with server
server and client to server connections. There are, however,
restrictions on client connections (which are considered to
untrustworthy) than on server connections
2.2 Character
No specific character set is specified. The protocol is based on a
set of codes which are composed of eight (8) bits, making up
octet. Each message may be composed of any number of these octets
however, some octet values are used for control codes which act
message delimiters
Regardless of being an 8-bit protocol, the delimiters and
are such that protocol is mostly usable from USASCII terminal and
telnet connection
Because of IRC's scandanavian origin, the characters {}|
considered to be the lower case equivalents of the characters []\,
respectively. This is a critical issue when determining
equivalence of two nicknames
2.3
Servers and clients send eachother messages which may or may
generate a reply. If the message contains a valid command,
described in later sections, the client should expect a reply
specified but it is not advised to wait forever for the reply;
to server and server to server communication is
asynchronous in nature
Each IRC message may consist of up to three main parts: the
(optional), the command, and the command parameters (of which
may be up to 15). The prefix, command, and all parameters
separated by one (or more) ASCII space character(s) (0x20).
The presence of a prefix is indicated with a single leading
colon character (':', 0x3b), which must be the first character of
message itself. There must be no gap (whitespace) between the
and the prefix. The prefix is used by servers to indicate the
Oikarinen & Reed [Page 7]
RFC 1459 Internet Relay Chat Protocol May 1993
origin of the message. If the prefix is missing from the message,
is assumed to have originated from the connection from which it
received. Clients should not use prefix when sending a message
themselves; if they use a prefix, the only valid prefix is
registered nickname associated with the client. If the
identified by the prefix cannot be found from the server's
database, or if the source is registered from a different link
from which the message arrived, the server must ignore the
silently
The command must either be a valid IRC command or a three (3)
number represented in ASCII text
IRC messages are always lines of characters terminated with a CR-
(Carriage Return - Line Feed) pair, and these messages shall
exceed 512 characters in length, counting all characters
the trailing CR-LF. Thus, there are 510 characters maximum
for the command and its parameters. There is no provision
continuation message lines. See section 7 for more details
current implementations
2.3.1 Message format in 'pseudo'
The protocol messages must be extracted from the contiguous stream
octets. The current solution is to designate two characters, CR
LF, as message separators. Empty messages are silently ignored
which permits use of the sequence CR-LF between
without extra problems
The extracted message is parsed into the components ,
and list of parameters matched either by
components
The BNF representation for this is
::= [':' ]
::= | [ '!' ] [ '@' ]
::= { } |
::= ' ' { ' ' }
::= [ ':' | ]
::= sequence of octets not including
or NUL or CR or LF, the first of which may not be ':'>
::= sequence of octets not
NUL or CR or LF
::= CR
Oikarinen & Reed [Page 8]
RFC 1459 Internet Relay Chat Protocol May 1993
NOTES
1) is consists only of SPACE character(s) (0x20).
Specially notice that TABULATION, and all other
characters are considered NON-WHITE-SPACE
2) After extracting the parameter list, all parameters are equal
whether matched by or . is
a syntactic trick to allow SPACE within parameter
3) The fact that CR and LF cannot appear in parameter strings
just artifact of the message framing. This might change later
4) The NUL character is not special in message framing,
basically could end up inside a parameter, but as it
cause extra complexities in normal C string handling.
NUL is not allowed within messages
5) The last parameter may be an empty string
6) Use of the extended prefix (['!' ] ['@' ])
not be used in server to server communications and is
intended for server to client messages in order to
clients with more useful information about who a message
from without the need for additional queries
Most protocol messages specify additional semantics and syntax
the extracted parameter strings dictated by their position in
list. For example, many server commands will assume that the
parameter after the command is the list of targets, which can
described with
::= [ "," ]
::= | '@' | |
::= ('#' | '&')
::=
::= see RFC 952 [DNS:4] for details on allowed
::= { | | }
::= ('#' | '$')
::=
comma (',')>
Other parameter syntaxes are
::= { }
::= 'a' ... 'z' | 'A' ... 'Z
::= '0' ... '9'
::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'
Oikarinen & Reed [Page 9]
RFC 1459 Internet Relay Chat Protocol May 1993
::=
(0xd), and LF (0xa)>
2.4 Numeric
Most of the messages sent to the server generate a reply of
sort. The most common reply is the numeric reply, used for
errors and normal replies. The numeric reply must be sent as
message consisting of the sender prefix, the three digit numeric,
the target of the reply. A numeric reply is not allowed to
from a client; any such messages received by a server are
dropped. In all other respects, a numeric reply is just like a
message, except that the keyword is made up of 3 numeric
rather than a string of letters. A list of different replies
supplied in section 6.
3. IRC Concepts
This section is devoted to describing the actual concepts behind
organization of the IRC protocol and how the
implementations deliver different classes of messages
1--\
A D---4
2--/ \ /
B----
/ \
3
Servers: A, B, C, D, E Clients: 1, 2, 3, 4
[ Fig. 2. Sample small IRC network ]
3.1 One-to-one
Communication on a one-to-one basis is usually only performed
clients, since most server-server traffic is not a result of
talking only to each other. To provide a secure means for clients
talk to each other, it is required that all servers be able to send
message in exactly one direction along the spanning tree in order
reach any client. The path of a message being delivered is
shortest path between any two points on the spanning tree
The following examples all refer to Figure 2 above
Oikarinen & Reed [Page 10]
RFC 1459 Internet Relay Chat Protocol May 1993
Example 1:
A message between clients 1 and 2 is only seen by server A,
sends it straight to client 2.
Example 2:
A message between clients 1 and 3 is seen by servers A & B,
client 3. No other clients or servers are allowed see the message
Example 3:
A message between clients 2 and 4 is seen by servers A, B, C &
and client 4 only
3.2 One-to-
The main goal of IRC is to provide a forum which allows easy
efficient conferencing (one to many conversations). IRC
several means to achieve this, each serving its own purpose
3.2.1 To a
The least efficient style of one-to-many conversation is
clients talking to a 'list' of users. How this is done is
self explanatory: the client gives a list of destinations to
the message is to be delivered and the server breaks it up
dispatches a separate copy of the message to each given destination
This isn't as efficient as using a group since the destination
is broken up and the dispatch sent without checking to make
duplicates aren't sent down each path
3.2.2 To a group (channel
In IRC the channel has a role equivalent to that of the
group; their existence is dynamic (coming and going as people
and leave channels) and the actual conversation carried out on
channel is only sent to servers which are supporting users on a
channel. If there are multiple users on a server in the
channel, the message text is sent only once to that server and
sent to each client on the channel. This action is then repeated
each client-server combination until the original message has
out and reached each member of the channel
The following examples all refer to Figure 2.
Example 4:
Any channel with 1 client in it. Messages to the channel go to
server and then nowhere else
Oikarinen & Reed [Page 11]
RFC 1459 Internet Relay Chat Protocol May 1993
Example 5:
2 clients in a channel. All messages traverse a path as if
were private messages between the two clients outside a channel
Example 6:
Clients 1, 2 and 3 in a channel. All messages to the channel
sent to all clients and only those servers which must be
by the message if it were a private message to a single client.
client 1 sends a message, it goes back to client 2 and then
server B to client 3.
3.2.3 To a host/server
To provide IRC operators with some mechanism to send messages to
large body of related users, host and server mask messages
provided. These messages are sent to users whose host or
information match that of the mask. The messages are only sent
locations where users are, in a fashion similar to that of channels
3.3 One-to-
The one-to-all type of message is better described as a
message, sent to all clients or servers or both. On a large
of users and servers, a single message can result in a lot of
being sent over the network in an effort to reach all of the
destinations
For some messages, there is no option but to broadcast it to
servers so that the state information held by each server
reasonably consistent between servers
3.3.1 Client-to-
There is no class of message which, from a single message, results
a message being sent to every other client
3.3.2 Client-to-
Most of the commands which result in a change of state
(such as channel membership, channel mode, user status, etc) must
sent to all servers by default, and this distribution may not
changed by the client
3.3.3 Server-to-Server
While most messages between servers are distributed to all 'other
servers, this is only required for any message that affects either
user, channel or server. Since these are the basic items found
Oikarinen & Reed [Page 12]
RFC 1459 Internet Relay Chat Protocol May 1993
IRC, nearly all messages originating from a server are broadcast
all other connected servers
4. Message
On the following pages are descriptions of each message recognized
the IRC server and client. All commands described in this
must be implemented by any server for this protocol
Where the reply ERR_NOSUCHSERVER is listed, it means that
parameter could not be found. The server must not send
other replies after this for that command
The server to which a client is connected is required to parse
complete message, returning any appropriate errors. If the
encounters a fatal error while parsing a message, an error must
sent back to the client and the parsing terminated. A fatal
may be considered to be incorrect command, a destination which
otherwise unknown to the server (server, nick or channel names
this category), not enough parameters or incorrect privileges
If a full set of parameters is presented, then each must be
for validity and appropriate responses sent back to the client.
the case of messages which use parameter lists using the comma as
item separator, a reply must be sent for each item
In the examples below, some messages appear using the full format
:Name COMMAND parameter
Such examples represent a message from "Name" in transit
servers, where it is essential to include the name of the
sender of the message so remote servers may send back a reply
the correct path
4.1 Connection
The commands described here are used to register a connection with
IRC server as either a user or a server as well as
disconnect
A "PASS" command is not required for either client or
connection to be registered, but it must precede the server
or the latter of the NICK/USER combination. It is
recommended that all server connections have a password in order
give some level of security to the actual connections.
recommended order for a client to register is as follows
Oikarinen & Reed [Page 13]
RFC 1459 Internet Relay Chat Protocol May 1993
1. Pass
2. Nick
3. User
4.1.1 Password
Command:
Parameters: <password
The PASS command is used to set a 'connection password'.
password can and must be set before any attempt to register
connection is made. Currently this requires that clients send a
command before sending the NICK/USER combination and servers *must
send a PASS command before any SERVER command. The password
must match the one contained in the C/N lines (for servers) or
lines (for clients). It is possible to send multiple PASS
before registering but only the last one sent is used
verification and it may not be changed once registered.
Replies
ERR_NEEDMOREPARAMS ERR_
Example
PASS
4.1.2 Nick
Command:
Parameters: <nickname> [ ]
NICK message is used to give user a nickname or change the
one. The parameter is only used by servers to
how far away a nick is from its home server. A local connection
a hopcount of 0. If supplied by a client, it must be ignored
If a NICK message arrives at a server which already knows about
identical nickname for another client, a nickname collision occurs
As a result of a nickname collision, all instances of the
are removed from the server's database, and a KILL command is
to remove the nickname from all other server's database. If the
message causing the collision was a nickname change, then
original (old) nick must be removed as well
If the server recieves an identical NICK from a client which
directly connected, it may issue an ERR_NICKCOLLISION to the
client, drop the NICK command, and not generate any kills
Oikarinen & Reed [Page 14]
RFC 1459 Internet Relay Chat Protocol May 1993
Numeric Replies
ERR_NONICKNAMEGIVEN ERR_
ERR_NICKNAMEINUSE ERR_
Example
NICK Wiz ; Introducing new nick "Wiz".
:WiZ NICK Kilroy ; WiZ changed his nickname to Kilroy
4.1.3 User
Command:
Parameters: <username> <hostname>
The USER message is used at the beginning of connection to
the username, hostname, servername and realname of s new user. It
also used in communication between servers to indicate new
arriving on IRC, since only after both USER and NICK have
received from a client does a user become registered
Between servers USER must to be prefixed with client's NICKname
Note that hostname and servername are normally ignored by the
server when the USER command comes from a directly connected
(for security reasons), but they are used in server to
communication. This means that a NICK must always be sent to
remote server when a new user is being introduced to the rest of
network before the accompanying USER is sent
It must be noted that realname parameter must be the last parameter
because it may contain space characters and must be prefixed with
colon (':') to make sure this is recognised as such
Since it is easy for a client to lie about its username by
solely on the USER message, the use of an "Identity Server"
recommended. If the host which a user connects from has such
server enabled the username is set to that as in the reply from
"Identity Server".
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
Examples
USER guest tolmoon tolsun :Ronnie
Oikarinen & Reed [Page 15]
RFC 1459 Internet Relay Chat Protocol May 1993
; User registering themselves with
username of "guest" and real
"Ronnie Reagan".
:testnick USER guest tolmoon tolsun :Ronnie
; message between servers with
nickname for which the USER
belongs
4.1.4 Server
Command:
Parameters:
The server message is used to tell a server that the other end of
new connection is a server. This message is also used to pass
data over whole net. When a new server is connected to net
information about it be broadcast to the whole network.
is used to give all servers some internal information on how far
all servers are. With a full server list, it would be possible
construct a map of the entire server tree, but hostmasks prevent
from being done
The SERVER message must only be accepted from either (a) a
which is yet to be registered and is attempting to register as
server, or (b) an existing connection to another server, in
case the SERVER message is introducing a new server behind
server
Most errors that occur with the receipt of a SERVER command result
the connection being terminated by the destination host (
SERVER). Error replies are usually sent using the "ERROR"
rather than the numeric since the ERROR command has several
properties which make it useful here
If a SERVER message is parsed and attempts to introduce a
which is already known to the receiving server, the connection
which that message must be closed (following the correct procedures),
since a duplicate route to a server has formed and the acyclic
of the IRC tree broken
Numeric Replies
ERR_
Example
Oikarinen & Reed [Page 16]
RFC 1459 Internet Relay Chat Protocol May 1993
SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental
; New server test.oulu.fi
itself and attempting to register.
name in []'s is the hostname for
host running test.oulu.fi
:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central
; Server tolsun.oulu.fi is our
for csd.bu.edu which is 5 hops away
4.1.5
Command:
Parameters: <password
OPER message is used by a normal user to obtain operator privileges
The combination of and <password> are required to
Operator privileges
If the client sending the OPER command supplies the correct
for the given user, the server then informs the rest of the
of the new operator by issuing a "MODE +o" for the clients nickname
The OPER message is client-server only
Numeric Replies
ERR_NEEDMOREPARAMS RPL_
ERR_NOOPERHOST ERR_
Example
OPER foo bar ; Attempt to register as an
using a username of "foo" and "bar"
the password
4.1.6
Command:
Parameters: []
A client session is ended with a quit message. The server must
the connection to a client which sends a QUIT message. If a "
Message" is given, this will be sent instead of the default message
the nickname
When netsplits (disconnecting of two servers) occur, the quit
Oikarinen & Reed [Page 17]
RFC 1459 Internet Relay Chat Protocol May 1993
is composed of the names of two servers involved, separated by
space. The first name is that of the server which is still
and the second name is that of the server that has
disconnected
If, for some other reason, a client connection is closed without
client issuing a QUIT command (e.g. client dies and EOF
on socket), the server is required to fill in the quit message
some sort of message reflecting the nature of the event
caused it to happen
Numeric Replies
None
Examples
QUIT :Gone to have lunch ; Preferred message format
4.1.7 Server quit
Command:
Parameters:
The SQUIT message is needed to tell about quitting or dead servers
If a server wishes to break the connection to another server it
send a SQUIT message to the other server, using the the name of
other server as the server parameter, which then closes
connection to the quitting server
This command is also available operators to help keep a network
IRC servers connected in an orderly fashion. Operators may
issue an SQUIT message for a remote server connection. In this case
the SQUIT must be parsed by each server inbetween the operator
the remote server, updating the view of the network held by
server as explained below
The should be supplied by all operators who execute a
for a remote server (that is not connected to the server they
currently on) so that other operators are aware for the reason
this action. The is also filled in by servers which
place an error or similar message here
Both of the servers which are on either side of the connection
closed are required to to send out a SQUIT message (to all its
server connections) for all other servers which are considered to
behind that link
Oikarinen & Reed [Page 18]
RFC 1459 Internet Relay Chat Protocol May 1993
Similarly, a QUIT message must be sent to the other connected
rest of the network on behalf of all clients behind that link.
addition to this, all channel members of a channel which lost
member due to the split must be sent a QUIT message
If a server connection is terminated prematurely (e.g. the server
the other end of the link died), the server which
this disconnection is required to inform the rest of the
that the connection has closed and fill in the comment
with something appropriate
Numeric replies
ERR_NOPRIVILEGES ERR_
Example
SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi
been terminated because of "Bad Link".
:Trillian SQUIT cm22.eng.umd.edu :Server out of
; message from Trillian to
"cm22.eng.umd.edu" from the
because "Server out of control".
4.2 Channel
This group of messages is concerned with manipulating channels,
properties (channel modes), and their contents (typically clients).
In implementing these, a number of race conditions are
when clients at opposing ends of a network send commands which
ultimately clash. It is also required that servers keep a
history to ensure that wherever a parameter is given,
server check its history in case it has recently been changed
4.2.1 Join
Command:
Parameters: {,} [{,}]
The JOIN command is used by client to start listening a
channel. Whether or not a client is allowed to join a channel
checked only by the server the client is connected to; all
servers automatically add the user to the channel when it is
from other servers. The conditions which affect this are as follows
1. the user must be invited if the channel is invite-only
Oikarinen & Reed [Page 19]
RFC 1459 Internet Relay Chat Protocol May 1993
2. the user's nick/username/hostname must not match
active bans
3. the correct key (password) must be given if it is set
These are discussed in more detail under the MODE command (
section 4.2.3 for more details).
Once a user has joined a channel, they receive notice about
commands their server receives which affect the channel.
includes MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE.
JOIN command needs to be broadcast to all servers so that each
knows where to find the users who are on the channel. This
optimal delivery of PRIVMSG/NOTICE messages to the channel
If a JOIN is successful, the user is then sent the channel's
(using RPL_TOPIC) and the list of users who are on the channel (
RPL_NAMREPLY), which must include the user joining
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
ERR_INVITEONLYCHAN ERR_
ERR_CHANNELISFULL ERR_
ERR_NOSUCHCHANNEL ERR_
RPL_
Examples
JOIN #foobar ; join channel #foobar
JOIN &foo fubar ; join channel &foo using key "fubar".
JOIN #foo,&bar fubar ; join channel #foo using key "fubar
and &bar using no key
JOIN #foo,#bar fubar,foobar ; join channel #foo using key "fubar".
and channel #bar using key "foobar".
JOIN #foo,#bar ; join channels #foo and #bar
:WiZ JOIN #Twilight_zone ; JOIN message from
4.2.2 Part
Command:
Parameters: {,}
Oikarinen & Reed [Page 20]
RFC 1459 Internet Relay Chat Protocol May 1993
The PART message causes the client sending the message to be
from the list of active users for all given channels listed in
parameter string
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
ERR_
Examples
PART #twilight_zone ; leave channel "#twilight_zone
PART #oz-ops,&group5 ; leave both channels "&group5"
"#oz-ops".
4.2.3 Mode
Command:
The MODE command is a dual-purpose command in IRC. It allows
usernames and channels to have their mode changed. The rationale
this choice is that one day nicknames will be obsolete and
equivalent property will be the channel
When parsing MODE messages, it is recommended that the entire
be parsed first and then the changes which resulted then passed on
4.2.3.1 Channel
Parameters: {[+|-]|o|p|s|i|t|n|b|v} [] []
[]
The MODE command is provided so that channel operators may change
characteristics of `their' channel. It is also required that
be able to change channel modes so that channel operators may
created
The various modes available for channels are as follows
o - give/take channel operator privileges
p - private channel flag
s - secret channel flag
i - invite-only channel flag
t - topic settable by channel operator only flag
n - no messages to channel from clients on the outside
m - moderated channel
l - set the user limit to channel
Oikarinen & Reed [Page 21]
RFC 1459 Internet Relay Chat Protocol May 1993
b - set a ban mask to keep users out
v - give/take the ability to speak on a moderated channel
k - set a channel key (password).
When using the 'o' and 'b' options, a restriction on a total of
per mode command has been imposed. That is, any combination of 'o
4.2.3.2 User
Parameters: <nickname> {[+|-]|i|w|s|o
The user MODEs are typically changes which affect either how
client is seen by others or what 'extra' messages the client is sent
A user MODE command may only be accepted if both the sender of
message and the nickname given as a parameter are both the same
The available modes are as follows
i - marks a users as invisible
s - marks a user for receipt of server notices
w - user receives wallops
o - operator flag
Additional modes may be available later on
If a user attempts to make themselves an operator using the "+o
flag, the attempt should be ignored. There is no restriction
however, on anyone `deopping' themselves (using "-o").
Replies
ERR_NEEDMOREPARAMS RPL_
ERR_CHANOPRIVSNEEDED ERR_
ERR_NOTONCHANNEL ERR_
RPL_BANLIST RPL_
ERR_UNKNOWNMODE ERR_
ERR_USERSDONTMATCH RPL_
ERR_
Examples
Use of Channel Modes
MODE #Finnish +im ; Makes #Finnish channel moderated
'invite-only'.
MODE #Finnish +o Kilroy ; Gives 'chanop' privileges to Kilroy
Oikarinen & Reed [Page 22]
RFC 1459 Internet Relay Chat Protocol May 1993
channel #Finnish
MODE #Finnish +v Wiz ; Allow WiZ to speak on #Finnish
MODE #Fins -s ; Removes 'secret' flag from
#Fins
MODE #42 +k oulu ; Set the channel key to "oulu".
MODE #eu-opers +l 10 ; Set the limit for the number of
on channel to 10.
MODE &oulu +b ; list ban masks set for channel
MODE &oulu +b *!*@* ; prevent all users from joining
MODE &oulu +b *!*@*.edu ; prevent any user from a
matching *.edu from joining
Use of user Modes
:MODE WiZ -w ; turns reception of WALLOPS
off for WiZ
:Angel MODE Angel +i ; Message from Angel to make
invisible
MODE WiZ -o ; WiZ 'deopping' (removing
status). The plain reverse of
command ("MODE WiZ +o") must not
allowed from users since would
the OPER command
4.2.4 Topic
Command:
Parameters: []
The TOPIC message is used to change or view the topic of a channel
The topic for channel is returned if there is no
given. If the parameter is present, the topic for
channel will be changed, if the channel modes permit this action
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
RPL_NOTOPIC RPL_
ERR_
Oikarinen & Reed [Page 23]
RFC 1459 Internet Relay Chat Protocol May 1993
Examples
:Wiz TOPIC #test :New topic ;User Wiz setting the topic
TOPIC #test :another topic ;set the topic on #test to "
topic".
TOPIC #test ; check the topic for #test
4.2.5 Names
Command:
Parameters: [{,}]
By using the NAMES command, a user can list all nicknames that
visible to them on any channel that they can see. Channel
which they can see are those which aren't private (+p) or secret (+s
or those which they are actually on. The
specifies which channel(s) to return information about if valid
There is no error reply for bad channel names
If no parameter is given, a list of all channels and
occupants is returned. At the end of this list, a list of users
are visible but either not on any channel or not on a visible
are listed as being on `channel' "*".
Numerics
RPL_NAMREPLY RPL_
Examples
NAMES #twilight_zone,#42 ; list visible users on #twilight_
and #42 if the channels are visible
you
NAMES ; list all visible channels and
4.2.6 List
Command:
Parameters: [{,} []]
The list message is used to list channels and their topics. If
parameter is used, only the status of that
is displayed. Private channels are listed (without
topics) as channel "Prv" unless the client generating the query
actually on that channel. Likewise, secret channels are not
Oikarinen & Reed [Page 24]
RFC 1459 Internet Relay Chat Protocol May 1993
at all unless the client is a member of the channel in question
Numeric Replies
ERR_NOSUCHSERVER RPL_
RPL_LIST RPL_
Examples
LIST ; List all channels
LIST #twilight_zone,#42 ; List channels #twilight_zone and #42
4.2.7 Invite
Command:
Parameters: <nickname>
The INVITE message is used to invite users to a channel.
parameter <nickname> is the nickname of the person to be invited
the target channel . There is no requirement that
channel the target user is being invited to must exist or be a
channel. To invite a user to a channel which is invite only (
+i), the client sending the invite must be recognised as being
channel operator on the given channel
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
ERR_NOTONCHANNEL ERR_
ERR_
RPL_INVITING RPL_
Examples
:Angel INVITE Wiz #Dust ; User Angel inviting WiZ to
#
INVITE Wiz #Twilight_Zone ; Command to invite WiZ
#Twilight_
4.2.8 Kick
Command:
Parameters: []
The KICK command can be used to forcibly remove a user from
channel. It 'kicks them out' of the channel (forced PART).
Oikarinen & Reed [Page 25]
RFC 1459 Internet Relay Chat Protocol May 1993
Only a channel operator may kick another user out of a channel
Each server that receives a KICK message checks that it is
(ie the sender is actually a channel operator) before
the victim from the channel
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
ERR_BADCHANMASK ERR_
ERR_
Examples
KICK &Melbourne Matthew ; Kick Matthew from &
KICK #Finnish John :Speaking
; Kick John from #Finnish
"Speaking English" as the
(comment).
:WiZ KICK #Finnish John ; KICK message from WiZ to remove
from channel #
NOTE
It is possible to extend the KICK command parameters to
following
{,} {,} []
4.3 Server queries and
The server query group of commands has been designed to
information about any server which is connected to the network.
servers connected must respond to these queries and
correctly. Any invalid response (or lack thereof) must be
a sign of a broken server and it must be disconnected/disabled
soon as possible until the situation is remedied
In these queries, where a parameter appears as "", it
usually mean it can be a nickname or a server or a wildcard name
some sort. For each parameter, however, only one query and set
replies is to be generated
4.3.1 Version
Command:
Parameters: []
Oikarinen & Reed [Page 26]
RFC 1459 Internet Relay Chat Protocol May 1993
The VERSION message is used to query the version of the
program. An optional parameter is used to query the
of the server program which a client is not directly connected to
Numeric Replies
ERR_NOSUCHSERVER RPL_
Examples
:Wiz VERSION *.se ; message from Wiz to check the
of a server matching "*.se
VERSION tolsun.oulu.fi ; check the version of
"tolsun.oulu.fi".
4.3.2 Stats
Command:
Parameters: [ []]
The stats message is used to query statistics of certain server.
parameter is omitted, only the end of stats reply is
back. The implementation of this command is highly dependent on
server which replies, although the server must be able to
information as described by the queries below (or similar).
A query may be given by any single letter which is only checked
the destination server (if given as the parameter) and
otherwise passed on by intermediate servers, ignored and unaltered
The following queries are those found in the current
implementation and provide a large portion of the setup
for that server. Although these may not be supported in the same
by other versions, all servers should be able to supply a valid
to a STATS query which is consistent with the reply formats
used and the purpose of the query
The currently supported queries are
c - returns a list of servers which the server may
to or allow connections from
h - returns a list of servers which are either forced to
treated as leaves or allowed to act as hubs
i - returns a list of hosts which the server allows a
to connect from
k - returns a list of banned username/hostname
for that server
l - returns a list of the server's connections, showing
Oikarinen & Reed [Page 27]
RFC 1459 Internet Relay Chat Protocol May 1993
long each connection has been established and the
over that connection in bytes and messages for
direction
m - returns a list of commands supported by the server
the usage count for each if the usage count is non zero
o - returns a list of hosts from which normal clients
become operators
y - show Y (Class) lines from server's configuration file
u - returns a string showing how long the server has been up
Numeric Replies
ERR_
RPL_STATSCLINE RPL_
RPL_STATSILINE RPL_
RPL_STATSQLINE RPL_
RPL_STATSLINKINFO RPL_
RPL_STATSCOMMANDS RPL_
RPL_STATSHLINE RPL_
Examples
STATS m ; check the command usage for the
you are connected
:Wiz STATS c eff.org ; request by WiZ for C/N
information from server eff.
4.3.3 Links
Command:
Parameters: [[] ]
With LINKS, a user can list all servers which are known by the
answering the query. The returned list of servers must match
mask, or if no mask is given, the full list is returned
If is given in addition to , the
command is forwarded to the first server found that matches that
(if any), and that server is then required to answer the query
Numeric Replies
ERR_
RPL_LINKS RPL_
Examples
Oikarinen & Reed [Page 28]
RFC 1459 Internet Relay Chat Protocol May 1993
LINKS *.au ; list all servers which have a
that matches *.au
:WiZ LINKS *.bu.edu *.edu ; LINKS message from WiZ to the
server matching *.edu for a list
servers matching *.bu.edu
4.3.4 Time
Command:
Parameters: []
The time message is used to query local time from the
server. If the server parameter is not given, the server handling
command must reply to the query
Numeric Replies
ERR_NOSUCHSERVER RPL_
Examples
TIME tolsun.oulu.fi ; check the time on the
"tolson.oulu.fi
Angel TIME *.au ; user angel checking the time on
server matching "*.au
4.3.5 Connect
Command:
Parameters: [ []]
The CONNECT command can be used to force a server to try to
a new connection to another server immediately. CONNECT is
privileged command and is to be available only to IRC Operators.
a remote server is given then the CONNECT attempt is made by
server to and .
Numeric Replies
ERR_NOSUCHSERVER ERR_
ERR_
Examples
CONNECT tolsun.oulu.fi ; Attempt to connect a server
tolsun.oulu.
Oikarinen & Reed [Page 29]
RFC 1459 Internet Relay Chat Protocol May 1993
:WiZ CONNECT eff.org 6667 csd.bu.
; CONNECT attempt by WiZ to get
eff.org and csd.bu.edu connected on
6667.
4.3.6 Trace
Command:
Parameters: []
TRACE command is used to find the route to specific server.
server that processes this message must tell the sender about it
sending a reply indicating it is a pass-through link, forming a
of replies similar to that gained from using "traceroute".
sending this reply back, it must then send the TRACE message to
next server until given server is reached. If the
is omitted, it is recommended that TRACE command send a message
the sender telling which servers the current server has
connection to
If the destination given by "" is an actual server, then
destination server is required to report all servers and users
are connected to it, although only operators are permitted to
users present. If the destination given by is a nickname
they only a reply for that nickname is given
Numeric Replies
ERR_
If the TRACE message is destined for another server, all
servers must return a RPL_TRACELINK reply to indicate that the
passed through it and where its going next
RPL_
A TRACE reply may be composed of any number of the following
replies
RPL_TRACECONNECTING RPL_
RPL_TRACEUNKNOWN RPL_
RPL_TRACEUSER RPL_
RPL_TRACESERVICE RPL_
RPL_
Examples
TRACE *.oulu.fi ; TRACE to a server matching *.oulu.
Oikarinen & Reed [Page 30]
RFC 1459 Internet Relay Chat Protocol May 1993
:WiZ TRACE AngelDust ; TRACE issued by WiZ to nick
4.3.7 Admin
Command:
Parameters: []
The admin message is used to find the name of the administrator
the given server, or current server if parameter is omitted
Each server must have the ability to forward ADMIN messages to
servers
Numeric Replies
ERR_
RPL_ADMINME RPL_ADMINLOC
RPL_ADMINLOC2 RPL_
Examples
ADMIN tolsun.oulu.fi ; request an ADMIN reply
tolsun.oulu.
:WiZ ADMIN *.edu ; ADMIN request from WiZ for
server found to match *.edu
4.3.8 Info
Command:
Parameters: []
The INFO command is required to return information which
the server: its version, when it was compiled, the patchlevel,
it was started, and any other miscellaneous information which may
considered to be relevant
Numeric Replies
ERR_
RPL_INFO RPL_
Examples
INFO csd.bu.edu ; request an INFO reply
csd.bu.
:Avalon INFO *.fi ; INFO request from Avalon for
server found to match *.fi
Oikarinen & Reed [Page 31]
RFC 1459 Internet Relay Chat Protocol May 1993
INFO Angel ; request info from the server
Angel is connected to
4.4 Sending
The main purpose of the IRC protocol is to provide a base for
to communicate with each other. PRIVMSG and NOTICE are the
messages available which actually perform delivery of a text
from one client to another - the rest just make it possible and
to ensure it happens in a reliable and structured manner
4.4.1 Private
Command:
Parameters: <receiver>{,<receiver>}
PRIVMSG is used to send private messages between users. <receiver
is the nickname of the receiver of the message. <receiver> can
be a list of names or channels separated with commas
The <receiver> parameter may also me a host mask (#mask) or
mask ($mask). In both cases the server will only send the
to those who have a server or host matching the mask. The mask
have at least 1 (one) "." in it and no wildcards following
last ".". This requirement exists to prevent people sending
to "#*" or "$*", which would broadcast to all users;
experience, this is abused more than used responsibly and properly
Wildcards are the '*' and '?' characters. This extension
the PRIVMSG command is only available to Operators
Numeric Replies
ERR_NORECIPIENT ERR_
ERR_CANNOTSENDTOCHAN ERR_
ERR_WILDTOPLEVEL ERR_
ERR_
RPL_
Examples
:Angel PRIVMSG Wiz :Hello are you receiving this message ?
; Message from Angel to Wiz
PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ;
Message to Angel
PRIVMSG jto@tolsun.oulu.fi :Hello !
; Message to a client on
Oikarinen & Reed [Page 32]
RFC 1459 Internet Relay Chat Protocol May 1993
tolsun.oulu.fi with username of "jto".
PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting
; Message to everyone on a server
has a name matching *.fi
PRIVMSG #*.edu :NSFNet is undergoing work, expect
; Message to all users who come from
host which has a name matching *.edu
4.4.2
Command:
Parameters: <nickname>
The NOTICE message is used similarly to PRIVMSG. The
between NOTICE and PRIVMSG is that automatic replies must never
sent in response to a NOTICE message. This rule applies to
too - they must not send any error reply back to the client
receipt of a notice. The object of this rule is to avoid
between a client automatically sending something in response
something it received. This is typically used by automatons (
with either an AI or other interactive program controlling
actions) which are always seen to be replying lest they end up in
loop with another automaton
See PRIVMSG for more details on replies and examples
4.5 User based
User queries are a group of commands which are primarily
with finding details on a particular user or group users. When
wildcards with any of these commands, if they match, they will
return information on users who are 'visible' to you. The
of a user is determined as a combination of the user's mode and
common set of channels you are both on
4.5.1 Who
Command:
Parameters: [ []]
The WHO message is used by a client to generate a query which
a list of information which 'matches' the parameter given
the client. In the absence of the parameter, all
(users who aren't invisible (user mode +i) and who don't have
common channel with the requesting client) are listed. The
result can be achieved by using a of "0" or any wildcard
Oikarinen & Reed [Page 33]
RFC 1459 Internet Relay Chat Protocol May 1993
will end up matching every entry possible
The passed to WHO is matched against users' host, server,
name and nickname if the channel cannot be found
If the "o" parameter is passed only operators are returned
to the name mask supplied
Numeric Replies
ERR_
RPL_WHOREPLY RPL_
Examples
WHO *.fi ; List all users who match
"*.fi".
WHO jto* o ; List all users with a match
"jto*" if they are an operator
4.5.2 Whois
Command:
Parameters: [] [,[,...]]
This message is used to query information about particular user.
server will answer this message with several numeric
indicating different statuses of each user which matches the
(if you are entitled to see them). If no wildcard is present in
, any information about that nick which you are allowed
see is presented. A comma (',') separated list of nicknames may
given
The latter version sends the query to a specific server. It
useful if you want to know how long the user in question has
idle as only local server (ie. the server the user is
connected to) knows that information, while everything else
globally known
Numeric Replies
ERR_NOSUCHSERVER ERR_
RPL_WHOISUSER RPL_
RPL_WHOISCHANNELS RPL_
RPL_AWAY RPL_
RPL_WHOISIDLE ERR_
RPL_
Oikarinen & Reed [Page 34]
RFC 1459 Internet Relay Chat Protocol May 1993
Examples
WHOIS wiz ; return available user
about nick
WHOIS eff.org trillian ; ask server eff.org for
information about
4.5.3
Command:
Parameters: <nickname> [ []]
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
history, looking for any nicks which are lexically the same (no
card matching here). The history is searched backward, returning
most recent entry first. If there are multiple entries, up
replies will be returned (or all of them if no
parameter is given). If a non-positive number is passed as
, then a full search is done
Numeric Replies
ERR_NONICKNAMEGIVEN ERR_
RPL_WHOWASUSER RPL_
RPL_
Examples
WHOWAS Wiz ; return all information in the
history about nick "WiZ";
WHOWAS Mermaid 9 ; return at most, the 9 most
entries in the nick history
"Mermaid";
WHOWAS Trillian 1 *.edu ; return the most recent history
"Trillian" from the first server
to match "*.edu".
4.6 Miscellaneous
Messages in this category do not fit into any of the above
but are nonetheless still a part of and required by the protocol
Oikarinen & Reed [Page 35]
RFC 1459 Internet Relay Chat Protocol May 1993
4.6.1 Kill
Command:
Parameters: <nickname>
The KILL message is used to cause a client-server connection to
closed by the server which has the actual connection. KILL is
by servers when they encounter a duplicate entry in the list of
nicknames and is used to remove both entries. It is also
to operators
Clients which have automatic reconnect algorithms effectively
this command useless since the disconnection is only brief. It
however break the flow of data and can be used to stop large
of being abused, any user may elect to receive KILL
generated for others to keep an 'eye' on would be trouble spots
In an arena where nicknames are required to be globally unique at
times, KILL messages are sent whenever 'duplicates' are
(that is an attempt to register two users with the same nickname)
the hope that both of them will disappear and only 1 reappear
The comment given must reflect the actual reason for the KILL.
server-generated KILLs it usually is made up of details
the origins of the two conflicting nicknames. For users it is
up to them to provide an adequate reason to satisfy others who
it. To prevent/discourage fake KILLs from being generated to
the identify of the KILLer, the comment also shows a 'kill-path
which is updated by each server it passes through, each
its name to the path
Numeric Replies
ERR_NOPRIVILEGES ERR_
ERR_NOSUCHNICK ERR_
KILL David (csd.bu.edu <- tolsun.oulu.fi
; Nickname collision between csd.bu.
and tolson.oulu.
NOTE
It is recommended that only Operators be allowed to kill other
with KILL message. In an ideal world not even operators would
to do this and it would be left to servers to deal with
Oikarinen & Reed [Page 36]
RFC 1459 Internet Relay Chat Protocol May 1993
4.6.2 Ping
Command:
Parameters: []
The PING message is used to test the presence of an active client
the other end of the connection. A PING message is sent at
intervals if no other activi