As per Relevance of the word parameter, we have this rfc below:
Network Working Group C.
Request for Comments: 2812 April 2000
Updates: 1459
Category:
Internet Relay Chat: Client
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
IESG NOTE
The IRC protocol itself enables several possibilities of
data between clients, and just like with other transfer
like email, the receiver of the data has to be careful about how
data is handled. For more information on security issues with the
protocol, see for example http://www.irchelp.org/irchelp/security/.
The IRC (Internet Relay Chat) protocol is for use with text
conferencing; the simplest client being any socket program capable
connecting to the server
This document defines the Client Protocol, and assumes that
reader is familiar with the IRC Architecture [IRC-ARCH].
Table of
1. Labels ..................................................... 3
1.1 Servers ................................................ 3
1.2 Clients ................................................ 3
1.2.1 Users ............................................. 4
1.2.1.1 Operators .................................... 4
1.2.2 Services .......................................... 4
1.3 Channels ............................................... 4
2. The IRC Client Specification ............................... 5
2.1 Overview ............................................... 5
2.2 Character codes ........................................ 5
2.3 Messages ............................................... 5
Kalt Informational [Page 1]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
2.3.1 Message format in Augmented BNF ................... 6
2.4 Numeric replies ........................................ 8
2.5 Wildcard expressions ................................... 9
3. Message Details ............................................ 9
3.1 Connection Registration ................................ 10
3.1.1 Password message .................................. 10
3.1.2 Nick message ...................................... 10
3.1.3 User message ...................................... 11
3.1.4 Oper message ...................................... 12
3.1.5 User mode message ................................. 12
3.1.6 Service message ................................... 13
3.1.7 Quit .............................................. 14
3.1.8 Squit ............................................. 15
3.2 Channel operations ..................................... 15
3.2.1 Join message ...................................... 16
3.2.2 Part message ...................................... 17
3.2.3 Channel mode message .............................. 18
3.2.4 Topic message ..................................... 19
3.2.5 Names message ..................................... 20
3.2.6 List message ...................................... 21
3.2.7 Invite message .................................... 21
3.2.8 Kick command ...................................... 22
3.3 Sending messages ....................................... 23
3.3.1 Private messages .................................. 23
3.3.2 Notice ............................................ 24
3.4 Server queries and commands ............................ 25
3.4.1 Motd message ...................................... 25
3.4.2 Lusers message .................................... 25
3.4.3 Version message ................................... 26
3.4.4 Stats message ..................................... 26
3.4.5 Links message ..................................... 27
3.4.6 Time message ...................................... 28
3.4.7 Connect message ................................... 28
3.4.8 Trace message ..................................... 29
3.4.9 Admin command ..................................... 30
3.4.10 Info command ...................................... 31
3.5 Service Query and Commands ............................. 31
3.5.1 Servlist message .................................. 31
3.5.2 Squery ............................................ 32
3.6 User based queries ..................................... 32
3.6.1 Who query ......................................... 32
3.6.2 Whois query ....................................... 33
3.6.3 Whowas ............................................ 34
3.7 Miscellaneous messages ................................. 34
3.7.1 Kill message ...................................... 35
3.7.2 Ping message ...................................... 36
3.7.3 Pong message ...................................... 37
3.7.4 Error ............................................. 37
Kalt Informational [Page 2]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
4. Optional features .......................................... 38
4.1 Away ................................................... 38
4.2 Rehash message ......................................... 39
4.3 Die message ............................................ 39
4.4 Restart message ........................................ 40
4.5 Summon message ......................................... 40
4.6 Users .................................................. 41
4.7 Operwall message ....................................... 41
4.8 Userhost message ....................................... 42
4.9 Ison message ........................................... 42
5. Replies .................................................... 43
5.1 Command responses ...................................... 43
5.2 Error Replies .......................................... 53
5.3 Reserved numerics ...................................... 59
6. Current implementations .................................... 60
7. Current problems ........................................... 60
7.1 Nicknames .............................................. 60
7.2 Limitation of wildcards ................................ 61
7.3 Security considerations ................................ 61
8. Current support and availability ........................... 61
9. Acknowledgements ........................................... 61
10. References ................................................ 62
11. Author's Address .......................................... 62
12. Full Copyright Statement .................................. 63
1.
This section defines the identifiers used for the various
of the IRC protocol
1.1
Servers are uniquely identified by their name, which has a
length of sixty three (63) characters. See the protocol
rules (section 2.3.1) for what may and may not be used in a
name
1.2
For each client all servers MUST have the following information:
netwide unique identifier (whose format depends on the type
client) and the server which introduced the client
Kalt Informational [Page 3]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
1.2.1
Each user is distinguished from other users by a unique
having a maximum length of nine (9) characters. See the
grammar rules (section 2.3.1) for what may and may not be used in
nickname
While the maximum length is limited to nine characters,
SHOULD accept longer strings as they may become used in
evolutions of the protocol
1.2.1.1
To allow a reasonable amount of order to be kept within the
network, a special class of users (operators) is allowed to
general maintenance functions on the network. Although the
granted to an operator can be considered as 'dangerous', they
nonetheless often necessary. Operators SHOULD be able to
basic network tasks such as disconnecting and reconnecting servers
needed. In recognition of this need, the protocol discussed
provides for operators only to be able to perform such functions
See sections 3.1.8 (SQUIT) and 3.4.7 (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 very delicate since its abuse is
destructive and annoying, and its benefits close to inexistent.
further details on this type of action, see section 3.7.1 (KILL).
1.2.2
Each service is distinguished from other services by a service
composed of a nickname and a server name. As for users, the
has a maximum length of nine (9) characters. See the
grammar rules (section 2.3.1) for what may and may not be used in
nickname
1.3
Channels names are strings (beginning with a '&', '#', '+' or '!'
character) of length up to fifty (50) characters. Apart from
requirement that the first character is either '&', '#', '+' or '!',
the only restriction on a channel name is that it SHALL NOT
any spaces (' '), a control G (^G or ASCII 7), a comma (',').
is used as parameter separator and command is used as a list
separator by the protocol). A colon (':') can also be used as
delimiter for the channel mask. Channel names are case insensitive
Kalt Informational [Page 4]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
See the protocol grammar rules (section 2.3.1) for the exact
of a channel name
Each prefix characterizes a different channel type. The
of the channel types is not relevant to the client-server
and thus it is beyond the scope of this document. More details
be found in "Internet Relay Chat: Channel Management" [IRC-CHAN].
2. The IRC Client
2.1
The protocol as described herein is for use only with client
server connections when the client registers as a user
2.2 Character
No specific character set is specified. The protocol is based on
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 US-ASCII terminal and
telnet connection
Because of IRC's Scandinavian 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 or channel names
2.3
Servers and clients send each other 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 by nature
Each IRC message may consist of up to three main parts: the
(OPTIONAL), the command, and the command parameters (maximum
fifteen (15)). The prefix, command, and all parameters are
by one ASCII space character (0x20) each
Kalt Informational [Page 5]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
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
origin of the message. If the prefix is missing from the message,
is assumed to have originated from the connection from which it
received from. Clients SHOULD NOT use a prefix when sending
message; if they use one, the only valid prefix is the
nickname associated with the client
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 of message lines. See section 6 for more details
current implementations
2.3.1 Message format in Augmented
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 messages
extra problems
The extracted message is parsed into the components ,
and list of parameters ().
The Augmented BNF representation for this is
message = [ ":" prefix SPACE ] command [ params ]
prefix = servername / ( nickname [ [ "!" user ] "@" host ] )
command = 1*letter / 3
params = *14( SPACE middle ) [ SPACE ":" trailing ]
=/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]
nospcrlfcl = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-
; any octet except NUL, CR, LF, " " and ":"
middle = nospcrlfcl *( ":" / nospcrlfcl )
trailing = *( ":" / " " / nospcrlfcl )
SPACE = %x20 ; space
crlf = %x0D %x0A ; "carriage return" "linefeed
Kalt Informational [Page 6]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
NOTES
1) After extracting the parameter list, all parameters are
whether matched by or . is just
syntactic trick to allow SPACE within the parameter
2) The NUL (%x00) character is not special in message framing,
basically could end up inside a parameter, but it would
extra complexities in normal C string handling. Therefore,
is not allowed within messages
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
target = nickname /
msgtarget = msgto *( "," msgto )
msgto = channel / ( user [ "%" host ] "@" servername )
msgto =/ ( user "%" host ) /
msgto =/ nickname / ( nickname "!" user "@" host )
channel = ( "#" / "+" / ( "!" channelid ) / "&" )
[ ":" chanstring ]
servername =
host = hostname /
hostname = shortname *( "." shortname )
shortname = ( letter / digit ) *( letter / digit / "-" )
*( letter / digit )
; as specified in RFC 1123 [HNAME
hostaddr = ip4addr / ip6
ip4addr = 1*3digit "." 1*3digit "." 1*3digit "." 1*3
ip6addr = 1*hexdigit 7( ":" 1*hexdigit )
ip6addr =/ "0:0:0:0:0:" ( "0" / "FFFF" ) ":" ip4
nickname = ( letter / special ) *8( letter / digit / special / "-" )
targetmask = ( "$" / "#" )
; see details on allowed masks in section 3.3.1
chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2
chanstring =/ %x2D-39 / %x3B-
; any octet except NUL, BELL, CR, LF, " ", "," and ":"
channelid = 5( %x41-5A / digit ) ; 5( A-Z / 0-9 )
Kalt Informational [Page 7]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
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-
digit = %x30-39 ; 0-9
hexdigit = digit / "A" / "B" / "C" / "D" / "E" / "F
special = %x5B-60 / %x7B-7
; "[", "]", "\", "`", "_", "^", "{", "|", "}"
NOTES
1) The syntax is given here for the sole purpose
indicating the format to follow for IP addresses.
reflects the fact that the only available implementations
this protocol uses TCP/IP as underlying network protocol but
not meant to prevent other protocols to be used
2) <hostname> has a maximum length of 63 characters. This is
limitation of the protocol as internet hostnames (
particular) can be longer. Such restriction is
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)
instead of the host name
3) Some parameters used in the following sections of
documents are not defined here as there is nothing
about them besides the name that is used for convenience
These parameters follow the general syntax defined
.
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. In all other respects, a numeric reply is just like
normal message, except that the keyword is made up of 3
digits rather than a string of letters. A list of different
is supplied in section 5 (Replies).
Kalt Informational [Page 8]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
2.5 Wildcard
When wildcards are allowed in a string, it is referred as a "mask".
For string matching purposes, the protocol allows the use of
special characters: '?' (%x3F) to match one and only one character
and '*' (%x2A) to match any number of any characters. These
characters can be escaped using the character '\' (%x5C).
The Augmented BNF syntax for this is
mask = *( nowild / noesc wildone / noesc wildmany )
wildone = %x3
wildmany = %x2
nowild = %x01-29 / %x2B-3E / %x40-
; any octet except NUL, "*", "?"
noesc = %x01-5B / %x5D-
; any octet except NUL and "\"
matchone = %x01-
; matches
matchmany = *
; matches
Examples
a?c ; Matches any string of 3 characters in length
with "a" and ending with "c
a*c ; Matches any string of at least 2 characters in
starting with "a" and ending with "c
3. Message
On the following pages there are descriptions of each
recognized by the IRC server and client. All commands described
this section MUST be implemented by any server for this protocol
Where the reply ERR_NOSUCHSERVER is returned, it means that
target of the message could not be found. The server MUST NOT
any other replies after this error for that command
The server to which a client is connected is required to parse
complete message, and return any appropriate errors
If multiple parameters is presented, then each MUST be checked
validity and appropriate responses MUST be sent back to the client
In the case of incorrect messages which use parameter lists
comma as an item separator, a reply MUST be sent for each item
Kalt Informational [Page 9]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
3.1 Connection
The commands described here are used to register a connection with
IRC server as a user as well as to correctly disconnect
A "PASS" command is not required for a client connection to
registered, but it MUST precede the latter of the NICK/
combination (for a user connection) or the SERVICE command (for
service connection). The RECOMMENDED order for a client to
is as follows
1. Pass
2. Nick message 2. Service
3. User
Upon success, the client will receive an RPL_WELCOME (for users)
RPL_YOURESERVICE (for services) message indicating that
connection is now registered and known the to the entire IRC network
The reply message MUST contain the full client identifier upon
it was registered
3.1.1 Password
Command:
Parameters: <password
The PASS command is used to set a 'connection password'.
optional password can and MUST be set before any attempt to
the connection is made. Currently this requires that user send
PASS command before sending the NICK/USER combination
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
Example
PASS
3.1.2 Nick
Command:
Parameters: <nickname
NICK command is used to give user a nickname or change the
one
Kalt Informational [Page 10]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
Numeric Replies
ERR_NONICKNAMEGIVEN ERR_
ERR_NICKNAMEINUSE ERR_
ERR_UNAVAILRESOURCE ERR_
Examples
NICK Wiz ; Introducing new nick "Wiz" if session
still unregistered, or user changing
nickname to "Wiz
:WiZ!jto@tolsun.oulu.fi NICK
; Server telling that WiZ changed
nickname to Kilroy
3.1.3 User
Command:
Parameters:
The USER command is used at the beginning of connection to
the username, hostname and realname of a new user
The parameter should be a numeric, and can be used
automatically set user modes when registering with the server.
parameter is a bitmask, with only 2 bits having any signification:
the bit 2 is set, the user mode 'w' will be set and if the bit 3
set, the user mode 'i' will be set. (See Section 3.1.5 "
Modes").
The may contain space characters
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
Example
USER guest 0 * :Ronnie Reagan ; User registering themselves with
username of "guest" and real
"Ronnie Reagan".
USER guest 8 * :Ronnie Reagan ; User registering themselves with
username of "guest" and real
"Ronnie Reagan", and asking to be
invisible
Kalt Informational [Page 11]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
3.1.4 Oper
Command:
Parameters: <password
A normal user uses the OPER command to obtain operator privileges
The combination of and <password> are REQUIRED to
Operator privileges. Upon success, the user will receive a
message (see section 3.1.5) indicating the new user modes
Numeric Replies
ERR_NEEDMOREPARAMS RPL_
ERR_NOOPERHOST ERR_
Example
OPER foo bar ; Attempt to register as an
using a username of "foo" and "bar
as the password
3.1.5 User mode
Command:
Parameters: <nickname
*( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) )
The user MODE's are typically changes which affect either how
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
message and the nickname given as a parameter are both the same.
no other parameter is given, then the server will return the
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
Kalt Informational [Page 12]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
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"
"+O" flag, the attempt SHOULD be ignored as users could bypass
authentication mechanisms of the OPER command. There is
restriction, however, on anyone `deopping' themselves (using "-o"
"-O").
On the other hand, if a user attempts to make themselves
using the "-r" flag, the attempt SHOULD be ignored. There is
restriction, however, on anyone `deopping' themselves (using "+r").
This flag is typically set by the server upon connection
administrative reasons. While the restrictions imposed are left
to the implementation, it is typical that a restricted user not
allowed to change nicknames, nor make use of the channel
status on channels
The flag 's' is obsolete but MAY still be used
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
ERR_UMODEUNKNOWNFLAG RPL_
Examples
MODE WiZ -w ; Command by WiZ to turn
reception of WALLOPS messages
MODE Angel +i ; Command from Angel to make
invisible
MODE WiZ -o ; WiZ 'deopping' (removing
status).
3.1.6 Service
Command:
Parameters: <nickname> <reserved> <distribution>
<reserved>
The SERVICE command to register a new service. Command
specify the service nickname, distribution, type and info of a
service
Kalt Informational [Page 13]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
The <distribution> parameter is used to specify the visibility of
service. The service may only be known to servers which have a
matching the distribution. For a matching server to have
of the service, the network path between that server and the
on which the service is connected MUST be composed of servers
names all match the mask
The parameter is currently reserved for future usage
Numeric Replies
ERR_ALREADYREGISTRED ERR_
ERR_
RPL_YOURESERVICE RPL_
RPL_
Example
SERVICE dict * *.fr 0 0 :French Dictionary ; Service
itself with a name of "dict".
service will only be available
servers which name matches "*.fr".
3.1.7
Command:
Parameters: [ ]
A client session is terminated with a quit message. The
acknowledges this by sending an ERROR message to the client
Numeric Replies
None
Example
QUIT :Gone to have lunch ; Preferred message format
:syrk!kalt@millennium.stealth.net QUIT :Gone to have lunch ;
syrk has quit IRC to have lunch
Kalt Informational [Page 14]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
3.1.8
Command:
Parameters:
The SQUIT command is available only to operators. It is used
disconnect server links. Also servers can generate SQUIT messages
error conditions. A SQUIT message may also target a remote
connection. In this case, the SQUIT message will simply be sent
the remote server without affecting the servers in between
operator and the remote server
The SHOULD be supplied by all operators who execute a
for a remote server. The server ordered to disconnect its
generates a WALLOPS message with included, so that
users may be aware of the reason of this action
Numeric replies
ERR_NOPRIVILEGES ERR_
ERR_
Examples
SQUIT tolsun.oulu.fi :Bad Link ? ; Command to uplink of the
tolson.oulu.fi to terminate
connection with comment "Bad Link".
:Trillian SQUIT cm22.eng.umd.edu :Server out of control ;
from Trillian from to
"cm22.eng.umd.edu" from the net
comment "Server out of control".
3.2 Channel
This group of messages is concerned with manipulating channels,
properties (channel modes), and their contents (typically users).
For this reason, these messages SHALL NOT be made available
services
All of these messages are requests which will or will not be
by the server. The server MUST send a reply informing the
whether the request was granted, denied or generated an error.
the server grants the request, the message is typically sent
(eventually reformatted) to the user with the prefix set to the
itself
Kalt Informational [Page 15]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
The rules governing how channels are managed are enforced by
servers. These rules are beyond the scope of this document.
details are found in "Internet Relay Chat: Channel Management" [IRC
CHAN].
3.2.1 Join
Command:
Parameters: ( *( "," ) [ *( "," ) ] )
/ "0"
The JOIN command is used by a user to request to start listening
the specific channel. Servers MUST be able to parse arguments in
form of a list of target, but SHOULD NOT use lists when sending
messages to clients
Once a user has joined a channel, he receives information
all commands his server receives affecting the channel.
includes JOIN, MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE
This allows channel members to keep track of the other
members, as well as channel modes
If a JOIN is successful, the user receives a JOIN message
confirmation and is then sent the channel's topic (using RPL_TOPIC)
the list of users who are on the channel (using RPL_NAMREPLY),
MUST include the user joining
Note that this message accepts a special argument ("0"), which
a special request to leave all channels the user is currently a
of. The server will process this message as if the user had
a PART command (See Section 3.2.2) for each channel he is a
of
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
ERR_INVITEONLYCHAN ERR_
ERR_CHANNELISFULL ERR_
ERR_NOSUCHCHANNEL ERR_
ERR_TOOMANYTARGETS ERR_
RPL_
Examples
JOIN #foobar ; Command to join channel #foobar
JOIN &foo fubar ; Command to join channel &foo
key "fubar".
Kalt Informational [Page 16]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
JOIN #foo,&bar fubar ; Command to join channel #foo
key "fubar" and &bar using no key
JOIN #foo,#bar fubar,foobar ; Command to join channel #foo
key "fubar", and channel #bar
key "foobar".
JOIN #foo,#bar ; Command to join channels #foo
#bar
JOIN 0 ; Leave all currently
channels
:WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone ; JOIN message from
on channel #Twilight_
3.2.2 Part
Command:
Parameters: *( "," ) [ ]
The PART command causes the user sending the message to be
from the list of active members for all given channels listed in
parameter string. If a "Part Message" is given, this will be
instead of the default message, the nickname. This request is
granted by the server
Servers MUST be able to parse arguments in the form of a list
target, but SHOULD NOT use lists when sending PART messages
clients
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
ERR_
Examples
PART #twilight_zone ; Command to leave
"#twilight_zone
PART #oz-ops,&group5 ; Command to leave both
"&group5" and "#oz-ops".
:WiZ!jto@tolsun.oulu.fi PART #playzone :I
; User WiZ leaving
"#playzone" with the message "
lost".
Kalt Informational [Page 17]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
3.2.3 Channel mode
Command:
Parameters: *( ( "-" / "+" ) * * )
The MODE command is provided so that users may query and change
characteristics of a channel. For more details on available
and their uses, see "Internet Relay Chat: Channel Management" [IRC
CHAN]. Note that there is a maximum limit of three (3) changes
command for modes that take a parameter
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
ERR_NOCHANMODES ERR_
ERR_USERNOTINCHANNEL ERR_
RPL_
RPL_BANLIST RPL_
RPL_EXCEPTLIST RPL_
RPL_INVITELIST RPL_
RPL_
The following examples are given to help understanding the syntax
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
moderated and 'invite-only' with
with a hostname matching *.
automatically invited
MODE #Finnish +o Kilroy ; Command to give 'chanop'
to Kilroy on channel #Finnish
MODE #Finnish +v Wiz ; Command to allow WiZ to speak
#Finnish
MODE #Fins -s ; Command to remove 'secret'
from channel #Fins
MODE #42 +k oulu ; Command to set the channel key
"oulu".
MODE #42 -k oulu ; Command to remove the "oulu
channel key on channel "#42".
Kalt Informational [Page 18]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
MODE #eu-opers +l 10 ; Command to set the limit for
number of users on
"#eu-opers" to 10.
:WiZ!jto@tolsun.oulu.fi MODE #eu-opers -
; User "WiZ" removing the limit
the number of users on channel "#eu
opers".
MODE &oulu +b ; Command to list ban masks set
the channel "&oulu".
MODE &oulu +b *!*@* ; Command to prevent all users
joining
MODE &oulu +b *!*@*.edu +e *!*@*.bu.
; Command to prevent any user from
hostname matching *.edu from joining
except if matching *.bu.
MODE #bu +be *!*@*.edu *!*@*.bu.
; Comment to prevent any user from
hostname matching *.edu from joining
except if matching *.bu.
MODE #meditation e ; Command to list exception masks
for the channel "#meditation".
MODE #meditation I ; Command to list invitations
set for the channel "#meditation".
MODE !12345ircd O ; Command to ask who the
creator for "!12345ircd"
3.2.4 Topic
Command:
Parameters: [ ]
The TOPIC command 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 this action is allowed for the
requesting it. If the parameter is an empty string,
topic for that channel will be removed
Kalt Informational [Page 19]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
RPL_NOTOPIC RPL_
ERR_CHANOPRIVSNEEDED ERR_
Examples
:WiZ!jto@tolsun.oulu.fi TOPIC #test :New topic ; User Wiz setting
topic
TOPIC #test :another topic ; Command to set the topic on #
to "another topic".
TOPIC #test : ; Command to clear the topic
#test
TOPIC #test ; Command to check the topic
#test
3.2.5 Names
Command:
Parameters: [ *( "," ) [ ] ]
By using the NAMES command, a user can list all nicknames that
visible to him. For more details on what is visible and what is not
see "Internet Relay Chat: Channel Management" [IRC-CHAN].
parameter specifies which channel(s) to return
about. 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' "*".
If the parameter is specified, the request is forwarded
that server which will generate the reply
Wildcards are allowed in the parameter
Numerics
ERR_TOOMANYMATCHES ERR_
RPL_NAMREPLY RPL_
Kalt Informational [Page 20]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
Examples
NAMES #twilight_zone,#42 ; Command to list visible users
#twilight_zone and #42
NAMES ; Command to list all
channels and
3.2.6 List
Command:
Parameters: [ *( "," ) [ ] ]
The list command is used to list channels and their topics. If
parameter is used, only the status of that channel
displayed
If the parameter is specified, the request is forwarded
that server which will generate the reply
Wildcards are allowed in the parameter
Numeric Replies
ERR_TOOMANYMATCHES ERR_
RPL_LIST RPL_
Examples
LIST ; Command to list all channels
LIST #twilight_zone,#42 ; Command to list
#twilight_zone and #42
3.2.7 Invite
Command:
Parameters: <nickname>
The INVITE command is used to invite a user 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. However, if the channel exists, only members of the
are allowed to invite other users. When the channel has invite-
flag set, only channel operators may issue INVITE command
Kalt Informational [Page 21]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
Only the user inviting and the user being invited will
notification of the invitation. Other channel members are
notified. (This is unlike the MODE changes, and is occasionally
source of trouble for users.)
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
ERR_NOTONCHANNEL ERR_
ERR_
RPL_INVITING RPL_
Examples
:Angel!wings@irc.org INVITE Wiz #
; Message to WiZ when he has
invited by user Angel to
#
INVITE Wiz #Twilight_Zone ; Command to invite WiZ
#Twilight_
3.2.8 Kick
Command:
Parameters: *( "," ) *( "," )
[]
The KICK command can be used to request the forced removal of a
from a channel. It causes the to PART from the
force. For the message to be syntactically correct, there MUST
either one channel parameter and multiple user parameter, or as
channel parameters as there are user parameters. If a "comment"
given, this will be sent instead of the default message, the
of the user issuing the KICK
The server MUST NOT send KICK messages with multiple channels
users to clients. This is necessarily to maintain
compatibility with old client software
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
ERR_BADCHANMASK ERR_
ERR_USERNOTINCHANNEL ERR_
Kalt Informational [Page 22]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
Examples
KICK &Melbourne Matthew ; Command to kick Matthew
&
KICK #Finnish John :Speaking
; Command to kick John from #
using "Speaking English" as
reason (comment).
:WiZ!jto@tolsun.oulu.fi KICK #Finnish
; KICK message on channel #
from WiZ to remove John from
3.3 Sending
The main purpose of the IRC protocol is to provide a base for
to communicate with each other. PRIVMSG, NOTICE and
(described in Section 3.5 on Service Query and Commands) 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
3.3.1 Private
Command:
Parameters:
PRIVMSG is used to send private messages between users, as well as
send messages to channels. is usually the nickname
the recipient of the message, or a channel name
The parameter may also be a host mask (#) or
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 the
".". This requirement exists to prevent people sending messages
"#*" or "$*", which would broadcast to all users. Wildcards are
'*' and '?' characters. This extension to the PRIVMSG command
only available to operators
Numeric Replies
ERR_NORECIPIENT ERR_
ERR_CANNOTSENDTOCHAN ERR_
ERR_WILDTOPLEVEL ERR_
ERR_
RPL_
Kalt Informational [Page 23]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
Examples
:Angel!wings@irc.org 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 jto@tolsun.oulu.fi :Hello !
; Command to send a message to a
on server tolsun.oulu.fi
username of "jto".
PRIVMSG kalt%millennium.stealth.net@irc.stealth.net :Are you a frog
; Message to a user on
irc.stealth.net with username
"kalt", and connected from the
millennium.stealth.net
PRIVMSG kalt%millennium.stealth.net :Do you like cheese
; Message to a user on the
server with username of "kalt",
connected from the
millennium.stealth.net
PRIVMSG Wiz!jto@tolsun.oulu.fi :Hello !
; Message to the user with
Wiz who is connected from the
tolsun.oulu.fi and has the
"jto".
PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting
; Message to everyone on a
which has a name matching *.fi
PRIVMSG #*.edu :NSFNet is undergoing work, expect
; Message to all users who come
a host which has a name
*.edu
3.3.2
Command:
Parameters:
The NOTICE command 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
Kalt Informational [Page 24]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
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 clients automatically sending something in response
something it received
This command is available to services as well as users
This is typically used by services, and automatons (clients
either an AI or other interactive program controlling their actions).
See PRIVMSG for more details on replies and examples
3.4 Server queries and
The server query group of commands has been designed to
information about any server which is connected to the network
In these queries, where a parameter appears as ,
masks are usually valid. For each parameter, however, only one
and set of replies is to be generated. In most cases, if a
is given, it will mean the server to which the user is connected
These messages typically have little value for services, it
therefore RECOMMENDED to forbid services from using them
3.4.1 Motd
Command:
Parameters: [ ]
The MOTD command is used to get the "Message Of The Day" of the
server, or current server if is omitted
Wildcards are allowed in the parameter
Numeric Replies
RPL_MOTDSTART RPL_
RPL_ENDOFMOTD ERR_
3.4.2 Lusers
Command:
Parameters: [ [ ] ]
The LUSERS command is used to get statistics about the size of
IRC network. If no parameter is given, the reply will be about
whole net. If a is specified, then the reply will
Kalt Informational [Page 25]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
concern the part of the network formed by the servers matching
mask. Finally, if the parameter is specified, the
is forwarded to that server which will generate the reply
Wildcards are allowed in the parameter
Numeric Replies
RPL_LUSERCLIENT RPL_
RPL_LUSERUNKOWN RPL_
RPL_LUSERME ERR_
3.4.3 Version
Command:
Parameters: [ ]
The VERSION command 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
Wildcards are allowed in the parameter
Numeric Replies
ERR_NOSUCHSERVER RPL_
Examples
VERSION tolsun.oulu.fi ; Command to check the version
server "tolsun.oulu.fi".
3.4.4 Stats
Command:
Parameters: [ [ ] ]
The stats command is used to query statistics of certain server.
parameter is omitted, only the end of stats reply is
back
A query may be given for any single letter which is only checked
the destination server and is otherwise passed on by
servers, ignored and unaltered
Wildcards are allowed in the parameter
Kalt Informational [Page 26]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
Except for the ones below, the list of valid queries
implementation dependent. The standard queries below SHOULD
supported by the server
l - returns a list of the server's connections, showing
long each connection has been established and
traffic over that connection in Kbytes and messages
each direction
m - returns the usage count for each of commands
by the server; commands for which the usage count
zero MAY be omitted
o - returns a list of configured privileged users
operators
u - returns a string showing how long the server has
up
It is also RECOMMENDED that client and server access configuration
published this way
Numeric Replies
ERR_
RPL_STATSLINKINFO RPL_
RPL_STATSCOMMANDS RPL_
RPL_
Examples
STATS m ; Command to check the command
for the server you are connected
3.4.5 Links
Command:
Parameters: [ [ ] ]
With LINKS, a user can list all servernames, which are known by
server answering the query. The returned list of servers MUST
the 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_
Kalt Informational [Page 27]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
Examples
LINKS *.au ; Command to list all servers
have a name that matches *.au
LINKS *.edu *.bu.edu ; Command to list servers
*.bu.edu as seen by the first
matching *.edu
3.4.6 Time
Command:
Parameters: [ ]
The time command is used to query local time from the
server. If the parameter is not given, the server
the command must reply to the query
Wildcards are allowed in the parameter
Numeric Replies
ERR_NOSUCHSERVER RPL_
Examples
TIME tolsun.oulu.fi ; check the time on the
"tolson.oulu.fi
3.4.7 Connect
Command:
Parameters: [ ]
The CONNECT command can be used to request a server to try
establish a new connection to another server immediately. CONNECT
a privileged command and SHOULD be available only to IRC Operators
If a is given and its mask doesn't match name of
parsing server, the CONNECT attempt is sent to the first match
remote server. Otherwise the CONNECT attempt is made by the
processing the request
The server receiving a remote CONNECT command SHOULD generate
WALLOPS message describing the source and target of the request
Numeric Replies
ERR_NOSUCHSERVER ERR_
ERR_
Kalt Informational [Page 28]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
Examples
CONNECT tolsun.oulu.fi 6667 ; Command to attempt to connect
server to tolsun.oulu.fi on port 6667
3.4.8 Trace
Command:
Parameters: [ ]
TRACE command is used to find the route to specific server
information about its peers. Each server that processes this
MUST report to the sender about it. The replies from pass-
links form a chain, which shows route to destination. After
this reply back, the query MUST be sent to the next server
given server is reached
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. After sending this reply back, it MUST then send
TRACE message to the next server until given server is reached.
the parameter is omitted, it is RECOMMENDED that
command sends a message to the sender telling which servers the
server has direct connection to
If the destination given by is an actual server,
destination server is REQUIRED to report all servers, services
operators which are connected to it; if the command was issued by
operator, the server MAY also report all users which are connected
it. If the destination given by is a nickname, then only
reply for that nickname is given. If the parameter
omitted, it is RECOMMENDED that the TRACE command is parsed
targeted to the processing server
Wildcards are allowed in the parameter
Numeric Replies
ERR_
If the TRACE message is destined for another server,
intermediate servers must return a RPL_TRACELINK reply to
that the TRACE passed through it and where it is going next
RPL_
Kalt Informational [Page 29]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
A TRACE reply may be composed of any number of the
numeric replies
RPL_TRACECONNECTING RPL_
RPL_TRACEUNKNOWN RPL_
RPL_TRACEUSER RPL_
RPL_TRACESERVICE RPL_
RPL_TRACECLASS RPL_
RPL_
Examples
TRACE *.oulu.fi ; TRACE to a server
*.oulu.
3.4.9 Admin
Command:
Parameters: [ ]
The admin command is used to find information about the
of the given server, or current server if parameter
omitted. Each server MUST have the ability to forward ADMIN
to other servers
Wildcards are allowed in the parameter
Numeric Replies
ERR_
RPL_ADMINME RPL_ADMINLOC
RPL_ADMINLOC2 RPL_
Examples
ADMIN tolsun.oulu.fi ; request an ADMIN reply
tolsun.oulu.
ADMIN syrk ; ADMIN request for the server
which the user syrk is
Kalt Informational [Page 30]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
3.4.10 Info
Command:
Parameters: [ ]
The INFO command is REQUIRED to return information describing
server: its version, when it was compiled, the patchlevel, when
was started, and any other miscellaneous information which may
considered to be relevant
Wildcards are allowed in the parameter
Numeric Replies
ERR_
RPL_INFO RPL_
Examples
INFO csd.bu.edu ; request an INFO reply
csd.bu.
INFO Angel ; request info from the server
Angel is connected to
3.5 Service Query and
The service query group of commands has been designed to
information about any service which is connected to the network
3.5.1 Servlist
Command:
Parameters: [ [ ] ]
The SERVLIST command is used to list services currently connected
the network and visible to the user issuing the command.
optional parameters may be used to restrict the result of the
(to matching services names, and services type).
Numeric Replies
RPL_SERVLIST RPL_
Kalt Informational [Page 31]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
3.5.2
Command:
Parameters:
The SQUERY command is used similarly to PRIVMSG. The only
is that the recipient MUST be a service. This is the only way for
text message to be delivered to a service
See PRIVMSG for more details on replies and example
Examples
SQUERY irchelp :HELP
; Message to the service
nickname irchelp
SQUERY dict@irc.fr :fr2en
; Message to the service with
dict@irc.fr
3.6 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
Although services SHOULD NOT be using this class of message, they
allowed to
3.6.1 Who
Command:
Parameters: [ [ "o" ] ]
The WHO command 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
will end up matching every visible user
The passed to WHO is matched against users' host, server,
name and nickname if the channel cannot be found
Kalt Informational [Page 32]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
If the "o" parameter is passed only operators are returned
to the supplied
Numeric Replies
ERR_
RPL_WHOREPLY RPL_
Examples
WHO *.fi ; Command to list all users who
against "*.fi".
WHO jto* o ; Command to list all users with
match against "jto*" if they are
operator
3.6.2 Whois
Command:
Parameters: [ ] *( "," )
This command is used to query information about particular user
The server will answer this command with several numeric
indicating different statuses of each user which matches the mask (
you are entitled to see them). If no wildcard is present in
, any information about that nick which you are allowed to
is presented
If the parameter is specified, it sends the query to
specific server. It is useful if you want to know how long the
in question has been idle as only local server (i.e., the server
user is directly connected to) knows that information,
everything else is globally known
Wildcards are allowed in the parameter
Numeric Replies
ERR_NOSUCHSERVER ERR_
RPL_WHOISUSER RPL_
RPL_WHOISCHANNELS RPL_
RPL_AWAY RPL_
RPL_WHOISIDLE ERR_
RPL_
Kalt Informational [Page 33]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
Examples
WHOIS wiz ; return available user
about nick
WHOIS eff.org trillian ; ask server eff.org for
information about
3.6.3
Command:
Parameters: <nickname> *( "," <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
Wildcards are allowed in the parameter
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
found to match "*.edu".
3.7 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
Kalt Informational [Page 34]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
3.7.1 Kill
Command:
Parameters: <nickname>
The KILL command is used to cause a client-server connection to
closed by the server which has the actual connection.
generate KILL messages on nickname collisions. It MAY also
available available to users who have the operator status
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 'flooding' from abusive users or accidents. Abusive users
don't care as they will reconnect promptly and resume their
behaviour. To prevent this command from being abused, any user
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
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
When a client is removed as the result of a KILL message, the
SHOULD add the nickname to the list of unavailable nicknames in
attempt to avoid clients to reuse this name immediately which
usually the pattern of abusive behaviour often leading to
"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.
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_
Kalt Informational [Page 35]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
NOTE
It is RECOMMENDED that only Operators be allowed to kill other
with KILL command. This command has been the subject of
controversies over the years, and along with the
recommendation, it is also widely recognized that not even
should be allowed to kill users on remote servers
3.7.2 Ping
Command:
Parameters: [ ]
The PING command is used to test the presence of an active client
server at the other end of the connection. Servers send a
message at regular intervals if no other activity detected
from a connection. If a connection fails to respond to a
message within a set amount of time, that connection is closed.
PING message MAY be sent even if the connection is active
When a PING message is received, the appropriate PONG message MUST
sent as reply to (server which sent the PING message out
as soon as possible. If the parameter is specified,
represents the target of the ping, and the message gets
there
Numeric Replies
ERR_NOORIGIN ERR_
Examples
PING tolsun.oulu.fi ; Command to send a PING message
PING WiZ tolsun.oulu.fi ; Command from WiZ to send a
message to server "tolsun.oulu.fi
PING :irc.funet.fi ; Ping message sent by
"irc.funet.fi
Kalt Informational [Page 36]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
3.7.3 Pong
Command:
Parameters: [ ]
PONG message is a reply to ping message. If parameter
given, this message MUST be forwarded to given target. The
parameter is the name of the entity who has responded to PING
and generated this message
Numeric Replies
ERR_NOORIGIN ERR_
Example
PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu
tolsun.oulu.
3.7.4
Command:
Parameters:
The ERROR command is for use by servers when reporting a serious
fatal error to its peers. It may also be sent from one server
another but MUST NOT be accepted from any normal unknown clients
Only an ERROR message SHOULD be used for reporting errors which
with a server-to-server link. An ERROR message is sent to the
at the other end (which reports it to appropriate local users
logs) and to appropriate local users and logs. It is not to
passed onto any other servers by a server if it is received from
server
The ERROR message is also used before terminating a
connection
When a server sends a received ERROR message to its operators,
message SHOULD be encapsulated inside a NOTICE message,
that the client was not responsible for the error
Numerics
None
Kalt Informational [Page 37]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
Examples
ERROR :Server *.fi already exists ; ERROR message to the other
which caused this error
NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already
; Same ERROR message as above
sent to user WiZ on the other server
4. Optional
This section describes OPTIONAL messages. They are not required in
working server implementation of the protocol described herein.
the absence of the feature, an error reply message MUST be
or an unknown command error. If the message is destined for
server to answer then it MUST be passed on (elementary
REQUIRED) The allocated numerics for this are listed with
messages below
From this section, only the USERHOST and ISON messages are
to services
4.1
Command:
Parameters: [ ]
With the AWAY command, clients can set an automatic reply string
any PRIVMSG commands directed at them (not to a channel they are on).
The server sends an automatic reply to the client sending the
command. The only replying server is the one to which the
client is connected to
The AWAY command is used either with one parameter, to set an
message, or with no parameters, to remove the AWAY message
Because of its high cost (memory and bandwidth wise), the
message SHOULD only be used for client-server communication.
server MAY choose to silently ignore AWAY messages received
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_
Kalt Informational [Page 38]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
Example
AWAY :Gone to lunch. Back in 5 ; Command to set away message
"Gone to lunch. Back in 5".
4.2 Rehash
Command:
Parameters:
The rehash command is an administrative command which can be used
an operator to force the server to re-read and process
configuration file
Numeric Replies
RPL_REHASHING ERR_
Example
REHASH ; message from user with
status to server asking it to
its configuration file
4.3 Die
Command:
Parameters:
An operator can use the DIE command to shutdown the server.
message is optional since it may be viewed as a risk to
arbitrary people to connect to a server as an operator and
this command
The DIE command MUST always be fully processed by the server to
the sending client is connected and MUST NOT be passed onto
connected servers
Numeric Replies
ERR_
Example
DIE ; no parameters required
Kalt Informational [Page 39]
RFC 2812 Internet Relay Chat: Client Protocol April 2000
4.4 Restart
Command:
Parameters:
An operator can use the restart command to force the server
restart itself. This message is optional since it may be viewed as
risk to allow arbitrary people to connect to a server as an
and execute this command, causing (at least) a disruption to service
The RESTART command MUST always be fully processed by the server
which the sending client is connected and MUST NOT be passed
other connected servers
Numeric Replies
ERR_
Example
RESTART ; no parameters required
4.5 Summon
Command:
Parameters: [ [ 