Network Working Group J. Oikarinen
`Request for Comments: 1459 D. Reed
` May 1993
`
` Internet Relay Chat Protocol
`
`Status of This Memo
`
` This memo defines an Experimental Protocol for the Internet
` community. Discussion and suggestions for improvement are requested.
` Please refer to the current edition of the "IAB Official Protocol
` Standards" for the standardization state and status of this protocol.
` Distribution of this memo is unlimited.
`
`Abstract
`
` The IRC protocol was developed over the last 4 years since it was
` first implemented as a means for users on a BBS to chat amongst
` themselves. Now it supports a world-wide network of servers and
` clients, and is stringing to cope with growth. Over the past 2 years,
` the average number of users connected to the main IRC network has
` grown by a factor of 10.
`
` The IRC protocol is a text-based protocol, with the simplest client
` being any socket program capable of connecting to the server.
`
`Table of Contents
`
` 1. INTRODUCTION ............................................... 4
` 1.1 Servers ................................................ 4
` 1.2 Clients ................................................ 5
` 1.2.1 Operators .......................................... 5
` 1.3 Channels ................................................ 5
` 1.3.1 Channel Operators .................................... 6
` 2. THE IRC SPECIFICATION ....................................... 7
` 2.1 Overview ................................................ 7
` 2.2 Character codes ......................................... 7
` 2.3 Messages ................................................ 7
` 2.3.1 Message format in ’pseudo’ BNF .................... 8
` 2.4 Numeric replies ......................................... 10
` 3. IRC Concepts ................................................ 10
` 3.1 One-to-one communication ................................ 10
` 3.2 One-to-many ............................................. 11
` 3.2.1 To a list .......................................... 11
` 3.2.2 To a group (channel) ............................... 11
` 3.2.3 To a host/server mask .............................. 12
` 3.3 One to all .............................................. 12
`
`Oikarinen & Reed [Page 1]
`
`Petitioner Microsoft Corporation, Ex. 1006, p. 1
`
`

`
`RFC 1459 Internet Relay Chat Protocol May 1993
`
` 3.3.1 Client to Client ................................... 12
` 3.3.2 Clients to Server .................................. 12
` 3.3.3 Server to Server ................................... 12
` 4. MESSAGE DETAILS ............................................. 13
` 4.1 Connection Registration ................................. 13
` 4.1.1 Password message ................................... 14
` 4.1.2 Nickname message ................................... 14
` 4.1.3 User message ....................................... 15
` 4.1.4 Server message ..................................... 16
` 4.1.5 Operator message ................................... 17
` 4.1.6 Quit message ....................................... 17
` 4.1.7 Server Quit message ................................ 18
` 4.2 Channel operations ...................................... 19
` 4.2.1 Join message ....................................... 19
` 4.2.2 Part message ....................................... 20
` 4.2.3 Mode message ....................................... 21
` 4.2.3.1 Channel modes ................................. 21
` 4.2.3.2 User modes .................................... 22
` 4.2.4 Topic message ...................................... 23
` 4.2.5 Names message ...................................... 24
` 4.2.6 List message ....................................... 24
` 4.2.7 Invite message ..................................... 25
` 4.2.8 Kick message ....................................... 25
` 4.3 Server queries and commands ............................. 26
` 4.3.1 Version message .................................... 26
` 4.3.2 Stats message ...................................... 27
` 4.3.3 Links message ...................................... 28
` 4.3.4 Time message ....................................... 29
` 4.3.5 Connect message .................................... 29
` 4.3.6 Trace message ...................................... 30
` 4.3.7 Admin message ...................................... 31
` 4.3.8 Info message ....................................... 31
` 4.4 Sending messages ........................................ 32
` 4.4.1 Private messages ................................... 32
` 4.4.2 Notice messages .................................... 33
` 4.5 User-based queries ...................................... 33
` 4.5.1 Who query .......................................... 33
` 4.5.2 Whois query ........................................ 34
` 4.5.3 Whowas message ..................................... 35
` 4.6 Miscellaneous messages .................................. 35
` 4.6.1 Kill message ....................................... 36
` 4.6.2 Ping message ....................................... 37
` 4.6.3 Pong message ....................................... 37
` 4.6.4 Error message ...................................... 38
` 5. OPTIONAL MESSAGES ........................................... 38
` 5.1 Away message ............................................ 38
` 5.2 Rehash command .......................................... 39
` 5.3 Restart command ......................................... 39
`
`Oikarinen & Reed [Page 2]
`
`Petitioner Microsoft Corporation, Ex. 1006, p. 2
`
`

`
`RFC 1459 Internet Relay Chat Protocol May 1993
`
` 5.4 Summon message .......................................... 40
` 5.5 Users message ........................................... 40
` 5.6 Operwall command ........................................ 41
` 5.7 Userhost message ........................................ 42
` 5.8 Ison message ............................................ 42
` 6. REPLIES ..................................................... 43
` 6.1 Error Replies ........................................... 43
` 6.2 Command responses ....................................... 48
` 6.3 Reserved numerics ....................................... 56
` 7. Client and server authentication ............................ 56
` 8. Current Implementations Details ............................. 56
` 8.1 Network protocol: TCP ................................... 57
` 8.1.1 Support of Unix sockets ............................ 57
` 8.2 Command Parsing ......................................... 57
` 8.3 Message delivery ........................................ 57
` 8.4 Connection ’Liveness’ ................................... 58
` 8.5 Establishing a server-client connection ................. 58
` 8.6 Establishing a server-server connection ................. 58
` 8.6.1 State information exchange when connecting ......... 59
` 8.7 Terminating server-client connections ................... 59
` 8.8 Terminating server-server connections ................... 59
` 8.9 Tracking nickname changes ............................... 60
` 8.10 Flood control of clients ............................... 60
` 8.11 Non-blocking lookups ................................... 61
` 8.11.1 Hostname (DNS) lookups ............................ 61
` 8.11.2 Username (Ident) lookups .......................... 61
` 8.12 Configuration file ..................................... 61
` 8.12.1 Allowing clients to connect ....................... 62
` 8.12.2 Operators ......................................... 62
` 8.12.3 Allowing servers to connect ....................... 62
` 8.12.4 Administrivia ..................................... 63
` 8.13 Channel membership ..................................... 63
` 9. Current problems ............................................ 63
` 9.1 Scalability ............................................. 63
` 9.2 Labels .................................................. 63
` 9.2.1 Nicknames .......................................... 63
` 9.2.2 Channels ........................................... 64
` 9.2.3 Servers ............................................ 64
` 9.3 Algorithms .............................................. 64
` 10. Support and availability ................................... 64
` 11. Security Considerations .................................... 65
` 12. Authors’ Addresses ......................................... 65
`
`Oikarinen & Reed [Page 3]
`
`Petitioner Microsoft Corporation, Ex. 1006, p. 3
`
`

`
`RFC 1459 Internet Relay Chat Protocol May 1993
`
`1. INTRODUCTION
`
` The IRC (Internet Relay Chat) protocol has been designed over a
` number of years for use with text based conferencing. This document
` describes the current IRC protocol.
`
` The IRC protocol has been developed on systems using the TCP/IP
` network protocol, although there is no requirement that this remain
` the only sphere in which it operates.
`
` IRC itself is a teleconferencing system, which (through the use of
` the client-server model) is well-suited to running on many machines
` in a distributed fashion. A typical setup involves a single process
` (the server) forming a central point for clients (or other servers)
` to connect to, performing the required message delivery/multiplexing
` and other functions.
`
`1.1 Servers
`
` The server forms the backbone of IRC, providing a point to which
` clients may connect to to talk to each other, and a point for other
` servers to connect to, forming an IRC network. The only network
` configuration allowed for IRC servers is that of a spanning tree [see
` Fig. 1] where each server acts as a central node for the rest of the
` net it sees.
`
` [ Server 15 ] [ Server 13 ] [ Server 14]
` / \ /
` / \ /
` [ Server 11 ] ------ [ Server 1 ] [ Server 12]
` / \ /
` / \ /
` [ Server 2 ] [ Server 3 ]
` / \ \
` / \ \
` [ Server 4 ] [ Server 5 ] [ Server 6 ]
` / | \ /
` / | \ /
` / | \____ /
` / | \ /
` [ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ]
`
` :
` [ etc. ]
` :
`
` [ Fig. 1. Format of IRC server network ]
`
`Oikarinen & Reed [Page 4]
`
`Petitioner Microsoft Corporation, Ex. 1006, p. 4
`
`

`
`RFC 1459 Internet Relay Chat Protocol May 1993
`
`1.2 Clients
`
` A client is anything connecting to a server that is not another
` server. Each client is distinguished from other clients by a unique
` nickname having a maximum length of nine (9) characters. See the
` protocol grammar rules for what may and may not be used in a
` nickname. In addition to the nickname, all servers must have the
` following information about all clients: the real name of the host
` that the client is running on, the username of the client on that
` host, and the server to which the client is connected.
`
`1.2.1 Operators
`
` To allow a reasonable amount of order to be kept within the IRC
` network, a special class of clients (operators) is allowed to perform
` general maintenance functions on the network. Although the powers
` granted to an operator can be considered as ’dangerous’, they are
` nonetheless required. Operators should be able to perform basic
` network tasks such as disconnecting and reconnecting servers as
` needed to prevent long-term use of bad network routing. In
` recognition of this need, the protocol discussed herein provides for
` operators only to be able to perform such functions. See sections
` 4.1.7 (SQUIT) and 4.3.5 (CONNECT).
`
` A more controversial power of operators is the ability to remove a
` user from the connected network by ’force’, i.e. operators are able
` to close the connection between any client and server. The
` justification for this is delicate since its abuse is both
` destructive and annoying. For further details on this type of
` action, see section 4.6.1 (KILL).
`
`1.3 Channels
`
` A channel is a named group of one or more clients which will all
` receive messages addressed to that channel. The channel is created
` implicitly when the first client joins it, and the channel ceases to
` exist when the last client leaves it. While channel exists, any
` client can reference the channel using the name of the channel.
`
` Channels names are strings (beginning with a ’&’ or ’#’ character) of
` length up to 200 characters. Apart from the the requirement that the
` first character being either ’&’ or ’#’; the only restriction on a
` channel name is that it may not contain any spaces (’ ’), a control G
` (^G or ASCII 7), or a comma (’,’ which is used as a list item
` separator by the protocol).
`
` There are two types of channels allowed by this protocol. One is a
` distributed channel which is known to all the servers that are
`
`Oikarinen & Reed [Page 5]
`
`Petitioner Microsoft Corporation, Ex. 1006, p. 5
`
`

`
`RFC 1459 Internet Relay Chat Protocol May 1993
`
` connected to the network. These channels are marked by the first
` character being a only clients on the server where it exists may join
` it. These are distinguished by a leading ’&’ character. On top of
` these two types, there are the various channel modes available to
` alter the characteristics of individual channels. See section 4.2.3
` (MODE command) for more details on this.
`
` To create a new channel or become part of an existing channel, a user
` is required to JOIN the channel. If the channel doesn’t exist prior
` to joining, the channel is created and the creating user becomes a
` channel operator. If the channel already exists, whether or not your
` request to JOIN that channel is honoured depends on the current modes
` of the channel. For example, if the channel is invite-only, (+i),
` then you may only join if invited. As part of the protocol, a user
` may be a part of several channels at once, but a limit of ten (10)
` channels is recommended as being ample for both experienced and
` novice users. See section 8.13 for more information on this.
`
` If the IRC network becomes disjoint because of a split between two
` servers, the channel on each side is only composed of those clients
` which are connected to servers on the respective sides of the split,
` possibly ceasing to exist on one side of the split. When the split
` is healed, the connecting servers announce to each other who they
` think is in each channel and the mode of that channel. If the
` channel exists on both sides, the JOINs and MODEs are interpreted in
` an inclusive manner so that both sides of the new connection will
` agree about which clients are in the channel and what modes the
` channel has.
`
`1.3.1 Channel Operators
`
` The channel operator (also referred to as a "chop" or "chanop") on a
` given channel is considered to ’own’ that channel. In recognition of
` this status, channel operators are endowed with certain powers which
` enable them to keep control and some sort of sanity in their channel.
` As an owner of a channel, a channel operator is not required to have
` reasons for their actions, although if their actions are generally
` antisocial or otherwise abusive, it might be reasonable to ask an IRC
` operator to intervene, or for the usersjust leave and go elsewhere
` and form their own channel.
`
` The commands which may only be used by channel operators are:
`
` KICK - Eject a client from the channel
` MODE - Change the channel’s mode
` INVITE - Invite a client to an invite-only channel (mode +i)
` TOPIC - Change the channel topic in a mode +t channel
`
`Oikarinen & Reed [Page 6]
`
`Petitioner Microsoft Corporation, Ex. 1006, p. 6
`
`

`
`RFC 1459 Internet Relay Chat Protocol May 1993
`
` A channel operator is identified by the ’@’ symbol next to their
` nickname whenever it is associated with a channel (ie replies to the
` NAMES, WHO and WHOIS commands).
`
`2. The IRC Specification
`
`2.1 Overview
`
` The protocol as described herein is for use both with server to
` server and client to server connections. There are, however, more
` restrictions on client connections (which are considered to be
` untrustworthy) than on server connections.
`
`2.2 Character codes
`
` No specific character set is specified. The protocol is based on a a
` set of codes which are composed of eight (8) bits, making up an
` octet. Each message may be composed of any number of these octets;
` however, some octet values are used for control codes which act as
` message delimiters.
`
` Regardless of being an 8-bit protocol, the delimiters and keywords
` are such that protocol is mostly usable from USASCII terminal and a
` telnet connection.
`
` Because of IRC’s scandanavian origin, the characters {}| are
` considered to be the lower case equivalents of the characters []\,
` respectively. This is a critical issue when determining the
` equivalence of two nicknames.
`
`2.3 Messages
`
` Servers and clients send eachother messages which may or may not
` generate a reply. If the message contains a valid command, as
` described in later sections, the client should expect a reply as
` specified but it is not advised to wait forever for the reply; client
` to server and server to server communication is essentially
` asynchronous in nature.
`
` Each IRC message may consist of up to three main parts: the prefix
` (optional), the command, and the command parameters (of which there
` may be up to 15). The prefix, command, and all parameters are
` separated by one (or more) ASCII space character(s) (0x20).
`
` The presence of a prefix is indicated with a single leading ASCII
` colon character (’:’, 0x3b), which must be the first character of the
` message itself. There must be no gap (whitespace) between the colon
` and the prefix. The prefix is used by servers to indicate the true
`
`Oikarinen & Reed [Page 7]
`
`Petitioner Microsoft Corporation, Ex. 1006, p. 7
`
`

`
`RFC 1459 Internet Relay Chat Protocol May 1993
`
` origin of the message. If the prefix is missing from the message, it
` is assumed to have originated from the connection from which it was
` received. Clients should not use prefix when sending a message from
` themselves; if they use a prefix, the only valid prefix is the
` registered nickname associated with the client. If the source
` identified by the prefix cannot be found from the server’s internal
` database, or if the source is registered from a different link than
` from which the message arrived, the server must ignore the message
` silently.
`
` The command must either be a valid IRC command or a three (3) digit
` number represented in ASCII text.
`
` IRC messages are always lines of characters terminated with a CR-LF
` (Carriage Return - Line Feed) pair, and these messages shall not
` exceed 512 characters in length, counting all characters including
` the trailing CR-LF. Thus, there are 510 characters maximum allowed
` for the command and its parameters. There is no provision for
` continuation message lines. See section 7 for more details about
` current implementations.
`
`2.3.1 Message format in ’pseudo’ BNF
`
` The protocol messages must be extracted from the contiguous stream of
` octets. The current solution is to designate two characters, CR and
` LF, as message separators. Empty messages are silently ignored,
` which permits use of the sequence CR-LF between messages
` without extra problems.
`
` The extracted message is parsed into the components <prefix>,
` <command> and list of parameters matched either by <middle> or
` <trailing> components.
`
` The BNF representation for this is:
`
`<message> ::= [’:’ <prefix> <SPACE> ] <command> <params> <crlf>
`<prefix> ::= <servername> | <nick> [ ’!’ <user> ] [ ’@’ <host> ]
`<command> ::= <letter> { <letter> } | <number> <number> <number>
`<SPACE> ::= ’ ’ { ’ ’ }
`<params> ::= <SPACE> [ ’:’ <trailing> | <middle> <params> ]
`
`<middle> ::= <Any *non-empty* sequence of octets not including SPACE
` or NUL or CR or LF, the first of which may not be ’:’>
`<trailing> ::= <Any, possibly *empty*, sequence of octets not including
` NUL or CR or LF>
`
`<crlf> ::= CR LF
`
`Oikarinen & Reed [Page 8]
`
`Petitioner Microsoft Corporation, Ex. 1006, p. 8
`
`

`
`RFC 1459 Internet Relay Chat Protocol May 1993
`
`NOTES:
`
` 1) <SPACE> is consists only of SPACE character(s) (0x20).
` Specially notice that TABULATION, and all other control
` characters are considered NON-WHITE-SPACE.
`
` 2) After extracting the parameter list, all parameters are equal,
` whether matched by <middle> or <trailing>. <Trailing> is just
` a syntactic trick to allow SPACE within parameter.
`
` 3) The fact that CR and LF cannot appear in parameter strings is
` just artifact of the message framing. This might change later.
`
` 4) The NUL character is not special in message framing, and
` basically could end up inside a parameter, but as it would
` cause extra complexities in normal C string handling. Therefore
` NUL is not allowed within messages.
`
` 5) The last parameter may be an empty string.
`
` 6) Use of the extended prefix ([’!’ <user> ] [’@’ <host> ]) must
` not be used in server to server communications and is only
` intended for server to client messages in order to provide
` clients with more useful information about who a message is
` from without the need for additional queries.
`
` Most protocol messages specify additional semantics and syntax for
` the extracted parameter strings dictated by their position in the
` list. For example, many server commands will assume that the first
` parameter after the command is the list of targets, which can be
` described with:
`
` <target> ::= <to> [ "," <target> ]
` <to> ::= <channel> | <user> ’@’ <servername> | <nick> | <mask>
` <channel> ::= (’#’ | ’&’) <chstring>
` <servername> ::= <host>
` <host> ::= see RFC 952 [DNS:4] for details on allowed hostnames
` <nick> ::= <letter> { <letter> | <number> | <special> }
` <mask> ::= (’#’ | ’$’) <chstring>
` <chstring> ::= <any 8bit code except SPACE, BELL, NUL, CR, LF and
` comma (’,’)>
`
` Other parameter syntaxes are:
`
` <user> ::= <nonwhite> { <nonwhite> }
` <letter> ::= ’a’ ... ’z’ | ’A’ ... ’Z’
` <number> ::= ’0’ ... ’9’
` <special> ::= ’-’ | ’[’ | ’]’ | ’\’ | ’‘’ | ’^’ | ’{’ | ’}’
`
`Oikarinen & Reed [Page 9]
`
`Petitioner Microsoft Corporation, Ex. 1006, p. 9
`
`

`
`RFC 1459 Internet Relay Chat Protocol May 1993
`
` <nonwhite> ::= <any 8bit code except SPACE (0x20), NUL (0x0), CR
` (0xd), and LF (0xa)>
`
`2.4 Numeric replies
`
` Most of the messages sent to the server generate a reply of some
` sort. The most common reply is the numeric reply, used for both
` errors and normal replies. The numeric reply must be sent as one
` message consisting of the sender prefix, the three digit numeric, and
` the target of the reply. A numeric reply is not allowed to originate
` from a client; any such messages received by a server are silently
` dropped. In all other respects, a numeric reply is just like a normal
` message, except that the keyword is made up of 3 numeric digits
` rather than a string of letters. A list of different replies is
` supplied in section 6.
`
`3. IRC Concepts.
`
` This section is devoted to describing the actual concepts behind the
` organization of the IRC protocol and how the current
` implementations deliver different classes of messages.
`
` 1--\
` A D---4
` 2--/ \ /
` B----C
` / \
` 3 E
`
` Servers: A, B, C, D, E Clients: 1, 2, 3, 4
`
` [ Fig. 2. Sample small IRC network ]
`
`3.1 One-to-one communication
`
` Communication on a one-to-one basis is usually only performed by
` clients, since most server-server traffic is not a result of servers
` talking only to each other. To provide a secure means for clients to
` talk to each other, it is required that all servers be able to send a
` message in exactly one direction along the spanning tree in order to
` reach any client. The path of a message being delivered is the
` shortest path between any two points on the spanning tree.
`
` The following examples all refer to Figure 2 above.
`
`Oikarinen & Reed [Page 10]
`
`Petitioner Microsoft Corporation, Ex. 1006, p. 10
`
`

`
`RFC 1459 Internet Relay Chat Protocol May 1993
`
`Example 1:
` A message between clients 1 and 2 is only seen by server A, which
` sends it straight to client 2.
`
`Example 2:
` A message between clients 1 and 3 is seen by servers A & B, and
` client 3. No other clients or servers are allowed see the message.
`
`Example 3:
` A message between clients 2 and 4 is seen by servers A, B, C & D
` and client 4 only.
`
`3.2 One-to-many
`
` The main goal of IRC is to provide a forum which allows easy and
` efficient conferencing (one to many conversations). IRC offers
` several means to achieve this, each serving its own purpose.
`
`3.2.1 To a list
`
` The least efficient style of one-to-many conversation is through
` clients talking to a ’list’ of users. How this is done is almost
` self explanatory: the client gives a list of destinations to which
` the message is to be delivered and the server breaks it up and
` dispatches a separate copy of the message to each given destination.
` This isn’t as efficient as using a group since the destination list
` is broken up and the dispatch sent without checking to make sure
` duplicates aren’t sent down each path.
`
`3.2.2 To a group (channel)
`
` In IRC the channel has a role equivalent to that of the multicast
` group; their existence is dynamic (coming and going as people join
` and leave channels) and the actual conversation carried out on a
` channel is only sent to servers which are supporting users on a given
` channel. If there are multiple users on a server in the same
` channel, the message text is sent only once to that server and then
` sent to each client on the channel. This action is then repeated for
` each client-server combination until the original message has fanned
` out and reached each member of the channel.
`
` The following examples all refer to Figure 2.
`
`Example 4:
` Any channel with 1 client in it. Messages to the channel go to the
` server and then nowhere else.
`
`Oikarinen & Reed [Page 11]
`
`Petitioner Microsoft Corporation, Ex. 1006, p. 11
`
`

`
`RFC 1459 Internet Relay Chat Protocol May 1993
`
`Example 5:
` 2 clients in a channel. All messages traverse a path as if they
` were private messages between the two clients outside a channel.
`
`Example 6:
` Clients 1, 2 and 3 in a channel. All messages to the channel are
` sent to all clients and only those servers which must be traversed
` by the message if it were a private message to a single client. If
` client 1 sends a message, it goes back to client 2 and then via
` server B to client 3.
`
`3.2.3 To a host/server mask
`
` To provide IRC operators with some mechanism to send messages to a
` large body of related users, host and server mask messages are
` provided. These messages are sent to users whose host or server
` information match that of the mask. The messages are only sent to
` locations where users are, in a fashion similar to that of channels.
`
`3.3 One-to-all
`
` The one-to-all type of message is better described as a broadcast
` message, sent to all clients or servers or both. On a large network
` of users and servers, a single message can result in a lot of traffic
` being sent over the network in an effort to reach all of the desired
` destinations.
`
` For some messages, there is no option but to broadcast it to all
` servers so that the state information held by each server is
` reasonably consistent between servers.
`
`3.3.1 Client-to-Client
`
` There is no class of message which, from a single message, results in
` a message being sent to every other client.
`
`3.3.2 Client-to-Server
`
` Most of the commands which result in a change of state information
` (such as channel membership, channel mode, user status, etc) must be
` sent to all servers by default, and this distribution may not be
` changed by the client.
`
`3.3.3 Server-to-Server.
`
` While most messages between servers are distributed to all ’other’
` servers, this is only required for any message that affects either a
` user, channel or server. Since these are the basic items found in
`
`Oikarinen & Reed [Page 12]
`
`Petitioner Microsoft Corporation, Ex. 1006, p. 12
`
`

`
`RFC 1459 Internet Relay Chat Protocol May 1993
`
` IRC, nearly all messages originating from a server are broadcast to
` all other connected servers.
`
`4. Message details
`
` On the following pages are descriptions of each message recognized by
` the IRC server and client. All commands described in this section
` must be implemented by any server for this protocol.
`
` Where the reply ERR_NOSUCHSERVER is listed, it means that the
` <server> parameter could not be found. The server must not send any
` other replies after this for that command.
`
` The server to which a client is connected is required to parse the
` complete message, returning any appropriate errors. If the server
` encounters a fatal error while parsing a message, an error must be
` sent back to the client and the parsing terminated. A fatal error
` may be considered to be incorrect command, a destination which is
` otherwise unknown to the server (server, nick or channel names fit
` this category), not enough parameters or incorrect privileges.
`
` If a full set of parameters is presented, then each must be checked
` for validity and appropriate responses sent back to the client. In
` the case of messages which use parameter lists using the comma as an
` item separator, a reply must be sent for each item.
`
` In the examples below, some messages appear using the full format:
`
` :Name COMMAND parameter list
`
` Such examples represent a message from "Name" in transit between
` servers, where it is essential to include the name of the original
` sender of the message so remote server