rfc2813.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,460 行 · 第 1/4 页
TXT
1,460 行
Network Working Group C. Kalt
Request for Comments: 2813 April 2000
Updates: 1459
Category: Informational
Internet Relay Chat: Server Protocol
Status of this Memo
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
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
While based on the client-server model, the IRC (Internet Relay Chat)
protocol allows servers to connect to each other effectively forming
a network.
This document defines the protocol used by servers to talk to each
other. It was originally a superset of the client protocol but has
evolved differently.
First formally documented in May 1993 as part of RFC 1459 [IRC], most
of the changes brought since then can be found in this document as
development was focused on making the protocol scale better. Better
scalability has allowed existing world-wide networks to keep growing
and reach sizes which defy the old specification.
Kalt Informational [Page 1]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
Table of Contents
1. Introduction ............................................... 3
2. Global database ............................................ 3
2.1 Servers ................................................ 3
2.2 Clients ................................................ 4
2.2.1 Users ............................................. 4
2.2.2 Services .......................................... 4
2.3 Channels ............................................... 4
3. The IRC Server Specification ............................... 5
3.1 Overview ............................................... 5
3.2 Character codes ........................................ 5
3.3 Messages ............................................... 5
3.3.1 Message format in Augmented BNF ................... 6
3.4 Numeric replies ........................................ 7
4. Message Details ............................................ 7
4.1 Connection Registration ................................ 8
4.1.1 Password message .................................. 8
4.1.2 Server message .................................... 9
4.1.3 Nick .............................................. 10
4.1.4 Service message ................................... 11
4.1.5 Quit .............................................. 12
4.1.6 Server quit message ............................... 13
4.2 Channel operations ..................................... 14
4.2.1 Join message ...................................... 14
4.2.2 Njoin message ..................................... 15
4.2.3 Mode message ...................................... 16
5. Implementation details .................................... 16
5.1 Connection 'Liveness' .................................. 16
5.2 Accepting a client to server connection ................ 16
5.2.1 Users ............................................. 16
5.2.2 Services .......................................... 17
5.3 Establishing a server-server connection. ............... 17
5.3.1 Link options ...................................... 17
5.3.1.1 Compressed server to server links ............ 18
5.3.1.2 Anti abuse protections ....................... 18
5.3.2 State information exchange when connecting ........ 18
5.4 Terminating server-client connections .................. 19
5.5 Terminating server-server connections .................. 19
5.6 Tracking nickname changes .............................. 19
5.7 Tracking recently used nicknames ....................... 20
5.8 Flood control of clients ............................... 20
5.9 Non-blocking lookups ................................... 21
5.9.1 Hostname (DNS) lookups ............................ 21
5.9.2 Username (Ident) lookups .......................... 21
6. Current problems ........................................... 21
6.1 Scalability ............................................ 21
6.2 Labels ................................................. 22
Kalt Informational [Page 2]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
6.2.1 Nicknames ......................................... 22
6.2.2 Channels .......................................... 22
6.2.3 Servers ........................................... 22
6.3 Algorithms ............................................. 22
7. Security Considerations .................................... 23
7.1 Authentication ......................................... 23
7.2 Integrity .............................................. 23
8. Current support and availability ........................... 24
9. Acknowledgements ........................................... 24
10. References ................................................ 24
11. Author's Address .......................................... 25
12. Full Copyright Statement ................................... 26
1. Introduction
This document is intended for people working on implementing an IRC
server but will also be useful to anyone implementing an IRC service.
Servers provide the three basic services required for realtime
conferencing defined by the "Internet Relay Chat: Architecture"
[IRC-ARCH]: client locator (via the client protocol [IRC-CLIENT]),
message relaying (via the server protocol defined in this document)
and channel hosting and management (following specific rules [IRC-
CHAN]).
2. Global database
Although the IRC Protocol defines a fairly distributed model, each
server maintains a "global state database" about the whole IRC
network. This database is, in theory, identical on all servers.
2.1 Servers
Servers are uniquely identified by their name which has a maximum
length of sixty three (63) characters. See the protocol grammar
rules (section 3.3.1) for what may and may not be used in a server
name.
Each server is typically known by all other servers, however it is
possible to define a "hostmask" to group servers together according
to their name. Inside the hostmasked area, all the servers have a
name which matches the hostmask, and any other server with a name
matching the hostmask SHALL NOT be connected to the IRC network
outside the hostmasked area. Servers which are outside the area have
no knowledge of the individual servers present inside the area,
instead they are presented with a virtual server which has the
hostmask for name.
Kalt Informational [Page 3]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
2.2 Clients
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 to which the client is connected.
2.2.1 Users
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 3.3.1) 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 users: the name of the host that the
user is running on, the username of the user on that host, and the
server to which the client is connected.
2.2.2 Services
Each service is distinguished from other services by a service name
composed of a nickname and a server name. The nickname has a maximum
length of nine (9) characters. See the protocol grammar rules
(section 3.3.1) for what may and may not be used in a nickname. The
server name used to compose the service name is the name of the
server to which the service is connected. In addition to this
service name all servers MUST know the service type.
Services differ from users by the format of their identifier, but
more importantly services and users don't have the same type of
access to the server: services can request part or all of the global
state information that a server maintains, but have a more restricted
set of commands available to them (See "IRC Client Protocol" [IRC-
CLIENT] for details on which) and are not allowed to join channels.
Finally services are not usually subject to the "Flood control"
mechanism described in section 5.8.
2.3 Channels
Alike services, channels have a scope [IRC-CHAN] and are not
necessarily known to all servers. When a channel existence is known
to a server, the server MUST keep track of the channel members, as
well as the channel modes.
Kalt Informational [Page 4]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
3. The IRC Server Specification
3.1 Overview
The protocol as described herein is for use with server to server
connections. For client to server connections, see the IRC Client
Protocol specification.
There are, however, more restrictions on client connections (which
are considered to be untrustworthy) than on server connections.
3.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 US-ASCII terminal and a
telnet connection.
Because of IRC's Scandinavian 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, or channel names.
3.3 Messages
Servers and clients send each other messages which may or may not
generate a reply. Most communication between servers do not generate
any reply, as servers mostly perform routing tasks for the clients.
Each IRC message may consist of up to three main parts: the prefix
(OPTIONAL), the command, and the command parameters (maximum of
fifteen (15)). The prefix, command, and all parameters are separated
by one ASCII space character (0x20) each.
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
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 a prefix when sending a message
from themselves; if they use one, the only valid prefix is the
registered nickname associated with the client.
Kalt Informational [Page 5]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
When a server receives a message, it MUST identify its source using
the (eventually assumed) prefix. If the prefix cannot be found in
the server's internal database, it MUST be discarded, and if the
prefix indicates the message comes from an (unknown) server, the link
from which the message was received MUST be dropped. Dropping a link
in such circumstances is a little excessive but necessary to maintain
the integrity of the network and to prevent future problems. Another
common error condition is that the prefix found in the server's
internal database identifies a different source (typically a source
registered from a different link than from which the message
arrived). If the message was received from a server link and the
prefix identifies a client, a KILL message MUST be issued for the
client and sent to all servers. In other cases, the link from which
the message arrived SHOULD be dropped for clients, and MUST be
dropped for servers. In all cases, the message MUST be discarded.
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 5 for more details about
current implementations.
3.3.1 Message format in Augmented 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 (<params>).
The Augmented BNF representation for this is found in "IRC Client
Protocol" [IRC-CLIENT].
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.
Kalt Informational [Page 6]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
3.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 "IRC Client Protocol" [IRC-CLIENT].
4. Message Details
All the messages recognized by the IRC server and client are
described in the IRC Client Protocol specification.
Where the reply ERR_NOSUCHSERVER is returned, it means that the
target of the message could not be found. The server MUST NOT send
any other replies after this error for that command.
The server to which a client is connected is required to parse the
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?