mirror of
https://github.com/matrix-construct/construct
synced 2024-09-08 17:55:47 +02:00
+ branches/release-2.1 -> 2.2 base + 3.0 -> branches/cxxconversion + backport some immediate 3.0 functionality for 2.2 + other stuff
3643 lines
No EOL
136 KiB
Text
3643 lines
No EOL
136 KiB
Text
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group J. Oikarinen
|
||
Request for Comments: 1459 D. Reed
|
||
May 1993
|
||
|
||
|
||
Internet Relay Chat Protocol
|
||
|
||
Status of This Memo
|
||
|
||
This memo defines an Experimental Protocol for the Internet
|
||
community. Discussion and suggestions for improvement are requested.
|
||
Please refer to the current edition of the "IAB Official Protocol
|
||
Standards" for the standardization state and status of this protocol.
|
||
Distribution of this memo is unlimited.
|
||
|
||
Abstract
|
||
|
||
The IRC protocol was developed over the last 4 years since it was
|
||
first implemented as a means for users on a BBS to chat amongst
|
||
themselves. Now it supports a world-wide network of servers and
|
||
clients, and is stringing to cope with growth. Over the past 2 years,
|
||
the average number of users connected to the main IRC network has
|
||
grown by a factor of 10.
|
||
|
||
The IRC protocol is a text-based protocol, with the simplest client
|
||
being any socket program capable of connecting to the server.
|
||
|
||
Table of Contents
|
||
|
||
1. INTRODUCTION ............................................... 4
|
||
1.1 Servers ................................................ 4
|
||
1.2 Clients ................................................ 5
|
||
1.2.1 Operators .......................................... 5
|
||
1.3 Channels ................................................ 5
|
||
1.3.1 Channel Operators .................................... 6
|
||
2. THE IRC SPECIFICATION ....................................... 7
|
||
2.1 Overview ................................................ 7
|
||
2.2 Character codes ......................................... 7
|
||
2.3 Messages ................................................ 7
|
||
2.3.1 Message format in 'pseudo' BNF .................... 8
|
||
2.4 Numeric replies ......................................... 10
|
||
3. IRC Concepts ................................................ 10
|
||
3.1 One-to-one communication ................................ 10
|
||
3.2 One-to-many ............................................. 11
|
||
3.2.1 To a list .......................................... 11
|
||
3.2.2 To a group (channel) ............................... 11
|
||
3.2.3 To a host/server mask .............................. 12
|
||
3.3 One to all .............................................. 12
|
||
|
||
|
||
|
||
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. INTRODUCTION
|
||
|
||
The IRC (Internet Relay Chat) protocol has been designed over a
|
||
number of years for use with text based conferencing. This document
|
||
describes the current IRC protocol.
|
||
|
||
The IRC protocol has been developed on systems using the TCP/IP
|
||
network protocol, although there is no requirement that this remain
|
||
the only sphere in which it operates.
|
||
|
||
IRC itself is a teleconferencing system, which (through the use of
|
||
the client-server model) is well-suited to running on many machines
|
||
in a distributed fashion. A typical setup involves a single process
|
||
(the server) forming a central point for clients (or other servers)
|
||
to connect to, performing the required message delivery/multiplexing
|
||
and other functions.
|
||
|
||
1.1 Servers
|
||
|
||
The server forms the backbone of IRC, providing a point to which
|
||
clients may connect to to talk to each other, and a point for other
|
||
servers to connect to, forming an IRC network. The only network
|
||
configuration allowed for IRC servers is that of a spanning tree [see
|
||
Fig. 1] where each server acts as a central node for the rest of the
|
||
net it sees.
|
||
|
||
|
||
[ Server 15 ] [ Server 13 ] [ Server 14]
|
||
/ \ /
|
||
/ \ /
|
||
[ Server 11 ] ------ [ Server 1 ] [ Server 12]
|
||
/ \ /
|
||
/ \ /
|
||
[ Server 2 ] [ Server 3 ]
|
||
/ \ \
|
||
/ \ \
|
||
[ Server 4 ] [ Server 5 ] [ Server 6 ]
|
||
/ | \ /
|
||
/ | \ /
|
||
/ | \____ /
|
||
/ | \ /
|
||
[ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ]
|
||
|
||
:
|
||
[ etc. ]
|
||
:
|
||
|
||
[ Fig. 1. Format of IRC server network ]
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 4]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
1.2 Clients
|
||
|
||
A client is anything connecting to a server that is not another
|
||
server. Each client is distinguished from other clients by a unique
|
||
nickname having a maximum length of nine (9) characters. See the
|
||
protocol grammar rules for what may and may not be used in a
|
||
nickname. In addition to the nickname, all servers must have the
|
||
following information about all clients: the real name of the host
|
||
that the client is running on, the username of the client on that
|
||
host, and the server to which the client is connected.
|
||
|
||
1.2.1 Operators
|
||
|
||
To allow a reasonable amount of order to be kept within the IRC
|
||
network, a special class of clients (operators) is allowed to perform
|
||
general maintenance functions on the network. Although the powers
|
||
granted to an operator can be considered as 'dangerous', they are
|
||
nonetheless required. Operators should be able to perform basic
|
||
network tasks such as disconnecting and reconnecting servers as
|
||
needed to prevent long-term use of bad network routing. In
|
||
recognition of this need, the protocol discussed herein provides for
|
||
operators only to be able to perform such functions. See sections
|
||
4.1.7 (SQUIT) and 4.3.5 (CONNECT).
|
||
|
||
A more controversial power of operators is the ability to remove a
|
||
user from the connected network by 'force', i.e. operators are able
|
||
to close the connection between any client and server. The
|
||
justification for this is delicate since its abuse is both
|
||
destructive and annoying. For further details on this type of
|
||
action, see section 4.6.1 (KILL).
|
||
|
||
1.3 Channels
|
||
|
||
A channel is a named group of one or more clients which will all
|
||
receive messages addressed to that channel. The channel is created
|
||
implicitly when the first client joins it, and the channel ceases to
|
||
exist when the last client leaves it. While channel exists, any
|
||
client can reference the channel using the name of the channel.
|
||
|
||
Channels names are strings (beginning with a '&' or '#' character) of
|
||
length up to 200 characters. Apart from the the requirement that the
|
||
first character being either '&' or '#'; the only restriction on a
|
||
channel name is that it may not contain any spaces (' '), a control G
|
||
(^G or ASCII 7), or a comma (',' which is used as a list item
|
||
separator by the protocol).
|
||
|
||
There are two types of channels allowed by this protocol. One is a
|
||
distributed channel which is known to all the servers that are
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 5]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
connected to the network. These channels are marked by the first
|
||
character being a only clients on the server where it exists may join
|
||
it. These are distinguished by a leading '&' character. On top of
|
||
these two types, there are the various channel modes available to
|
||
alter the characteristics of individual channels. See section 4.2.3
|
||
(MODE command) for more details on this.
|
||
|
||
To create a new channel or become part of an existing channel, a user
|
||
is required to JOIN the channel. If the channel doesn't exist prior
|
||
to joining, the channel is created and the creating user becomes a
|
||
channel operator. If the channel already exists, whether or not your
|
||
request to JOIN that channel is honoured depends on the current modes
|
||
of the channel. For example, if the channel is invite-only, (+i),
|
||
then you may only join if invited. As part of the protocol, a user
|
||
may be a part of several channels at once, but a limit of ten (10)
|
||
channels is recommended as being ample for both experienced and
|
||
novice users. See section 8.13 for more information on this.
|
||
|
||
If the IRC network becomes disjoint because of a split between two
|
||
servers, the channel on each side is only composed of those clients
|
||
which are connected to servers on the respective sides of the split,
|
||
possibly ceasing to exist on one side of the split. When the split
|
||
is healed, the connecting servers announce to each other who they
|
||
think is in each channel and the mode of that channel. If the
|
||
channel exists on both sides, the JOINs and MODEs are interpreted in
|
||
an inclusive manner so that both sides of the new connection will
|
||
agree about which clients are in the channel and what modes the
|
||
channel has.
|
||
|
||
1.3.1 Channel Operators
|
||
|
||
The channel operator (also referred to as a "chop" or "chanop") on a
|
||
given channel is considered to 'own' that channel. In recognition of
|
||
this status, channel operators are endowed with certain powers which
|
||
enable them to keep control and some sort of sanity in their channel.
|
||
As an owner of a channel, a channel operator is not required to have
|
||
reasons for their actions, although if their actions are generally
|
||
antisocial or otherwise abusive, it might be reasonable to ask an IRC
|
||
operator to intervene, or for the usersjust leave and go elsewhere
|
||
and form their own channel.
|
||
|
||
The commands which may only be used by channel operators are:
|
||
|
||
KICK - Eject a client from the channel
|
||
MODE - Change the channel's mode
|
||
INVITE - Invite a client to an invite-only channel (mode +i)
|
||
TOPIC - Change the channel topic in a mode +t channel
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 6]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
A channel operator is identified by the '@' symbol next to their
|
||
nickname whenever it is associated with a channel (ie replies to the
|
||
NAMES, WHO and WHOIS commands).
|
||
|
||
2. The IRC Specification
|
||
|
||
2.1 Overview
|
||
|
||
The protocol as described herein is for use both with server to
|
||
server and client to server connections. There are, however, more
|
||
restrictions on client connections (which are considered to be
|
||
untrustworthy) than on server connections.
|
||
|
||
2.2 Character codes
|
||
|
||
No specific character set is specified. The protocol is based on a a
|
||
set of codes which are composed of eight (8) bits, making up an
|
||
octet. Each message may be composed of any number of these octets;
|
||
however, some octet values are used for control codes which act as
|
||
message delimiters.
|
||
|
||
Regardless of being an 8-bit protocol, the delimiters and keywords
|
||
are such that protocol is mostly usable from USASCII terminal and a
|
||
telnet connection.
|
||
|
||
Because of IRC's scandanavian origin, the characters {}| are
|
||
considered to be the lower case equivalents of the characters []\,
|
||
respectively. This is a critical issue when determining the
|
||
equivalence of two nicknames.
|
||
|
||
2.3 Messages
|
||
|
||
Servers and clients send eachother messages which may or may not
|
||
generate a reply. If the message contains a valid command, as
|
||
described in later sections, the client should expect a reply as
|
||
specified but it is not advised to wait forever for the reply; client
|
||
to server and server to server communication is essentially
|
||
asynchronous in nature.
|
||
|
||
Each IRC message may consist of up to three main parts: the prefix
|
||
(optional), the command, and the command parameters (of which there
|
||
may be up to 15). The prefix, command, and all parameters are
|
||
separated by one (or more) ASCII space character(s) (0x20).
|
||
|
||
The presence of a prefix is indicated with a single leading ASCII
|
||
colon character (':', 0x3b), which must be the first character of the
|
||
message itself. There must be no gap (whitespace) between the colon
|
||
and the prefix. The prefix is used by servers to indicate the true
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 7]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
origin of the message. If the prefix is missing from the message, it
|
||
is assumed to have originated from the connection from which it was
|
||
received. Clients should not use prefix when sending a message from
|
||
themselves; if they use a prefix, the only valid prefix is the
|
||
registered nickname associated with the client. If the source
|
||
identified by the prefix cannot be found from the server's internal
|
||
database, or if the source is registered from a different link than
|
||
from which the message arrived, the server must ignore the message
|
||
silently.
|
||
|
||
The command must either be a valid IRC command or a three (3) digit
|
||
number represented in ASCII text.
|
||
|
||
IRC messages are always lines of characters terminated with a CR-LF
|
||
(Carriage Return - Line Feed) pair, and these messages shall not
|
||
exceed 512 characters in length, counting all characters including
|
||
the trailing CR-LF. Thus, there are 510 characters maximum allowed
|
||
for the command and its parameters. There is no provision for
|
||
continuation message lines. See section 7 for more details about
|
||
current implementations.
|
||
|
||
2.3.1 Message format in 'pseudo' BNF
|
||
|
||
The protocol messages must be extracted from the contiguous stream of
|
||
octets. The current solution is to designate two characters, CR and
|
||
LF, as message separators. Empty messages are silently ignored,
|
||
which permits use of the sequence CR-LF between messages
|
||
without extra problems.
|
||
|
||
The extracted message is parsed into the components <prefix>,
|
||
<command> and list of parameters matched either by <middle> or
|
||
<trailing> components.
|
||
|
||
The BNF representation for this is:
|
||
|
||
|
||
<message> ::= [':' <prefix> <SPACE> ] <command> <params> <crlf>
|
||
<prefix> ::= <servername> | <nick> [ '!' <user> ] [ '@' <host> ]
|
||
<command> ::= <letter> { <letter> } | <number> <number> <number>
|
||
<SPACE> ::= ' ' { ' ' }
|
||
<params> ::= <SPACE> [ ':' <trailing> | <middle> <params> ]
|
||
|
||
<middle> ::= <Any *non-empty* sequence of octets not including SPACE
|
||
or NUL or CR or LF, the first of which may not be ':'>
|
||
<trailing> ::= <Any, possibly *empty*, sequence of octets not including
|
||
NUL or CR or LF>
|
||
|
||
<crlf> ::= CR LF
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 8]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
NOTES:
|
||
|
||
1) <SPACE> is consists only of SPACE character(s) (0x20).
|
||
Specially notice that TABULATION, and all other control
|
||
characters are considered NON-WHITE-SPACE.
|
||
|
||
2) After extracting the parameter list, all parameters are equal,
|
||
whether matched by <middle> or <trailing>. <Trailing> is just
|
||
a syntactic trick to allow SPACE within parameter.
|
||
|
||
3) The fact that CR and LF cannot appear in parameter strings is
|
||
just artifact of the message framing. This might change later.
|
||
|
||
4) The NUL character is not special in message framing, and
|
||
basically could end up inside a parameter, but as it would
|
||
cause extra complexities in normal C string handling. Therefore
|
||
NUL is not allowed within messages.
|
||
|
||
5) The last parameter may be an empty string.
|
||
|
||
6) Use of the extended prefix (['!' <user> ] ['@' <host> ]) must
|
||
not be used in server to server communications and is only
|
||
intended for server to client messages in order to provide
|
||
clients with more useful information about who a message is
|
||
from without the need for additional queries.
|
||
|
||
Most protocol messages specify additional semantics and syntax for
|
||
the extracted parameter strings dictated by their position in the
|
||
list. For example, many server commands will assume that the first
|
||
parameter after the command is the list of targets, which can be
|
||
described with:
|
||
|
||
<target> ::= <to> [ "," <target> ]
|
||
<to> ::= <channel> | <user> '@' <servername> | <nick> | <mask>
|
||
<channel> ::= ('#' | '&') <chstring>
|
||
<servername> ::= <host>
|
||
<host> ::= see RFC 952 [DNS:4] for details on allowed hostnames
|
||
<nick> ::= <letter> { <letter> | <number> | <special> }
|
||
<mask> ::= ('#' | '$') <chstring>
|
||
<chstring> ::= <any 8bit code except SPACE, BELL, NUL, CR, LF and
|
||
comma (',')>
|
||
|
||
Other parameter syntaxes are:
|
||
|
||
<user> ::= <nonwhite> { <nonwhite> }
|
||
<letter> ::= 'a' ... 'z' | 'A' ... 'Z'
|
||
<number> ::= '0' ... '9'
|
||
<special> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 9]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
<nonwhite> ::= <any 8bit code except SPACE (0x20), NUL (0x0), CR
|
||
(0xd), and LF (0xa)>
|
||
|
||
2.4 Numeric replies
|
||
|
||
Most of the messages sent to the server generate a reply of some
|
||
sort. The most common reply is the numeric reply, used for both
|
||
errors and normal replies. The numeric reply must be sent as one
|
||
message consisting of the sender prefix, the three digit numeric, and
|
||
the target of the reply. A numeric reply is not allowed to originate
|
||
from a client; any such messages received by a server are silently
|
||
dropped. In all other respects, a numeric reply is just like a normal
|
||
message, except that the keyword is made up of 3 numeric digits
|
||
rather than a string of letters. A list of different replies is
|
||
supplied in section 6.
|
||
|
||
3. IRC Concepts.
|
||
|
||
This section is devoted to describing the actual concepts behind the
|
||
organization of the IRC protocol and how the current
|
||
implementations deliver different classes of messages.
|
||
|
||
|
||
|
||
1--\
|
||
A D---4
|
||
2--/ \ /
|
||
B----C
|
||
/ \
|
||
3 E
|
||
|
||
Servers: A, B, C, D, E Clients: 1, 2, 3, 4
|
||
|
||
[ Fig. 2. Sample small IRC network ]
|
||
|
||
3.1 One-to-one communication
|
||
|
||
Communication on a one-to-one basis is usually only performed by
|
||
clients, since most server-server traffic is not a result of servers
|
||
talking only to each other. To provide a secure means for clients to
|
||
talk to each other, it is required that all servers be able to send a
|
||
message in exactly one direction along the spanning tree in order to
|
||
reach any client. The path of a message being delivered is the
|
||
shortest path between any two points on the spanning tree.
|
||
|
||
The following examples all refer to Figure 2 above.
|
||
|
||
|
||
|
||
|
||
|
||
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, which
|
||
sends it straight to client 2.
|
||
|
||
Example 2:
|
||
A message between clients 1 and 3 is seen by servers A & B, and
|
||
client 3. No other clients or servers are allowed see the message.
|
||
|
||
Example 3:
|
||
A message between clients 2 and 4 is seen by servers A, B, C & D
|
||
and client 4 only.
|
||
|
||
3.2 One-to-many
|
||
|
||
The main goal of IRC is to provide a forum which allows easy and
|
||
efficient conferencing (one to many conversations). IRC offers
|
||
several means to achieve this, each serving its own purpose.
|
||
|
||
3.2.1 To a list
|
||
|
||
The least efficient style of one-to-many conversation is through
|
||
clients talking to a 'list' of users. How this is done is almost
|
||
self explanatory: the client gives a list of destinations to which
|
||
the message is to be delivered and the server breaks it up and
|
||
dispatches a separate copy of the message to each given destination.
|
||
This isn't as efficient as using a group since the destination list
|
||
is broken up and the dispatch sent without checking to make sure
|
||
duplicates aren't sent down each path.
|
||
|
||
3.2.2 To a group (channel)
|
||
|
||
In IRC the channel has a role equivalent to that of the multicast
|
||
group; their existence is dynamic (coming and going as people join
|
||
and leave channels) and the actual conversation carried out on a
|
||
channel is only sent to servers which are supporting users on a given
|
||
channel. If there are multiple users on a server in the same
|
||
channel, the message text is sent only once to that server and then
|
||
sent to each client on the channel. This action is then repeated for
|
||
each client-server combination until the original message has fanned
|
||
out and reached each member of the channel.
|
||
|
||
The following examples all refer to Figure 2.
|
||
|
||
Example 4:
|
||
Any channel with 1 client in it. Messages to the channel go to the
|
||
server and then nowhere else.
|
||
|
||
|
||
|
||
|
||
|
||
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 they
|
||
were private messages between the two clients outside a channel.
|
||
|
||
Example 6:
|
||
Clients 1, 2 and 3 in a channel. All messages to the channel are
|
||
sent to all clients and only those servers which must be traversed
|
||
by the message if it were a private message to a single client. If
|
||
client 1 sends a message, it goes back to client 2 and then via
|
||
server B to client 3.
|
||
|
||
3.2.3 To a host/server mask
|
||
|
||
To provide IRC operators with some mechanism to send messages to a
|
||
large body of related users, host and server mask messages are
|
||
provided. These messages are sent to users whose host or server
|
||
information match that of the mask. The messages are only sent to
|
||
locations where users are, in a fashion similar to that of channels.
|
||
|
||
3.3 One-to-all
|
||
|
||
The one-to-all type of message is better described as a broadcast
|
||
message, sent to all clients or servers or both. On a large network
|
||
of users and servers, a single message can result in a lot of traffic
|
||
being sent over the network in an effort to reach all of the desired
|
||
destinations.
|
||
|
||
For some messages, there is no option but to broadcast it to all
|
||
servers so that the state information held by each server is
|
||
reasonably consistent between servers.
|
||
|
||
3.3.1 Client-to-Client
|
||
|
||
There is no class of message which, from a single message, results in
|
||
a message being sent to every other client.
|
||
|
||
3.3.2 Client-to-Server
|
||
|
||
Most of the commands which result in a change of state information
|
||
(such as channel membership, channel mode, user status, etc) must be
|
||
sent to all servers by default, and this distribution may not be
|
||
changed by the client.
|
||
|
||
3.3.3 Server-to-Server.
|
||
|
||
While most messages between servers are distributed to all 'other'
|
||
servers, this is only required for any message that affects either a
|
||
user, channel or server. Since these are the basic items found in
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 12]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
IRC, nearly all messages originating from a server are broadcast to
|
||
all other connected servers.
|
||
|
||
4. Message details
|
||
|
||
On the following pages are descriptions of each message recognized by
|
||
the IRC server and client. All commands described in this section
|
||
must be implemented by any server for this protocol.
|
||
|
||
Where the reply ERR_NOSUCHSERVER is listed, it means that the
|
||
<server> parameter could not be found. The server must not send any
|
||
other replies after this for that command.
|
||
|
||
The server to which a client is connected is required to parse the
|
||
complete message, returning any appropriate errors. If the server
|
||
encounters a fatal error while parsing a message, an error must be
|
||
sent back to the client and the parsing terminated. A fatal error
|
||
may be considered to be incorrect command, a destination which is
|
||
otherwise unknown to the server (server, nick or channel names fit
|
||
this category), not enough parameters or incorrect privileges.
|
||
|
||
If a full set of parameters is presented, then each must be checked
|
||
for validity and appropriate responses sent back to the client. In
|
||
the case of messages which use parameter lists using the comma as an
|
||
item separator, a reply must be sent for each item.
|
||
|
||
In the examples below, some messages appear using the full format:
|
||
|
||
:Name COMMAND parameter list
|
||
|
||
Such examples represent a message from "Name" in transit between
|
||
servers, where it is essential to include the name of the original
|
||
sender of the message so remote servers may send back a reply along
|
||
the correct path.
|
||
|
||
4.1 Connection Registration
|
||
|
||
The commands described here are used to register a connection with an
|
||
IRC server as either a user or a server as well as correctly
|
||
disconnect.
|
||
|
||
A "PASS" command is not required for either client or server
|
||
connection to be registered, but it must precede the server message
|
||
or the latter of the NICK/USER combination. It is strongly
|
||
recommended that all server connections have a password in order to
|
||
give some level of security to the actual connections. The
|
||
recommended order for a client to register is as follows:
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 13]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
1. Pass message
|
||
2. Nick message
|
||
3. User message
|
||
|
||
4.1.1 Password message
|
||
|
||
|
||
Command: PASS
|
||
Parameters: <password>
|
||
|
||
The PASS command is used to set a 'connection password'. The
|
||
password can and must be set before any attempt to register the
|
||
connection is made. Currently this requires that clients send a PASS
|
||
command before sending the NICK/USER combination and servers *must*
|
||
send a PASS command before any SERVER command. The password supplied
|
||
must match the one contained in the C/N lines (for servers) or I
|
||
lines (for clients). It is possible to send multiple PASS commands
|
||
before registering but only the last one sent is used for
|
||
verification and it may not be changed once registered. Numeric
|
||
Replies:
|
||
|
||
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
|
||
|
||
Example:
|
||
|
||
PASS secretpasswordhere
|
||
|
||
4.1.2 Nick message
|
||
|
||
Command: NICK
|
||
Parameters: <nickname> [ <hopcount> ]
|
||
|
||
NICK message is used to give user a nickname or change the previous
|
||
one. The <hopcount> parameter is only used by servers to indicate
|
||
how far away a nick is from its home server. A local connection has
|
||
a hopcount of 0. If supplied by a client, it must be ignored.
|
||
|
||
If a NICK message arrives at a server which already knows about an
|
||
identical nickname for another client, a nickname collision occurs.
|
||
As a result of a nickname collision, all instances of the nickname
|
||
are removed from the server's database, and a KILL command is issued
|
||
to remove the nickname from all other server's database. If the NICK
|
||
message causing the collision was a nickname change, then the
|
||
original (old) nick must be removed as well.
|
||
|
||
If the server recieves an identical NICK from a client which is
|
||
directly connected, it may issue an ERR_NICKCOLLISION to the local
|
||
client, drop the NICK command, and not generate any kills.
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 14]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
|
||
ERR_NICKNAMEINUSE ERR_NICKCOLLISION
|
||
|
||
Example:
|
||
|
||
NICK Wiz ; Introducing new nick "Wiz".
|
||
|
||
:WiZ NICK Kilroy ; WiZ changed his nickname to Kilroy.
|
||
|
||
4.1.3 User message
|
||
|
||
Command: USER
|
||
Parameters: <username> <hostname> <servername> <realname>
|
||
|
||
The USER message is used at the beginning of connection to specify
|
||
the username, hostname, servername and realname of s new user. It is
|
||
also used in communication between servers to indicate new user
|
||
arriving on IRC, since only after both USER and NICK have been
|
||
received from a client does a user become registered.
|
||
|
||
Between servers USER must to be prefixed with client's NICKname.
|
||
Note that hostname and servername are normally ignored by the IRC
|
||
server when the USER command comes from a directly connected client
|
||
(for security reasons), but they are used in server to server
|
||
communication. This means that a NICK must always be sent to a
|
||
remote server when a new user is being introduced to the rest of the
|
||
network before the accompanying USER is sent.
|
||
|
||
It must be noted that realname parameter must be the last parameter,
|
||
because it may contain space characters and must be prefixed with a
|
||
colon (':') to make sure this is recognised as such.
|
||
|
||
Since it is easy for a client to lie about its username by relying
|
||
solely on the USER message, the use of an "Identity Server" is
|
||
recommended. If the host which a user connects from has such a
|
||
server enabled the username is set to that as in the reply from the
|
||
"Identity Server".
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
|
||
|
||
Examples:
|
||
|
||
|
||
USER guest tolmoon tolsun :Ronnie Reagan
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 15]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
; User registering themselves with a
|
||
username of "guest" and real name
|
||
"Ronnie Reagan".
|
||
|
||
|
||
:testnick USER guest tolmoon tolsun :Ronnie Reagan
|
||
; message between servers with the
|
||
nickname for which the USER command
|
||
belongs to
|
||
|
||
4.1.4 Server message
|
||
|
||
Command: SERVER
|
||
Parameters: <servername> <hopcount> <info>
|
||
|
||
The server message is used to tell a server that the other end of a
|
||
new connection is a server. This message is also used to pass server
|
||
data over whole net. When a new server is connected to net,
|
||
information about it be broadcast to the whole network. <hopcount>
|
||
is used to give all servers some internal information on how far away
|
||
all servers are. With a full server list, it would be possible to
|
||
construct a map of the entire server tree, but hostmasks prevent this
|
||
from being done.
|
||
|
||
The SERVER message must only be accepted from either (a) a connection
|
||
which is yet to be registered and is attempting to register as a
|
||
server, or (b) an existing connection to another server, in which
|
||
case the SERVER message is introducing a new server behind that
|
||
server.
|
||
|
||
Most errors that occur with the receipt of a SERVER command result in
|
||
the connection being terminated by the destination host (target
|
||
SERVER). Error replies are usually sent using the "ERROR" command
|
||
rather than the numeric since the ERROR command has several useful
|
||
properties which make it useful here.
|
||
|
||
If a SERVER message is parsed and attempts to introduce a server
|
||
which is already known to the receiving server, the connection from
|
||
which that message must be closed (following the correct procedures),
|
||
since a duplicate route to a server has formed and the acyclic nature
|
||
of the IRC tree broken.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_ALREADYREGISTRED
|
||
|
||
Example:
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 16]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server
|
||
; New server test.oulu.fi introducing
|
||
itself and attempting to register. The
|
||
name in []'s is the hostname for the
|
||
host running test.oulu.fi.
|
||
|
||
|
||
:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
|
||
; Server tolsun.oulu.fi is our uplink
|
||
for csd.bu.edu which is 5 hops away.
|
||
|
||
4.1.5 Oper
|
||
|
||
Command: OPER
|
||
Parameters: <user> <password>
|
||
|
||
OPER message is used by a normal user to obtain operator privileges.
|
||
The combination of <user> and <password> are required to gain
|
||
Operator privileges.
|
||
|
||
If the client sending the OPER command supplies the correct password
|
||
for the given user, the server then informs the rest of the network
|
||
of the new operator by issuing a "MODE +o" for the clients nickname.
|
||
|
||
The OPER message is client-server only.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NEEDMOREPARAMS RPL_YOUREOPER
|
||
ERR_NOOPERHOST ERR_PASSWDMISMATCH
|
||
|
||
Example:
|
||
|
||
OPER foo bar ; Attempt to register as an operator
|
||
using a username of "foo" and "bar" as
|
||
the password.
|
||
|
||
4.1.6 Quit
|
||
|
||
Command: QUIT
|
||
Parameters: [<Quit message>]
|
||
|
||
A client session is ended with a quit message. The server must close
|
||
the connection to a client which sends a QUIT message. If a "Quit
|
||
Message" is given, this will be sent instead of the default message,
|
||
the nickname.
|
||
|
||
When netsplits (disconnecting of two servers) occur, the quit message
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 17]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
is composed of the names of two servers involved, separated by a
|
||
space. The first name is that of the server which is still connected
|
||
and the second name is that of the server that has become
|
||
disconnected.
|
||
|
||
If, for some other reason, a client connection is closed without the
|
||
client issuing a QUIT command (e.g. client dies and EOF occurs
|
||
on socket), the server is required to fill in the quit message with
|
||
some sort of message reflecting the nature of the event which
|
||
caused it to happen.
|
||
|
||
Numeric Replies:
|
||
|
||
None.
|
||
|
||
Examples:
|
||
|
||
QUIT :Gone to have lunch ; Preferred message format.
|
||
|
||
4.1.7 Server quit message
|
||
|
||
Command: SQUIT
|
||
Parameters: <server> <comment>
|
||
|
||
The SQUIT message is needed to tell about quitting or dead servers.
|
||
If a server wishes to break the connection to another server it must
|
||
send a SQUIT message to the other server, using the the name of the
|
||
other server as the server parameter, which then closes its
|
||
connection to the quitting server.
|
||
|
||
This command is also available operators to help keep a network of
|
||
IRC servers connected in an orderly fashion. Operators may also
|
||
issue an SQUIT message for a remote server connection. In this case,
|
||
the SQUIT must be parsed by each server inbetween the operator and
|
||
the remote server, updating the view of the network held by each
|
||
server as explained below.
|
||
|
||
The <comment> should be supplied by all operators who execute a SQUIT
|
||
for a remote server (that is not connected to the server they are
|
||
currently on) so that other operators are aware for the reason of
|
||
this action. The <comment> is also filled in by servers which may
|
||
place an error or similar message here.
|
||
|
||
Both of the servers which are on either side of the connection being
|
||
closed are required to to send out a SQUIT message (to all its other
|
||
server connections) for all other servers which are considered to be
|
||
behind that link.
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 18]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
Similarly, a QUIT message must be sent to the other connected servers
|
||
rest of the network on behalf of all clients behind that link. In
|
||
addition to this, all channel members of a channel which lost a
|
||
member due to the split must be sent a QUIT message.
|
||
|
||
If a server connection is terminated prematurely (e.g. the server on
|
||
the other end of the link died), the server which detects
|
||
this disconnection is required to inform the rest of the network
|
||
that the connection has closed and fill in the comment field
|
||
with something appropriate.
|
||
|
||
Numeric replies:
|
||
|
||
ERR_NOPRIVILEGES ERR_NOSUCHSERVER
|
||
|
||
Example:
|
||
|
||
SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has
|
||
been terminated because of "Bad Link".
|
||
|
||
:Trillian SQUIT cm22.eng.umd.edu :Server out of control
|
||
; message from Trillian to disconnect
|
||
"cm22.eng.umd.edu" from the net
|
||
because "Server out of control".
|
||
|
||
4.2 Channel operations
|
||
|
||
This group of messages is concerned with manipulating channels, their
|
||
properties (channel modes), and their contents (typically clients).
|
||
In implementing these, a number of race conditions are inevitable
|
||
when clients at opposing ends of a network send commands which will
|
||
ultimately clash. It is also required that servers keep a nickname
|
||
history to ensure that wherever a <nick> parameter is given, the
|
||
server check its history in case it has recently been changed.
|
||
|
||
4.2.1 Join message
|
||
|
||
Command: JOIN
|
||
Parameters: <channel>{,<channel>} [<key>{,<key>}]
|
||
|
||
The JOIN command is used by client to start listening a specific
|
||
channel. Whether or not a client is allowed to join a channel is
|
||
checked only by the server the client is connected to; all other
|
||
servers automatically add the user to the channel when it is received
|
||
from other servers. The conditions which affect this are as follows:
|
||
|
||
1. the user must be invited if the channel is invite-only;
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 19]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
2. the user's nick/username/hostname must not match any
|
||
active bans;
|
||
|
||
3. the correct key (password) must be given if it is set.
|
||
|
||
These are discussed in more detail under the MODE command (see
|
||
section 4.2.3 for more details).
|
||
|
||
Once a user has joined a channel, they receive notice about all
|
||
commands their server receives which affect the channel. This
|
||
includes MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. The
|
||
JOIN command needs to be broadcast to all servers so that each server
|
||
knows where to find the users who are on the channel. This allows
|
||
optimal delivery of PRIVMSG/NOTICE messages to the channel.
|
||
|
||
If a JOIN is successful, the user is then sent the channel's topic
|
||
(using RPL_TOPIC) and the list of users who are on the channel (using
|
||
RPL_NAMREPLY), which must include the user joining.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
|
||
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
|
||
ERR_CHANNELISFULL ERR_BADCHANMASK
|
||
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
|
||
RPL_TOPIC
|
||
|
||
Examples:
|
||
|
||
JOIN #foobar ; join channel #foobar.
|
||
|
||
JOIN &foo fubar ; join channel &foo using key "fubar".
|
||
|
||
JOIN #foo,&bar fubar ; join channel #foo using key "fubar"
|
||
and &bar using no key.
|
||
|
||
JOIN #foo,#bar fubar,foobar ; join channel #foo using key "fubar".
|
||
and channel #bar using key "foobar".
|
||
|
||
JOIN #foo,#bar ; join channels #foo and #bar.
|
||
|
||
:WiZ JOIN #Twilight_zone ; JOIN message from WiZ
|
||
|
||
4.2.2 Part message
|
||
|
||
Command: PART
|
||
Parameters: <channel>{,<channel>}
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 20]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
The PART message causes the client sending the message to be removed
|
||
from the list of active users for all given channels listed in the
|
||
parameter string.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
|
||
ERR_NOTONCHANNEL
|
||
|
||
Examples:
|
||
|
||
PART #twilight_zone ; leave channel "#twilight_zone"
|
||
|
||
PART #oz-ops,&group5 ; leave both channels "&group5" and
|
||
"#oz-ops".
|
||
|
||
4.2.3 Mode message
|
||
|
||
Command: MODE
|
||
|
||
The MODE command is a dual-purpose command in IRC. It allows both
|
||
usernames and channels to have their mode changed. The rationale for
|
||
this choice is that one day nicknames will be obsolete and the
|
||
equivalent property will be the channel.
|
||
|
||
When parsing MODE messages, it is recommended that the entire message
|
||
be parsed first and then the changes which resulted then passed on.
|
||
|
||
4.2.3.1 Channel modes
|
||
|
||
Parameters: <channel> {[+|-]|o|p|s|i|t|n|b|v} [<limit>] [<user>]
|
||
[<ban mask>]
|
||
|
||
The MODE command is provided so that channel operators may change the
|
||
characteristics of `their' channel. It is also required that servers
|
||
be able to change channel modes so that channel operators may be
|
||
created.
|
||
|
||
The various modes available for channels are as follows:
|
||
|
||
o - give/take channel operator privileges;
|
||
p - private channel flag;
|
||
s - secret channel flag;
|
||
i - invite-only channel flag;
|
||
t - topic settable by channel operator only flag;
|
||
n - no messages to channel from clients on the outside;
|
||
m - moderated channel;
|
||
l - set the user limit to channel;
|
||
|
||
|
||
|
||
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 three
|
||
per mode command has been imposed. That is, any combination of 'o'
|
||
and
|
||
|
||
4.2.3.2 User modes
|
||
|
||
Parameters: <nickname> {[+|-]|i|w|s|o}
|
||
|
||
The user MODEs are typically changes which affect either how the
|
||
client is seen by others or what 'extra' messages the client is sent.
|
||
A user MODE command may only be accepted if both the sender of the
|
||
message and the nickname given as a parameter are both the same.
|
||
|
||
The available modes are as follows:
|
||
|
||
i - marks a users as invisible;
|
||
s - marks a user for receipt of server notices;
|
||
w - user receives wallops;
|
||
o - operator flag.
|
||
|
||
Additional modes may be available later on.
|
||
|
||
If a user attempts to make themselves an operator using the "+o"
|
||
flag, the attempt should be ignored. There is no restriction,
|
||
however, on anyone `deopping' themselves (using "-o"). Numeric
|
||
Replies:
|
||
|
||
ERR_NEEDMOREPARAMS RPL_CHANNELMODEIS
|
||
ERR_CHANOPRIVSNEEDED ERR_NOSUCHNICK
|
||
ERR_NOTONCHANNEL ERR_KEYSET
|
||
RPL_BANLIST RPL_ENDOFBANLIST
|
||
ERR_UNKNOWNMODE ERR_NOSUCHCHANNEL
|
||
|
||
ERR_USERSDONTMATCH RPL_UMODEIS
|
||
ERR_UMODEUNKNOWNFLAG
|
||
|
||
Examples:
|
||
|
||
Use of Channel Modes:
|
||
|
||
MODE #Finnish +im ; Makes #Finnish channel moderated and
|
||
'invite-only'.
|
||
|
||
MODE #Finnish +o Kilroy ; Gives 'chanop' privileges to Kilroy on
|
||
|
||
|
||
|
||
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 channel
|
||
#Fins.
|
||
|
||
MODE #42 +k oulu ; Set the channel key to "oulu".
|
||
|
||
MODE #eu-opers +l 10 ; Set the limit for the number of users
|
||
on channel to 10.
|
||
|
||
MODE &oulu +b ; list ban masks set for channel.
|
||
|
||
MODE &oulu +b *!*@* ; prevent all users from joining.
|
||
|
||
MODE &oulu +b *!*@*.edu ; prevent any user from a hostname
|
||
matching *.edu from joining.
|
||
|
||
Use of user Modes:
|
||
|
||
:MODE WiZ -w ; turns reception of WALLOPS messages
|
||
off for WiZ.
|
||
|
||
:Angel MODE Angel +i ; Message from Angel to make themselves
|
||
invisible.
|
||
|
||
MODE WiZ -o ; WiZ 'deopping' (removing operator
|
||
status). The plain reverse of this
|
||
command ("MODE WiZ +o") must not be
|
||
allowed from users since would bypass
|
||
the OPER command.
|
||
|
||
4.2.4 Topic message
|
||
|
||
Command: TOPIC
|
||
Parameters: <channel> [<topic>]
|
||
|
||
The TOPIC message is used to change or view the topic of a channel.
|
||
The topic for channel <channel> is returned if there is no <topic>
|
||
given. If the <topic> parameter is present, the topic for that
|
||
channel will be changed, if the channel modes permit this action.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
|
||
RPL_NOTOPIC RPL_TOPIC
|
||
ERR_CHANOPRIVSNEEDED
|
||
|
||
|
||
|
||
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 "another
|
||
topic".
|
||
|
||
TOPIC #test ; check the topic for #test.
|
||
|
||
4.2.5 Names message
|
||
|
||
Command: NAMES
|
||
Parameters: [<channel>{,<channel>}]
|
||
|
||
By using the NAMES command, a user can list all nicknames that are
|
||
visible to them on any channel that they can see. Channel names
|
||
which they can see are those which aren't private (+p) or secret (+s)
|
||
or those which they are actually on. The <channel> parameter
|
||
specifies which channel(s) to return information about if valid.
|
||
There is no error reply for bad channel names.
|
||
|
||
If no <channel> parameter is given, a list of all channels and their
|
||
occupants is returned. At the end of this list, a list of users who
|
||
are visible but either not on any channel or not on a visible channel
|
||
are listed as being on `channel' "*".
|
||
|
||
Numerics:
|
||
|
||
RPL_NAMREPLY RPL_ENDOFNAMES
|
||
|
||
Examples:
|
||
|
||
NAMES #twilight_zone,#42 ; list visible users on #twilight_zone
|
||
and #42 if the channels are visible to
|
||
you.
|
||
|
||
NAMES ; list all visible channels and users
|
||
|
||
4.2.6 List message
|
||
|
||
Command: LIST
|
||
Parameters: [<channel>{,<channel>} [<server>]]
|
||
|
||
The list message is used to list channels and their topics. If the
|
||
<channel> parameter is used, only the status of that channel
|
||
is displayed. Private channels are listed (without their
|
||
topics) as channel "Prv" unless the client generating the query is
|
||
actually on that channel. Likewise, secret channels are not listed
|
||
|
||
|
||
|
||
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_LISTSTART
|
||
RPL_LIST RPL_LISTEND
|
||
|
||
Examples:
|
||
|
||
LIST ; List all channels.
|
||
|
||
LIST #twilight_zone,#42 ; List channels #twilight_zone and #42
|
||
|
||
4.2.7 Invite message
|
||
|
||
Command: INVITE
|
||
Parameters: <nickname> <channel>
|
||
|
||
The INVITE message is used to invite users to a channel. The
|
||
parameter <nickname> is the nickname of the person to be invited to
|
||
the target channel <channel>. There is no requirement that the
|
||
channel the target user is being invited to must exist or be a valid
|
||
channel. To invite a user to a channel which is invite only (MODE
|
||
+i), the client sending the invite must be recognised as being a
|
||
channel operator on the given channel.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
|
||
ERR_NOTONCHANNEL ERR_USERONCHANNEL
|
||
ERR_CHANOPRIVSNEEDED
|
||
RPL_INVITING RPL_AWAY
|
||
|
||
Examples:
|
||
|
||
:Angel INVITE Wiz #Dust ; User Angel inviting WiZ to channel
|
||
#Dust
|
||
|
||
INVITE Wiz #Twilight_Zone ; Command to invite WiZ to
|
||
#Twilight_zone
|
||
|
||
4.2.8 Kick command
|
||
|
||
Command: KICK
|
||
Parameters: <channel> <user> [<comment>]
|
||
|
||
The KICK command can be used to forcibly remove a user from a
|
||
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 valid
|
||
(ie the sender is actually a channel operator) before removing
|
||
the victim from the channel.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
|
||
ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
|
||
ERR_NOTONCHANNEL
|
||
|
||
Examples:
|
||
|
||
KICK &Melbourne Matthew ; Kick Matthew from &Melbourne
|
||
|
||
KICK #Finnish John :Speaking English
|
||
; Kick John from #Finnish using
|
||
"Speaking English" as the reason
|
||
(comment).
|
||
|
||
:WiZ KICK #Finnish John ; KICK message from WiZ to remove John
|
||
from channel #Finnish
|
||
|
||
NOTE:
|
||
It is possible to extend the KICK command parameters to the
|
||
following:
|
||
|
||
<channel>{,<channel>} <user>{,<user>} [<comment>]
|
||
|
||
4.3 Server queries and commands
|
||
|
||
The server query group of commands has been designed to return
|
||
information about any server which is connected to the network. All
|
||
servers connected must respond to these queries and respond
|
||
correctly. Any invalid response (or lack thereof) must be considered
|
||
a sign of a broken server and it must be disconnected/disabled as
|
||
soon as possible until the situation is remedied.
|
||
|
||
In these queries, where a parameter appears as "<server>", it will
|
||
usually mean it can be a nickname or a server or a wildcard name of
|
||
some sort. For each parameter, however, only one query and set of
|
||
replies is to be generated.
|
||
|
||
4.3.1 Version message
|
||
|
||
Command: VERSION
|
||
Parameters: [<server>]
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 26]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
The VERSION message is used to query the version of the server
|
||
program. An optional parameter <server> is used to query the version
|
||
of the server program which a client is not directly connected to.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOSUCHSERVER RPL_VERSION
|
||
|
||
Examples:
|
||
|
||
:Wiz VERSION *.se ; message from Wiz to check the version
|
||
of a server matching "*.se"
|
||
|
||
VERSION tolsun.oulu.fi ; check the version of server
|
||
"tolsun.oulu.fi".
|
||
|
||
4.3.2 Stats message
|
||
|
||
Command: STATS
|
||
Parameters: [<query> [<server>]]
|
||
|
||
The stats message is used to query statistics of certain server. If
|
||
<server> parameter is omitted, only the end of stats reply is sent
|
||
back. The implementation of this command is highly dependent on the
|
||
server which replies, although the server must be able to supply
|
||
information as described by the queries below (or similar).
|
||
|
||
A query may be given by any single letter which is only checked by
|
||
the destination server (if given as the <server> parameter) and is
|
||
otherwise passed on by intermediate servers, ignored and unaltered.
|
||
The following queries are those found in the current IRC
|
||
implementation and provide a large portion of the setup information
|
||
for that server. Although these may not be supported in the same way
|
||
by other versions, all servers should be able to supply a valid reply
|
||
to a STATS query which is consistent with the reply formats currently
|
||
used and the purpose of the query.
|
||
|
||
The currently supported queries are:
|
||
|
||
c - returns a list of servers which the server may connect
|
||
to or allow connections from;
|
||
h - returns a list of servers which are either forced to be
|
||
treated as leaves or allowed to act as hubs;
|
||
i - returns a list of hosts which the server allows a client
|
||
to connect from;
|
||
k - returns a list of banned username/hostname combinations
|
||
for that server;
|
||
l - returns a list of the server's connections, showing how
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 27]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
long each connection has been established and the traffic
|
||
over that connection in bytes and messages for each
|
||
direction;
|
||
m - returns a list of commands supported by the server and
|
||
the usage count for each if the usage count is non zero;
|
||
o - returns a list of hosts from which normal clients may
|
||
become operators;
|
||
y - show Y (Class) lines from server's configuration file;
|
||
u - returns a string showing how long the server has been up.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOSUCHSERVER
|
||
RPL_STATSCLINE RPL_STATSNLINE
|
||
RPL_STATSILINE RPL_STATSKLINE
|
||
RPL_STATSQLINE RPL_STATSLLINE
|
||
RPL_STATSLINKINFO RPL_STATSUPTIME
|
||
RPL_STATSCOMMANDS RPL_STATSOLINE
|
||
RPL_STATSHLINE RPL_ENDOFSTATS
|
||
|
||
Examples:
|
||
|
||
STATS m ; check the command usage for the server
|
||
you are connected to
|
||
|
||
:Wiz STATS c eff.org ; request by WiZ for C/N line
|
||
information from server eff.org
|
||
|
||
4.3.3 Links message
|
||
|
||
Command: LINKS
|
||
Parameters: [[<remote server>] <server mask>]
|
||
|
||
With LINKS, a user can list all servers which are known by the server
|
||
answering the query. The returned list of servers must match the
|
||
mask, or if no mask is given, the full list is returned.
|
||
|
||
If <remote server> is given in addition to <server mask>, the LINKS
|
||
command is forwarded to the first server found that matches that name
|
||
(if any), and that server is then required to answer the query.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOSUCHSERVER
|
||
RPL_LINKS RPL_ENDOFLINKS
|
||
|
||
Examples:
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 28]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
LINKS *.au ; list all servers which have a name
|
||
that matches *.au;
|
||
|
||
:WiZ LINKS *.bu.edu *.edu ; LINKS message from WiZ to the first
|
||
server matching *.edu for a list of
|
||
servers matching *.bu.edu.
|
||
|
||
4.3.4 Time message
|
||
|
||
Command: TIME
|
||
Parameters: [<server>]
|
||
|
||
The time message is used to query local time from the specified
|
||
server. If the server parameter is not given, the server handling the
|
||
command must reply to the query.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOSUCHSERVER RPL_TIME
|
||
|
||
Examples:
|
||
|
||
TIME tolsun.oulu.fi ; check the time on the server
|
||
"tolson.oulu.fi"
|
||
|
||
Angel TIME *.au ; user angel checking the time on a
|
||
server matching "*.au"
|
||
|
||
4.3.5 Connect message
|
||
|
||
Command: CONNECT
|
||
Parameters: <target server> [<port> [<remote server>]]
|
||
|
||
The CONNECT command can be used to force a server to try to establish
|
||
a new connection to another server immediately. CONNECT is a
|
||
privileged command and is to be available only to IRC Operators. If
|
||
a remote server is given then the CONNECT attempt is made by that
|
||
server to <target server> and <port>.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOSUCHSERVER ERR_NOPRIVILEGES
|
||
ERR_NEEDMOREPARAMS
|
||
|
||
Examples:
|
||
|
||
CONNECT tolsun.oulu.fi ; Attempt to connect a server to
|
||
tolsun.oulu.fi
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 29]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
:WiZ CONNECT eff.org 6667 csd.bu.edu
|
||
; CONNECT attempt by WiZ to get servers
|
||
eff.org and csd.bu.edu connected on port
|
||
6667.
|
||
|
||
4.3.6 Trace message
|
||
|
||
Command: TRACE
|
||
Parameters: [<server>]
|
||
|
||
TRACE command is used to find the route to specific server. Each
|
||
server that processes this message must tell the sender about it by
|
||
sending a reply indicating it is a pass-through link, forming a chain
|
||
of replies similar to that gained from using "traceroute". After
|
||
sending this reply back, it must then send the TRACE message to the
|
||
next server until given server is reached. If the <server> parameter
|
||
is omitted, it is recommended that TRACE command send a message to
|
||
the sender telling which servers the current server has direct
|
||
connection to.
|
||
|
||
If the destination given by "<server>" is an actual server, then the
|
||
destination server is required to report all servers and users which
|
||
are connected to it, although only operators are permitted to see
|
||
users present. If the destination given by <server> is a nickname,
|
||
they only a reply for that nickname is given.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOSUCHSERVER
|
||
|
||
If the TRACE message is destined for another server, all intermediate
|
||
servers must return a RPL_TRACELINK reply to indicate that the TRACE
|
||
passed through it and where its going next.
|
||
|
||
RPL_TRACELINK
|
||
A TRACE reply may be composed of any number of the following numeric
|
||
replies.
|
||
|
||
RPL_TRACECONNECTING RPL_TRACEHANDSHAKE
|
||
RPL_TRACEUNKNOWN RPL_TRACEOPERATOR
|
||
RPL_TRACEUSER RPL_TRACESERVER
|
||
RPL_TRACESERVICE RPL_TRACENEWTYPE
|
||
RPL_TRACECLASS
|
||
|
||
Examples:
|
||
|
||
TRACE *.oulu.fi ; TRACE to a server matching *.oulu.fi
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 30]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
:WiZ TRACE AngelDust ; TRACE issued by WiZ to nick AngelDust
|
||
|
||
4.3.7 Admin command
|
||
|
||
Command: ADMIN
|
||
Parameters: [<server>]
|
||
|
||
The admin message is used to find the name of the administrator of
|
||
the given server, or current server if <server> parameter is omitted.
|
||
Each server must have the ability to forward ADMIN messages to other
|
||
servers.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOSUCHSERVER
|
||
RPL_ADMINME RPL_ADMINLOC1
|
||
RPL_ADMINLOC2 RPL_ADMINEMAIL
|
||
|
||
Examples:
|
||
|
||
ADMIN tolsun.oulu.fi ; request an ADMIN reply from
|
||
tolsun.oulu.fi
|
||
|
||
:WiZ ADMIN *.edu ; ADMIN request from WiZ for first
|
||
server found to match *.edu.
|
||
|
||
4.3.8 Info command
|
||
|
||
Command: INFO
|
||
Parameters: [<server>]
|
||
|
||
The INFO command is required to return information which describes
|
||
the server: its version, when it was compiled, the patchlevel, when
|
||
it was started, and any other miscellaneous information which may be
|
||
considered to be relevant.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOSUCHSERVER
|
||
RPL_INFO RPL_ENDOFINFO
|
||
|
||
Examples:
|
||
|
||
INFO csd.bu.edu ; request an INFO reply from
|
||
csd.bu.edu
|
||
|
||
:Avalon INFO *.fi ; INFO request from Avalon for first
|
||
server found to match *.fi.
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 31]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
INFO Angel ; request info from the server that
|
||
Angel is connected to.
|
||
|
||
4.4 Sending messages
|
||
|
||
The main purpose of the IRC protocol is to provide a base for clients
|
||
to communicate with each other. PRIVMSG and NOTICE are the only
|
||
messages available which actually perform delivery of a text message
|
||
from one client to another - the rest just make it possible and try
|
||
to ensure it happens in a reliable and structured manner.
|
||
|
||
4.4.1 Private messages
|
||
|
||
Command: PRIVMSG
|
||
Parameters: <receiver>{,<receiver>} <text to be sent>
|
||
|
||
PRIVMSG is used to send private messages between users. <receiver>
|
||
is the nickname of the receiver of the message. <receiver> can also
|
||
be a list of names or channels separated with commas.
|
||
|
||
The <receiver> parameter may also me a host mask (#mask) or server
|
||
mask ($mask). In both cases the server will only send the PRIVMSG
|
||
to those who have a server or host matching the mask. The mask must
|
||
have at least 1 (one) "." in it and no wildcards following the
|
||
last ".". This requirement exists to prevent people sending messages
|
||
to "#*" or "$*", which would broadcast to all users; from
|
||
experience, this is abused more than used responsibly and properly.
|
||
Wildcards are the '*' and '?' characters. This extension to
|
||
the PRIVMSG command is only available to Operators.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NORECIPIENT ERR_NOTEXTTOSEND
|
||
ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
|
||
ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
|
||
ERR_NOSUCHNICK
|
||
RPL_AWAY
|
||
|
||
Examples:
|
||
|
||
:Angel PRIVMSG Wiz :Hello are you receiving this message ?
|
||
; Message from Angel to Wiz.
|
||
|
||
PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ;
|
||
Message to Angel.
|
||
|
||
PRIVMSG jto@tolsun.oulu.fi :Hello !
|
||
; Message to a client on server
|
||
|
||
|
||
|
||
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 which
|
||
has a name matching *.fi.
|
||
|
||
PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions
|
||
; Message to all users who come from a
|
||
host which has a name matching *.edu.
|
||
|
||
4.4.2 Notice
|
||
|
||
Command: NOTICE
|
||
Parameters: <nickname> <text>
|
||
|
||
The NOTICE message is used similarly to PRIVMSG. The difference
|
||
between NOTICE and PRIVMSG is that automatic replies must never be
|
||
sent in response to a NOTICE message. This rule applies to servers
|
||
too - they must not send any error reply back to the client on
|
||
receipt of a notice. The object of this rule is to avoid loops
|
||
between a client automatically sending something in response to
|
||
something it received. This is typically used by automatons (clients
|
||
with either an AI or other interactive program controlling their
|
||
actions) which are always seen to be replying lest they end up in a
|
||
loop with another automaton.
|
||
|
||
See PRIVMSG for more details on replies and examples.
|
||
|
||
4.5 User based queries
|
||
|
||
User queries are a group of commands which are primarily concerned
|
||
with finding details on a particular user or group users. When using
|
||
wildcards with any of these commands, if they match, they will only
|
||
return information on users who are 'visible' to you. The visibility
|
||
of a user is determined as a combination of the user's mode and the
|
||
common set of channels you are both on.
|
||
|
||
4.5.1 Who query
|
||
|
||
Command: WHO
|
||
Parameters: [<name> [<o>]]
|
||
|
||
The WHO message is used by a client to generate a query which returns
|
||
a list of information which 'matches' the <name> parameter given by
|
||
the client. In the absence of the <name> parameter, all visible
|
||
(users who aren't invisible (user mode +i) and who don't have a
|
||
common channel with the requesting client) are listed. The same
|
||
result can be achieved by using a <name> of "0" or any wildcard which
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 33]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
will end up matching every entry possible.
|
||
|
||
The <name> passed to WHO is matched against users' host, server, real
|
||
name and nickname if the channel <name> cannot be found.
|
||
|
||
If the "o" parameter is passed only operators are returned according
|
||
to the name mask supplied.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOSUCHSERVER
|
||
RPL_WHOREPLY RPL_ENDOFWHO
|
||
|
||
Examples:
|
||
|
||
WHO *.fi ; List all users who match against
|
||
"*.fi".
|
||
|
||
WHO jto* o ; List all users with a match against
|
||
"jto*" if they are an operator.
|
||
|
||
4.5.2 Whois query
|
||
|
||
Command: WHOIS
|
||
Parameters: [<server>] <nickmask>[,<nickmask>[,...]]
|
||
|
||
This message is used to query information about particular user. The
|
||
server will answer this message with several numeric messages
|
||
indicating different statuses of each user which matches the nickmask
|
||
(if you are entitled to see them). If no wildcard is present in the
|
||
<nickmask>, any information about that nick which you are allowed to
|
||
see is presented. A comma (',') separated list of nicknames may be
|
||
given.
|
||
|
||
The latter version sends the query to a specific server. It is
|
||
useful if you want to know how long the user in question has been
|
||
idle as only local server (ie. the server the user is directly
|
||
connected to) knows that information, while everything else is
|
||
globally known.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
|
||
RPL_WHOISUSER RPL_WHOISCHANNELS
|
||
RPL_WHOISCHANNELS RPL_WHOISSERVER
|
||
RPL_AWAY RPL_WHOISOPERATOR
|
||
RPL_WHOISIDLE ERR_NOSUCHNICK
|
||
RPL_ENDOFWHOIS
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 34]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
Examples:
|
||
|
||
WHOIS wiz ; return available user information
|
||
about nick WiZ
|
||
|
||
WHOIS eff.org trillian ; ask server eff.org for user
|
||
information about trillian
|
||
|
||
4.5.3 Whowas
|
||
|
||
Command: WHOWAS
|
||
Parameters: <nickname> [<count> [<server>]]
|
||
|
||
Whowas asks for information about a nickname which no longer exists.
|
||
This may either be due to a nickname change or the user leaving IRC.
|
||
In response to this query, the server searches through its nickname
|
||
history, looking for any nicks which are lexically the same (no wild
|
||
card matching here). The history is searched backward, returning the
|
||
most recent entry first. If there are multiple entries, up to
|
||
<count> replies will be returned (or all of them if no <count>
|
||
parameter is given). If a non-positive number is passed as being
|
||
<count>, then a full search is done.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
|
||
RPL_WHOWASUSER RPL_WHOISSERVER
|
||
RPL_ENDOFWHOWAS
|
||
|
||
Examples:
|
||
|
||
WHOWAS Wiz ; return all information in the nick
|
||
history about nick "WiZ";
|
||
|
||
WHOWAS Mermaid 9 ; return at most, the 9 most recent
|
||
entries in the nick history for
|
||
"Mermaid";
|
||
|
||
WHOWAS Trillian 1 *.edu ; return the most recent history for
|
||
"Trillian" from the first server found
|
||
to match "*.edu".
|
||
|
||
4.6 Miscellaneous messages
|
||
|
||
Messages in this category do not fit into any of the above categories
|
||
but are nonetheless still a part of and required by the protocol.
|
||
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 35]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
4.6.1 Kill message
|
||
|
||
Command: KILL
|
||
Parameters: <nickname> <comment>
|
||
|
||
The KILL message is used to cause a client-server connection to be
|
||
closed by the server which has the actual connection. KILL is used
|
||
by servers when they encounter a duplicate entry in the list of valid
|
||
nicknames and is used to remove both entries. It is also available
|
||
to operators.
|
||
|
||
Clients which have automatic reconnect algorithms effectively make
|
||
this command useless since the disconnection is only brief. It does
|
||
however break the flow of data and can be used to stop large amounts
|
||
of being abused, any user may elect to receive KILL messages
|
||
generated for others to keep an 'eye' on would be trouble spots.
|
||
|
||
In an arena where nicknames are required to be globally unique at all
|
||
times, KILL messages are sent whenever 'duplicates' are detected
|
||
(that is an attempt to register two users with the same nickname) in
|
||
the hope that both of them will disappear and only 1 reappear.
|
||
|
||
The comment given must reflect the actual reason for the KILL. For
|
||
server-generated KILLs it usually is made up of details concerning
|
||
the origins of the two conflicting nicknames. For users it is left
|
||
up to them to provide an adequate reason to satisfy others who see
|
||
it. To prevent/discourage fake KILLs from being generated to hide
|
||
the identify of the KILLer, the comment also shows a 'kill-path'
|
||
which is updated by each server it passes through, each prepending
|
||
its name to the path.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
|
||
ERR_NOSUCHNICK ERR_CANTKILLSERVER
|
||
|
||
|
||
KILL David (csd.bu.edu <- tolsun.oulu.fi)
|
||
; Nickname collision between csd.bu.edu
|
||
and tolson.oulu.fi
|
||
|
||
|
||
NOTE:
|
||
It is recommended that only Operators be allowed to kill other users
|
||
with KILL message. In an ideal world not even operators would need
|
||
to do this and it would be left to servers to deal with.
|
||
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 36]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
4.6.2 Ping message
|
||
|
||
Command: PING
|
||
Parameters: <server1> [<server2>]
|
||
|
||
The PING message is used to test the presence of an active client at
|
||
the other end of the connection. A PING message is sent at regular
|
||
intervals if no other activity detected coming from a connection. If
|
||
a connection fails to respond to a PING command within a set amount
|
||
of time, that connection is closed.
|
||
|
||
Any client which receives a PING message must respond to <server1>
|
||
(server which sent the PING message out) as quickly as possible with
|
||
an appropriate PONG message to indicate it is still there and alive.
|
||
Servers should not respond to PING commands but rely on PINGs from
|
||
the other end of the connection to indicate the connection is alive.
|
||
If the <server2> parameter is specified, the PING message gets
|
||
forwarded there.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOORIGIN ERR_NOSUCHSERVER
|
||
|
||
Examples:
|
||
|
||
PING tolsun.oulu.fi ; server sending a PING message to
|
||
another server to indicate it is still
|
||
alive.
|
||
|
||
PING WiZ ; PING message being sent to nick WiZ
|
||
|
||
4.6.3 Pong message
|
||
|
||
Command: PONG
|
||
Parameters: <daemon> [<daemon2>]
|
||
|
||
PONG message is a reply to ping message. If parameter <daemon2> is
|
||
given this message must be forwarded to given daemon. The <daemon>
|
||
parameter is the name of the daemon who has responded to PING message
|
||
and generated this message.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOORIGIN ERR_NOSUCHSERVER
|
||
|
||
Examples:
|
||
|
||
PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 37]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
tolsun.oulu.fi
|
||
|
||
4.6.4 Error
|
||
|
||
Command: ERROR
|
||
Parameters: <error message>
|
||
|
||
The ERROR command is for use by servers when reporting a serious or
|
||
fatal error to its operators. It may also be sent from one server to
|
||
another but must not be accepted from any normal unknown clients.
|
||
|
||
An ERROR message is for use for reporting errors which occur with a
|
||
server-to-server link only. An ERROR message is sent to the server
|
||
at the other end (which sends it to all of its connected operators)
|
||
and to all operators currently connected. It is not to be passed
|
||
onto any other servers by a server if it is received from a server.
|
||
|
||
When a server sends a received ERROR message to its operators, the
|
||
message should be encapsulated inside a NOTICE message, indicating
|
||
that the client was not responsible for the error.
|
||
|
||
Numerics:
|
||
|
||
None.
|
||
|
||
Examples:
|
||
|
||
ERROR :Server *.fi already exists; ERROR message to the other server
|
||
which caused this error.
|
||
|
||
NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
|
||
; Same ERROR message as above but sent
|
||
to user WiZ on the other server.
|
||
|
||
5. OPTIONALS
|
||
|
||
This section describes OPTIONAL messages. They are not required in a
|
||
working server implementation of the protocol described herein. In
|
||
the absence of the option, an error reply message must be generated
|
||
or an unknown command error. If the message is destined for another
|
||
server to answer then it must be passed on (elementary parsing
|
||
required) The allocated numerics for this are listed with the
|
||
messages below.
|
||
|
||
5.1 Away
|
||
|
||
Command: AWAY
|
||
Parameters: [message]
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 38]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
With the AWAY message, clients can set an automatic reply string for
|
||
any PRIVMSG commands directed at them (not to a channel they are on).
|
||
The automatic reply is sent by the server to client sending the
|
||
PRIVMSG command. The only replying server is the one to which the
|
||
sending client is connected to.
|
||
|
||
The AWAY message is used either with one parameter (to set an AWAY
|
||
message) or with no parameters (to remove the AWAY message).
|
||
|
||
Numeric Replies:
|
||
|
||
RPL_UNAWAY RPL_NOWAWAY
|
||
|
||
Examples:
|
||
|
||
AWAY :Gone to lunch. Back in 5 ; set away message to "Gone to lunch.
|
||
Back in 5".
|
||
|
||
:WiZ AWAY ; unmark WiZ as being away.
|
||
|
||
|
||
5.2 Rehash message
|
||
|
||
Command: REHASH
|
||
Parameters: None
|
||
|
||
The rehash message can be used by the operator to force the server to
|
||
re-read and process its configuration file.
|
||
|
||
Numeric Replies:
|
||
|
||
RPL_REHASHING ERR_NOPRIVILEGES
|
||
|
||
Examples:
|
||
|
||
REHASH ; message from client with operator
|
||
status to server asking it to reread its
|
||
configuration file.
|
||
|
||
5.3 Restart message
|
||
|
||
Command: RESTART
|
||
Parameters: None
|
||
|
||
The restart message can only be used by an operator to force a server
|
||
restart itself. This message is optional since it may be viewed as a
|
||
risk to allow arbitrary people to connect to a server as an operator
|
||
and execute this command, causing (at least) a disruption to service.
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 39]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
The RESTART command must always be fully processed by the server to
|
||
which the sending client is connected and not be passed onto other
|
||
connected servers.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOPRIVILEGES
|
||
|
||
Examples:
|
||
|
||
RESTART ; no parameters required.
|
||
|
||
5.4 Summon message
|
||
|
||
Command: SUMMON
|
||
Parameters: <user> [<server>]
|
||
|
||
The SUMMON command can be used to give users who are on a host
|
||
running an IRC server a message asking them to please join IRC. This
|
||
message is only sent if the target server (a) has SUMMON enabled, (b)
|
||
the user is logged in and (c) the server process can write to the
|
||
user's tty (or similar).
|
||
|
||
If no <server> parameter is given it tries to summon <user> from the
|
||
server the client is connected to is assumed as the target.
|
||
|
||
If summon is not enabled in a server, it must return the
|
||
ERR_SUMMONDISABLED numeric and pass the summon message onwards.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NORECIPIENT ERR_FILEERROR
|
||
ERR_NOLOGIN ERR_NOSUCHSERVER
|
||
RPL_SUMMONING
|
||
|
||
Examples:
|
||
|
||
SUMMON jto ; summon user jto on the server's host
|
||
|
||
SUMMON jto tolsun.oulu.fi ; summon user jto on the host which a
|
||
server named "tolsun.oulu.fi" is
|
||
running.
|
||
|
||
|
||
5.5 Users
|
||
|
||
Command: USERS
|
||
Parameters: [<server>]
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 40]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
The USERS command returns a list of users logged into the server in a
|
||
similar format to who(1), rusers(1) and finger(1). Some people
|
||
may disable this command on their server for security related
|
||
reasons. If disabled, the correct numeric must be returned to
|
||
indicate this.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NOSUCHSERVER ERR_FILEERROR
|
||
RPL_USERSSTART RPL_USERS
|
||
RPL_NOUSERS RPL_ENDOFUSERS
|
||
ERR_USERSDISABLED
|
||
|
||
Disabled Reply:
|
||
|
||
ERR_USERSDISABLED
|
||
|
||
Examples:
|
||
|
||
USERS eff.org ; request a list of users logged in on
|
||
server eff.org
|
||
|
||
:John USERS tolsun.oulu.fi ; request from John for a list of users
|
||
logged in on server tolsun.oulu.fi
|
||
|
||
5.6 Operwall message
|
||
|
||
Command: WALLOPS
|
||
Parameters: Text to be sent to all operators currently online
|
||
|
||
Sends a message to all operators currently online. After
|
||
implementing WALLOPS as a user command it was found that it was
|
||
often and commonly abused as a means of sending a message to a lot
|
||
of people (much similar to WALL). Due to this it is recommended
|
||
that the current implementation of WALLOPS be used as an
|
||
example by allowing and recognising only servers as the senders of
|
||
WALLOPS.
|
||
|
||
Numeric Replies:
|
||
|
||
ERR_NEEDMOREPARAMS
|
||
|
||
Examples:
|
||
|
||
:csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua; WALLOPS
|
||
message from csd.bu.edu announcing a
|
||
CONNECT message it received and acted
|
||
upon from Joshua.
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 41]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
5.7 Userhost message
|
||
|
||
Command: USERHOST
|
||
Parameters: <nickname>{<space><nickname>}
|
||
|
||
The USERHOST command takes a list of up to 5 nicknames, each
|
||
separated by a space character and returns a list of information
|
||
about each nickname that it found. The returned list has each reply
|
||
separated by a space.
|
||
|
||
Numeric Replies:
|
||
|
||
RPL_USERHOST ERR_NEEDMOREPARAMS
|
||
|
||
Examples:
|
||
|
||
USERHOST Wiz Michael Marty p ;USERHOST request for information on
|
||
nicks "Wiz", "Michael", "Marty" and "p"
|
||
|
||
5.8 Ison message
|
||
|
||
Command: ISON
|
||
Parameters: <nickname>{<space><nickname>}
|
||
|
||
The ISON command was implemented to provide a quick and efficient
|
||
means to get a response about whether a given nickname was currently
|
||
on IRC. ISON only takes one (1) parameter: a space-separated list of
|
||
nicks. For each nickname in the list that is present, the server
|
||
adds that to its reply string. Thus the reply string may return
|
||
empty (none of the given nicks are present), an exact copy of the
|
||
parameter string (all of them present) or as any other subset of the
|
||
set of nicks given in the parameter. The only limit on the number
|
||
of nicks that may be checked is that the combined length must not be
|
||
too large as to cause the server to chop it off so it fits in 512
|
||
characters.
|
||
|
||
ISON is only be processed by the server local to the client sending
|
||
the command and thus not passed onto other servers for further
|
||
processing.
|
||
|
||
Numeric Replies:
|
||
|
||
RPL_ISON ERR_NEEDMOREPARAMS
|
||
|
||
Examples:
|
||
|
||
ISON phone trillian WiZ jarlek Avalon Angel Monstah
|
||
; Sample ISON request for 7 nicks.
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 42]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
6. REPLIES
|
||
|
||
The following is a list of numeric replies which are generated in
|
||
response to the commands given above. Each numeric is given with its
|
||
number, name and reply string.
|
||
|
||
6.1 Error Replies.
|
||
|
||
401 ERR_NOSUCHNICK
|
||
"<nickname> :No such nick/channel"
|
||
|
||
- Used to indicate the nickname parameter supplied to a
|
||
command is currently unused.
|
||
|
||
402 ERR_NOSUCHSERVER
|
||
"<server name> :No such server"
|
||
|
||
- Used to indicate the server name given currently
|
||
doesn't exist.
|
||
|
||
403 ERR_NOSUCHCHANNEL
|
||
"<channel name> :No such channel"
|
||
|
||
- Used to indicate the given channel name is invalid.
|
||
|
||
404 ERR_CANNOTSENDTOCHAN
|
||
"<channel name> :Cannot send to channel"
|
||
|
||
- Sent to a user who is either (a) not on a channel
|
||
which is mode +n or (b) not a chanop (or mode +v) on
|
||
a channel which has mode +m set and is trying to send
|
||
a PRIVMSG message to that channel.
|
||
|
||
405 ERR_TOOMANYCHANNELS
|
||
"<channel name> :You have joined too many \
|
||
channels"
|
||
- Sent to a user when they have joined the maximum
|
||
number of allowed channels and they try to join
|
||
another channel.
|
||
|
||
406 ERR_WASNOSUCHNICK
|
||
"<nickname> :There was no such nickname"
|
||
|
||
- Returned by WHOWAS to indicate there is no history
|
||
information for that nickname.
|
||
|
||
407 ERR_TOOMANYTARGETS
|
||
"<target> :Duplicate recipients. No message \
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 43]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
delivered"
|
||
|
||
- Returned to a client which is attempting to send a
|
||
PRIVMSG/NOTICE using the user@host destination format
|
||
and for a user@host which has several occurrences.
|
||
|
||
409 ERR_NOORIGIN
|
||
":No origin specified"
|
||
|
||
- PING or PONG message missing the originator parameter
|
||
which is required since these commands must work
|
||
without valid prefixes.
|
||
|
||
411 ERR_NORECIPIENT
|
||
":No recipient given (<command>)"
|
||
412 ERR_NOTEXTTOSEND
|
||
":No text to send"
|
||
413 ERR_NOTOPLEVEL
|
||
"<mask> :No toplevel domain specified"
|
||
414 ERR_WILDTOPLEVEL
|
||
"<mask> :Wildcard in toplevel domain"
|
||
|
||
- 412 - 414 are returned by PRIVMSG to indicate that
|
||
the message wasn't delivered for some reason.
|
||
ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
|
||
are returned when an invalid use of
|
||
"PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
|
||
|
||
421 ERR_UNKNOWNCOMMAND
|
||
"<command> :Unknown command"
|
||
|
||
- Returned to a registered client to indicate that the
|
||
command sent is unknown by the server.
|
||
|
||
422 ERR_NOMOTD
|
||
":MOTD File is missing"
|
||
|
||
- Server's MOTD file could not be opened by the server.
|
||
|
||
423 ERR_NOADMININFO
|
||
"<server> :No administrative info available"
|
||
|
||
- Returned by a server in response to an ADMIN message
|
||
when there is an error in finding the appropriate
|
||
information.
|
||
|
||
424 ERR_FILEERROR
|
||
":File error doing <file op> on <file>"
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 44]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
- Generic error message used to report a failed file
|
||
operation during the processing of a message.
|
||
|
||
431 ERR_NONICKNAMEGIVEN
|
||
":No nickname given"
|
||
|
||
- Returned when a nickname parameter expected for a
|
||
command and isn't found.
|
||
|
||
432 ERR_ERRONEUSNICKNAME
|
||
"<nick> :Erroneus nickname"
|
||
|
||
- Returned after receiving a NICK message which contains
|
||
characters which do not fall in the defined set. See
|
||
section x.x.x for details on valid nicknames.
|
||
|
||
433 ERR_NICKNAMEINUSE
|
||
"<nick> :Nickname is already in use"
|
||
|
||
- Returned when a NICK message is processed that results
|
||
in an attempt to change to a currently existing
|
||
nickname.
|
||
|
||
436 ERR_NICKCOLLISION
|
||
"<nick> :Nickname collision KILL"
|
||
|
||
- Returned by a server to a client when it detects a
|
||
nickname collision (registered of a NICK that
|
||
already exists by another server).
|
||
|
||
441 ERR_USERNOTINCHANNEL
|
||
"<nick> <channel> :They aren't on that channel"
|
||
|
||
- Returned by the server to indicate that the target
|
||
user of the command is not on the given channel.
|
||
|
||
442 ERR_NOTONCHANNEL
|
||
"<channel> :You're not on that channel"
|
||
|
||
- Returned by the server whenever a client tries to
|
||
perform a channel effecting command for which the
|
||
client isn't a member.
|
||
|
||
443 ERR_USERONCHANNEL
|
||
"<user> <channel> :is already on channel"
|
||
|
||
- Returned when a client tries to invite a user to a
|
||
channel they are already on.
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 45]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
444 ERR_NOLOGIN
|
||
"<user> :User not logged in"
|
||
|
||
- Returned by the summon after a SUMMON command for a
|
||
user was unable to be performed since they were not
|
||
logged in.
|
||
|
||
445 ERR_SUMMONDISABLED
|
||
":SUMMON has been disabled"
|
||
|
||
- Returned as a response to the SUMMON command. Must be
|
||
returned by any server which does not implement it.
|
||
|
||
446 ERR_USERSDISABLED
|
||
":USERS has been disabled"
|
||
|
||
- Returned as a response to the USERS command. Must be
|
||
returned by any server which does not implement it.
|
||
|
||
451 ERR_NOTREGISTERED
|
||
":You have not registered"
|
||
|
||
- Returned by the server to indicate that the client
|
||
must be registered before the server will allow it
|
||
to be parsed in detail.
|
||
|
||
461 ERR_NEEDMOREPARAMS
|
||
"<command> :Not enough parameters"
|
||
|
||
- Returned by the server by numerous commands to
|
||
indicate to the client that it didn't supply enough
|
||
parameters.
|
||
|
||
462 ERR_ALREADYREGISTRED
|
||
":You may not reregister"
|
||
|
||
- Returned by the server to any link which tries to
|
||
change part of the registered details (such as
|
||
password or user details from second USER message).
|
||
|
||
|
||
463 ERR_NOPERMFORHOST
|
||
":Your host isn't among the privileged"
|
||
|
||
- Returned to a client which attempts to register with
|
||
a server which does not been setup to allow
|
||
connections from the host the attempted connection
|
||
is tried.
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 46]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
464 ERR_PASSWDMISMATCH
|
||
":Password incorrect"
|
||
|
||
- Returned to indicate a failed attempt at registering
|
||
a connection for which a password was required and
|
||
was either not given or incorrect.
|
||
|
||
465 ERR_YOUREBANNEDCREEP
|
||
":You are banned from this server"
|
||
|
||
- Returned after an attempt to connect and register
|
||
yourself with a server which has been setup to
|
||
explicitly deny connections to you.
|
||
|
||
467 ERR_KEYSET
|
||
"<channel> :Channel key already set"
|
||
471 ERR_CHANNELISFULL
|
||
"<channel> :Cannot join channel (+l)"
|
||
472 ERR_UNKNOWNMODE
|
||
"<char> :is unknown mode char to me"
|
||
473 ERR_INVITEONLYCHAN
|
||
"<channel> :Cannot join channel (+i)"
|
||
474 ERR_BANNEDFROMCHAN
|
||
"<channel> :Cannot join channel (+b)"
|
||
475 ERR_BADCHANNELKEY
|
||
"<channel> :Cannot join channel (+k)"
|
||
481 ERR_NOPRIVILEGES
|
||
":Permission Denied- You're not an IRC operator"
|
||
|
||
- Any command requiring operator privileges to operate
|
||
must return this error to indicate the attempt was
|
||
unsuccessful.
|
||
|
||
482 ERR_CHANOPRIVSNEEDED
|
||
"<channel> :You're not channel operator"
|
||
|
||
- Any command requiring 'chanop' privileges (such as
|
||
MODE messages) must return this error if the client
|
||
making the attempt is not a chanop on the specified
|
||
channel.
|
||
|
||
483 ERR_CANTKILLSERVER
|
||
":You cant kill a server!"
|
||
|
||
- Any attempts to use the KILL command on a server
|
||
are to be refused and this error returned directly
|
||
to the client.
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 47]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
491 ERR_NOOPERHOST
|
||
":No O-lines for your host"
|
||
|
||
- If a client sends an OPER message and the server has
|
||
not been configured to allow connections from the
|
||
client's host as an operator, this error must be
|
||
returned.
|
||
|
||
501 ERR_UMODEUNKNOWNFLAG
|
||
":Unknown MODE flag"
|
||
|
||
- Returned by the server to indicate that a MODE
|
||
message was sent with a nickname parameter and that
|
||
the a mode flag sent was not recognized.
|
||
|
||
502 ERR_USERSDONTMATCH
|
||
":Cant change mode for other users"
|
||
|
||
- Error sent to any user trying to view or change the
|
||
user mode for a user other than themselves.
|
||
|
||
6.2 Command responses.
|
||
|
||
300 RPL_NONE
|
||
Dummy reply number. Not used.
|
||
|
||
302 RPL_USERHOST
|
||
":[<reply>{<space><reply>}]"
|
||
|
||
- Reply format used by USERHOST to list replies to
|
||
the query list. The reply string is composed as
|
||
follows:
|
||
|
||
<reply> ::= <nick>['*'] '=' <'+'|'-'><hostname>
|
||
|
||
The '*' indicates whether the client has registered
|
||
as an Operator. The '-' or '+' characters represent
|
||
whether the client has set an AWAY message or not
|
||
respectively.
|
||
|
||
303 RPL_ISON
|
||
":[<nick> {<space><nick>}]"
|
||
|
||
- Reply format used by ISON to list replies to the
|
||
query list.
|
||
|
||
301 RPL_AWAY
|
||
"<nick> :<away message>"
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 48]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
305 RPL_UNAWAY
|
||
":You are no longer marked as being away"
|
||
306 RPL_NOWAWAY
|
||
":You have been marked as being away"
|
||
|
||
- These replies are used with the AWAY command (if
|
||
allowed). RPL_AWAY is sent to any client sending a
|
||
PRIVMSG to a client which is away. RPL_AWAY is only
|
||
sent by the server to which the client is connected.
|
||
Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the
|
||
client removes and sets an AWAY message.
|
||
|
||
311 RPL_WHOISUSER
|
||
"<nick> <user> <host> * :<real name>"
|
||
312 RPL_WHOISSERVER
|
||
"<nick> <server> :<server info>"
|
||
313 RPL_WHOISOPERATOR
|
||
"<nick> :is an IRC operator"
|
||
317 RPL_WHOISIDLE
|
||
"<nick> <integer> :seconds idle"
|
||
318 RPL_ENDOFWHOIS
|
||
"<nick> :End of /WHOIS list"
|
||
319 RPL_WHOISCHANNELS
|
||
"<nick> :{[@|+]<channel><space>}"
|
||
|
||
- Replies 311 - 313, 317 - 319 are all replies
|
||
generated in response to a WHOIS message. Given that
|
||
there are enough parameters present, the answering
|
||
server must either formulate a reply out of the above
|
||
numerics (if the query nick is found) or return an
|
||
error reply. The '*' in RPL_WHOISUSER is there as
|
||
the literal character and not as a wild card. For
|
||
each reply set, only RPL_WHOISCHANNELS may appear
|
||
more than once (for long lists of channel names).
|
||
The '@' and '+' characters next to the channel name
|
||
indicate whether a client is a channel operator or
|
||
has been granted permission to speak on a moderated
|
||
channel. The RPL_ENDOFWHOIS reply is used to mark
|
||
the end of processing a WHOIS message.
|
||
|
||
314 RPL_WHOWASUSER
|
||
"<nick> <user> <host> * :<real name>"
|
||
369 RPL_ENDOFWHOWAS
|
||
"<nick> :End of WHOWAS"
|
||
|
||
- When replying to a WHOWAS message, a server must use
|
||
the replies RPL_WHOWASUSER, RPL_WHOISSERVER or
|
||
ERR_WASNOSUCHNICK for each nickname in the presented
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 49]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
list. At the end of all reply batches, there must
|
||
be RPL_ENDOFWHOWAS (even if there was only one reply
|
||
and it was an error).
|
||
|
||
321 RPL_LISTSTART
|
||
"Channel :Users Name"
|
||
322 RPL_LIST
|
||
"<channel> <# visible> :<topic>"
|
||
323 RPL_LISTEND
|
||
":End of /LIST"
|
||
|
||
- Replies RPL_LISTSTART, RPL_LIST, RPL_LISTEND mark
|
||
the start, actual replies with data and end of the
|
||
server's response to a LIST command. If there are
|
||
no channels available to return, only the start
|
||
and end reply must be sent.
|
||
|
||
324 RPL_CHANNELMODEIS
|
||
"<channel> <mode> <mode params>"
|
||
|
||
331 RPL_NOTOPIC
|
||
"<channel> :No topic is set"
|
||
332 RPL_TOPIC
|
||
"<channel> :<topic>"
|
||
|
||
- When sending a TOPIC message to determine the
|
||
channel topic, one of two replies is sent. If
|
||
the topic is set, RPL_TOPIC is sent back else
|
||
RPL_NOTOPIC.
|
||
|
||
341 RPL_INVITING
|
||
"<channel> <nick>"
|
||
|
||
- Returned by the server to indicate that the
|
||
attempted INVITE message was successful and is
|
||
being passed onto the end client.
|
||
|
||
342 RPL_SUMMONING
|
||
"<user> :Summoning user to IRC"
|
||
|
||
- Returned by a server answering a SUMMON message to
|
||
indicate that it is summoning that user.
|
||
|
||
351 RPL_VERSION
|
||
"<version>.<debuglevel> <server> :<comments>"
|
||
|
||
- Reply by the server showing its version details.
|
||
The <version> is the version of the software being
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 50]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
used (including any patchlevel revisions) and the
|
||
<debuglevel> is used to indicate if the server is
|
||
running in "debug mode".
|
||
|
||
The "comments" field may contain any comments about
|
||
the version or further version details.
|
||
|
||
352 RPL_WHOREPLY
|
||
"<channel> <user> <host> <server> <nick> \
|
||
<H|G>[*][@|+] :<hopcount> <real name>"
|
||
315 RPL_ENDOFWHO
|
||
"<name> :End of /WHO list"
|
||
|
||
- The RPL_WHOREPLY and RPL_ENDOFWHO pair are used
|
||
to answer a WHO message. The RPL_WHOREPLY is only
|
||
sent if there is an appropriate match to the WHO
|
||
query. If there is a list of parameters supplied
|
||
with a WHO message, a RPL_ENDOFWHO must be sent
|
||
after processing each list item with <name> being
|
||
the item.
|
||
|
||
353 RPL_NAMREPLY
|
||
"<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]"
|
||
366 RPL_ENDOFNAMES
|
||
"<channel> :End of /NAMES list"
|
||
|
||
- To reply to a NAMES message, a reply pair consisting
|
||
of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the
|
||
server back to the client. If there is no channel
|
||
found as in the query, then only RPL_ENDOFNAMES is
|
||
returned. The exception to this is when a NAMES
|
||
message is sent with no parameters and all visible
|
||
channels and contents are sent back in a series of
|
||
RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
|
||
the end.
|
||
|
||
364 RPL_LINKS
|
||
"<mask> <server> :<hopcount> <server info>"
|
||
365 RPL_ENDOFLINKS
|
||
"<mask> :End of /LINKS list"
|
||
|
||
- In replying to the LINKS message, a server must send
|
||
replies back using the RPL_LINKS numeric and mark the
|
||
end of the list using an RPL_ENDOFLINKS reply.
|
||
|
||
367 RPL_BANLIST
|
||
"<channel> <banid>"
|
||
368 RPL_ENDOFBANLIST
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 51]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
"<channel> :End of channel ban list"
|
||
|
||
- When listing the active 'bans' for a given channel,
|
||
a server is required to send the list back using the
|
||
RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate
|
||
RPL_BANLIST is sent for each active banid. After the
|
||
banids have been listed (or if none present) a
|
||
RPL_ENDOFBANLIST must be sent.
|
||
|
||
371 RPL_INFO
|
||
":<string>"
|
||
374 RPL_ENDOFINFO
|
||
":End of /INFO list"
|
||
|
||
- A server responding to an INFO message is required to
|
||
send all its 'info' in a series of RPL_INFO messages
|
||
with a RPL_ENDOFINFO reply to indicate the end of the
|
||
replies.
|
||
|
||
375 RPL_MOTDSTART
|
||
":- <server> Message of the day - "
|
||
372 RPL_MOTD
|
||
":- <text>"
|
||
376 RPL_ENDOFMOTD
|
||
":End of /MOTD command"
|
||
|
||
- When responding to the MOTD message and the MOTD file
|
||
is found, the file is displayed line by line, with
|
||
each line no longer than 80 characters, using
|
||
RPL_MOTD format replies. These should be surrounded
|
||
by a RPL_MOTDSTART (before the RPL_MOTDs) and an
|
||
RPL_ENDOFMOTD (after).
|
||
|
||
381 RPL_YOUREOPER
|
||
":You are now an IRC operator"
|
||
|
||
- RPL_YOUREOPER is sent back to a client which has
|
||
just successfully issued an OPER message and gained
|
||
operator status.
|
||
|
||
382 RPL_REHASHING
|
||
"<config file> :Rehashing"
|
||
|
||
- If the REHASH option is used and an operator sends
|
||
a REHASH message, an RPL_REHASHING is sent back to
|
||
the operator.
|
||
|
||
391 RPL_TIME
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 52]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
"<server> :<string showing server's local time>"
|
||
|
||
- When replying to the TIME message, a server must send
|
||
the reply using the RPL_TIME format above. The string
|
||
showing the time need only contain the correct day and
|
||
time there. There is no further requirement for the
|
||
time string.
|
||
|
||
392 RPL_USERSSTART
|
||
":UserID Terminal Host"
|
||
393 RPL_USERS
|
||
":%-8s %-9s %-8s"
|
||
394 RPL_ENDOFUSERS
|
||
":End of users"
|
||
395 RPL_NOUSERS
|
||
":Nobody logged in"
|
||
|
||
- If the USERS message is handled by a server, the
|
||
replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and
|
||
RPL_NOUSERS are used. RPL_USERSSTART must be sent
|
||
first, following by either a sequence of RPL_USERS
|
||
or a single RPL_NOUSER. Following this is
|
||
RPL_ENDOFUSERS.
|
||
|
||
200 RPL_TRACELINK
|
||
"Link <version & debug level> <destination> \
|
||
<next server>"
|
||
201 RPL_TRACECONNECTING
|
||
"Try. <class> <server>"
|
||
202 RPL_TRACEHANDSHAKE
|
||
"H.S. <class> <server>"
|
||
203 RPL_TRACEUNKNOWN
|
||
"???? <class> [<client IP address in dot form>]"
|
||
204 RPL_TRACEOPERATOR
|
||
"Oper <class> <nick>"
|
||
205 RPL_TRACEUSER
|
||
"User <class> <nick>"
|
||
206 RPL_TRACESERVER
|
||
"Serv <class> <int>S <int>C <server> \
|
||
<nick!user|*!*>@<host|server>"
|
||
208 RPL_TRACENEWTYPE
|
||
"<newtype> 0 <client name>"
|
||
261 RPL_TRACELOG
|
||
"File <logfile> <debug level>"
|
||
|
||
- The RPL_TRACE* are all returned by the server in
|
||
response to the TRACE message. How many are
|
||
returned is dependent on the the TRACE message and
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 53]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
whether it was sent by an operator or not. There
|
||
is no predefined order for which occurs first.
|
||
Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and
|
||
RPL_TRACEHANDSHAKE are all used for connections
|
||
which have not been fully established and are either
|
||
unknown, still attempting to connect or in the
|
||
process of completing the 'server handshake'.
|
||
RPL_TRACELINK is sent by any server which handles
|
||
a TRACE message and has to pass it on to another
|
||
server. The list of RPL_TRACELINKs sent in
|
||
response to a TRACE command traversing the IRC
|
||
network should reflect the actual connectivity of
|
||
the servers themselves along that path.
|
||
RPL_TRACENEWTYPE is to be used for any connection
|
||
which does not fit in the other categories but is
|
||
being displayed anyway.
|
||
|
||
211 RPL_STATSLINKINFO
|
||
"<linkname> <sendq> <sent messages> \
|
||
<sent bytes> <received messages> \
|
||
<received bytes> <time open>"
|
||
212 RPL_STATSCOMMANDS
|
||
"<command> <count>"
|
||
213 RPL_STATSCLINE
|
||
"C <host> * <name> <port> <class>"
|
||
214 RPL_STATSNLINE
|
||
"N <host> * <name> <port> <class>"
|
||
215 RPL_STATSILINE
|
||
"I <host> * <host> <port> <class>"
|
||
216 RPL_STATSKLINE
|
||
"K <host> * <username> <port> <class>"
|
||
218 RPL_STATSYLINE
|
||
"Y <class> <ping frequency> <connect \
|
||
frequency> <max sendq>"
|
||
219 RPL_ENDOFSTATS
|
||
"<stats letter> :End of /STATS report"
|
||
241 RPL_STATSLLINE
|
||
"L <hostmask> * <servername> <maxdepth>"
|
||
242 RPL_STATSUPTIME
|
||
":Server Up %d days %d:%02d:%02d"
|
||
243 RPL_STATSOLINE
|
||
"O <hostmask> * <name>"
|
||
244 RPL_STATSHLINE
|
||
"H <hostmask> * <servername>"
|
||
|
||
221 RPL_UMODEIS
|
||
"<user mode string>"
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 54]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
- To answer a query about a client's own mode,
|
||
RPL_UMODEIS is sent back.
|
||
|
||
251 RPL_LUSERCLIENT
|
||
":There are <integer> users and <integer> \
|
||
invisible on <integer> servers"
|
||
252 RPL_LUSEROP
|
||
"<integer> :operator(s) online"
|
||
253 RPL_LUSERUNKNOWN
|
||
"<integer> :unknown connection(s)"
|
||
254 RPL_LUSERCHANNELS
|
||
"<integer> :channels formed"
|
||
255 RPL_LUSERME
|
||
":I have <integer> clients and <integer> \
|
||
servers"
|
||
|
||
- In processing an LUSERS message, the server
|
||
sends a set of replies from RPL_LUSERCLIENT,
|
||
RPL_LUSEROP, RPL_USERUNKNOWN,
|
||
RPL_LUSERCHANNELS and RPL_LUSERME. When
|
||
replying, a server must send back
|
||
RPL_LUSERCLIENT and RPL_LUSERME. The other
|
||
replies are only sent back if a non-zero count
|
||
is found for them.
|
||
|
||
256 RPL_ADMINME
|
||
"<server> :Administrative info"
|
||
257 RPL_ADMINLOC1
|
||
":<admin info>"
|
||
258 RPL_ADMINLOC2
|
||
":<admin info>"
|
||
259 RPL_ADMINEMAIL
|
||
":<admin info>"
|
||
|
||
- When replying to an ADMIN message, a server
|
||
is expected to use replies RLP_ADMINME
|
||
through to RPL_ADMINEMAIL and provide a text
|
||
message with each. For RPL_ADMINLOC1 a
|
||
description of what city, state and country
|
||
the server is in is expected, followed by
|
||
details of the university and department
|
||
(RPL_ADMINLOC2) and finally the administrative
|
||
contact for the server (an email address here
|
||
is required) in RPL_ADMINEMAIL.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 55]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
6.3 Reserved numerics.
|
||
|
||
These numerics are not described above since they fall into one of
|
||
the following categories:
|
||
|
||
1. no longer in use;
|
||
|
||
2. reserved for future planned use;
|
||
|
||
3. in current use but are part of a non-generic 'feature' of
|
||
the current IRC server.
|
||
|
||
209 RPL_TRACECLASS 217 RPL_STATSQLINE
|
||
231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES
|
||
233 RPL_SERVICE 234 RPL_SERVLIST
|
||
235 RPL_SERVLISTEND
|
||
316 RPL_WHOISCHANOP 361 RPL_KILLDONE
|
||
362 RPL_CLOSING 363 RPL_CLOSEEND
|
||
373 RPL_INFOSTART 384 RPL_MYPORTIS
|
||
466 ERR_YOUWILLBEBANNED 476 ERR_BADCHANMASK
|
||
492 ERR_NOSERVICEHOST
|
||
|
||
7. Client and server authentication
|
||
|
||
Clients and servers are both subject to the same level of
|
||
authentication. For both, an IP number to hostname lookup (and
|
||
reverse check on this) is performed for all connections made to the
|
||
server. Both connections are then subject to a password check (if
|
||
there is a password set for that connection). These checks are
|
||
possible on all connections although the password check is only
|
||
commonly used with servers.
|
||
|
||
An additional check that is becoming of more and more common is that
|
||
of the username responsible for making the connection. Finding the
|
||
username of the other end of the connection typically involves
|
||
connecting to an authentication server such as IDENT as described in
|
||
RFC 1413.
|
||
|
||
Given that without passwords it is not easy to reliably determine who
|
||
is on the other end of a network connection, use of passwords is
|
||
strongly recommended on inter-server connections in addition to any
|
||
other measures such as using an ident server.
|
||
|
||
8. Current implementations
|
||
|
||
The only current implementation of this protocol is the IRC server,
|
||
version 2.8. Earlier versions may implement some or all of the
|
||
commands described by this document with NOTICE messages replacing
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 56]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
many of the numeric replies. Unfortunately, due to backward
|
||
compatibility requirements, the implementation of some parts of this
|
||
document varies with what is laid out. On notable difference is:
|
||
|
||
* recognition that any LF or CR anywhere in a message marks the
|
||
end of that message (instead of requiring CR-LF);
|
||
|
||
The rest of this section deals with issues that are mostly of
|
||
importance to those who wish to implement a server but some parts
|
||
also apply directly to clients as well.
|
||
|
||
8.1 Network protocol: TCP - why it is best used here.
|
||
|
||
IRC has been implemented on top of TCP since TCP supplies a reliable
|
||
network protocol which is well suited to this scale of conferencing.
|
||
The use of multicast IP is an alternative, but it is not widely
|
||
available or supported at the present time.
|
||
|
||
8.1.1 Support of Unix sockets
|
||
|
||
Given that Unix domain sockets allow listen/connect operations, the
|
||
current implementation can be configured to listen and accept both
|
||
client and server connections on a Unix domain socket. These are
|
||
recognized as sockets where the hostname starts with a '/'.
|
||
|
||
When providing any information about the connections on a Unix domain
|
||
socket, the server is required to supplant the actual hostname in
|
||
place of the pathname unless the actual socket name is being asked
|
||
for.
|
||
|
||
8.2 Command Parsing
|
||
|
||
To provide useful 'non-buffered' network IO for clients and servers,
|
||
each connection is given its own private 'input buffer' in which the
|
||
results of the most recent read and parsing are kept. A buffer size
|
||
of 512 bytes is used so as to hold 1 full message, although, this
|
||
will usually hold several commands. The private buffer is parsed
|
||
after every read operation for valid messages. When dealing with
|
||
multiple messages from one client in the buffer, care should be taken
|
||
in case one happens to cause the client to be 'removed'.
|
||
|
||
8.3 Message delivery
|
||
|
||
It is common to find network links saturated or hosts to which you
|
||
are sending data unable to send data. Although Unix typically
|
||
handles this through the TCP window and internal buffers, the server
|
||
often has large amounts of data to send (especially when a new
|
||
server-server link forms) and the small buffers provided in the
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 57]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
kernel are not enough for the outgoing queue. To alleviate this
|
||
problem, a "send queue" is used as a FIFO queue for data to be sent.
|
||
A typical "send queue" may grow to 200 Kbytes on a large IRC network
|
||
with a slow network connection when a new server connects.
|
||
|
||
When polling its connections, a server will first read and parse all
|
||
incoming data, queuing any data to be sent out. When all available
|
||
input is processed, the queued data is sent. This reduces the number
|
||
of write() system calls and helps TCP make bigger packets.
|
||
|
||
8.4 Connection 'Liveness'
|
||
|
||
To detect when a connection has died or become unresponsive, the
|
||
server must ping each of its connections that it doesn't get a
|
||
response from in a given amount of time.
|
||
|
||
If a connection doesn't respond in time, its connection is closed
|
||
using the appropriate procedures. A connection is also dropped if
|
||
its sendq grows beyond the maximum allowed, because it is better to
|
||
close a slow connection than have a server process block.
|
||
|
||
8.5 Establishing a server to client connection
|
||
|
||
Upon connecting to an IRC server, a client is sent the MOTD (if
|
||
present) as well as the current user/server count (as per the LUSER
|
||
command). The server is also required to give an unambiguous message
|
||
to the client which states its name and version as well as any other
|
||
introductory messages which may be deemed appropriate.
|
||
|
||
After dealing with this, the server must then send out the new user's
|
||
nickname and other information as supplied by itself (USER command)
|
||
and as the server could discover (from DNS/authentication servers).
|
||
The server must send this information out with NICK first followed by
|
||
USER.
|
||
|
||
8.6 Establishing a server-server connection.
|
||
|
||
The process of establishing of a server-to-server connection is
|
||
fraught with danger since there are many possible areas where
|
||
problems can occur - the least of which are race conditions.
|
||
|
||
After a server has received a connection following by a PASS/SERVER
|
||
pair which were recognised as being valid, the server should then
|
||
reply with its own PASS/SERVER information for that connection as
|
||
well as all of the other state information it knows about as
|
||
described below.
|
||
|
||
When the initiating server receives a PASS/SERVER pair, it too then
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 58]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
checks that the server responding is authenticated properly before
|
||
accepting the connection to be that server.
|
||
|
||
8.6.1 Server exchange of state information when connecting
|
||
|
||
The order of state information being exchanged between servers is
|
||
essential. The required order is as follows:
|
||
|
||
* all known other servers;
|
||
|
||
* all known user information;
|
||
|
||
* all known channel information.
|
||
|
||
Information regarding servers is sent via extra SERVER messages, user
|
||
information with NICK/USER/MODE/JOIN messages and channels with MODE
|
||
messages.
|
||
|
||
NOTE: channel topics are *NOT* exchanged here because the TOPIC
|
||
command overwrites any old topic information, so at best, the two
|
||
sides of the connection would exchange topics.
|
||
|
||
By passing the state information about servers first, any collisions
|
||
with servers that already exist occur before nickname collisions due
|
||
to a second server introducing a particular nickname. Due to the IRC
|
||
network only being able to exist as an acyclic graph, it may be
|
||
possible that the network has already reconnected in another
|
||
location, the place where the collision occurs indicating where the
|
||
net needs to split.
|
||
|
||
8.7 Terminating server-client connections
|
||
|
||
When a client connection closes, a QUIT message is generated on
|
||
behalf of the client by the server to which the client connected. No
|
||
other message is to be generated or used.
|
||
|
||
8.8 Terminating server-server connections
|
||
|
||
If a server-server connection is closed, either via a remotely
|
||
generated SQUIT or 'natural' causes, the rest of the connected IRC
|
||
network must have its information updated with by the server which
|
||
detected the closure. The server then sends a list of SQUITs (one
|
||
for each server behind that connection) and a list of QUITs (again,
|
||
one for each client behind that connection).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 59]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
8.9 Tracking nickname changes
|
||
|
||
All IRC servers are required to keep a history of recent nickname
|
||
changes. This is required to allow the server to have a chance of
|
||
keeping in touch of things when nick-change race conditions occur
|
||
with commands which manipulate them. Commands which must trace nick
|
||
changes are:
|
||
|
||
* KILL (the nick being killed)
|
||
|
||
* MODE (+/- o,v)
|
||
|
||
* KICK (the nick being kicked)
|
||
|
||
No other commands are to have nick changes checked for.
|
||
|
||
In the above cases, the server is required to first check for the
|
||
existence of the nickname, then check its history to see who that
|
||
nick currently belongs to (if anyone!). This reduces the chances of
|
||
race conditions but they can still occur with the server ending up
|
||
affecting the wrong client. When performing a change trace for an
|
||
above command it is recommended that a time range be given and
|
||
entries which are too old ignored.
|
||
|
||
For a reasonable history, a server should be able to keep previous
|
||
nickname for every client it knows about if they all decided to
|
||
change. This size is limited by other factors (such as memory, etc).
|
||
|
||
8.10 Flood control of clients
|
||
|
||
With a large network of interconnected IRC servers, it is quite easy
|
||
for any single client attached to the network to supply a continuous
|
||
stream of messages that result in not only flooding the network, but
|
||
also degrading the level of service provided to others. Rather than
|
||
require every 'victim' to be provide their own protection, flood
|
||
protection was written into the server and is applied to all clients
|
||
except services. The current algorithm is as follows:
|
||
|
||
* check to see if client's `message timer' is less than
|
||
current time (set to be equal if it is);
|
||
|
||
* read any data present from the client;
|
||
|
||
* while the timer is less than ten seconds ahead of the current
|
||
time, parse any present messages and penalize the client by
|
||
2 seconds for each message;
|
||
|
||
which in essence means that the client may send 1 message every 2
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 60]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
seconds without being adversely affected.
|
||
|
||
8.11 Non-blocking lookups
|
||
|
||
In a real-time environment, it is essential that a server process do
|
||
as little waiting as possible so that all the clients are serviced
|
||
fairly. Obviously this requires non-blocking IO on all network
|
||
read/write operations. For normal server connections, this was not
|
||
difficult, but there are other support operations that may cause the
|
||
server to block (such as disk reads). Where possible, such activity
|
||
should be performed with a short timeout.
|
||
|
||
8.11.1 Hostname (DNS) lookups
|
||
|
||
Using the standard resolver libraries from Berkeley and others has
|
||
meant large delays in some cases where replies have timed out. To
|
||
avoid this, a separate set of DNS routines were written which were
|
||
setup for non-blocking IO operations and then polled from within the
|
||
main server IO loop.
|
||
|
||
8.11.2 Username (Ident) lookups
|
||
|
||
Although there are numerous ident libraries for use and inclusion
|
||
into other programs, these caused problems since they operated in a
|
||
synchronous manner and resulted in frequent delays. Again the
|
||
solution was to write a set of routines which would cooperate with
|
||
the rest of the server and work using non-blocking IO.
|
||
|
||
8.12 Configuration File
|
||
|
||
To provide a flexible way of setting up and running the server, it is
|
||
recommended that a configuration file be used which contains
|
||
instructions to the server on the following:
|
||
|
||
* which hosts to accept client connections from;
|
||
|
||
* which hosts to allow to connect as servers;
|
||
|
||
* which hosts to connect to (both actively and
|
||
passively);
|
||
|
||
* information about where the server is (university,
|
||
city/state, company are examples of this);
|
||
|
||
* who is responsible for the server and an email address
|
||
at which they can be contacted;
|
||
|
||
* hostnames and passwords for clients which wish to be given
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 61]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
access to restricted operator commands.
|
||
|
||
In specifying hostnames, both domain names and use of the 'dot'
|
||
notation (127.0.0.1) should both be accepted. It must be possible to
|
||
specify the password to be used/accepted for all outgoing and
|
||
incoming connections (although the only outgoing connections are
|
||
those to other servers).
|
||
|
||
The above list is the minimum requirement for any server which wishes
|
||
to make a connection with another server. Other items which may be
|
||
of use are:
|
||
|
||
* specifying which servers other server may introduce;
|
||
|
||
* how deep a server branch is allowed to become;
|
||
|
||
* hours during which clients may connect.
|
||
|
||
8.12.1 Allowing clients to connect
|
||
|
||
A server should use some sort of 'access control list' (either in the
|
||
configuration file or elsewhere) that is read at startup and used to
|
||
decide what hosts clients may use to connect to it.
|
||
|
||
Both 'deny' and 'allow' should be implemented to provide the required
|
||
flexibility for host access control.
|
||
|
||
8.12.2 Operators
|
||
|
||
The granting of operator privileges to a disruptive person can have
|
||
dire consequences for the well-being of the IRC net in general due to
|
||
the powers given to them. Thus, the acquisition of such powers
|
||
should not be very easy. The current setup requires two 'passwords'
|
||
to be used although one of them is usually easy guessed. Storage of
|
||
oper passwords in configuration files is preferable to hard coding
|
||
them in and should be stored in a crypted format (ie using crypt(3)
|
||
from Unix) to prevent easy theft.
|
||
|
||
8.12.3 Allowing servers to connect
|
||
|
||
The interconnection of server is not a trivial matter: a bad
|
||
connection can have a large impact on the usefulness of IRC. Thus,
|
||
each server should have a list of servers to which it may connect and
|
||
which servers may connect to it. Under no circumstances should a
|
||
server allow an arbitrary host to connect as a server. In addition
|
||
to which servers may and may not connect, the configuration file
|
||
should also store the password and other characteristics of that
|
||
link.
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 62]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
8.12.4 Administrivia
|
||
|
||
To provide accurate and valid replies to the ADMIN command (see
|
||
section 4.3.7), the server should find the relevant details in the
|
||
configuration.
|
||
|
||
8.13 Channel membership
|
||
|
||
The current server allows any registered local user to join upto 10
|
||
different channels. There is no limit imposed on non-local users so
|
||
that the server remains (reasonably) consistant with all others on a
|
||
channel membership basis
|
||
|
||
9. Current problems
|
||
|
||
There are a number of recognized problems with this protocol, all of
|
||
which hope to be solved sometime in the near future during its
|
||
rewrite. Currently, work is underway to find working solutions to
|
||
these problems.
|
||
|
||
9.1 Scalability
|
||
|
||
It is widely recognized that this protocol does not scale
|
||
sufficiently well when used in a large arena. The main problem comes
|
||
from the requirement that all servers know about all other servers
|
||
and users and that information regarding them be updated as soon as
|
||
it changes. It is also desirable to keep the number of servers low
|
||
so that the path length between any two points is kept minimal and
|
||
the spanning tree as strongly branched as possible.
|
||
|
||
9.2 Labels
|
||
|
||
The current IRC protocol has 3 types of labels: the nickname, the
|
||
channel name and the server name. Each of the three types has its
|
||
own domain and no duplicates are allowed inside that domain.
|
||
Currently, it is possible for users to pick the label for any of the
|
||
three, resulting in collisions. It is widely recognized that this
|
||
needs reworking, with a plan for unique names for channels and nicks
|
||
that don't collide being desirable as well as a solution allowing a
|
||
cyclic tree.
|
||
|
||
9.2.1 Nicknames
|
||
|
||
The idea of the nickname on IRC is very convenient for users to use
|
||
when talking to each other outside of a channel, but there is only a
|
||
finite nickname space and being what they are, its not uncommon for
|
||
several people to want to use the same nick. If a nickname is chosen
|
||
by two people using this protocol, either one will not succeed or
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 63]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
both will removed by use of KILL (4.6.1).
|
||
|
||
9.2.2 Channels
|
||
|
||
The current channel layout requires that all servers know about all
|
||
channels, their inhabitants and properties. Besides not scaling
|
||
well, the issue of privacy is also a concern. A collision of
|
||
channels is treated as an inclusive event (both people who create the
|
||
new channel are considered to be members of it) rather than an
|
||
exclusive one such as used to solve nickname collisions.
|
||
|
||
9.2.3 Servers
|
||
|
||
Although the number of servers is usually small relative to the
|
||
number of users and channels, they two currently required to be known
|
||
globally, either each one separately or hidden behind a mask.
|
||
|
||
9.3 Algorithms
|
||
|
||
In some places within the server code, it has not been possible to
|
||
avoid N^2 algorithms such as checking the channel list of a set
|
||
of clients.
|
||
|
||
In current server versions, there are no database consistency checks,
|
||
each server assumes that a neighbouring server is correct. This
|
||
opens the door to large problems if a connecting server is buggy or
|
||
otherwise tries to introduce contradictions to the existing net.
|
||
|
||
Currently, because of the lack of unique internal and global labels,
|
||
there are a multitude of race conditions that exist. These race
|
||
conditions generally arise from the problem of it taking time for
|
||
messages to traverse and effect the IRC network. Even by changing to
|
||
unique labels, there are problems with channel-related commands being
|
||
disrupted.
|
||
|
||
10. Current support and availability
|
||
|
||
Mailing lists for IRC related discussion:
|
||
Future protocol: ircd-three-request@eff.org
|
||
General discussion: operlist-request@eff.org
|
||
|
||
Software implemenations
|
||
cs.bu.edu:/irc
|
||
nic.funet.fi:/pub/irc
|
||
coombs.anu.edu.au:/pub/irc
|
||
|
||
Newsgroup: alt.irc
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 64]
|
||
|
||
RFC 1459 Internet Relay Chat Protocol May 1993
|
||
|
||
|
||
Security Considerations
|
||
|
||
Security issues are discussed in sections 4.1, 4.1.1, 4.1.3, 5.5, and
|
||
7.
|
||
|
||
12. Authors' Addresses
|
||
|
||
Jarkko Oikarinen
|
||
Tuirantie 17 as 9
|
||
90500 OULU
|
||
FINLAND
|
||
|
||
Email: jto@tolsun.oulu.fi
|
||
|
||
|
||
Darren Reed
|
||
4 Pateman Street
|
||
Watsonia, Victoria 3087
|
||
Australia
|
||
|
||
Email: avalon@coombs.anu.edu.au
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Oikarinen & Reed [Page 65]
|
||
|