 |
|
CowCulture 2812 IRC - Internet Relay Chat: Client Protocol
|
 Status of this Memo [166 B] This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
__
Copyright Notice [70 B] Copyright (C) The Internet Society (2000). All Rights Reserved.
__
IESG NOTE: [361 B] The IRC protocol itself enables several possibilities of transferring
data between clients, and just like with other transfer mechanisms
like email, the receiver of the data has to be careful about how the
data is handled. For more inform __
Abstract [301 B] The IRC (Internet Relay Chat) protocol is for use with text based
conferencing; the simplest client being any socket program capable of
connecting to the server.
This document defines the Client Protocol, and assumes that the
reader i __
Table of Contents [5.7 KB]
1. Labels [98 B] This section defines the identifiers used for the various components
of the IRC protocol.
__
1.1 Servers [219 B] Servers are uniquely identified by their name, which has a maximum
length of sixty three (63) characters. See the protocol grammar
rules (section 2.3.1) for what may and may not be used in a server
name.
__
1.2 Clients [193 B] For each client all servers MUST have the following information: a
netwide unique identifier (whose format depends on the type of
client) and the server which introduced the client.
__
1.2.1 Users [388 B] Each user is distinguished from other users by a unique nickname
having a maximum length of nine (9) characters. See the protocol
grammar rules (section 2.3.1) for what may and may not be used in a
nickname.
While the maximum length __
1.2.1.1 Operators [1 KB] To allow a reasonable amount of order to be kept within the IRC
network, a special class of users (operators) is allowed to perform
general maintenance functions on the network. Although the powers
granted to an operator can be considere __
1.2.2 Services [296 B] Each service is distinguished from other services by a service name
composed of a nickname and a server name. As for users, the nickname
has a maximum length of nine (9) characters. See the protocol
grammar rules (section 2.3.1) for wha __
1.3 Channels [887 B] Channels names are strings (beginning with a '&', '#', '+' or '!'
character) of length up to fifty (50) characters. Apart from the
requirement that the first character is either '&', '#', '+' or '!',
any spaces (' '), a control G __
2. The IRC Client Specification [1 B]
2.1 Overview [128 B] The protocol as described herein is for use only with client to
server connections when the client registers as a user.
__
2.2 Character codes [718 B] No specific character set is specified. The protocol is based on 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 __
2.3 Messages [1.74 KB] Servers and clients send each other 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 for __
2.3.1 Message format in Augmented BNF [5.15 KB] 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 __
2.4 Numeric replies [531 B] 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, t __
2.5 Wildcard expressions [1.12 KB] When wildcards are allowed in a string, it is referred as a "mask".
For string matching purposes, the protocol allows the use of two
special characters: '?' (%x3F) to match one and only one character,
and '*' (%x2A) to match an __
3. Message Details [735 B] On the following pages there 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 retur __
3.1 Connection Registration [868 B] The commands described here are used to register a connection with an
IRC server as a user as well as to correctly disconnect.
A "PASS" command is not required for a client connection to be
registered, but it MUST precede the l __
3.1.1 Password message [454 B] Command: PASS
Parameters: <password>
The PASS command is used to set a 'connection password'. The
optional password can and MUST be set before any attempt to register
the connection is made. Currently this requires that use __
3.1.2 Nick message [689 B] Parameters: <nickname>
NICK command is used to give user a nickname or change the existing
one.
Numeric Replies:
ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
ERR_NICKNAMEINUSE ERR_NICKC __
3.1.3 User message [1.13 KB] Command: USER
Parameters: <user> <mode> <unused> <realname>
The USER command is used at the beginning of connection to specify
the username, hostname and realname of a new user.
The <mode> parameter s __
3.1.4 Oper message [715 B] Command: OPER
Parameters: <name> <password>
A normal user uses the OPER command to obtain operator privileges.
The combination of <name> and <password> are REQUIRED to gain
Operator privileges. Upon success __
3.1.5 User mode message [2.39 KB] Command: MODE
Parameters: <nickname>
*( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) )
The user MODE's are typically changes which affect either __
3.1.6 Service message [1.18 KB] Command: SERVICE
Parameters: <nickname> <reserved> <distribution> <type>
<reserved> <info>
The SERVICE command to register a new service. Command parameters
service.
The <dist __
3.1.7 Quit [379 B] Command: QUIT
Parameters: [ <Quit Message> ]
A client session is terminated with a quit message. The server
acknowledges this by sending an ERROR message to the client.
Numeric Replies:
None.
Example:
QU __
3.1.8 Squit [1.34 KB] Command: SQUIT
Parameters: <server> <comment>
The SQUIT command is available only to operators. It is used to
disconnect server links. Also servers can generate SQUIT messages on
error conditions. A SQUIT message may __
3.2 Channel operations [749 B] This group of messages is concerned with manipulating channels, their
properties (channel modes), and their contents (typically users).
For this reason, these messages SHALL NOT be made available to
services.
All of these messages are __
3.2.1 Join message [2.43 KB] Command: JOIN
Parameters: ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] )
/ "0"
The JOIN command is used by a user to request to start listening to
the spe __
3.2.2 Part message [1.12 KB] Command: PART
Parameters: <channel> *( "," <channel> ) [ <Part Message> ]
The PART command causes the user sending the message to be removed
from the list of active members for all given channels listed in __
3.2.3 Channel mode message [3.54 KB] Command: MODE
Parameters: <channel> *( ( "-" / "+" ) *<modes> *<modeparams> )
The MODE command is provided so that users may query and change the
characteristics of a channel. For more details on __
3.2.4 Topic message [1.07 KB] Command: TOPIC
Parameters: <channel> [ <topic> ]
The TOPIC command is used to change or view the topic of a channel.
The topic for channel <channel> is returned if there is no <topic>
given. If the <topi __
3.2.5 Names message [1.23 KB] Command: NAMES
Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]
By using the NAMES command, a user can list all nicknames that are
visible to him. For more details on what is visible and what is no __
3.2.6 List message [793 B] Command: LIST
Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]
The list command is used to list channels and their topics. If the
<channel> parameter is used, only the status of that channel __
3.2.7 Invite message [1.28 KB] Command: INVITE
Parameters: <nickname> <channel>
The INVITE command is used to invite a user to a channel. The
parameter <nickname> is the nickname of the person to be invited to
the target channel <channel> __
3.2.8 Kick command [1.5 KB] Command: KICK
Parameters: <channel> *( "," <channel> ) <user> *( "," <user> )
[<comment>]
The KICK command can be used to request the forced removal of a user
from a cha __
3.3 Sending messages [415 B] The main purpose of the IRC protocol is to provide a base for clients
to communicate with each other. PRIVMSG, NOTICE and SQUERY
(described in Section 3.5 on Service Query and Commands) are the only
messages available which actually perf __
3.3.1 Private messages [2.92 KB] Command: PRIVMSG
Parameters: <msgtarget> <text to be sent>
PRIVMSG is used to send private messages between users, as well as to
send messages to channels. <msgtarget> is usually the nickname of
the recipient of __
3.3.2 Notice [696 B] Command: NOTICE
Parameters: <msgtarget> <text>
The NOTICE command is used similarly to PRIVMSG. The difference
sent in response to a NOTICE message. This rule applies to servers
too - they MUST NOT send any error rep __
3.4 Server queries and commands [553 B] The server query group of commands has been designed to return
information about any server which is connected to the network.
In these queries, where a parameter appears as <target>, wildcard
masks are usually valid. For each par __
3.4.1 Motd message [385 B] Command: MOTD
Parameters: [ <target> ]
The MOTD command is used to get the "Message Of The Day" of the given
server, or current server if <target> is omitted.
Wildcards are allowed in the <target> param __
3.4.2 Lusers message [755 B] Command: LUSERS
Parameters: [ <mask> [ <target> ] ]
The LUSERS command is used to get statistics about the size of the
IRC network. If no parameter is given, the reply will be about the
whole net. If a <mask> is __
3.4.3 Version message [565 B] Command: VERSION
Parameters: [ <target> ]
The VERSION command is used to query the version of the server
program. An optional parameter <target> is used to query the version
of the server program which a client is not __
3.4.4 Stats message [1.6 KB] Command: STATS
Parameters: [ <query> [ <target> ] ]
The stats command is used to query statistics of certain server. If
<query> parameter is omitted, only the end of stats reply is sent
back.
A query may be g __
3.4.5 Links message [947 B] Command: LINKS
Parameters: [ [ <remote server> ] <server mask> ]
With LINKS, a user can list all servernames, which are known by the
server answering the query. The returned list of servers MUST match
the mask, or if n __
3.4.6 Time message [515 B] Command: TIME
Parameters: [ <target> ]
The time command is used to query local time from the specified
server. If the <target> parameter is not given, the server receiving
the command must reply to the query.
Wildca __
3.4.7 Connect message [961 B] Command: CONNECT
Parameters: <target server> <port> [ <remote server> ]
The CONNECT command can be used to request a server to try to
establish a new connection to another server immediately. CONNECT is
a privile __
3.4.8 Trace message [2.34 KB] Command: TRACE
Parameters: [ <target> ]
TRACE command is used to find the route to specific server and
information about its peers. Each server that processes this command
MUST report to the sender about it. The replies fro __
3.4.9 Admin command [717 B] Command: ADMIN
Parameters: [ <target> ]
The admin command is used to find information about the administrator
of the given server, or current server if <target> parameter is
omitted. Each server MUST have the ability t __
3.4.10 Info command [714 B] Command: INFO
Parameters: [ <target> ]
The INFO command is REQUIRED to return information describing the
server: its version, when it was compiled, the patchlevel, when it
was started, and any other miscellaneous information __
3.5 Service Query and Commands [137 B] The service query group of commands has been designed to return
information about any service which is connected to the network.
__
3.5.1 Servlist message [414 B] Command: SERVLIST
Parameters: [ <mask> [ <type> ] ]
The SERVLIST command is used to list services currently connected to
the network and visible to the user issuing the command. The
optional parameters may be used to r __
3.5.2 Squery [643 B] Command: SQUERY
Parameters: <servicename> <text>
The SQUERY command is used similarly to PRIVMSG. The only difference
is that the recipient MUST be a service. This is the only way for a
text message to be delivered to __
3.6 User based queries [492 B] User queries are a group of commands which are primarily concerned
with finding details on a particular user or group users. When using
wildcards with any of these commands, if they match, they will only
return information on users who a __
3.6.1 Who query [1.2 KB] Command: WHO
Parameters: [ <mask> [ "o" ] ]
The WHO command is used by a client to generate a query which returns
a list of information which 'matches' the <mask> parameter given by
the client. In the absence __
3.6.2 Whois query [1.37 KB] Command: WHOIS
Parameters: [ <target> ] <mask> *( "," <mask> )
This command is used to query information about particular user.
The server will answer this command with several numeric messages
indicatin __
3.6.3 Whowas [1.51 KB] Command: WHOWAS
Parameters: <nickname> *( "," <nickname> ) [ <count> [ <target> ] ]
Whowas asks for information about a nickname which no longer exists.
This may either be due to a nickname change or __
3.7 Miscellaneous messages [144 B] Messages in this category do not fit into any of the above categories
but are nonetheless still a part of and REQUIRED by the protocol.
__
3.7.1 Kill message [2.43 KB] Command: KILL
Parameters: <nickname> <comment>
The KILL command is used to cause a client-server connection to be
closed by the server which has the actual connection. Servers
generate KILL messages on nickname collisi __
3.7.2 Ping message [1.18 KB] Command: PING
Parameters: <server1> [ <server2> ]
The PING command is used to test the presence of an active client or
server at the other end of the connection. Servers send a PING
message at regular intervals if no o __
3.7.3 Pong message [545 B] Command: PONG
Parameters: <server> [ <server2> ]
PONG message is a reply to ping message. If parameter <server2> is
given, this message MUST be forwarded to given target. The <server>
parameter is the name __
3.7.4 Error [1.25 KB] Command: ERROR
Parameters: <error message>
The ERROR command is for use by servers when reporting a serious or
fatal error to its peers. It may also be sent from one server to
another but MUST NOT be accepted from any normal __
4. Optional features [529 B] This section describes OPTIONAL messages. They are not required in a
working server implementation of the protocol described herein. In
the absence of the feature, an error reply message MUST be generated
or an unknown command error. I __
4.1 Away [1.03 KB] Command: AWAY
Parameters: [ <text> ]
With the AWAY command, clients can set an automatic reply string for
any PRIVMSG commands directed at them (not to a channel they are on).
The server sends an automatic reply to the client __
4.2 Rehash message [496 B] Command: REHASH
Parameters: None
The rehash command is an administrative command which can be used by
an operator to force the server to re-read and process its
configuration file.
Numeric Replies:
RPL_REHASHING __
4.3 Die message [552 B] Command: DIE
Parameters: None
An operator can use the DIE command to shutdown the server. This
message is optional since it may be viewed as a risk to allow
arbitrary people to connect to a server as an operator and execute
thi __
4.4 Restart message [624 B] Command: RESTART
Parameters: None
An operator can use the restart command to force the server to
restart itself. This message is optional since it may be viewed as a
risk to allow arbitrary people to connect to a server as an oper __
4.5 Summon message [1.07 KB] Command: SUMMON
Parameters: <user> [ <target> [ <channel> ] ]
The SUMMON command can be used to give users who are on a host
running an IRC server a message asking them to please join IRC. This
message is only se __
4.6 Users [1.01 KB] Command: USERS
Parameters: [ <target> ]
The USERS command returns a list of users logged into the server in a
format similar to the UNIX commands who(1), rusers(1) and finger(1).
If disabled, the correct numeric MUST be retur __
4.7 Operwall message [812 B] Command: WALLOPS
Parameters: <Text to be sent>
connected users who have set the 'w' user mode for themselves. (See
Section 3.1.5 "User modes").
After implementing WALLOPS as a user command it was found that it was __
4.8 Userhost message [712 B] Command: USERHOST
Parameters: <nickname> *( SPACE <nickname> )
The USERHOST command takes a list of up to 5 nicknames, each
separated by a space character and returns a list of information
about each nickname that it fo __
4.9 Ison message [1.08 KB] Command: ISON
Parameters: <nickname> *( SPACE <nickname> )
The ISON command was implemented to provide a quick and efficient
on IRC. ISON only takes one (1) type of parameter: a space-separated
list of nicks. For each __
5. Replies [178 B] The following is a list of numeric replies which are generated in
response to the commands given above. Each numeric is given with its
number, name and reply string.
__
5.1 Command responses [19 KB] Numerics in the range from 001 to 099 are used for client-server
connections only and should never travel between servers. Replies
generated in the response to commands are found in the range from 200
to 399.
001 RPL_WELCOME
__
5.2 Error Replies [11.02 KB] Error replies are found in the range from 400 to 599.
401 ERR_NOSUCHNICK
"<nickname> :No such nick/channel"
- Used to indicate the nickname parameter supplied to a
command is curr __
5.3 Reserved numerics [987 B] These numerics are not described above since they fall into one of
the following categories:
1. no longer in use;
2. reserved for future planned use;
3. in current use but are part of a non-generic 'feature' of
the current IRC __
6. Current implementations [370 B] The IRC software, version 2.10 is the only complete implementation of
the IRC protocol (client and server). Because of the small amount of
changes in the client protocol since the publication of RFC 1459
[IRC], implementations that follo __
7. Current problems [276 B] There are a number of recognized problems with the IRC Client
Protocol, and more generally with the IRC Server Protocol. In order
to preserve backward compatibility with old clients, this protocol
has almost not evolved since the publica __
7.1 Nicknames [353 B] The idea of the nickname on IRC is very convenient for users to use
when talking to each other outside of a channel, but there is only a
several people to want to use the same nick. If a nickname is chosen
by two people using this protoc __
7.2 Limitation of wildcards [218 B] There is no way to escape the escape character "" (%x5C). While
this isn't usually a problem, it makes it impossible to form a mask
with a backslash character ("") preceding a wildcard.
__
7.3 Security considerations [185 B] Security issues related to this protocol are discussed in the "IRC
Server Protocol" [IRC-SERVER] as they are mostly an issue for the
server side of the connection.
__
8. Current support and availability [334 B] Mailing lists for IRC related discussion:
General discussion: ircd-users@irc.org
Protocol development: ircd-dev@irc.org
Software implementations:
ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi __
9. Acknowledgements [333 B] Parts of this document were copied from the RFC 1459 [IRC] which
first formally documented the IRC Protocol. It has also benefited
from many rounds of review and comments. In particular, the
document:
Matthew Green, Michael Neumayer __
10. References [909 B] [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specification __
11. Author's Address [105 B] Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
EMail: kalt@stealth.net
__
12. Full Copyright Statement [1.43 KB] Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may __
Acknowledgement [91 B] Funding for the RFC Editor function is currently provided by the
Internet Society.
__
|
Gogloom.com - Loading
- Please, wait
Search Examples: