RFC1459

From IRC Wiki
Jump to: navigation, search
This article is a work in progress, see the discussion page to see how you can help finish it.

The IRC protocol has been developed on systems using the TCP / IP network, but is not imperative that this is the only way that works.

The IRC is itself a teleconference system (through client-server) model is suitable for operation in many machines in a distributed fashion. A typical configuration includes a single process (the server) forming a central point for clients (or other servers) to connect to it, performing shipments and multiplexing of messages required and other functions.

Servers

The server forms the backbone of IRC, providing a point to which clients may connect to talk with each other, and point for other servers to connect to it, forming a network IRC. The only network configuration allowed for servers IRC is an extended-shaped tree [see Figure 1], where each hub server to make the rest of the network that the server "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]

Customers

A client is anything connecting to a server other than another server. Each client is distinguished from other clients by a only nick of 9 characters in length. See rules grammar protocol to see what can and what can not use a nick. Nick addition, all servers must have the following information about all clients: the real name host from which you connect the client, the user name client on that host, and the server to which the client is connected.

Operators

To maintain a certain order in the IRC network, there is a kind of special customers (operators) that perform general functions network maintenance. Although the "powers" granted to a an operator can be considered "dangerous", they are necessary. The Operators must be able to perform basic network as disconnecting and reconnecting servers to prevent prolonged use of bad network routing. In recognition of this need, protocol discussed here only allows operators to those functions. See sections 4.1.7 (SQUIT) and 4.3.5 (CONNECT).

A more controversial power is the possibility that an operator remove a user from the network by the "strength". For example, Operators are able to close the connection between any client and server. The justification for this is delicate since its abuse is the destructive and annoying. For more details on this action see section 4.6.1 (KILL).

Channels

A channel is a group (by name) of one or more clients receiving messages addressed to that channel. The channel is created implicitly by joining the first customer, and ceases to exist when the last client leaves. While channel exists, any client can go the channel using the name of the channel.

The channel names are strings (beginning with '&' or '#') of up to 200 characters. Apart from the requirement that the first character it is a '&' or '#', the only restriction is that you can not contain blanks () control G (^ G or ASCII 7), or a comma (',', used as separator parameter lists).

There are two types of channels allowed by the protocol. One is a distributed channel which is known to all servers network. These channels are marked with the first character '#'. Another type channel is characterized by being connected to customers only to server on which the channel is located. Are distinguished by their first character is '&'. Above these types, there are ways to varying channel characteristics of the channels. For more details, see section 4.2.3 (MODE command).

To create a new channel or join an existing one, one Users must join (JOIN) channel. If the channel does not exist before join is created and the creator of the channel becomes channel operator. If the channel exists, the request to join it will be accepted or not Depending on the current channel modes. For example, if the channel is invite-only (+ i), you can only join if invited. As part of the protocol, a user can join multiple channels simultaneously, but a limit of 10 channels is recommended as enough for experienced and novice users. See section 8.13 for more information.

If the IRC network is separated because of a breakdown in connection between two servers, the channel on each side is composed of the clients connected to the servers on each side of the rupture. When the connection is remade, reconnect servers They announce another who thinks he's on every channel and modes that channel. If the channel exists in both parties, unions (JOINs) and modes (MODEs) are interpreted in an inclusive manner so that both New connection sides agree on forming customers and channel modes thereof.

Channel Operators

The channel operator (also called "chop" or "chanop") was considered the "owner" of the channel. In recognition of this status, channel operators have certain "powers" who maintain control and allow some order in your channel. As owner the channel, the channel operator does not have to give justifications for their actions, although if their actions are antisocial or abusive, you can be reasonable to ask an IRC operator to intervene, or the sake of users, go and create your own channel.

The commands you can use only channel operators are:

  • KICK - Eject a client channel, so that it can re-enter
  • MODE - Change the channel modes
  • INVITE - Invite a user to a channel
  • TOPIC - Change the topic on a channel mode + t

A channel operator is identified by the symbol "@" (at) that precedes his nickname, when it is associated with a channel (responses the NAMES, WHO and WHOIS) commands.

The specification of the IRC

Discussion

The protocol as described herein is used for both server-server connections as a client-server. There are, however, more restrictions on client connections (which are considered unreliable) which servers connections.

Character Codes

There is no specified character set. The protocol is based on a character set consists of 8 bits, forming a octet. Each message can consist of any number of these bytes; however, some values ​​of these bytes are used to form control codes that act as delimiters messages.

Despite being an 8-bit protocol, the delimiters and words Key are such that the protocol can be used from a terminal USASCII and telnet. Due to IRC Scandinavian origin, the characters {,}, and | it considered "sensitive" by the characters [,] and \, respectively. This is critical to determining the equivalence of two nicks.

Posts

Servers and clients send messages to each other that they can generating a response or not. If the message contains a valid command one of the ways described in later sections, the client You should expect a reply as specified but has why wait forever for that answer; the communication client-server and server-server is essentially asynchronous.

Each IRC message may consist of 3 main parts: prefix (optional), the command and the command parameters (up a total of 15). The prefix, command and parameters must be separated by one (or more) ASCII space white (0x20).

The presence of a prefix is ​​indicated by colons (':', 0x3b), which must be the first character of the message itself. No there should be space between the colon and the message. The prefix is ​​used by servers to indicate the true origin of message. If the prefix does not appear in the message, it is assumed that It comes from the connection from which it was received. Customers do not prefixes should be used when sending messages; if they use a prefix, only valid registered nick is associated with the client. If the source identified by the prefix is ​​not found in the database internal data server or if the source is registered from a link different to that from which the message arrived, the server You must ignore the message silently.

The command must either be a valid IRC command or number 3 digit represented in ASCII text. IRC messages are always lines of characters in a finished pair CR-LF (Carriage Return-Line Feed = Carriage Return-jump Line), and the messages must not exceed 512 characters length, including CR-LF pair. Therefore, there is a maximum of 510 allowed for the command and its parameters characters. There is not provision for continuation message lines. For more implementation details see Section 7.

Message format in 'pseudo' BNF

The protocol messages must be extracted from the contiguous chain octets. The solution is to assign two characters, CR and LF as Message separators. Empty messages are ignored so silent, allowing the use of the CR-LF sequence between messages without problems.

The extracted message is divided into the components <prefix>, <Command> and list of parameters consisting of components <parameter Intermediate> or <final parameter> The BNF representation for this is:

<Message> :: = ['' <code> <SPACE>] <command> <parameter> <crlf>
<Prefix> :: = <server name> | '!' <Nick> [ <User>] ['@' <host>]
<Command> :: = <letter> {<letter>} | <number> <number> <number>
<SPACE> :: = '' {''}
<Parameter> :: = <space> [':' <end parameter> |
                             <Intermediate parameter> <parameter>]

<Intermediate parameter> :: = <any sequence of octets * non-empty *
                             not including SPACE, NUL, CR or LF, the
                             first of which can not be ''>
<Final parameter> :: = <any sequence, possibly * empty * not
                      including NUL, CR or LF>

<Crlf> :: = CR LF

NOTES:

  • 1) <SPACE> is only space characters (0x20). Note especially that the TAB and other characters Control not considered whitespace.
  • 2) After extracting the parameter list, all are equal, whether <intermediate parameter> or <end> parameter. The latter It is just a syntactic trick to allow SPACE a parameter.
  • 3) The reason why CR and LF can not appear in parameter It is an artifact of the message structure. This might change later.
  • 4) The NUL character is not special in message framing and basically you could end up in a parameter, but this cause extra complexities in normal driving chains C. Therefore, NUL is not allowed in messages.
  • 5) The last parameter must be an empty string.
  • 6) The widespread use of the prefix (['!' <User>] ['@' <host>]) not be used in server-server communications and is only oriented client-server messages to provide customers more useful information about who stems from a message without additional requests.

Most protocols specify a semantic messages and Additional syntax for parameters dictated by their position in the parameter list. For example, many commands servers will mean that the first parameter after the command is the list of objectives that can be described as:

   <Target> :: = <a> ["," <target>]
   <a> :: = <channel> | <user> '@' <server name> |
                   <Nick> | <mask>
   <Channel> :: = ('#' | '&') <string>
   <Server name> :: = <host>
   <Host> :: = see RFC 952 [DNS: 4] for details on names
                    Valid host
   <Name> :: = <letter> {<letter> | <number> | <special>}
   <Mask> :: = ('#' | '$') <string>
   <String> :: = <any 8-bit code except
                                SPACE, BELL, NUL, CR, LF and comma (',')>

Other parameter syntax is:

  • <User> :: = <NO-SPACE> {<NO-SPACE>}
  • <Letter> :: = 'a' ... 'z' | 'A' ... 'Z'
  • <Number> :: = '0' ... '9'
  • <Special> :: = '-' | '[' | ']' | '\' | '|' ^ '|' {'|'} '
   <NO-SPACE> :: = <any 8-bit code except SPACE
                      (0x20), NUL (0x00), CR (0x0d) and LF (0x0a)>

Numeric Replies

Most of the messages sent to the server generate a response of some kind. The most common reply is the numeric, used both for error responses to normal. The numerical answer should be sent as a message composed of the prefix of the sender, the 3-digit number, and the objective of the answer. No numerical answers are allowed from a customer; any such message received by the server silently discarded. A numerical answer is like a normal, except that the keyword message is created from 3 numeric digits rather than a string of letters. A list of answers in section 6.

IRC Concepts

This section is devoted to describing the actual concepts They are behind the organization of the IRC protocol and how the current implementations send different kinds of messages.

                          1 - \
                              A D --- 4
                          2 - / \ /
                                B ---- C
                               / \
                              3 E

   Servers: A, B, C, D, E Customers: 1, 2, 3, 4

           [Figure 2. Sample small IRC network]

Communication one-to-one

The one-to-one usually only performed by clients, since most server-server traffic is not the result of servers communicate only with each other. To providing a secure communication between clients is all servers must be able to send a message exactly in one direction through the spanning tree for to reach any client. The way of a message is the most short between any two points of the tree.

The following examples all refer to Figure 2 above. Example 1:
A message between clients 1 and 2 is only seen by server A, which sends it straight to client 2.

Example 2:
A message between clients 1 and 3 is seen by servers A and B. No other server or client can see it.

Example 3:
A message between clients 2 and 4 is seen by servers A, B, C and D and client 4.

One-to-many

The main purpose of IRC is to provide a forum that allows conferencing easily and efficiently. The IRC offers several ways to achieve this, each with its own purpose.

A list

The least efficient form of one-to-many is done through clients that communicate with a "list" of users. The How this is done is almost self-explanatory: the customer gives a list of destinations for a message and the server splits the list and distributes a separate copy of the message to each destination. It is not as efficient as using a group since the destination list is separate message is sent without ensuring that they are not sent duplicate each time.

To a group (channel)

In IRC the channel has an equal role to that of a forum. His existence is dynamic (coming and going as people and out of the channels), and the conversation is sent only those servers that have users in the channel. If there multiple users on a server in the same channel, the message only It is sent once to that server and from there to every customer channel. This is repeated for each client-server combination until the original message sent to each member of the channel.

The following examples refer to Figure 2.

Example 4:
A channel with a client on it. Messages to the channel go to server and nowhere else.

Example 5:
2 clients in a channel. All messages traverse a path as if they were private messages between the two clients outside channel.

Example 6:
Clients 1, 2 and 3 in a channel. All messages are sent to all clients and only those servers that have to traversed if a private message to a single client. If he Client 1 sends a message, go to the client 2 and, via server B Customer 3.

To a host or server mask

To provide IRC operators mechanisms to send many related messages to users, messages are provided to host and server mask. These messages are sent to users whose host or server information match that of the mask. The Messages are sent only to the sites where they are these users, similar to the channels.

One-to-all

The message type one-on-all described as a message issue, sent to all clients or servers or both. In a large network, a single message can result in a lot of traffic through network in an attempt to make it reach all destinations.

For some messages no choice but to send it to all servers for the information handled by each server is reasonably consistent between servers.

Client-to-client

There is no class of message which, from a single message, resulting in that the message is sent to all other clients.

Client-to-server

Most commands that result in a change in the status information (channel members, channel modes, user status, etc) should be sent to all servers, and this distribution can not be changed by the customer.

Server-to-server

While most messages between servers are distributed all "other" servers, this is only necessary for a While affecting message to a user, a channel or a server. Given these are necessary parts of the IRC, nearly all messages originating from a server are sent to all other servers connected.

DETAILS OF MESSAGES

In the following pages are descriptions of each message recognize the IRC server and client. All commands described in this section shall be implemented in any server that follow the protocol.

When ERR_NOSUCHSERVER (Error response is listed, there is the server), it means that the <server> parameter is not found. The server should not send another answer to that command.

The server to which the client connects must parse the message complete, returning the appropriate error. If the server is a fatal error in the analysis of a message, should sent an error message and complete the scan. A fatal error It can be an incorrect command, a destination that is unfamiliar to the server (in this category includes servers, nicks or channels) parameters missing or incorrect privileges.

If a complete set of parameters is presented, each must check that is valid and appropriate responses will be sent to client. If messages using separate lists parameters Comma responses must be sent separately to each.

In the examples below, some messages appear in format full:

: Name COMMAND parameter list

These examples represent a message from "Name" between servers, where it is essential to include the name of the issuer original message so remote servers may send a response through the right path.

Connection Registration

The commands described here are used to register a connection with IRC server whether a user is as if other server plus disconnections.

A 'PASS' (password) command is required to be registered each connection of a client or server, but must precede the server message or the latter of the NICK / USER combination. Are Connections strongly recommends a server have passkey to give a degree of security to connections. The Recommended for registration of a customer order is as follows:

  • Message Password
  • Nick message
  • User Message

Message Password

Command: PASS
Parameters: <password>

The PASS command is used to establish a "key connection". The key can and must be set before any attempt to make the connection. This requires customers to send PASS command before the NICK / USER combination and servers Must send a PASS command before any SERVER command. The key must match one of the C / N lines (for servers) or the I (for customers). You can send multiple PASS commands before registration but only the latter that is sent is checked and no It can be changed once made the record. Numeric Replies: ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED

Example: PASS clavesecretaaquí

Nick message

Command: NICK
Parameters: <nickname> [<contadordesalto>]

NICK message is used to give the user a nickname or change the above. The <contadordesalto> parameter is used only by the servers to indicate how far is the nickname of the server. A local connection has a counter jump 0. If you send a client is ignored.

If a NICK message arrives at a server that already has an identical nick for another client, a collision occurs nick. As a result of this, all references in the nick of the database are removed Server, and a KILL command is executed to remove the nick of the databases of the other servers. If the NICK message that It caused the collision was a nickname change, the original nickname (old) It must also be removed.

If the server receives a idéntifo nick of a customer who is directly connected, you can send a message to ERR_NICKCOLLISION Local customer, ignoring the NICK command and not run any command KILL.

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.

User Message

Command: USER
Parameters: <user name> <hostname> <Server name> <real name>

USER message is used at the beginning of each connection to indicate the user name, host and server and the real name of the new user. It is also used in communication between servers to indicate that a new user gets to the IRC network, as only after receiving the USER and NICK client messages is recorded the user.

Among the nick client servers must precede the message USER. Note that the server host name and usually are ignored by the server when the USER command comes from a client connected directly (for safety reasons), but used in server-to-server communications. This means that a nick should always be sent to a remote server when a new user to the network before sending the USER message.

The <real name> parameter must be the last, because it may contain blanks and must be preceded by a colon (":") to ensure it is recognized as such. Since it is easy for a client to lie about the user name supported solely on the USER message, the use of recommended one "Identity Server". If the host from which a user connects has that enabled server, the user name is the one It provides that server.

Numeric Replies:

ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED

Examples:
USER guest tolmoon tolsun: Ronnie Reagan; The user registers with name User "guest" and real name "Ronnie Reagan".

: USER guest testnick tolmoon tolsun: Ronnie Reagan; Message between servers with the nick that owns the command USER

Message Server

Command: SERVER
Parameters: <server name> <jump counter>

The server message is used to indicate to a server that the other side of the connection is a server. It is also used to send data servers throughout the network. When you connect a new server to the network, you must send information about it to the rest of the network. The <jump counter> is used to give servers internal information on how far away all servers are. With a complete list of servers, it would be possible to build a Full map server tree, but it masks host avoided.

The SERVER message must only be accepted from (a) a connection yet to be registered and that attempts to register as a server or (b) an existing connection to another server, in which case the Message SERVER introduces a new server behind that server.

Most errors that occur on receipt of the command SERVER just a connection termination by the host destination (target server). Error responses are sent usually using the "ERROR" command instead of an answer numerical as the ERROR command has properties that make it useful here.

If a SERVER message is analyzed and attempts to introduce a server which is already known to the target server, the connection to He came the message must be closed (following the procedures Suitable) as a double path to a server is formed and therefore acyclic nature of the IRC tree.

Numeric Replies: ERR_ALREADYREGISTRED

Example: SERVER test.oulu.fi 1: [tolsun.oulu.fi] experimental Server; The new server is test.oulu.fi presents and attempts to register. The name in brackets is the name host carrying test.oulu.fi.

: Tolsun.oulu.fi SERVER csd.bu.edu 5: BU Central Server; Tolsun.oulu.fi server is the link csd.bu.edu top, which is 5 jumps.

Oper

Command: OPER
Parameters: <user> <password>

The OPER command is used to obtain a normal user Operator privileges. The combination <user> and <password> is necessary for operator privileges.

If the client sending the OPER command gives a correct password for the given user, the server informs the rest of the network new operator running a "MODE + O" command for the nick client.

The OPER message is client-server only.

Numeric Replies:
ERR_NEEDMOREPARAMS RPL_YOUREOPER
ERR_NOOPERHOST ERR_PASSWDMISMATCH

Example: OPER foo bar; Try registering as Operator using the username "foo" and the key "bar"

Outgoing Message

Command: QUIT
Parameters: [<message output>]

A client session ends with an outgoing message. The server must close the connection with a client that sends a message on the way out. Take it a <message output>, it will be sent instead the default message, the nickname.

When there netsplits (disconnection of two servers), the message Output consists of the names of the officials involved, separated by a space. The first name is the server that still is connected, the second you disconnected.

If, for any reason, the connection is closed with a client without the client sends the QUIT (eg command: the client dies and there EOF - End Of File - in socket), the server must complete the output message with a message that reflects the nature of the because he has made it happen.

Numeric Replies: None.

Examples: QUIT: I'm going to eat; Message Format

Outgoing Message Server

Command: SQUIT
Parameters: <server> <comment>

The message is needed to treat SQUIT servers disconnected. If a server wants to terminate the connection with other server, you must send a message to another server SQUIT with the another server name as a parameter, which closes its connection with the server off.

This command is available to operators to help keep an IRC network connected in order. Operators also SQUIT can run a command to a remote connection between servers. In this case, the SQUIT be analyzed per server between the operator and the remote server, updating scheme the network held by each server as explained more below.

The <comment> should be indicated by operators running a SQUIT to a remote server (that is, one that is not connected to server on which the operator is located), so that the other Operators know the cause of the trip. The <comment> also the server filled, which may include error messages.

It requires two servers on each side of the connection SQUIT ends send a message (to all its connections with other server), so it should all servers behind that link.

Likewise, QUIT message must be sent to the other networked servers representing all clients behind that link. Furthermore, all members of a channel lost due to the split member should receive a message from QUIT.

If a connection to a server is terminated prematurely (eg falls the server on the other side of the link), the server detects the disconnection must inform the rest of the network that the connection has been closed and fill the comment field with something appropriate.

Numeric Replies:
ERR_NOPRIVILEGES ERR_NOSUCHSERVER

Example: SQUIT tolsun.oulu.fi: Bad Link?; The server link finished tolson.oulu.fi by "Bad Link"
Trillian SQUIT cm22.eng.umd.edu: Server out of control; Server Down message to control Trillian disconnect "cm22.eng.umd.edu" by "Server out of control"

Operations on a channel

This message group refers to the manipulation of canals, properties (channel modes) and their contents (typically clients). To implement them, are inevitable conditions "career" when customers on opposite sides of a network send commands they end up colliding. It also requires the server to maintain a record to verify when a parameter <nickname> is whether it has changed.

Message entry channel (JOIN)

Command: JOIN
Parameters: <channel> {, <channel>} [<password> {<key>}]

The JOIN command is used by the client to start listening a channel specific. Which a client is allowed to enter the channel or not verifies only the server to which the client is connected; the other servers automatically add the user to the channel when They get the message to other servers. The conditions to be meet the customer are:

  • The user must be invited if the channel is set invite only;
  • The <name> / <username> / <hostname> User You should not meet any of the active bans;
  • must be passed the correct password if active on the channel.

This is discussed in more detail under the MODE command (see sevvión 4.2.3 for more information).

Once the user has entered the channel receives announcements all commands his server receives affecting the channel. This It includes MODE, KICK, PART, QUIT and of course PRIVMSG / NOTICE. The JOIN command must be sent to all servers so that each server users know where to find a channel. This allows optimal messaging PRIVMSG / NOTICE channel.

If you get to join the channel, the user "topic" is sent from channel (using RPL_TOPIC) and the list of users who are in the channel (using RPL_NAMREPLY), which must include the user newly I entered.

Numeric Replies:
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
RPL_TOPIC

Examples:
JOIN #foobar; #foobar join the channel.

JOIN & fubar foo; join the channel & foo using as key "fubar".

JOIN # foo, & fubar bar; join the channel using #foo key "fubar" and & bar without key.

JOIN # foo, # fubar bar, foobar; #foo join the channel with the keyword "Fubar" and the key channel #bar "Foobar".

JOIN # foo # bar; join the #foo and #bar channels

: WiZ JOIN #Twilight_zone; JOIN message WiZ

Message channel output (PART)

Command: PART
Parameters: <channel> {, <channel>}

The output causes the deletion of the user list assets of all channels given in the list of parameters.

Numeric Replies:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_NOTONCHANNEL

Examples: PART #twilight_zone; leave the channel "#twilight_zone"

PART # oz-ops, & group5; leave channel "& group5" and "# Oz-ops".

Message modes

Command: MODE

The MODE command is a dual-purpose command in IRC. It allows switch modes to both users and channels. The reason if this choice is that one day nicknames will be obsolete and the equivalent property will be the canal.N. T.: I do not really know what mean here, because if one does not agree with nick ... How did It makes?

When analyzing MODE messages, it is recommended to first analyze the message complete and pass the changes later.

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 they can change the characteristics of the channel. It takes also servers can change the channel modes to be able create channel operators.

The modes available for channels are:

Mode Description
o give / take channel operator privileges
p private channel mode
s secret channel
i only guests canal
t Only channel operators can change the topic
n no messages to channel allowed from customers outside
m moderated channel
l set a limit of users on channel
b put a ban mask to keep users out
v give / remove voice in a moderated channel
k putting key channel

By using the options 'or' and 'b', there is a restriction on a total of 3 by MODE command. This means that any combination of 'o' and 'b' should not exceed 3 in number of parameters.

User modes

Parameters: <name> {[+ | -] | i | w | s | o}

User modes are changes that affect how others view the customer or a "extra" you can get. A MODE command only accepted if both the sender and the nickname given as match parameter.

The available modes are:

Mode Description
i marks the user as an invisible
s marks a user to receive messages server
w user receives wallops (see 5.6) or - operator mode

There may be additional modes available later.

If a user tries to become operator using the "+ o" option, you must ignored. However, there is no restriction on that one "deopee" (with "-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:

Using channel modes:

MODE + im #Finnish; The channel is now #Finnish moderate only for guests

MODE #Finnish + or Kilroy; Da privileges "chanop" Kilroy in #Finnish channel.

MODE #Finnish + v Wiz; It lets talk to WiZ in #Finnish.

MODE #Fins -s; The channel #Fins longer "secret"

MODE # 42 + k Oulu; Set as key channel "oulu"

MODE # eu-opers + l 10; Putting a limit of 10 users in the canal

MODE & oulu + b; List channel ban masks

MODE & oulu + b * @ *!; It prohibits entry to all users

MODE & oulu + b *!*@*.edu; Prohibits entry to any host user mask * .edu

Using user modes:
: MODE WiZ -w; Disables receiving messages WALLOPS to WiZ

Angel MODE Angel + i; Angel message to be invisible

MODE WiZ -o; WiZ "deopeándose" (remove status operator. The reverse should not be permitted users as it would skip the OPER command.

Message topic

Command: TOPIC
Parameters: <channel> [<topic>]

TOPIC message is used to change or view the topic of a channel. The topic for channel <channel> is returned if not specified. If he <topic> parameter is present, the topic will change, if channel modes permit.

Numeric Replies:

ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
RPL_NOTOPIC RPL_TOPIC
ERR_CHANOPRIVSNEEDED

Examples:

: Wiz #test TOPIC: New topic; WiZ The user puts a topic

TOPIC # test: another topic; he puts the topic "another topic" in #test

TOPIC # test; See the topic #test

Message names

Command: NAMES
Parameters: [<channel> {, <channel>}]

With the NAMES command, a user can list all nicknames that they are visible on any channel that they can see. Names channel you can see are those which are not private (+ p) or secret (+ S), or those that are. The <channel> parameter specifies the (those) channel (s) to which we must return the information as possible. No error message if the name of the channel is incorrect.

If a <channel> parameter is specified, a list of all occurs channels and their occupants. At the end of the list are the users who are visible but either not on any channel or a visible channel, and labeled as being in the "channel" '*'.

Numeric Replies:
RPL_NAMREPLY RPL_ENDOFNAMES

Examples:

NAMES # twilight_zone, # 42; list visible users on # 42 and #twilight_zone if you can see the channels NAMES; list all channels and users visible

Message channel list

Command: LIST
Parameters: [<channel> {, <channel>} [<server>]]

LIST message is used to list channels and their topics. Whether gives the <channel> parameter, only the status of that channel is displayed. Private channels are listed (without topical) as channel "Prv" unless unless the client generating the petition is in the channel. Likewise, the secret channels are not listed unless the client 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, and # List #twilight_zone channels 42


message invitation to a channel

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 invite to the channel <Channel>. There is no requirement that the channel to which the user is encouraged exist or be a valid channel. To invite someone to a channel only guest (+ i), the client sends the INVITE should be channel operator on that channel.

Numeric Replies:
ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
ERR_NOTONCHANNEL ERR_USERONCHANNEL
ERR_CHANOPRIVSNEEDED
RPL_INVITING RPL_AWAY

Examples:

Angel INVITE Wiz #Dust; Angel invites WiZ channel #Dust

INVITE Wiz #Twilight_Zone; Command to invite channel WiZ #Twilight_zone

Command temporary suspension

Command: KICK
Parameters: <channel> <user> [<comment>]

The KICK command can be used to remove a user from the list members of a channel. "It kicks him" the channel (forced PART).

Only channel operators can kick another user of a channel. Each server that receives a KICK message checks that it is valid (ie the sender is channel operator) before remove the victim from the channel.

Numeric Replies:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
ERR_NOTONCHANNEL

Examples:

KICK & Melbourne Matthew; Matthew expel & Melbourne

KICK #Finnish John: Speak English; #Finnish Expel John of the comment "Speaking English reason (comment)

: KICK WiZ #Finnish John; KICK message to drive Wiz John #Finnish channel

NOTE: You may extend the parameters of the KICK command of the form: <Channel> {, <channel>} <user> {, <user>} [<comment>]

4.3 Petitions and server commands

The command group server request serves to return information on any server connected to the network. All the servers connected must respond correctly to requests. Any incorrect response (or lack thereof) must considered a down server and must be disconnected or disabled as soon as possible until it is resolved the problem.

In these requests, where a parameter appears as "<server>" normally it means it can be a nickname or a server mask of some sort. For each parameter, only one request is generated and response.

Version 4.3.1 Message

Command: VERSION
Parameters: [<server>]

The VERSION message is used to ask about the program version that the server supports. The optional parameter <server> is used for the version of a server that is not connected customer directly.

Numeric Replies:
ERR_NOSUCHSERVER RPL_VERSION

Examples:
: Wiz VERSION * .se; message from Wiz to check the version a server with mask * .se

4.3.2 Message statistics

Command: STATS
Parameters: [<application> [<server>]]

STATS message is used to obtain statistics on a server specific. If <server> parameter is omitted, only returns the end of the response statistics. The implementation of this command depends largely on the server responds, but the server must be able to provide the information as described by requests specified below (or something similar).

A request can be a single letter that only checks the target server (if the parameter is given <server>, in another case passing through intermediate servers, ignored and unaltered. The types request that follow are those currently implemented and They provide a large portion of the configuration information server. Although it can not be supported in the same way by all versions, all servers should give an answer valid to a request for STATS.

Request types supported are:

FLAG DESCRIPTION
c returns a list of servers that the server can connect or from allowing connections.
h returns a list of servers that are treated as leaves and discussed as hubs (hubs).
i returns a list of hosts from which the server It allows a connecting client.
k returns a list of combinations username / hostname banned from the server.
l returns a list of server connections, showing the duration of each established connection and traffic over that connection in bytes and messages for each address.
m returns a list of commands supported by the server and if the usage count is not zero.
o returns a list of hosts from which clients Operators can be normal (O-lines). and - lines show Y (Class) file server configuration.
u returns a string showing how long the active server.

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 server commands
: Wiz STATS c eff.org; WiZ request information lines C / N eff.org server

4.3.3 Message Server links

Command: LINKS
Parameters: [[<remote server>] <server mask>]

With the LINKS message, a user can list servers knows the server to respond to the request. The list must meet mask, but the mask is not provided, returns the complete list.

If <remote server> plus <mask parameter is given server>, the LINKS command is sent to the first server that has that name (if any), and that server is responding to the petition.

Numeric Replies:
ERR_NOSUCHSERVER
RPL_LINKS RPL_ENDOFLINKS

Examples:
LINKS * .au; list whose name servers contains * .au

: WiZ .bu.edu LINKS * * .edu; LINKS message from the first WiZ server * .edu for a list of * .bu.edu servers

N. T .: the comment of example does not match what it says on the Description of command, I do not know the correct syntax.

4.3.4 Message local time server

     Command: TIME
  Parameters: [<server>]
  The time message is used for local server
  specified. If <server> parameter is given, it will answer the
  collect the command server.
  Numeric Replies:
          ERR_NOSUCHSERVER RPL_TIME
  Examples:
  TIME tolsun.oulu.fi; Ask for time "tolson.oulu.fi"
  Angel TIME * .au; Angel question time on a server
                          "* .au"

4.3.5 Message server-server connection

     Command: CONNECT
  Parameters: <target server> [<port> [<remote server>]]
  The CONNECT command is used to force a server to try
  connect to another server. This is a command
  privileged and is only available to IRC Operators. If you are given
  the <remote server> parameter, the connection is made by that server
  to the <port> specified <target server>.
  Numeric Replies:
          ERR_NOSUCHSERVER ERR_NOPRIVILEGES
          ERR_NEEDMOREPARAMS
  Examples:

CONNECT tols.oulu.fi; Attempt to connect a server to tols.oulu.fi

WiZ CONNECT 6667 eff.org csd.bu.edu
                     ; CONNECT attempt to connect WiZ
                     eff.org csd.bu.edu servers on port 6667





Oikarinen & Reed [Page. 29]

Talk RFC 1459 Protocol Based on Internet in May 1993


4.3.6 Message trace route

     Command: TRACE
  Parameters: [<server>]
  The TRACE command is used to find the route to a server
  specific. Each server that processes this message must tell the
  sender with a response indicating that is a link,
  it forming a chain responses similar to that obtained by
  use "traceroute". After sending the response, you must send the message
  TRACE to the next server until it reaches the server
  specified. If <server> parameter is omitted, it is recommended that
  TRACE command send a message to the requesting mapping
  Saying servers to which the current server is connected
  directly.
  If the destination specified by <server> is a server,
  target server must inform all servers and users
  which they are connected to it, although only operators can see
  users. If <server> is a nickname, it will be just the answer for
  that nickname.
  Numeric Replies:
          ERR_NOSUCHSERVER
  If the TRACE message is destined for another server, all
  intermediate servers must return a response RPL_TRACELINK
  to indicate that the message passed through it and where it was then.
          RPL_TRACELINK
  A response may be composed TRACE any number
  the following numerical answers:
          RPL_TRACECONNECTING RPL_TRACEHANDSHAKE
          RPL_TRACEUNKNOWN RPL_TRACEOPERATOR
          RPL_TRACEUSER RPL_TRACESERVER
          RPL_TRACESERVICE RPL_TRACENEWTYPE
          RPL_TRACECLASS
  Examples:

TRACE * .oulu.fi; TRACE server * .oulu.fi

WiZ TRACE AngelDust; Wiz TRACE nick AngelDust




Oikarinen & Reed [Page. 30]

Talk RFC 1459 Protocol Based on Internet in May 1993


4.3.7 Message Server administrator name

     Command: ADMIN
  Parameters: [<server>]
  ADMIN message is used to get the name Administrator
  given server, or server that is connected if omitted
  the <server> parameter. Each server must be able to forward
  ADMIN messages to other servers.
  Numeric Replies:
          ERR_NOSUCHSERVER
          RPL_ADMINME RPL_ADMINLOC1
          RPL_ADMINLOC2 RPL_ADMINEMAIL
  Examples:
  ADMIN tolsun.oulu.fi; ask for a response ADMIN tolsun.oulu.fi
  : WiZ ADMIN * .edu; ADMIN request from WiZ the first
                          * .edu server.

4.3.8 Message server information

     Command: INFO
  Parameters: [<server>]
  The INFO command is required to obtain information describing the
  server: its version, when compiled, patches applied,
  when it started and other information that may be relevant.
  Numeric Replies:
          ERR_NOSUCHSERVER
          RPL_INFO RPL_ENDOFINFO
  Examples:
  INFO csd.bu.edu; INFO request csd.bu.edu
  : Avalon INFO * .fi; INFO request from Avalon for first
                        * .fi server.
  INFO Angel; our database server that Angel is
                        connected




Oikarinen & Reed [Page. 31]

Talk RFC 1459 Protocol Based on Internet in May 1993


4.4 Sending messages

  The main purpose of the IRC protocol is to provide a basis
  communication between clients. PRIVMSG and NOTICE are the only
  available commands that send text messages from a client to
  other - the rest is just possible and try to ensure that
  It occurs in a reliable and structured manner.

4.4.1 Private Messages

     Command: PRIVMSG
  Parameters: <receiver> {, <receiver>} <text>
  PRIVMSG is used to send private messages between users.
  <Receiver> is the nickname of who should receive the message. can be
  Also a list of nicks or channels separated by commas.
  The <receiver> parameter may also be a host mask
  (#mask) Or server ($ mask). In both cases the server only
  send the PRIVMSG those who have a server or host matching
  with the mask. The mask should contain at least one "." and any
  wildcard after the last ".". This requirement exists to prevent
  send messages to "# *" or "$ *", which would send it to all users;
  experience shows that this is abused more than used so
  responsible and appropriate. Wildcards are the characters "*" and "?".
  This extension of PRIVMSG command is only available for
  IRC operators.
  Respuesas number:
          ERR_NORECIPIENT ERR_NOTEXTTOSEND
          ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
          ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
          ERR_NOSUCHNICK
          RPL_AWAY
  Examples:

Angel PRIVMSG Wiz: Hi do you get this?

                               ; Message from Angel to Wiz.

PRIVMSG Angel: Yes, I get it :); Message to Angel.

PRIVMSG [email protected]: Hello

                            ; Message to a client on the server
                            tolsun.oulu.fi with username "jto"

PRIVMSG $ * fi. Tolsun.oulu.fi Server restarting

                               ; Message to all connected to a
                               * server mask .fi


Oikarinen & Reed [Page. 32]

Talk RFC 1459 Protocol Based on Internet in May 1993



PRIVMSG # * edu. NSFNET is working, disruptions expected

                               ; Message to all users
                               have hostmask * .edu

4.4.2. Warning messages

     Command: NOTICE
  Parameters: <nickname> <text>
  The NOTICE command is used similarly to PRIVMSG. The difference
  between the two it is that you can not send an automatic response to a
  NOTICE. This rule also applies servers (can not
  send error messages in response to a NOTICE). The purpose of
  this rule is to avoid loops between clients send a
  automatic response to something they receive. This is typical of the
  automatons (clients with AI or other interactive program controlling
  their actions) always tend to respond in ways that end up in
  one buble with another automaton.
  See PRIVMSG for more details on replies and examples.

4.5 User Requests

  User requests are related command grupoo
  search for details on a user or group of users
  concrete. When wildcards are used, if any match, only
  it will return information on users who are 'visible' to
  requesting it. The visibility of a user is determined by
  combining user modes and settings
  in which both channels are.

4.5.1 Request for "WHO"

     Command: WHO
  Parameters: [<name> [<o>]]
  The message WHO uses a client to generate a request
  returns a list of information that meets the <name>
  given by the customer. In the absence of the <name> parameter, all
  visible users are listed. The same result is obtained by
  used as <name> "0" or any wildcard meeting any
  possible entry.
  The <name> passed to WHO compared with hosts users,
  servers, real names and nicknames if the channel <name> is not
  find.
  If the <or> parameter is passed only operators are returned whose
  match the supplied mask in <name>.


Oikarinen & Reed [Page. 33]

Talk RFC 1459 Protocol Based on Internet in May 1993


  Numeric Replies:
          ERR_NOSUCHSERVER
          RPL_WHOREPLY RPL_ENDOFWHO
  Examples:
  WHO * .fi; List users with mask "* .fi"
  WHO jto * o; Operators list mask "jto *"

4.5.2 Request for "whois"

     Command: whois
  Parameters: [<server>] <mask nick> [<mask nick> [, ...]]
  This command is used to request information about a user in
  particular. The server will respond to the message with multiple answers
  number indicating various states of each user that meets
  nick mask (if one is able to see them). If no wildcards
  in <mask nick>, any information submitted on that
  nick to be able to see. You can use a separate list of nick
  Comma.
  The latest version sends the request to a specific server. This
  It is useful when you want to know how long it takes inactive
  user, since only the server to which the user is connected
  know this information directly, while the rest
  known globally.
  Numeric Replies:
          ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
          RPL_WHOISUSER RPL_WHOISCHANNELS
          RPL_WHOISCHANNELS RPL_WHOISSERVER
          RPL_AWAY RPL_WHOISOPERATOR
          RPL_WHOISIDLE ERR_NOSUCHNICK
          RPL_ENDOFWHOIS
  Examples:
  WHOIS wiz; return available information WiZ
  WHOIS eff.org trillian; asks the server eff.org information
                         trillian





Oikarinen & Reed [Page. 3. 4]

Talk RFC 1459 Protocol Based on Internet in May 1993


4.5.3 Request for "WHOWAS"

     Command: WHOWAS
  Parameters: <nickname> [<count> [<server>]]
  WHOWAS asks for information about a nickname which no longer exists. This can
  be good for a change of nick or because the user exits the IRC.
  In response, the server looks in its history nick nicks
  match the given (no wildcards). The search is on
  ascending order, returning the most recent entry. If more than
  an entry is returned as much <count> replies (or all
  if no <count>). If a negative number is given to <count> is
  performs a full search.
  Respuesas number:
          ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
          RPL_WHOWASUSER RPL_WHOISSERVER
          RPL_ENDOFWHOWAS
  Examples:
  WHOWAS Wiz, returns all the information in the
                            history nicks on "WiZ"
  WHOWAS Mermaid 9; return as much 9 more entries
                            Recent nick "Mermaid"
  WHOWAS Trillian 1 * .edu; return the latest entry nick
                            "Trillian" from the first server that has
                            mask "* .edu".

4.6 Other messages

  Messages in this category do not fall under any of the others,
  but anyway they are party and protocol requirement.

4.6.1 Message "KILL"

     Command: KILL
  Parameters: <nickname> <comment>
  The KILL command is used to close a client-server connection,
  by the server that holds the servers used conexión.Lo
  when they encounter a duplicate entry in the list of valid nicknames
  and serves to remove both entries. It is also available to
  IRC operators.




Oikarinen & Reed [Page. 35]

Talk RFC 1459 Protocol Based on Internet in May 1993


  This command is useless against customers who have algorithms
  automatic reconnection since the disconnection is brief. However,
  the data stream is broken and can be used to stop "flooding"
  data flow. Any user can choose to receive the
  KILL messages generated for others.
  In an "arena" where nicks must be globally unique throughout the
  time, KILL messages are sent when detected
  "Duplicate" (attempt to register two users with the same nickname)
  They are hoping that both will disappear and reappear just one.
  The commentary should reflect the reason for the KILL. To kills generated
  per server is usually filled with details of the
  origins of the two conflicting nicknames. Users are
  leaves provide adequate reason to satisfy users who
  see. To prevent fake kills to conceal the identity of the
  KILLeador, the comment also shows a "road kill"
  completed by the server through which it passes, each adding their
  name to "path".
  Numeric Replies:
          ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
          ERR_NOSUCHNICK ERR_CANTKILLSERVER


  KILL David (csd.bu.edu <- tolsun.oulu.fi)
                  ; Collision between csd.bu.edu nicks and tolson.oulu.fi


  NOTE:
  It is recommended that only Operators can KILLear other users
  with the KILL command. In an ideal world not even operators
  They need to do and this work is left to the servers.


4.6.2 Message "PING"

     Command: PING
  Parameters: <server1> [<server2>]
  PING message is used to check for a customer
  active across the connection. The server sends a message
  PING at regular intervals if activity is detected a
  connection. If a connection does not respond to a PING command within a
  space of time, the connection is closed.
  Any customer who receives a PING must respond to <server1>
  (Server that sends the message PING) as soon as possible
  with appropriate PONG message to indicate it is active. The
  Servers should not respond to rely PINGs but where


Oikarinen & Reed [Page. 36]

Talk RFC 1459 Protocol Based on Internet in May 1993


  come across the connection to verify that the connection
  She is alive. If specified <server2>, the ping message
  forwarded there.
  Numeric Replies:
          ERR_NOORIGIN ERR_NOSUCHSERVER
  Examples:
  PING tolsun.oulu.fi; server sending a PING message to another
                          to indicate that he is alive.
  WiZ PING, PING message sent to nick WiZ

4.6.3 Message "PONG"

     Command: PONG
  Parameters: <daemon> [<demonio2>]
  PONG message is a response to PING message. If you pass the
  parameter <demonio2>, the message should be forwarded to the devil
  specified. The <daemon> parameter is the name of the demon
  responds 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
                                  tolson.oulu.fi


4.6.4 Error

     Command: ERROR
  Parameters: <error>
  ERROR is used by servers to report bugs command
  serious or fatal to their operators. You can also send a
  server to another, but it should not be accepted from any normal client
  it is unknown.
  An error message only reports errors that occur in a
  server-server link. It is sent to the server on the other side (which
  sends to all connected operators) and to all operators
  connected. Should not send one server to other servers if
  received from a server.


Oikarinen & Reed [Page. 37]

Talk RFC 1459 Protocol Based on Internet in May 1993


  When a server sends an error message that welcomes
  Operators, the message should be included in a NOTICE message,
  indicating that the client was not responsible for the error.
  Numeric Replies:
          None
  Examples:
  ERROR: Server * .fi already exists ERROR message to the server
                                     caused the error
  WiZ NOTICE: ERROR from csd.bu.edu - Server * .fi already exists
                                ; Same as above but sent message
                                the user on the other server WiZ

5. OPTIONAL MESSAGES

  This section describes OPTIONAL messages. They are not formal notice
  an implementation of the protocol described here for a server. In
  absence of this option, you must generate an error message or an
  unknown command error. If the message is destined for another
  server, upgrade (element analysis is required). The
  numerical answers are listed in the following sections.

5.1 Absent Message (AWAY)

     Command: AWAY
  Parameters: [message]
  With the AWAY message, the client can establish a chain of
  PRIVMSG response to any command you to go to him (not a
  channel on which they are). The automatic reply is sent by the
  server to client sending the PRIVMSG. The server responds
  It is that to which the client is connected sender.
  The AWAY message is used either with one parameter (to set up a
  away message) or with no parameters (to remove the message
  absence).
  Numeric Replies:
          RPL_UNAWAY RPL_NOWAWAY
  Examples:
  AWAY: I'll be back in 5 minutes, puts away message "Back in 5 min"
  : WiZ AWAY; removes the message from the absence of WiZ


Oikarinen & Reed [Page. 38]

Talk RFC 1459 Protocol Based on Internet in May 1993


5.2 Command server reconfiguration

     Command: REHASH
  Parameters: None
  REHASH message you can use an operator to force the
  server to re-read and process its configuration file.
  Numeric Replies:
       RPL_REHASHING ERR_NOPRIVILEGES

Examples:

REHASH; message from a client with operator status

                 the server reread its configuration file

5.3 Command server restart

     Command: RESTART
  Parameters: None
  RESTART message can only be used to force an operator
  a server to reboot. This command is optional, as it can
  seen as a risk to allow people to connect to the server
  as operator and run the command, causing (as little) A
  outage.
  The RESTART command must always be processed by the server
  that the client is connected and sends it not happened to others
  servers.
  Numeric Replies:
          ERR_NOPRIVILEGES
  Examples:
  RESTART; no parameters are required

5.4 Message invocation (Summon)

     Command: SUMMON
  Parameters: <user> [<server>]
  The SUMMON command can be used to send a message to users
  connected to a host that has an IRC server to join
  IRC. This message is sent only if: the server (a) objective
  the invocation is enabled, (b) the user is connected, and (c)
  the server can write to the console (or similar) user.


Oikarinen & Reed [Page. 39]

Talk RFC 1459 Protocol Based on Internet in May 1993


  If <server> parameter is not given, it tries to invoke the <user>
  from the server to the client is connected.
  If the invocation is not enabled on a server, you must return the
  ERR_SUMMONDISABLED response and pass the message invocation
  below.
  Numeric Replies:
          ERR_NORECIPIENT ERR_FILEERROR
          ERR_NOLOGIN ERR_NOSUCHSERVER
          RPL_SUMMONING
  Examples:
  SUMMON jto; jto invoke the user on the host
                             IRC server
  SUMMON jto tolsun.oulu.fi; jto invoke the user on the host
                             It has an IRC server named
                             "Tolsun.oulu.fi"


5.5 Message User List

     Command: USERS
  Parameters: [<server>]
  The USERS command returns a list of users connected to
  Similar to server who (1), rusers (1) and finger (1). can
  this command disabled for security reasons. If done,
  It must be returned to the proper numeric response indicate.
  Numeric Replies:
          ERR_NOSUCHSERVER ERR_FILEERROR
          RPL_USERSSTART RPL_USERS
          RPL_NOUSERS RPL_ENDOFUSERS
          ERR_USERSDISABLED
  Reply disabled command:
          ERR_USERSDISABLED
  Examples:

USERS eff.org; request for the list of connected users

                          the server eff.org

John USERS tolsun.oulu.fi; request of John of the user list

                             the server tolsun.oulu.fi


Oikarinen & Reed [Page. 40]

Talk RFC 1459 Protocol Based on Internet in May 1993


5.6 Command message to the operators

     Command: WALLOPS
  Parameters: Message to all connected operators
  Send a message to all IRC operators connected. Behind the
  Wallops implementation as a user command, you saw that
  used to send messages to many people (similar to WALL).
  Because of this, it is recommended that implementation will use Wallops
  as an example by allowing and recognizing only servers
  the ability to send WALLOPS.
  Numeric Replies:
          ERR_NEEDMOREPARAMS
  Examples:
  : Csd.bu.edu WALLOPS: Connection '* .uiuc.edu 6667' Joshua
                             ; Wallops csd.bu.edu announcing a
                             Connect message received from Joshua

5.7 Command USERHOST

     Command: USERHOST
  Parameters: <nickname> {<space> <nickname>}
  The USERHOST command takes a list of up to 5 nicknames, separated by
  spaces and returns a list of information about each. The
  list has each reply separated by a space.
  Numeric Replies:
          RPL_USERHOST ERR_NEEDMOREPARAMS
  Examples:
  USERHOST Wiz Michael Marty p; USERHOST on request nicks
                                 "Wiz", "Michael", "Marty" and "p"

5.8 Command ISON

     Command: ISON
  Parameters: <nickname> {<space> <nickname>}
  The ISON command was implemented to provide a quick and
  efficient to get a response about whether a given nickname was
  IRC. It only takes as a parameter a list of nicks separated
  spaces. The server adds each nick your response string. For
  Therefore, the response string may be empty (none of the nicks
  is the IRC), an exact copy of the parameter string


Oikarinen & Reed [Page. 41]

Talk RFC 1459 Protocol Based on Internet in May 1993


  (All are) or a subset of the set of nicks
  provided. The only restriction on the number of nicks
  It can be checked next is given by the combined length,
  which must not exceed 512 characters.
  ISON should only prosecute the server you are connected
  client sending the command and thus should not be to others
  servers.
  Numeric Replies:
          RPL_ISON ERR_NEEDMOREPARAMS
  Examples:
  ISON phone trillian WiZ jarlek Avalon Angel Monstah
                                  ; Example ISON request 7 nicks


6. Answers

  Below is a list of numeric responses generated in
  response to commands given above. Each answer is given with
  their number, name and reply string.

6.1 Error Replies

       401 ERR_NOSUCHNICK
                      "<Nick>: No such nick / channel"
               - Used to indicate the <nick>
                 It provided a command is not ecuentra
       402 ERR_NOSUCHSERVER
                      "<Server name>: No such server"
               - Indicates that the server whose name is provided not
                 exists
       403 ERR_NOSUCHCHANNEL
                      "<Channel name>: No such channel"
               - Indicates the channel name is invalid
       404 ERR_CANNOTSENDTOCHAN
                      "<Channel name>: Can not send to channel"
               - A user is sent to (a) is not in a channel
               no way has the + (b) is not a channel operator (or
               It has the + v) on a channel mode + m



Oikarinen & Reed [Page. 42]

Talk RFC 1459 Protocol Based on Internet in May 1993


       405 ERR_TOOMANYCHANNELS
                      "<Channel name>: You've entered too many \
                       channels "
               - Sent to a user who has reached number
                 maximum channels you are allowed to be e
                 tries to enter another
       406 ERR_WASNOSUCHNICK
                      "<Nick>: not found nick"
               - Returned by WHOWAS to indicate that there
                 information on the registration of nick
       407 ERR_TOOMANYTARGETS
                      "<Target>. Receivers duplicates Not \
                        sent the message "
               - Returned to a client attempting to send a message
                 using the format user @ host destination when the
                 target has several destinations
       409 ERR_NOORIGIN
                       ": No origin specified"
               - PING or PONG message that has not been indicated
                 origin is required since these commands must
                 work without valid prefixes
       411 ERR_NORECIPIENT
                       "No receiver (<command>) has given"
       412 ERR_NOTEXTTOSEND
                       "There is no text to send"
       413 ERR_NOTOPLEVEL
                       "<Mask>: Not specified domain \
                                   superior "
       414 ERR_WILDTOPLEVEL
                       "<Mask>: Wildcard top domain"
               - 412-414 PRIVMSG returns to indicate that a
                 message was not sent for some reason. ERR_NOTOPLEVEL
                 and returned to try ERR_WILDTOPLEVEL use
                 incorrect "PRIVMSG $ <server>" or "PRIVMSG # <host>"
       421 ERR_UNKNOWNCOMMAND
                       "<Command>: Unknown command"
               - A registered client is returned to indicate that
                 the server does not know the command



Oikarinen & Reed [Page. 43]

Talk RFC 1459 Protocol Based on Internet in May 1993


       422 ERR_NOMOTD
                       "Missing MOTD file"
               - The server could not open the file MOTD (Message Of
                 The Day Message of the Day)
       423 ERR_NOADMININFO
                       "<Server>: No infomation Administrator"
               - Server response to ADMIN command when a
                 Failed to find the information
       424 ERR_FILEERROR
               "Error file <file operation> in <file>"
               - Generic error message to report a
                 file operation failed processing
                 a message
       431 ERR_NONICKNAMEGIVEN
                       "There has been no nick"
               - Returned when there is the <nick>
                 course for a command
       432 ERR_ERRONEUSNICKNAME
                       "<Nick>: Nick incorrect"
               - Returned when a NICK message contains characters
                 that are not included in the assembly definition.
                 See section xxx for details on nicks
                 valid.
       433 ERR_NICKNAMEINUSE
                       "<Nick>: The nickname is already in use"
               - Returned when a NICK command tries to change to a
                 existing nick
       436 ERR_NICKCOLLISION
                       "<Nick>: nick collision KILL"
               - Returned by the server to a client when it detects
                 nick collision (registered of a NICK that already
                 It exists on another server)
       441 ERR_USERNOTINCHANNEL
                       "<Nick> <channel>: They are not in the channel"
               - Indicates that the target of the command is not in the
                 given channel


Oikarinen & Reed [Page. 44]

Talk RFC 1459 Protocol Based on Internet in May 1993


       442 ERR_NOTONCHANNEL
                       "<Channel>: You're not on that channel"
               - It returns the server when a client tries
                 run a command channel that is not a member
       443 ERR_USERONCHANNEL
                       "<User> <channel>: is already on channel"
               - Returned when a client tries to invite a
                 user to a channel that is already


       463 ERR_NOPERMFORHOST
                       "Your host is not among the privileged!"
               - Returned when a client attempts to register a
                 server that does not support connections from the host
                 customer
       444 ERR_NOLOGIN
                       "<User>: User not connected '
               - Returned by the caller after a command
                 SUMMON for a user who is not connected
       445 ERR_SUMMONDISABLED
                       "SUMMON is disabled"
               - Response to the SUMMON command from a server that
                 It is disabled
       446 ERR_USERSDISABLED
                       "USERS disabled"
               - Response to USERS command from a server that does not
                 implements
       451 ERR_NOTREGISTERED
                       "Not yet registered"
               - Indication server that the client should
                 register before being allowed to send
                 commands
       461 ERR_NEEDMOREPARAMS
                       "<Command>: Not enough parameters"
               - Returned by many commands to indicate that the
                 customer did not provide enough parameters


Oikarinen & Reed [Page. 4. 5]

Talk RFC 1459 Protocol Based on Internet in May 1993


       462 ERR_ALREADYREGISTRED
                       "You can not re-register"
               - Returned by the server to a link that tries
                 change of registration details (such as
                 Key details user or a second message
                 USER)
       464 ERR_PASSWDMISMATCH
                       ": Password incorrect"
               - Indicates a failed attempt to register a connection
                 for which key is needed and not provided or
                 It is incorrect
       465 ERR_YOUREBANNEDCREEP
                       "You are banned from this server"
               - Returned after an attempt to connect and register
                 a server configured to deny connections
                 you
       467 ERR_KEYSET
                       "<Channel>: The key channel is laid"
       471 ERR_CHANNELISFULL
                       "<Channel>: Can not join channel (+ l)"
       472 ERR_UNKNOWNMODE
                       "<Character>: the mode is unknown to the server"
       473 ERR_INVITEONLYCHAN
                       "<Channel>: Can not join channel (+ i)"
       474 ERR_BANNEDFROMCHAN
                       "<Channel>: Can not join channel (+ b)"
       475 ERR_BADCHANNELKEY
                       "<Channel>: Can not join channel (+ k)"
       481 ERR_NOPRIVILEGES
                       "Not Permit denegado- IRC Operator"
               - A command requiring operator privileges must
                 return this error to indicate the attempt failed
       482 ERR_CHANOPRIVSNEEDED
                       "<Channel>: is not channel operator"
               - Any command that requires privileges
                 channel operator (such messages MODE)
                 You must return this error if the client runs
                 not channel operator on the given channel
       483 ERR_CANTKILLSERVER
                       "You can not killear a server!"


Oikarinen & Reed [Page. 46]

Talk RFC 1459 Protocol Based on Internet in May 1993


               - Any attempts to use the KILL command with a
                 server must be rejected and returned this error
                 customer
       491 ERR_NOOPERHOST
                       "No O-lines for host"
               - If a client sends an OPER message and the server does not
                 It is configured to allow connections Operator
                 from the client host should be returned this error
       501 ERR_UMODEUNKNOWNFLAG
                       "Unknown mode"
               - Returned by the server to indicate that a message
                 MODE was sent with an unknown mode parameter
       502 ERR_USERSDONTMATCH
                       "You can not change modes other users"
               - Error sent to a user who attempts to view or change
                 a way for a user other than yourself

6.2 Responses to commands

       300 RPL_NONE
                       Number of false answer. Not used
       302 RPL_USERHOST
                       "[<Answer> {<space> <reply>}]"
               - Response format used by USERHOST to list
                 the answers. The answer string consists of
                 as follows:
               <Response> :: = <nick> ['*'] '=' <'+' | '-'> <hostname>
                 The '*' indicates whether the client is registered as
                 Operator. The '-' or '+' account if the customer is
                 or "AWAY", respectively.
       303 RPL_ISON
                       "[<Nickname> {<space> <nickname>}]"
               - Answer format used by ISON to list their
                 reply
       301 RPL_AWAY
                       "<Nick> <message away>"



Oikarinen & Reed [Page. 47]

Talk RFC 1459 Protocol Based on Internet in May 1993


       305 RPL_UNAWAY
                       "No longer is marked as absent"
       306 RPL_NOWAWAY
                       "You are marked as absent"
               - These responses are used with the AWAY command (if
                 On). RPL_AWAY any customer is sent to
                 Give a PRIVMSG another client who is absent.
                 RPL_AWAY only sends the server to which it is
                 connected client that sent the PRIVMSG. The
                 RPL_UNAWAY and responses are sent when RPL_NOWAWAY
                 the client removes and away message.
       311 RPL_WHOISUSER
                       "<Name> <user> <host> * <real name>"
       312 RPL_WHOISSERVER
                       "<Name> <server>: <Server information>"
       313 RPL_WHOISOPERATOR
                       "<Nick>: is IRC Operator"
       317 RPL_WHOISIDLE
                       "<Nick> <integer>: seconds inactive"
       318 RPL_ENDOFWHOIS
                       "<Nick>: End of list / whois"
       319 RPL_WHOISCHANNELS
                       "<Nick>: {[@ | +] <channel> <space>}"
               - The responses 311-313, 317-319 are generated after
                 WHOIS message. Of course there are enough
                 parameters, the server must formulate answers
                 an answer from the above numbers (if
                 is the nickname) or return an error. The '*' in
                 RPL_WHOISUSER is a literal character and not a wildcard.
                 For each set of responses, only
                 RPL_WHOISCHANNELS may appear more than once
                 (Long lists of channels). The characters '@' and '+'
                 next to the channel name indicate whether the customer is
                 channel operator or has permission to speak on a
                 moderated channel. The response is used RPL_ENDOFWHOIS
                 to mark the end of processing a message
                 WHOIS.
       314 RPL_WHOWASUSER
                       "<Name> <user> <host> * <real name>"
       369 RPL_ENDOFWHOWAS
                       "<Nick>: End of list / WHOWAS"
               - When replying to a message WHOWAS, a server must
                 RPL_WHOWASUSER use, or answers RPL_WHOISSERVER
                 ERR_WASNOSUCHNICK for every nick on the list
                 submitted. At the end of lots of respuesa must


Oikarinen & Reed [Page. 48]

Talk RFC 1459 Protocol Based on Internet in May 1993


                 will be RPL_ENDOFWHOWAS (even if there was only one
                 response and this was a mistake).
       321 RPL_LISTSTART
                       "Channel: Users Name"
       322 RPL_LIST
                       "<Channel> <# visible>: <topic>"
       323 RPL_LISTEND
                       "End of / LIST"
               - The responses RPL_LISTSTART, RPL_LIST, RPL_LISTEND
                 They mark the beginning, the response itself and the end of
                 the server reply to the LIST command. Otherwise
                 there are channels to return, only sent the
                 start and end answers.
       324 RPL_CHANNELMODEIS
                       "<Channel> <mode> <parameter mode>"
       331 RPL_NOTOPIC
                       "<Channel>: No topic set"
       332 RPL_TOPIC
                       "<Channel> <topic>"
               - When a TOPIC message is sent to determine the
                 channel topic, you send one of two answers.
                 If no topic set, RPL_TOPIC sent in
                 Otherwise, RPL_NOTOPIC.
       341 RPL_INVITING
                       "<Channel> <nick>"
               - Indicates that the INVITE message is successfully implemented and
                 It is being passed to the client destination.
       342 RPL_SUMMONING
                       "<User>: Calling user to IRC"
               - Returned by a server answering a message
                 SUMMON to indicate that the user is calling.
       351 RPL_VERSION
                       "<Version> <debug level> <server>. \
                        <Comments> "
               - Server response showing details of its
                 version. The <version> is the program that is
                 using (including revisions of the patches) and



Oikarinen & Reed [Page. 49]

Talk RFC 1459 Protocol Based on Internet in May 1993


                 <Debug level> indicates whether the server is
                 "Debug mode".
                 The <comment> may contain comments
                 about the version or further version details.
       352 RPL_WHOREPLY
                       "<Channel> <user> <host> <server> <name> \
                     <H | G> [*] [@ | +] <jump counter> <real name> "
       315 RPL_ENDOFWHO
                       "<Name>: End of list / WHO"
               - RPL_WHOREPLY and RPL_ENDOFWHO used to answer
                 one WHO message. RPL_WHOREPLY only sent if there is a
                 appropriate input to the request of WHO. If a
                 parameter list in the WHO message must be sent
                 one RPL_ENDOFWHO after processing each element
                 list, where <name> element.
       353 RPL_NAMREPLY
                       "<Channel>: [[@ | +] <nick>  +] <nick> [...]"
       366 RPL_ENDOFNAMES
                       "<Channel>: End of list / NAMES"
               - To reply to a NAMES message, sent to the customer
                 a pair of posts RPL_NAMREPLY and RPL_ENDOFNAMES.
                 If a channel is not found as the request,
                 RPL_ENDOFNAMES only ships. An exception to this is
                 if the message is sent without parameters NAMES in that
                 If all visible channels and returned
                 contained in a series of messages with RPL_NAMEREPLY
                 one RPL_ENDOFNAMES marking the end.
       364 RPL_LINKS
                       "<Mask> <server>: <counter jump> \
                       <Server information> "
       365 RPL_ENDOFLINKS
                       "<Mask>: End of / LINKS list"
               - To reply to a message LINKS, the server must
                 send responses using RPL_LINKS and mark the end
                 with RPL_ENDOFLINKS.
       367 RPL_BANLIST
                       "<Channel> <ID ban>"
       368 RPL_ENDOFBANLIST
                       "<Channel>: End of channel ban list"
               - When the "bans" are listed assets of a channel,
                 server should return the list using messages


Oikarinen & Reed [Page. 50]

Talk RFC 1459 Protocol Based on Internet in May 1993


                 RPL_BANLIST and RPL_ENDOFBANLIST. It sends a
                 RPL_BANLIST separately for each identification
                 active ban. After all be listed (or if no
                 none), you send an RPL_ENDOFBANLIST.
       371 RPL_INFO
                       "<String>"
       374 RPL_ENDOFINFO
                       "End of list / INFO"
               - A server responding to an INFO message must
                 send all your information in a series of messages
                 RPL_INFO with RPL_ENDOFINFO to indicate the end
                 response.
       375 RPL_MOTDSTART
                       "- <Server> Day -"
       372 RPL_MOTD
                       "- <Text>"
       376 RPL_ENDOFMOTD
                       "End of command / MOTD"
               - When responding to the MOTD message and the MOTD file
                 is, line line shown not surpassing
                 each 80 characters, using the format
                 response of RPL_MOTD. These should be opened and
                 closed with a RPL_MOTDSTART (before RPL_MOTD)
                 and RPL_ENDOFMOTD (after).
       381 RPL_YOUREOPER
                       "Are you now IRC operator"
               - RPL_YOUREOPER a customer you just sent
                 successfully run a command OPER obtained status
                 IRC Operator.
       382 RPL_REHASHING
                       "<Configuration file>: Resetting"
               - If REHASH option is used and an operator sends a
                 REHASH message a RPL_REHASHING returned to
                 Operator.
       391 RPL_TIME
                 "<Server>: <string local server>"
               - When replying to the TIME command, the server must send
                 the answer using the above format RPL_TIME.
                 The string must contain only the date and time
                 correct. No more requirements for the chain.


Oikarinen & Reed [Page. 51]

Talk RFC 1459 Protocol Based on Internet in May 1993


       392 RPL_USERSSTART
                       "Host Terminal UserID"
       393 RPL_USERS
                       "% - 8s% -9s% -8s"
       394 RPL_ENDOFUSERS
                       "End users"
       395 RPL_NOUSERS
                       "Nobody connected"
               - If a server receives an USERS command, use the
                 RPL_USERSTART answers, RPL_USERS, and RPL_ENDOFUSERS
                 RPL_NOUSERS. RPL_USERSSTART be sent first,
                 followed by a sequence of one or RPL_USERS
                 RPL_NOUSER only. After this RPL_ENDOFUSERS sent.
       200 RPL_TRACELINK
                       "Link <version & debug level> \
                       <Destination> <next server> "
       201 RPL_TRACECONNECTING
                       "Trying to <class> <server>"
       202 RPL_TRACEHANDSHAKE
                       "HS <class> <server>"
       203 RPL_TRACEUNKNOWN
                       "???? <Class> [<IP address of the client \
                       the form separated by dots> numbers] "
       204 RPL_TRACEOPERATOR
                       "Operator <class> <nick>"
       205 RPL_TRACEUSER
                       "User <class> <nick>"
       206 RPL_TRACESERVER
                       "Server <class> <int> S <int> C <server> \
                        <Nick user |! * *!> @ <Host | server> "
       208 RPL_TRACENEWTYPE
                       "<New type> 0 <customer name>"
       261 RPL_TRACELOG
                       "File <file> <level \
                       Debug> "
               - The RPL_TRACE * the server returns the response
                 a TRACE command. Be returned depends on many
                 TRACE message sent and if an operator or not. No
                 no predefined order of response. The answers
                 RPL_TRACEUNKNOWN, and RPL_TRACECONNECTING
                 RPL_TRACEHANDSHAKE are used for connections that are not
                 They have finished setting and either are unknown or
                 It is still attempting to connect or completing the
                 "High-Five" server. RPL_TRACELINK it
                 sends a server receives a message from TRACE and
                 you have to pass to another. List
                 RPL_TRACELINKs sent in response to a command


Oikarinen & Reed [Page. 52]

Talk RFC 1459 Protocol Based on Internet in May 1993


                 TRACE traversing the IRC network should reflect the
                 Real server connectivity through
                 route. RPL_TRACENEWTYPE be used for a connection
                 not fit in the other categories but is shown
                 Likewise.
       211 RPL_STATSLINKINFO
                       "<Link name> <send queue [senq]> \
                        <Sent messages> <bytes sent> \
                        <Received messages> <Bytes Received> \
                        <Airtime> "
       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
                       "And <class> <frequency table> <frequency \
                        Connection> <maximum sendq> "
       219 RPL_ENDOFSTATS
                       "<Status information>: End of report \
                        / STATS "
       241 RPL_STATSLLINE
                       "L <hostmask> * <server name> \
                        <Maximum depth> "
       242 RPL_STATSUPTIME
                       "Active Server% d days% d:% 02d:% 02d"
       243 RPL_STATSOLINE
                       "O <hostmask> * <name>"
       244 RPL_STATSHLINE
                       "H <hostmask> * <server name>"
       221 RPL_UMODEIS
                       "<String User Mode>"
                       - Is sent to check a user mode
       251 RPL_LUSERCLIENT
                       "There are <integer1> users and <integer2> Invisible
                         in <integer3> servers
       252 RPL_LUSEROP
                       "<Integer>: Operator (s) connected (s)"
       253 RPL_LUSERUNKNOWN
                       "<Integer>: Connection (s) unknown (s)"


Oikarinen & Reed [Page. 53]

Talk RFC 1459 Protocol Based on Internet in May 1993

       254 RPL_LUSERCHANNELS
                       "<Integer>: channel (s) set (s)"
       255 RPL_LUSERME
                       "I <integer1> customers <integer2> \
                         Servers "
                       - When processing a message LUSERS, the server
                         sends a set of responses
                         RPL_LUSERCLIENT, RPL_LUSEROP,
                         RPL_USERUNKNOWN, and RPL_LUSERCHANNELS
                         RPL_LUSERME. In response, the server must
                         send RPL_LUSERCLIENT and RPL_LUSERME. The
                         other responses are sent only if there is a
                         counter is not zero for them.
       256 RPL_ADMINME
                       "<Server>: Administrator Information"
       257 RPL_ADMINLOC1
                       "<Administrator Information>"
       258 RPL_ADMINLOC2
                       "<Administrator Information>"
       259 RPL_ADMINEMAIL
                       "<Administrator Information>"
                       - When replying to an ADMIN message, a server
                         you must use the answers to RLP_ADMINME
                         RPL_ADMINEMAIL and provide a message
                         text each. To RPL_ADMINLOC1 is
                         expects a description of the city, state and
                         country, followed by the details of the
                         university and department (RPL_ADMINLOC2), and
                         Finally, contact administrator
                         server (an email address is required
                         e) in RPL_ADMINEMAIL.










Oikarinen & Reed [Page. 54]

Talk RFC 1459 Protocol Based on Internet in May 1993


6.3 Replies reserved

  These responses are not described above since they fall in one of the
  following categories:
       1. no longer in use;
       2 are reserved for future use ;;
       3. are in use but are part of non-generic features
          server.
       209 217 RPL_TRACECLASS RPL_STATSQLINE
       231 232 RPL_SERVICEINFO RPL_ENDOFSERVICES
       233 234 RPL_SERVICE RPL_SERVLIST
       235 RPL_SERVLISTEND
       316 361 RPL_WHOISCHANOP RPL_KILLDONE
       362 363 RPL_CLOSING RPL_CLOSEEND
       373 384 RPL_INFOSTART RPL_MYPORTIS
       466 476 ERR_YOUWILLBEBANNED ERR_BADCHANMASK
       492 ERR_NOSERVICEHOST

7. AUTHENTICATION OF CLIENT AND SERVER

  Clients and servers are subject both at the same level
  atenticación. For both, a search is performed IP number and
  hostname (and reverse this check) for each
  connection made to the server. After both connections are subject to
  a check key (if there is one key set for that
  connection). These checks are possible on all connections
  while key checking is commonly used only
  servers.
  A check that is becoming more common is the User
  responsible for the connection. Find the user across the
  connection usually requires connection to a server
  IDENT authentication, described in RFC 1413.
  Since no key is not easy to reliably determine who is
  across a network connection, it is strongly recommended
  the use of key connections between servers as well as other
  measures such as the use of an ident server.

8. DETAILS OF IMPLEMENTATION

  The only current implementation of this protocol is the server
  IRC, version 2.8. Later versions may implement some or
  All commands described in this document messages
  NOTICE replacing many of the numeric replies. For



Oikarinen & Reed [Page. 55]

Talk RFC 1459 Protocol Based on Internet in May 1993


  Unfortunately, due to backward compatibility requirements, the
  implementation of some parts of this document varies with what
  it is expressed. One important difference is:
       * Recognize any LF character (Line Feed - EOL) or
         CR (Carriage Return - Carriage Return) anywhere
         a message as to the message (instead of requiring
         CR-LF)
  The remainder of this section discusses the most important points
  for those who wish to implement a server, but most
  parts also apply directly to customers.

8.1 Network protocol: TCP - why it is appropriate to use it here

  The IRC has been implemented on TCP since TCP provides a
  reliable network protocol which fits well with this type of
  "Conferenciación". Using [multicast] IP is an alternative, but
  not too available or supported at present.

8.1.1 Support of UNIX sockets

  Since UNIX domain sockets allow operations
  listen / connection, the current implementation can be configured to
  listen and accept both client connections on a server
  UNIX domain socket. These are recognized as sockets where the
  hostname starts with a '/'.
  By providing information about the connections on a socket
  UNIX domain, the server must place the actual host name in the
  siito the way (path) unless you ask for the name of the
  socket.

8.2 Analysis Command

  To provide an input / output buffer without useful network for
  clients and servers, each connection gets its input buffer
  own private in which the results are saved
  Latest readings and analysis. A buffer size of 512 bytes
  It is used to store a complete message, however, usually
  You can host multiple commands. The buff er private analyzed after
  each read operation valid messages. When dealing with
  multiple messages from one client in the buffer, caution
  in case one results in the elimination of the client.

8.3 Messaging

  It is common to find network links saturated or hosts to which you
  sends data but is unable to send data. Though UNIX
  typically handles this through the TCP window and buffers
  internally, the server often has large amounts of data


Oikarinen & Reed [Page. 56]

Talk RFC 1459 Protocol Based on Internet in May 1993

  to send (especially when a new bond is formed server-
  server) and small kernel buffers are not enough to
  the output queue. To alleviate this problem, a "queue used
  shipping "as FIFO queue for data to be sent. A" send queue "
  typically can be up to 200 kilobytes in a large IRC network
  slow connections in the connection of a new server.
  When choosing its connections, a server must read and analyze first
  all input data, send data gluing. When
  processed all available inputs, the data are sent the
  tail. This reduces the number of system calls to write () and aid
  TCP make bigger packets.

8.4 Life of a connection

  To detect when a connection has died or does not respond, the
  server must check each of your connections (send ping)
  which has no answers in a given time interval.
  If a connection does not respond in time, its connection is closed using
  proper procedures. The connection also closes if your
  send queue grows above the maximum allowed, because it is better
  close a slow connection than have a server process
  blocked.

8.5 Establishing a client-server connection

  After connecting to an IRC server, the client sends the MOTF (if
  It is), plus the current user counter / servers
  (As shown by the command LUSER). The server must also give
  unambiguous message to the client with your name and version,
  as well as any introductory message that might qualify
  appropriate.
  After this, the server must send the new user's nickname and other
  information provided by himself (USER command) and the
  server can discover (from DNS / authentication servers). The
  server must send this information with NICK first followed by
  USER.

8.6 Establishing a server-server connection

  The process of establishing a server-server connection does not
  It is risk-free because there are many parts that can
  have problems - they are under race conditions.
  After a server receives a connection followed a couple
  PASS / SERVER which have been recognized as valid, the server should
  respond with your own information PASS / SERVER for that connection
  Like all state information dealing with the form
  described below.
  When the server that initiates the connection receives a pair PASS / SERVER,

Oikarinen & Reed [Page. 57]

Talk RFC 1459 Protocol Based on Internet in May 1993


  checks that the server responding is authenticated properly
  acecptar before the connection is on that server.

8.6.1 Exchange status information to connect

  The order of state information being exchanged between
  servers is critical. The required order is as follows:
       * All known other servers;
       * All known user information;
       * All known channel information.
  Information regarding servers is sent via messages
  Extra SERVER, user information with messages NICK / USER /
  MODE / JOIN messages and channels with MODE.
  NOTE: channel topics are * NOT * exchanged here because the
  TOPIC command overwrites any previous information there.
  At first pass the state information about servers,
  any collisions with servers that already exist occur before
  nickname collisions due to a second server introducing
  a nick in particular. Because the IRC network only exists as
  acyclic graph, it is possible that the network has already reconnected in another
  position, indicating the crash site must be separated where the
  network.

8.7 Completion of client-server connections

  When a client connection is closed, the server to which the
  connected client generates a message on behalf of QUIT
  client. It does not generate or use another message.

8.8 Completion of server-server connections

  If server-server connection is closed, either via one SQUIT
  Remote or "natural" causes, the rest of the IRC network must
  upgrade your server information detected closure
  connection. The server sends a list of squits (one per
  server behind that closed connection) and a list of quits (again,
  one for each client behind that connection).






Oikarinen & Reed [Page. 58]

Talk RFC 1459 Protocol Based on Internet in May 1993


8.9 Tracking nickname changes

  All IRC servers must maintain a historical record of the
  Recent changes nick. This is mandatory to allow the
  server has the chance to keep track of changes when
  you give race conditions nick changes, due to orders
  who they handle them. The commands to be followed by changes of nick
  They are:
       * KILL (the nick being ejected IRC)
       * MODE (+/- or v)
       * KICK (the nick that is ejected from the channel)
  No other command has to check nick changes.
  In the above cases, the server should check first
  nick existence, then check its history to see who
  belongs today that nickname (if any). This reduces the
  career opportunities but can still happen and end up in the
  server acts on the wrong nick. To track
  change for a previous command is recommended to take a
  time interval and inputs that are too old ignored.
  For a reasonable history, a server should be able to
  service for every customer who knows if all previous nicks
  they decided to change it. The size is limited by other factors
  (Such as memory, etc.).

8.10 Customer flood control

  In a large network of IRC servers, it is easy for a single customer
  networked provide a continuous flow of messages
  resulting not only in a "flood" of the network but also in the
  degradation of service to others. Rather than requiring protection
  each "victim" flood protection was included in the
  server and applies to all clients except services. The
  current algorithm is as follows:


       * Check if the "counter message" customer is less
         the current time (sets equal if it is);


       * Read customer data;
       * While the timer is less than ten seconds ahead
         the current time, parse any message and penalize
         client with two seconds per message;


Oikarinen & Reed [Page. 59]

Talk RFC 1459 Protocol Based on Internet in May 1993

  So, in essence, it means that the customer can send 1 message
  every 2 seconds if suffer.


8.11 unblocked searches

  In a real time environment, it is essential that the process of
  server wait as little as possible so that it serves all
  customers fairly. Obviously this requires not been
  blocking I / O operations read / write.
  For normal server connections, this is not difficult, but there
  other operations that can cause a server crash (as
  disk reads). When possible, these activities should
  performed with a short pause.

8.11.1 host name resolution (DNS)

  Using libraries resolution Berkeley and others has
  meaning significant delays in some cases where the
  responses have expired. To avoid this, a set written
  DNS other routines, which were designed for operations
  I / S nonblocking and taken out outside the main loop of E / S of
  server.

8.11.2 Search Username (Ident)

  Although there are many libraries ident, caused problems since
  They operated synchronously and resulted in frequent delays. The
  solution, again, was to write routines cooperating with
  rest of the server and work using E / S without blocking.

8.12 Configuration File

  To provide a flexible way to configure and run the
  server using a configuration file is recommended that
  the server contains instructions regarding:
       * Which hosts to accept client connections;
       * What hosts server connections are allowed;
       * Which hosts to connect (active and passive);
       * Location information server (university,
         city ​​/ state, company ...);
       * Who is responsible for the server and an e-
         Contact E-Mail;
       * Hostnames and passwords for clients who wish to access
         to restricted operator commands.


Oikarinen & Reed [Page. 60]

Talk RFC 1459 Protocol Based on Internet in May 1993

  When specifying hostnames, both domain names such as
  notation "point" (127.0.0.1) should be accepted. It should be possible
  specify the key used / accepted for all connections
  incoming and outgoing (although the only outgoing connections are
  other servers).
  The above list are the minimum requirements for a server
  you want to connect to another. Other aspects of utility are:
       * Specifying which servers other server may occur;
       * The maximum depth of the branch of a server;
       * Maximum number of times of connection customer.

8.12.1 Allow the connection of customers

  A server should use some sort of "control list
  access "(either in the configuration file or elsewhere) that
  read at startup and used to decide what hosts can use
  clients to connect.
  Both 'deny' and 'allow' should be implemented to
  provide the required flexibility for the access control
  host.

8.12.2 Operators

  The granting of operator privileges to inappropriate person
  You can have direct consequences for the good brand network
  IRC in general due to the powers granted. Therefore, the
  obtaining these powers should not be easy. The configuration
  Current requires two keys although one of them is usually easy
  to find out. It is better to keep the keys of files Operator
  configuration included in the code and should be kept in
  encrypted format (for example, using crypt (3) UNIX) for
  prevent easy theft.

8.12.3 Allow the connection server

  The interconnection of server is not a trivial problem: poor
  connection can have a large impact on the usefulness of IRC. For
  Thus, each server should have a list of the servers
  which can be connected and that can be connected to it. Low
  no circumstances should a server allow connection of a
  either as a server host. In addition to the servers that can and
  can not connect, the configuration file should contain
  also the key and other characteristics of the link.




Oikarinen & Reed [Page. 61]

Talk RFC 1459 Protocol Based on Internet in May 1993


8.12.4 Administration

  To provide valid and complete responses to command ADMIN
  (See section 4.3.7), the server must include details
  relevant settings.

8.13 Members channels

  The current server allows local registered membership
  up to 10 different channels. There is no limit for users
  so that the local server is (reasonably) consistent
  with all other members based on a channel.

9. CURRENT PROBLEMS

  There are a few problems with this protocol, which is
  expected to be solved in the near future. Currently,
  It is working to solve these problems.

9.1 Scalability

  It is well known that this protocol does not scale sufficiently
  well when used in a very massive way. The problem most
  important is the requirement that all servers know
  about others and about users, and that information on
  you upgrade them to change. It is also desirable to maintain a
  reduced number of servers so that the path length between
  two points is minimal and the spanning tree is as
  branched possible.

9.2 Tags

  The current IRC protocol has three types of tags: nick,
  channel name and server name. Each of the types has
  your own domain and no duplication is allowed within each.
  Currently it is possible for users to pick up one label
  three, which ends in collisions. It is known that this needs more
  Working with a plan for unique names for channels and nicks that do not
  collide, and a solution allowing a cyclic tree.
  N. T .: a tree by definition is acyclic (graph without cycles)
  but the literal translation is preserved.

9.2.1 Nicks

  The idea nick on IRC is very convenient for users face
  to talk to each other outside of a channel, but there is a finite space
  nicks and what they are, it is not uncommon that several people want the
  same. If two people using this protocol escojen the same nickname,
  either one will not succeed or both will be eliminated by using
  KILL (section 4.6.1).


Oikarinen & Reed [Page. 62]

Talk RFC 1459 Protocol Based on Internet in May 1993


9.2.2 Channels

  The composition of current channels requires that all servers
  know about all channels, their members and property. Apart
  not scale well, the issue of privacy is also important.
  A collision between channels is as inclusive event (both
  that created the new channel are considered members of it) rather than
  exclusive as in the case of collisions of nicks.

9.2.3 Servers

  Although the number of servers is usually small compared to
  the users and channels, both need to be known globally,
  either each separately or masked.

9.3 Algorithms

  In some portions of the server code they have not been able to avoid
  N ^ 2 algorithms such as checking the channel list of a set
  customer.
  In current versions of the server, no checkup
  consistency of the database, the server assumes that each
  neighboring server is correct. This opens the door to problems
  great if a connected server is defective or try to enter
  contradictions to the network.
  At present, due to the shortage of internal tags and
  only global, there are many conditions that can occur racing.
  These usually they come in the time it takes to messages
  through the IRC network. Even by changing to unique labels, there
  problems related interruption command channels.

10. SUPPORT AND AVAILABILITY

          Mailing lists for discussions on IRC:
               Future protocol: [email protected]
               General discussion: [email protected]
          Software Implementation:
               cs.bu.edu:/irc
               nic.funet.fi:/pub/irc
               coombs.anu.edu.au:/pub/irc
          Newsgroups: alt.irc


11. SAFETY ISSUES

  These are discussed in sections 4.1, 4.1.1, 4.1.3, 5.5 and 7.


Oikarinen & Reed [Page. 63]

Talk RFC 1459 Protocol Based on Internet in May 1993


12. ADDRESSES OF AUTHORS

  Jarkko Oikarinen
  Tuirantie as September 17
  90500 OULU
  FINLAND
  Email: [email protected]


  Darren Reed
  4 Pateman Street
  Watsonia, Victoria 3087
  Australia
  Email: [email protected]


  Translator:
  Carlos García Argos
  C / Antonio Trueba, 14; 4-8-2
  MALAGA 29017
  SPAIN / SPAIN
  Email: [email protected]