1 |
$Id$ |
2 |
|
3 |
Network Working Group C. Kalt |
4 |
Request for Comments: 2813 April 2000 |
5 |
Updates: 1459 |
6 |
Category: Informational |
7 |
|
8 |
Internet Relay Chat: Server Protocol |
9 |
|
10 |
Status of this Memo |
11 |
|
12 |
This memo provides information for the Internet community. It does |
13 |
not specify an Internet standard of any kind. Distribution of this |
14 |
memo is unlimited. |
15 |
|
16 |
Copyright Notice |
17 |
|
18 |
Copyright (C) The Internet Society (2000). All Rights Reserved. |
19 |
|
20 |
Abstract |
21 |
|
22 |
While based on the client-server model, the IRC (Internet Relay Chat) |
23 |
protocol allows servers to connect to each other effectively forming |
24 |
a network. |
25 |
|
26 |
This document defines the protocol used by servers to talk to each |
27 |
other. It was originally a superset of the client protocol but has |
28 |
evolved differently. |
29 |
|
30 |
First formally documented in May 1993 as part of RFC 1459 [IRC], most |
31 |
of the changes brought since then can be found in this document as |
32 |
development was focused on making the protocol scale better. Better |
33 |
scalability has allowed existing world-wide networks to keep growing |
34 |
and reach sizes which defy the old specification. |
35 |
|
36 |
Table of Contents |
37 |
|
38 |
1. Introduction ............................................... 3 |
39 |
2. Global database ............................................ 3 |
40 |
2.1 Servers ................................................ 3 |
41 |
2.2 Clients ................................................ 4 |
42 |
2.2.1 Users ............................................. 4 |
43 |
2.2.2 Services .......................................... 4 |
44 |
2.3 Channels ............................................... 4 |
45 |
3. The IRC Server Specification ............................... 5 |
46 |
3.1 Overview ............................................... 5 |
47 |
3.2 Character codes ........................................ 5 |
48 |
3.3 Messages ............................................... 5 |
49 |
3.3.1 Message format in Augmented BNF ................... 6 |
50 |
3.4 Numeric replies ........................................ 7 |
51 |
4. Message Details ............................................ 7 |
52 |
4.1 Connection Registration ................................ 8 |
53 |
4.1.1 Password message .................................. 8 |
54 |
4.1.2 Server message .................................... 9 |
55 |
4.1.3 Nick .............................................. 10 |
56 |
4.1.4 Service message ................................... 11 |
57 |
4.1.5 Quit .............................................. 12 |
58 |
4.1.6 Server quit message ............................... 13 |
59 |
4.2 Channel operations ..................................... 14 |
60 |
4.2.1 Join message ...................................... 14 |
61 |
4.2.2 Njoin message ..................................... 15 |
62 |
4.2.3 Mode message ...................................... 16 |
63 |
5. Implementation details .................................... 16 |
64 |
5.1 Connection 'Liveness' .................................. 16 |
65 |
5.2 Accepting a client to server connection ................ 16 |
66 |
5.2.1 Users ............................................. 16 |
67 |
5.2.2 Services .......................................... 17 |
68 |
5.3 Establishing a server-server connection. ............... 17 |
69 |
5.3.1 Link options ...................................... 17 |
70 |
5.3.1.1 Compressed server to server links ............ 18 |
71 |
5.3.1.2 Anti abuse protections ....................... 18 |
72 |
5.3.2 State information exchange when connecting ........ 18 |
73 |
5.4 Terminating server-client connections .................. 19 |
74 |
5.5 Terminating server-server connections .................. 19 |
75 |
5.6 Tracking nickname changes .............................. 19 |
76 |
5.7 Tracking recently used nicknames ....................... 20 |
77 |
5.8 Flood control of clients ............................... 20 |
78 |
5.9 Non-blocking lookups ................................... 21 |
79 |
5.9.1 Hostname (DNS) lookups ............................ 21 |
80 |
5.9.2 Username (Ident) lookups .......................... 21 |
81 |
6. Current problems ........................................... 21 |
82 |
6.1 Scalability ............................................ 21 |
83 |
6.2 Labels ................................................. 22 |
84 |
|
85 |
6.2.1 Nicknames ......................................... 22 |
86 |
6.2.2 Channels .......................................... 22 |
87 |
6.2.3 Servers ........................................... 22 |
88 |
6.3 Algorithms ............................................. 22 |
89 |
7. Security Considerations .................................... 23 |
90 |
7.1 Authentication ......................................... 23 |
91 |
7.2 Integrity .............................................. 23 |
92 |
8. Current support and availability ........................... 24 |
93 |
9. Acknowledgements ........................................... 24 |
94 |
10. References ................................................ 24 |
95 |
11. Author's Address .......................................... 25 |
96 |
12. Full Copyright Statement ................................... 26 |
97 |
|
98 |
1. Introduction |
99 |
|
100 |
This document is intended for people working on implementing an IRC |
101 |
server but will also be useful to anyone implementing an IRC service. |
102 |
|
103 |
Servers provide the three basic services required for realtime |
104 |
conferencing defined by the "Internet Relay Chat: Architecture" |
105 |
[IRC-ARCH]: client locator (via the client protocol [IRC-CLIENT]), |
106 |
message relaying (via the server protocol defined in this document) |
107 |
and channel hosting and management (following specific rules [IRC- |
108 |
CHAN]). |
109 |
|
110 |
2. Global database |
111 |
|
112 |
Although the IRC Protocol defines a fairly distributed model, each |
113 |
server maintains a "global state database" about the whole IRC |
114 |
network. This database is, in theory, identical on all servers. |
115 |
|
116 |
2.1 Servers |
117 |
|
118 |
Servers are uniquely identified by their name which has a maximum |
119 |
length of sixty three (63) characters. See the protocol grammar |
120 |
rules (section 3.3.1) for what may and may not be used in a server |
121 |
name. |
122 |
|
123 |
Each server is typically known by all other servers, however it is |
124 |
possible to define a "hostmask" to group servers together according |
125 |
to their name. Inside the hostmasked area, all the servers have a |
126 |
name which matches the hostmask, and any other server with a name |
127 |
matching the hostmask SHALL NOT be connected to the IRC network |
128 |
outside the hostmasked area. Servers which are outside the area have |
129 |
no knowledge of the individual servers present inside the area, |
130 |
instead they are presented with a virtual server which has the |
131 |
hostmask for name. |
132 |
|
133 |
2.2 Clients |
134 |
|
135 |
For each client, all servers MUST have the following information: a |
136 |
netwide unique identifier (whose format depends on the type of |
137 |
client) and the server to which the client is connected. |
138 |
|
139 |
2.2.1 Users |
140 |
|
141 |
Each user is distinguished from other users by a unique nickname |
142 |
having a maximum length of nine (9) characters. See the protocol |
143 |
grammar rules (section 3.3.1) for what may and may not be used in a |
144 |
nickname. In addition to the nickname, all servers MUST have the |
145 |
following information about all users: the name of the host that the |
146 |
user is running on, the username of the user on that host, and the |
147 |
server to which the client is connected. |
148 |
|
149 |
2.2.2 Services |
150 |
|
151 |
Each service is distinguished from other services by a service name |
152 |
composed of a nickname and a server name. The nickname has a maximum |
153 |
length of nine (9) characters. See the protocol grammar rules |
154 |
(section 3.3.1) for what may and may not be used in a nickname. The |
155 |
server name used to compose the service name is the name of the |
156 |
server to which the service is connected. In addition to this |
157 |
service name all servers MUST know the service type. |
158 |
|
159 |
Services differ from users by the format of their identifier, but |
160 |
more importantly services and users don't have the same type of |
161 |
access to the server: services can request part or all of the global |
162 |
state information that a server maintains, but have a more restricted |
163 |
set of commands available to them (See "IRC Client Protocol" [IRC- |
164 |
CLIENT] for details on which) and are not allowed to join channels. |
165 |
Finally services are not usually subject to the "Flood control" |
166 |
mechanism described in section 5.8. |
167 |
|
168 |
2.3 Channels |
169 |
|
170 |
Alike services, channels have a scope [IRC-CHAN] and are not |
171 |
necessarily known to all servers. When a channel existence is known |
172 |
to a server, the server MUST keep track of the channel members, as |
173 |
well as the channel modes. |
174 |
|
175 |
3. The IRC Server Specification |
176 |
|
177 |
3.1 Overview |
178 |
|
179 |
The protocol as described herein is for use with server to server |
180 |
connections. For client to server connections, see the IRC Client |
181 |
Protocol specification. |
182 |
|
183 |
There are, however, more restrictions on client connections (which |
184 |
are considered to be untrustworthy) than on server connections. |
185 |
|
186 |
3.2 Character codes |
187 |
|
188 |
No specific character set is specified. The protocol is based on a a |
189 |
set of codes which are composed of eight (8) bits, making up an |
190 |
octet. Each message may be composed of any number of these octets; |
191 |
however, some octet values are used for control codes which act as |
192 |
message delimiters. |
193 |
|
194 |
Regardless of being an 8-bit protocol, the delimiters and keywords |
195 |
are such that protocol is mostly usable from US-ASCII terminal and a |
196 |
telnet connection. |
197 |
|
198 |
Because of IRC's Scandinavian origin, the characters {}|^ are |
199 |
considered to be the lower case equivalents of the characters []\~, |
200 |
respectively. This is a critical issue when determining the |
201 |
equivalence of two nicknames, or channel names. |
202 |
|
203 |
3.3 Messages |
204 |
|
205 |
Servers and clients send each other messages which may or may not |
206 |
generate a reply. Most communication between servers do not generate |
207 |
any reply, as servers mostly perform routing tasks for the clients. |
208 |
|
209 |
Each IRC message may consist of up to three main parts: the prefix |
210 |
(OPTIONAL), the command, and the command parameters (maximum of |
211 |
fifteen (15)). The prefix, command, and all parameters are separated |
212 |
by one ASCII space character (0x20) each. |
213 |
|
214 |
The presence of a prefix is indicated with a single leading ASCII |
215 |
colon character (':', 0x3b), which MUST be the first character of the |
216 |
message itself. There MUST be NO gap (whitespace) between the colon |
217 |
and the prefix. The prefix is used by servers to indicate the true |
218 |
origin of the message. If the prefix is missing from the message, it |
219 |
is assumed to have originated from the connection from which it was |
220 |
received. Clients SHOULD not use a prefix when sending a message |
221 |
from themselves; if they use one, the only valid prefix is the |
222 |
registered nickname associated with the client. |
223 |
|
224 |
When a server receives a message, it MUST identify its source using |
225 |
the (eventually assumed) prefix. If the prefix cannot be found in |
226 |
the server's internal database, it MUST be discarded, and if the |
227 |
prefix indicates the message comes from an (unknown) server, the link |
228 |
from which the message was received MUST be dropped. Dropping a link |
229 |
in such circumstances is a little excessive but necessary to maintain |
230 |
the integrity of the network and to prevent future problems. Another |
231 |
common error condition is that the prefix found in the server's |
232 |
internal database identifies a different source (typically a source |
233 |
registered from a different link than from which the message |
234 |
arrived). If the message was received from a server link and the |
235 |
prefix identifies a client, a KILL message MUST be issued for the |
236 |
client and sent to all servers. In other cases, the link from which |
237 |
the message arrived SHOULD be dropped for clients, and MUST be |
238 |
dropped for servers. In all cases, the message MUST be discarded. |
239 |
|
240 |
The command MUST either be a valid IRC command or a three (3) digit |
241 |
number represented in ASCII text. |
242 |
|
243 |
IRC messages are always lines of characters terminated with a CR-LF |
244 |
(Carriage Return - Line Feed) pair, and these messages SHALL NOT |
245 |
exceed 512 characters in length, counting all characters including |
246 |
the trailing CR-LF. Thus, there are 510 characters maximum allowed |
247 |
for the command and its parameters. There is no provision for |
248 |
continuation message lines. See section 5 for more details about |
249 |
current implementations. |
250 |
|
251 |
3.3.1 Message format in Augmented BNF |
252 |
|
253 |
The protocol messages must be extracted from the contiguous stream of |
254 |
octets. The current solution is to designate two characters, CR and |
255 |
LF, as message separators. Empty messages are silently ignored, |
256 |
which permits use of the sequence CR-LF between messages without |
257 |
extra problems. |
258 |
|
259 |
The extracted message is parsed into the components <prefix>, |
260 |
<command> and list of parameters (<params>). |
261 |
|
262 |
The Augmented BNF representation for this is found in "IRC Client |
263 |
Protocol" [IRC-CLIENT]. |
264 |
|
265 |
The extended prefix (["!" user "@" host ]) MUST NOT be used in server |
266 |
to server communications and is only intended for server to client |
267 |
messages in order to provide clients with more useful information |
268 |
about who a message is from without the need for additional queries. |
269 |
|
270 |
3.4 Numeric replies |
271 |
|
272 |
Most of the messages sent to the server generate a reply of some |
273 |
sort. The most common reply is the numeric reply, used for both |
274 |
errors and normal replies. The numeric reply MUST be sent as one |
275 |
message consisting of the sender prefix, the three digit numeric, and |
276 |
the target of the reply. A numeric reply is not allowed to originate |
277 |
from a client; any such messages received by a server are silently |
278 |
dropped. In all other respects, a numeric reply is just like a normal |
279 |
message, except that the keyword is made up of 3 numeric digits |
280 |
rather than a string of letters. A list of different replies is |
281 |
supplied in "IRC Client Protocol" [IRC-CLIENT]. |
282 |
|
283 |
4. Message Details |
284 |
|
285 |
All the messages recognized by the IRC server and client are |
286 |
described in the IRC Client Protocol specification. |
287 |
|
288 |
Where the reply ERR_NOSUCHSERVER is returned, it means that the |
289 |
target of the message could not be found. The server MUST NOT send |
290 |
any other replies after this error for that command. |
291 |
|
292 |
The server to which a client is connected is required to parse the |
293 |
complete message, returning any appropriate errors. If the server |
294 |
encounters a fatal error while parsing a message, an error MUST be |
295 |
sent back to the client and the parsing terminated. A fatal error |
296 |
may follow from incorrect command, a destination which is otherwise |
297 |
unknown to the server (server, client or channel names fit this |
298 |
category), not enough parameters or incorrect privileges. |
299 |
|
300 |
If a full set of parameters is presented, then each MUST be checked |
301 |
for validity and appropriate responses sent back to the client. In |
302 |
the case of messages which use parameter lists using the comma as an |
303 |
item separator, a reply MUST be sent for each item. |
304 |
|
305 |
In the examples below, some messages appear using the full format: |
306 |
|
307 |
:Name COMMAND parameter list |
308 |
|
309 |
Such examples represent a message from "Name" in transit between |
310 |
servers, where it is essential to include the name of the original |
311 |
sender of the message so remote servers may send back a reply along |
312 |
the correct path. |
313 |
|
314 |
The message details for client to server communication are described |
315 |
in the "IRC Client Protocol" [IRC-CLIENT]. Some sections in the |
316 |
following pages apply to some of these messages, they are additions |
317 |
to the message specifications which are only relevant to server to |
318 |
|
319 |
server communication, or to the server implementation. The messages |
320 |
which are introduced here are only used for server to server |
321 |
communication. |
322 |
|
323 |
4.1 Connection Registration |
324 |
|
325 |
The commands described here are used to register a connection with |
326 |
another IRC server. |
327 |
|
328 |
4.1.1 Password message |
329 |
|
330 |
Command: PASS |
331 |
Parameters: <password> <version> <flags> [<options>] |
332 |
|
333 |
The PASS command is used to set a 'connection password'. The |
334 |
password MUST be set before any attempt to register the connection is |
335 |
made. Currently this means that servers MUST send a PASS command |
336 |
before any SERVER command. Only one (1) PASS command SHALL be |
337 |
accepted from a connection. |
338 |
|
339 |
The last three (3) parameters MUST be ignored if received from a |
340 |
client (e.g. a user or a service). They are only relevant when |
341 |
received from a server. |
342 |
|
343 |
The <version> parameter is a string of at least four (4) characters, |
344 |
and up to fourteen (14) characters. The first four (4) characters |
345 |
MUST be digits and indicate the protocol version known by the server |
346 |
issuing the message. The protocol described by this document is |
347 |
version 2.10 which is encoded as "0210". The remaining OPTIONAL |
348 |
characters are implementation dependent and should describe the |
349 |
software version number. |
350 |
|
351 |
The <flags> parameter is a string of up to one hundred (100) |
352 |
characters. It is composed of two substrings separated by the |
353 |
character "|" (%x7C). If present, the first substring MUST be the |
354 |
name of the implementation. The reference implementation (See |
355 |
Section 8, "Current support and availability") uses the string "IRC". |
356 |
If a different implementation is written, which needs an identifier, |
357 |
then that identifier should be registered through publication of an |
358 |
RFC. The second substring is implementation dependent. Both |
359 |
substrings are OPTIONAL, but the character "|" is REQUIRED. The |
360 |
character "|" MUST NOT appear in either substring. |
361 |
|
362 |
Finally, the last parameter, <options>, is used for link options. |
363 |
The only options defined by the protocol are link compression (using |
364 |
the character "Z"), and an abuse protection flag (using the character |
365 |
|
366 |
"P"). See sections 5.3.1.1 (Compressed server to server links) and |
367 |
5.3.1.2 (Anti abuse protections) respectively for more information on |
368 |
these options. |
369 |
|
370 |
Numeric Replies: |
371 |
|
372 |
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED |
373 |
|
374 |
Example: |
375 |
|
376 |
PASS moresecretpassword 0210010000 IRC|aBgH$ Z |
377 |
|
378 |
4.1.2 Server message |
379 |
|
380 |
Command: SERVER |
381 |
Parameters: <servername> <hopcount> <token> <info> |
382 |
|
383 |
The SERVER command is used to register a new server. A new connection |
384 |
introduces itself as a server to its peer. This message is also used |
385 |
to pass server data over whole net. When a new server is connected |
386 |
to net, information about it MUST be broadcasted to the whole |
387 |
network. |
388 |
|
389 |
The <info> parameter may contain space characters. |
390 |
|
391 |
<hopcount> is used to give all servers some internal information on |
392 |
how far away each server is. Local peers have a value of 0, and each |
393 |
passed server increments the value. With a full server list, it |
394 |
would be possible to construct a map of the entire server tree, but |
395 |
hostmasks prevent this from being done. |
396 |
|
397 |
The <token> parameter is an unsigned number used by servers as an |
398 |
identifier. This identifier is subsequently used to reference a |
399 |
server in the NICK and SERVICE messages sent between servers. Server |
400 |
tokens only have a meaning for the point-to-point peering they are |
401 |
used and MUST be unique for that connection. They are not global. |
402 |
|
403 |
The SERVER message MUST only be accepted from either (a) a connection |
404 |
which is yet to be registered and is attempting to register as a |
405 |
server, or (b) an existing connection to another server, in which |
406 |
case the SERVER message is introducing a new server behind that |
407 |
server. |
408 |
|
409 |
Most errors that occur with the receipt of a SERVER command result in |
410 |
the connection being terminated by the destination host (target |
411 |
SERVER). Because of the severity of such event, error replies are |
412 |
usually sent using the "ERROR" command rather than a numeric. |
413 |
|
414 |
If a SERVER message is parsed and it attempts to introduce a server |
415 |
which is already known to the receiving server, the connection, from |
416 |
which that message arrived, MUST be closed (following the correct |
417 |
procedures), since a duplicate route to a server has been formed and |
418 |
the acyclic nature of the IRC tree breaks. In some conditions, the |
419 |
connection from which the already known server has registered MAY be |
420 |
closed instead. It should be noted that this kind of error can also |
421 |
be the result of a second running server, problem which cannot be |
422 |
fixed within the protocol and typically requires human intervention. |
423 |
This type of problem is particularly insidious, as it can quite |
424 |
easily result in part of the IRC network to be isolated, with one of |
425 |
the two servers connected to each partition therefore making it |
426 |
impossible for the two parts to unite. |
427 |
|
428 |
Numeric Replies: |
429 |
|
430 |
ERR_ALREADYREGISTRED |
431 |
|
432 |
Example: |
433 |
|
434 |
SERVER test.oulu.fi 1 1 :Experimental server ; New server |
435 |
test.oulu.fi introducing itself and |
436 |
attempting to register. |
437 |
|
438 |
:tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server |
439 |
tolsun.oulu.fi is our uplink for |
440 |
csd.bu.edu which is 5 hops away. The |
441 |
token "34" will be used by |
442 |
tolsun.oulu.fi when introducing new |
443 |
users or services connected to |
444 |
csd.bu.edu. |
445 |
|
446 |
4.1.3 Nick |
447 |
|
448 |
Command: NICK |
449 |
Parameters: <nickname> <hopcount> <username> <host> <servertoken> |
450 |
<umode> <realname> |
451 |
|
452 |
This form of the NICK message MUST NOT be allowed from user |
453 |
connections. However, it MUST be used instead of the NICK/USER pair |
454 |
to notify other servers of new users joining the IRC network. |
455 |
|
456 |
This message is really the combination of three distinct messages: |
457 |
NICK, USER and MODE [IRC-CLIENT]. |
458 |
|
459 |
The <hopcount> parameter is used by servers to indicate how far away |
460 |
a user is from its home server. A local connection has a hopcount of |
461 |
0. The hopcount value is incremented by each passed server. |
462 |
|
463 |
The <servertoken> parameter replaces the <servername> parameter of |
464 |
the USER (See section 4.1.2 for more information on server tokens). |
465 |
|
466 |
Examples: |
467 |
|
468 |
NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New |
469 |
user with nickname "syrk", username |
470 |
"kalt", connected from host |
471 |
"millennium.stealth.net" to server |
472 |
"34" ("csd.bu.edu" according to the |
473 |
previous example). |
474 |
|
475 |
:krys NICK syrk ; The other form of the NICK message, |
476 |
as defined in "IRC Client Protocol" |
477 |
[IRC-CLIENT] and used between |
478 |
servers: krys changed his nickname to |
479 |
syrk |
480 |
|
481 |
4.1.4 Service message |
482 |
|
483 |
Command: SERVICE |
484 |
Parameters: <servicename> <servertoken> <distribution> <type> |
485 |
<hopcount> <info> |
486 |
|
487 |
The SERVICE command is used to introduce a new service. This form of |
488 |
the SERVICE message SHOULD NOT be allowed from client (unregistered, |
489 |
or registered) connections. However, it MUST be used between servers |
490 |
to notify other servers of new services joining the IRC network. |
491 |
|
492 |
The <servertoken> is used to identify the server to which the service |
493 |
is connected. (See section 4.1.2 for more information on server |
494 |
tokens). |
495 |
|
496 |
The <hopcount> parameter is used by servers to indicate how far away |
497 |
a service is from its home server. A local connection has a hopcount |
498 |
of 0. The hopcount value is incremented by each passed server. |
499 |
|
500 |
The <distribution> parameter is used to specify the visibility of a |
501 |
service. The service may only be known to servers which have a name |
502 |
matching the distribution. For a matching server to have knowledge |
503 |
of the service, the network path between that server and the server |
504 |
to which the service is connected MUST be composed of servers whose |
505 |
names all match the mask. Plain "*" is used when no restriction is |
506 |
wished. |
507 |
|
508 |
The <type> parameter is currently reserved for future usage. |
509 |
|
510 |
Numeric Replies: |
511 |
|
512 |
ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS |
513 |
ERR_ERRONEUSNICKNAME |
514 |
RPL_YOURESERVICE RPL_YOURHOST |
515 |
RPL_MYINFO |
516 |
|
517 |
Example: |
518 |
|
519 |
SERVICE dict@irc.fr 9 *.fr 0 1 :French Dictionary r" registered on |
520 |
server "9" is being announced to |
521 |
another server. This service will |
522 |
only be available on servers whose |
523 |
name matches "*.fr". |
524 |
|
525 |
4.1.5 Quit |
526 |
|
527 |
Command: QUIT |
528 |
Parameters: [<Quit Message>] |
529 |
|
530 |
A client session ends with a quit message. The server MUST close the |
531 |
connection to a client which sends a QUIT message. If a "Quit |
532 |
Message" is given, this will be sent instead of the default message, |
533 |
the nickname or service name. |
534 |
|
535 |
When "netsplit" (See Section 4.1.6) occur, the "Quit Message" is |
536 |
composed of the names of two servers involved, separated by a space. |
537 |
The first name is that of the server which is still connected and the |
538 |
second name is either that of the server which has become |
539 |
disconnected or that of the server to which the leaving client was |
540 |
connected: |
541 |
|
542 |
<Quit Message> = ":" servername SPACE servername |
543 |
|
544 |
Because the "Quit Message" has a special meaning for "netsplits", |
545 |
servers SHOULD NOT allow a client to use a <Quit Message> in the |
546 |
format described above. |
547 |
|
548 |
If, for some other reason, a client connection is closed without the |
549 |
client issuing a QUIT command (e.g. client dies and EOF occurs on |
550 |
socket), the server is REQUIRED to fill in the quit message with some |
551 |
sort of message reflecting the nature of the event which caused it to |
552 |
happen. Typically, this is done by reporting a system specific |
553 |
error. |
554 |
|
555 |
Numeric Replies: |
556 |
|
557 |
None. |
558 |
|
559 |
Examples: |
560 |
|
561 |
:WiZ QUIT :Gone to have lunch ; Preferred message format. |
562 |
|
563 |
4.1.6 Server quit message |
564 |
|
565 |
Command: SQUIT |
566 |
Parameters: <server> <comment> |
567 |
|
568 |
The SQUIT message has two distinct uses. |
569 |
|
570 |
The first one (described in "Internet Relay Chat: Client Protocol" |
571 |
[IRC-CLIENT]) allows operators to break a local or remote server |
572 |
link. This form of the message is also eventually used by servers to |
573 |
break a remote server link. |
574 |
|
575 |
The second use of this message is needed to inform other servers when |
576 |
a "network split" (also known as "netsplit") occurs, in other words |
577 |
to inform other servers about quitting or dead servers. If a server |
578 |
wishes to break the connection to another server it MUST send a SQUIT |
579 |
message to the other server, using the name of the other server as |
580 |
the server parameter, which then closes its connection to the |
581 |
quitting server. |
582 |
|
583 |
The <comment> is filled in by servers which SHOULD place an error or |
584 |
similar message here. |
585 |
|
586 |
Both of the servers which are on either side of the connection being |
587 |
closed are REQUIRED to send out a SQUIT message (to all its other |
588 |
server connections) for all other servers which are considered to be |
589 |
behind that link. |
590 |
|
591 |
Similarly, a QUIT message MAY be sent to the other still connected |
592 |
servers on behalf of all clients behind that quitting link. In |
593 |
addition to this, all channel members of a channel which lost a |
594 |
member due to the "split" MUST be sent a QUIT message. Messages to |
595 |
channel members are generated by each client's local server. |
596 |
|
597 |
If a server connection is terminated prematurely (e.g., the server on |
598 |
the other end of the link died), the server which detects this |
599 |
disconnection is REQUIRED to inform the rest of the network that the |
600 |
connection has closed and fill in the comment field with something |
601 |
appropriate. |
602 |
|
603 |
When a client is removed as the result of a SQUIT message, the server |
604 |
SHOULD add the nickname to the list of temporarily unavailable |
605 |
nicknames in an attempt to prevent future nickname collisions. See |
606 |
|
607 |
section 5.7 (Tracking recently used nicknames) for more information |
608 |
on this procedure. |
609 |
|
610 |
Numeric replies: |
611 |
|
612 |
ERR_NOPRIVILEGES ERR_NOSUCHSERVER |
613 |
ERR_NEEDMOREPARAMS |
614 |
|
615 |
Example: |
616 |
|
617 |
SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi |
618 |
has been terminated because of "Bad |
619 |
Link". |
620 |
|
621 |
:Trillian SQUIT cm22.eng.umd.edu :Server out of control ; message |
622 |
from Trillian to disconnect |
623 |
"cm22.eng.umd.edu" from the net |
624 |
because "Server out of control". |
625 |
|
626 |
4.2 Channel operations |
627 |
|
628 |
This group of messages is concerned with manipulating channels, their |
629 |
properties (channel modes), and their contents (typically users). In |
630 |
implementing these, a number of race conditions are inevitable when |
631 |
users at opposing ends of a network send commands which will |
632 |
ultimately clash. It is also REQUIRED that servers keep a nickname |
633 |
history to ensure that wherever a <nick> parameter is given, the |
634 |
server check its history in case it has recently been changed. |
635 |
|
636 |
4.2.1 Join message |
637 |
|
638 |
Command: JOIN |
639 |
Parameters: <channel>[ %x7 <modes> ] |
640 |
*( "," <channel>[ %x7 <modes> ] ) |
641 |
|
642 |
The JOIN command is used by client to start listening a specific |
643 |
channel. Whether or not a client is allowed to join a channel is |
644 |
checked only by the local server the client is connected to; all |
645 |
other servers automatically add the user to the channel when the |
646 |
command is received from other servers. |
647 |
|
648 |
Optionally, the user status (channel modes 'O', 'o', and 'v') on the |
649 |
channel may be appended to the channel name using a control G (^G or |
650 |
ASCII 7) as separator. Such data MUST be ignored if the message |
651 |
wasn't received from a server. This format MUST NOT be sent to |
652 |
clients, it can only be used between servers and SHOULD be avoided. |
653 |
|
654 |
The JOIN command MUST be broadcast to all servers so that each server |
655 |
knows where to find the users who are on the channel. This allows |
656 |
optimal delivery of PRIVMSG and NOTICE messages to the channel. |
657 |
|
658 |
Numeric Replies: |
659 |
|
660 |
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN |
661 |
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY |
662 |
ERR_CHANNELISFULL ERR_BADCHANMASK |
663 |
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS |
664 |
ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE |
665 |
RPL_TOPIC |
666 |
|
667 |
Examples: |
668 |
|
669 |
:WiZ JOIN #Twilight_zone ; JOIN message from WiZ |
670 |
|
671 |
4.2.2 Njoin message |
672 |
|
673 |
Command: NJOIN |
674 |
Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname> |
675 |
*( "," [ "@@" / "@" ] [ "+" ] <nickname> ) |
676 |
|
677 |
The NJOIN message is used between servers only. If such a message is |
678 |
received from a client, it MUST be ignored. It is used when two |
679 |
servers connect to each other to exchange the list of channel members |
680 |
for each channel. |
681 |
|
682 |
Even though the same function can be performed by using a succession |
683 |
of JOIN, this message SHOULD be used instead as it is more efficient. |
684 |
The prefix "@@" indicates that the user is the "channel creator", the |
685 |
character "@" alone indicates a "channel operator", and the character |
686 |
'+' indicates that the user has the voice privilege. |
687 |
|
688 |
Numeric Replies: |
689 |
|
690 |
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL |
691 |
ERR_ALREADYREGISTRED |
692 |
|
693 |
Examples: |
694 |
|
695 |
:ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN |
696 |
message from ircd.stealth.net |
697 |
announcing users joining the |
698 |
#Twilight_zone channel: WiZ with |
699 |
channel operator status, syrk with |
700 |
voice privilege and avalon with no |
701 |
privilege. |
702 |
|
703 |
4.2.3 Mode message |
704 |
|
705 |
The MODE message is a dual-purpose command in IRC. It allows both |
706 |
usernames and channels to have their mode changed. |
707 |
|
708 |
When parsing MODE messages, it is RECOMMENDED that the entire message |
709 |
be parsed first, and then the changes which resulted passed on. |
710 |
|
711 |
It is REQUIRED that servers are able to change channel modes so that |
712 |
"channel creator" and "channel operators" may be created. |
713 |
|
714 |
5. Implementation details |
715 |
|
716 |
A the time of writing, the only current implementation of this |
717 |
protocol is the IRC server, version 2.10. Earlier versions may |
718 |
implement some or all of the commands described by this document with |
719 |
NOTICE messages replacing many of the numeric replies. Unfortunately, |
720 |
due to backward compatibility requirements, the implementation of |
721 |
some parts of this document varies with what is laid out. One |
722 |
notable difference is: |
723 |
|
724 |
* recognition that any LF or CR anywhere in a message marks |
725 |
the end of that message (instead of requiring CR-LF); |
726 |
|
727 |
The rest of this section deals with issues that are mostly of |
728 |
importance to those who wish to implement a server but some parts |
729 |
also apply directly to clients as well. |
730 |
|
731 |
5.1 Connection 'Liveness' |
732 |
|
733 |
To detect when a connection has died or become unresponsive, the |
734 |
server MUST poll each of its connections. The PING command (See "IRC |
735 |
Client Protocol" [IRC-CLIENT]) is used if the server doesn't get a |
736 |
response from its peer in a given amount of time. |
737 |
|
738 |
If a connection doesn't respond in time, its connection is closed |
739 |
using the appropriate procedures. |
740 |
|
741 |
5.2 Accepting a client to server connection |
742 |
|
743 |
5.2.1 Users |
744 |
|
745 |
When a server successfully registers a new user connection, it is |
746 |
REQUIRED to send to the user unambiguous messages stating: the user |
747 |
identifiers upon which it was registered (RPL_WELCOME), the server |
748 |
name and version (RPL_YOURHOST), the server birth information |
749 |
(RPL_CREATED), available user and channel modes (RPL_MYINFO), and it |
750 |
MAY send any introductory messages which may be deemed appropriate. |
751 |
|
752 |
In particular the server SHALL send the current user/service/server |
753 |
count (as per the LUSER reply) and finally the MOTD (if any, as per |
754 |
the MOTD reply). |
755 |
|
756 |
After dealing with registration, the server MUST then send out to |
757 |
other servers the new user's nickname (NICK message), other |
758 |
information as supplied by itself (USER message) and as the server |
759 |
could discover (from DNS servers). The server MUST NOT send this |
760 |
information out with a pair of NICK and USER messages as defined in |
761 |
"IRC Client Protocol" [IRC-CLIENT], but MUST instead take advantage |
762 |
of the extended NICK message defined in section 4.1.3. |
763 |
|
764 |
5.2.2 Services |
765 |
|
766 |
Upon successfully registering a new service connection, the server is |
767 |
subject to the same kind of REQUIREMENTS as for a user. Services |
768 |
being somewhat different, only the following replies are sent: |
769 |
RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO. |
770 |
|
771 |
After dealing with this, the server MUST then send out to other |
772 |
servers (SERVICE message) the new service's nickname and other |
773 |
information as supplied by the service (SERVICE message) and as the |
774 |
server could discover (from DNS servers). |
775 |
|
776 |
5.3 Establishing a server-server connection. |
777 |
|
778 |
The process of establishing a server-to-server connection is fraught |
779 |
with danger since there are many possible areas where problems can |
780 |
occur - the least of which are race conditions. |
781 |
|
782 |
After a server has received a connection following by a PASS/SERVER |
783 |
pair which were recognized as being valid, the server SHOULD then |
784 |
reply with its own PASS/SERVER information for that connection as |
785 |
well as all of the other state information it knows about as |
786 |
described below. |
787 |
|
788 |
When the initiating server receives a PASS/SERVER pair, it too then |
789 |
checks that the server responding is authenticated properly before |
790 |
accepting the connection to be that server. |
791 |
|
792 |
5.3.1 Link options |
793 |
|
794 |
Server links are based on a common protocol (defined by this |
795 |
document) but a particular link MAY set specific options using the |
796 |
PASS message (See Section 4.1.1). |
797 |
|
798 |
5.3.1.1 Compressed server to server links |
799 |
|
800 |
If a server wishes to establish a compressed link with its peer, it |
801 |
MUST set the 'Z' flag in the options parameter to the PASS message. |
802 |
If both servers request compression and both servers are able to |
803 |
initialize the two compressed streams, then the remainder of the |
804 |
communication is to be compressed. If any server fails to initialize |
805 |
the stream, it will send an uncompressed ERROR message to its peer |
806 |
and close the connection. |
807 |
|
808 |
The data format used for the compression is described by RFC 1950 |
809 |
[ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP]. |
810 |
|
811 |
5.3.1.2 Anti abuse protections |
812 |
|
813 |
Most servers implement various kinds of protections against possible |
814 |
abusive behaviours from non trusted parties (typically users). On |
815 |
some networks, such protections are indispensable, on others they are |
816 |
superfluous. To require that all servers implement and enable such |
817 |
features on a particular network, the 'P' flag is used when two |
818 |
servers connect. If this flag is present, it means that the server |
819 |
protections are enabled, and that the server REQUIRES all its server |
820 |
links to enable them as well. |
821 |
|
822 |
Commonly found protections are described in sections 5.7 (Tracking |
823 |
recently used nicknames) and 5.8 (Flood control of clients). |
824 |
|
825 |
5.3.2 State information exchange when connecting |
826 |
|
827 |
The order of state information being exchanged between servers is |
828 |
essential. The REQUIRED order is as follows: |
829 |
|
830 |
* all known servers; |
831 |
|
832 |
* all known client information; |
833 |
|
834 |
* all known channel information. |
835 |
|
836 |
Information regarding servers is sent via extra SERVER messages, |
837 |
client information with NICK and SERVICE messages and channels with |
838 |
NJOIN/MODE messages. |
839 |
|
840 |
NOTE: channel topics SHOULD NOT be exchanged here because the TOPIC |
841 |
command overwrites any old topic information, so at best, the two |
842 |
sides of the connection would exchange topics. |
843 |
|
844 |
By passing the state information about servers first, any collisions |
845 |
with servers that already exist occur before nickname collisions |
846 |
caused by a second server introducing a particular nickname. Due to |
847 |
the IRC network only being able to exist as an acyclic graph, it may |
848 |
be possible that the network has already reconnected in another |
849 |
location. In this event, the place where the server collision occurs |
850 |
indicates where the net needs to split. |
851 |
|
852 |
5.4 Terminating server-client connections |
853 |
|
854 |
When a client connection unexpectedly closes, a QUIT message is |
855 |
generated on behalf of the client by the server to which the client |
856 |
was connected. No other message is to be generated or used. |
857 |
|
858 |
5.5 Terminating server-server connections |
859 |
|
860 |
If a server-server connection is closed, either via a SQUIT command |
861 |
or "natural" causes, the rest of the connected IRC network MUST have |
862 |
its information updated by the server which detected the closure. |
863 |
The terminating server then sends a list of SQUITs (one for each |
864 |
server behind that connection). (See Section 4.1.6 (SQUIT)). |
865 |
|
866 |
5.6 Tracking nickname changes |
867 |
|
868 |
All IRC servers are REQUIRED to keep a history of recent nickname |
869 |
changes. This is important to allow the server to have a chance of |
870 |
keeping in touch of things when nick-change race conditions occur |
871 |
with commands manipulating them. Messages which MUST trace nick |
872 |
changes are: |
873 |
|
874 |
* KILL (the nick being disconnected) |
875 |
|
876 |
* MODE (+/- o,v on channels) |
877 |
|
878 |
* KICK (the nick being removed from channel) |
879 |
|
880 |
No other commands need to check nick changes. |
881 |
|
882 |
In the above cases, the server is required to first check for the |
883 |
existence of the nickname, then check its history to see who that |
884 |
nick now belongs to (if anyone!). This reduces the chances of race |
885 |
conditions but they can still occur with the server ending up |
886 |
affecting the wrong client. When performing a change trace for an |
887 |
above command it is RECOMMENDED that a time range be given and |
888 |
entries which are too old ignored. |
889 |
|
890 |
For a reasonable history, a server SHOULD be able to keep previous |
891 |
nickname for every client it knows about if they all decided to |
892 |
change. This size is limited by other factors (such as memory, etc). |
893 |
|
894 |
5.7 Tracking recently used nicknames |
895 |
|
896 |
This mechanism is commonly known as "Nickname Delay", it has been |
897 |
proven to significantly reduce the number of nickname collisions |
898 |
resulting from "network splits"/reconnections as well as abuse. |
899 |
|
900 |
In addition of keeping track of nickname changes, servers SHOULD keep |
901 |
track of nicknames which were recently used and were released as the |
902 |
result of a "network split" or a KILL message. These nicknames are |
903 |
then unavailable to the server local clients and cannot be re-used |
904 |
(even though they are not currently in use) for a certain period of |
905 |
time. |
906 |
|
907 |
The duration for which a nickname remains unavailable SHOULD be set |
908 |
considering many factors among which are the size (user wise) of the |
909 |
IRC network, and the usual duration of "network splits". It SHOULD |
910 |
be uniform on all servers for a given IRC network. |
911 |
|
912 |
5.8 Flood control of clients |
913 |
|
914 |
With a large network of interconnected IRC servers, it is quite easy |
915 |
for any single client attached to the network to supply a continuous |
916 |
stream of messages that result in not only flooding the network, but |
917 |
also degrading the level of service provided to others. Rather than |
918 |
require every 'victim' to provide their own protection, flood |
919 |
protection was written into the server and is applied to all clients |
920 |
except services. The current algorithm is as follows: |
921 |
|
922 |
* check to see if client's `message timer' is less than current time |
923 |
(set to be equal if it is); |
924 |
|
925 |
* read any data present from the client; |
926 |
|
927 |
* while the timer is less than ten (10) seconds ahead of the current |
928 |
time, parse any present messages and penalize the client by two (2) |
929 |
seconds for each message; |
930 |
|
931 |
* additional penalties MAY be used for specific commands which |
932 |
generate a lot of traffic across the network. |
933 |
|
934 |
This in essence means that the client may send one (1) message every |
935 |
two (2) seconds without being adversely affected. Services MAY also |
936 |
be subject to this mechanism. |
937 |
|
938 |
5.9 Non-blocking lookups |
939 |
|
940 |
In a real-time environment, it is essential that a server process |
941 |
does as little waiting as possible so that all the clients are |
942 |
serviced fairly. Obviously this requires non-blocking IO on all |
943 |
network read/write operations. For normal server connections, this |
944 |
was not difficult, but there are other support operations that may |
945 |
cause the server to block (such as disk reads). Where possible, such |
946 |
activity SHOULD be performed with a short timeout. |
947 |
|
948 |
5.9.1 Hostname (DNS) lookups |
949 |
|
950 |
Using the standard resolver libraries from Berkeley and others has |
951 |
meant large delays in some cases where replies have timed out. To |
952 |
avoid this, a separate set of DNS routines were written for the |
953 |
current implementation. Routines were setup for non-blocking IO |
954 |
operations with local cache, and then polled from within the main |
955 |
server IO loop. |
956 |
|
957 |
5.9.2 Username (Ident) lookups |
958 |
|
959 |
Although there are numerous ident libraries (implementing the |
960 |
"Identification Protocol" [IDENT]) for use and inclusion into other |
961 |
programs, these caused problems since they operated in a synchronous |
962 |
manner and resulted in frequent delays. Again the solution was to |
963 |
write a set of routines which would cooperate with the rest of the |
964 |
server and work using non-blocking IO. |
965 |
|
966 |
6. Current problems |
967 |
|
968 |
There are a number of recognized problems with this protocol, all of |
969 |
which are hoped to be solved sometime in the near future during its |
970 |
rewrite. Currently, work is underway to find working solutions to |
971 |
these problems. |
972 |
|
973 |
6.1 Scalability |
974 |
|
975 |
It is widely recognized that this protocol does not scale |
976 |
sufficiently well when used in a large arena. The main problem comes |
977 |
from the requirement that all servers know about all other servers |
978 |
and clients and that information regarding them be updated as soon as |
979 |
it changes. It is also desirable to keep the number of servers low |
980 |
so that the path length between any two points is kept minimal and |
981 |
the spanning tree as strongly branched as possible. |
982 |
|
983 |
6.2 Labels |
984 |
|
985 |
The current IRC protocol has 4 types of labels: the nickname, the |
986 |
channel name, the server name and the service name. Each of the four |
987 |
types has its own domain and no duplicates are allowed inside that |
988 |
domain. Currently, it is possible for users to pick the label for |
989 |
any of the first three, resulting in collisions. It is widely |
990 |
recognized that this needs reworking, with a plan for unique names |
991 |
for nicks that don't collide being desirable as well as a solution |
992 |
allowing a cyclic tree. |
993 |
|
994 |
6.2.1 Nicknames |
995 |
|
996 |
The idea of the nickname on IRC is very convenient for users to use |
997 |
when talking to each other outside of a channel, but there is only a |
998 |
finite nickname space and being what they are, it's not uncommon for |
999 |
several people to want to use the same nick. If a nickname is chosen |
1000 |
by two people using this protocol, either one will not succeed or |
1001 |
both will be removed by use of KILL (See Section 3.7.1 of "IRC Client |
1002 |
Protocol" [IRC-CLIENT]). |
1003 |
|
1004 |
6.2.2 Channels |
1005 |
|
1006 |
The current channel layout requires that all servers know about all |
1007 |
channels, their inhabitants and properties. Besides not scaling |
1008 |
well, the issue of privacy is also a concern. A collision of |
1009 |
channels is treated as an inclusive event (people from both nets on |
1010 |
channel with common name are considered to be members of it) rather |
1011 |
than an exclusive one such as used to solve nickname collisions. |
1012 |
|
1013 |
This protocol defines "Safe Channels" which are very unlikely to be |
1014 |
the subject of a channel collision. Other channel types are kept for |
1015 |
backward compatibility. |
1016 |
|
1017 |
6.2.3 Servers |
1018 |
|
1019 |
Although the number of servers is usually small relative to the |
1020 |
number of users and channels, they too are currently REQUIRED to be |
1021 |
known globally, either each one separately or hidden behind a mask. |
1022 |
|
1023 |
6.3 Algorithms |
1024 |
|
1025 |
In some places within the server code, it has not been possible to |
1026 |
avoid N^2 algorithms such as checking the channel list of a set of |
1027 |
clients. |
1028 |
|
1029 |
In current server versions, there are only few database consistency |
1030 |
checks, most of the time each server assumes that a neighbouring |
1031 |
server is correct. This opens the door to large problems if a |
1032 |
connecting server is buggy or otherwise tries to introduce |
1033 |
contradictions to the existing net. |
1034 |
|
1035 |
Currently, because of the lack of unique internal and global labels, |
1036 |
there are a multitude of race conditions that exist. These race |
1037 |
conditions generally arise from the problem of it taking time for |
1038 |
messages to traverse and effect the IRC network. Even by changing to |
1039 |
unique labels, there are problems with channel-related commands being |
1040 |
disrupted. |
1041 |
|
1042 |
7. Security Considerations |
1043 |
|
1044 |
7.1 Authentication |
1045 |
|
1046 |
Servers only have two means of authenticating incoming connections: |
1047 |
plain text password, and DNS lookups. While these methods are weak |
1048 |
and widely recognized as unsafe, their combination has proven to be |
1049 |
sufficient in the past: |
1050 |
|
1051 |
* public networks typically allow user connections with only few |
1052 |
restrictions, without requiring accurate authentication. |
1053 |
|
1054 |
* private networks which operate in a controlled environment often |
1055 |
use home-grown authentication mechanisms not available on the |
1056 |
internet: reliable ident servers [IDENT], or other proprietary |
1057 |
mechanisms. |
1058 |
|
1059 |
The same comments apply to the authentication of IRC Operators. |
1060 |
|
1061 |
It should also be noted that while there has been no real demand over |
1062 |
the years for stronger authentication, and no real effort to provide |
1063 |
better means to safely authenticate users, the current protocol |
1064 |
offers enough to be able to easily plug-in external authentication |
1065 |
methods based on the information that a client can submit to the |
1066 |
server upon connection: nickname, username, password. |
1067 |
|
1068 |
7.2 Integrity |
1069 |
|
1070 |
Since the PASS and OPER messages of the IRC protocol are sent in |
1071 |
clear text, a stream layer encryption mechanism (like "The TLS |
1072 |
Protocol" [TLS]) could be used to protect these transactions. |
1073 |
|
1074 |
8. Current support and availability |
1075 |
|
1076 |
Mailing lists for IRC related discussion: |
1077 |
General discussion: ircd-users@irc.org |
1078 |
Protocol development: ircd-dev@irc.org |
1079 |
|
1080 |
Software implementations: |
1081 |
ftp://ftp.irc.org/irc/server |
1082 |
ftp://ftp.funet.fi/pub/unix/irc |
1083 |
ftp://coombs.anu.edu.au/pub/irc |
1084 |
|
1085 |
Newsgroup: alt.irc |
1086 |
|
1087 |
9. Acknowledgements |
1088 |
|
1089 |
Parts of this document were copied from the RFC 1459 [IRC] which |
1090 |
first formally documented the IRC Protocol. It has also benefited |
1091 |
from many rounds of review and comments. In particular, the |
1092 |
following people have made significant contributions to this |
1093 |
document: |
1094 |
|
1095 |
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa |
1096 |
Ruokonen, Magnus Tjernstrom, Stefan Zehl. |
1097 |
|
1098 |
10. References |
1099 |
|
1100 |
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate |
1101 |
Requirement Levels", BCP 14, RFC 2119, March 1997. |
1102 |
|
1103 |
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax |
1104 |
Specifications: ABNF", RFC 2234, November 1997. |
1105 |
|
1106 |
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat |
1107 |
Protocol", RFC 1459, May 1993. |
1108 |
|
1109 |
[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, |
1110 |
April 2000. |
1111 |
|
1112 |
[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC |
1113 |
2812, April 2000. |
1114 |
|
1115 |
[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC |
1116 |
2811, April 2000. |
1117 |
|
1118 |
[ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data |
1119 |
Format Specification version 3.3", RFC 1950, May 1996. |
1120 |
|
1121 |
[DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format |
1122 |
Specification version 1.3", RFC 1951, May 1996. |
1123 |
|
1124 |
[GZIP] Deutsch, P., "GZIP file format specification version |
1125 |
4.3", RFC 1952, May 1996. |
1126 |
|
1127 |
[IDENT] St. Johns, M., "The Identification Protocol", RFC 1413, |
1128 |
February 1993. |
1129 |
|
1130 |
[TLS] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, |
1131 |
January 1999. |
1132 |
|
1133 |
11. Author's Address |
1134 |
|
1135 |
Christophe Kalt |
1136 |
99 Teaneck Rd, Apt #117 |
1137 |
Ridgefield Park, NJ 07660 |
1138 |
USA |
1139 |
|
1140 |
EMail: kalt@stealth.net |
1141 |
|
1142 |
12. Full Copyright Statement |
1143 |
|
1144 |
Copyright (C) The Internet Society (2000). All Rights Reserved. |
1145 |
|
1146 |
This document and translations of it may be copied and furnished to |
1147 |
others, and derivative works that comment on or otherwise explain it |
1148 |
or assist in its implementation may be prepared, copied, published |
1149 |
and distributed, in whole or in part, without restriction of any |
1150 |
kind, provided that the above copyright notice and this paragraph are |
1151 |
included on all such copies and derivative works. However, this |
1152 |
document itself may not be modified in any way, such as by removing |
1153 |
the copyright notice or references to the Internet Society or other |
1154 |
Internet organizations, except as needed for the purpose of |
1155 |
developing Internet standards in which case the procedures for |
1156 |
copyrights defined in the Internet Standards process must be |
1157 |
followed, or as required to translate it into languages other than |
1158 |
English. |
1159 |
|
1160 |
The limited permissions granted above are perpetual and will not be |
1161 |
revoked by the Internet Society or its successors or assigns. |
1162 |
|
1163 |
This document and the information contained herein is provided on an |
1164 |
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING |
1165 |
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING |
1166 |
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION |
1167 |
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF |
1168 |
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
1169 |
|
1170 |
Acknowledgement |
1171 |
|
1172 |
Funding for the RFC Editor function is currently provided by the |
1173 |
Internet Society. |