1 |
$Id: rfc2812.txt,v 7.1 2005/08/20 15:00:55 knight Exp $ |
2 |
|
3 |
Network Working Group C. Kalt |
4 |
Request for Comments: 2812 April 2000 |
5 |
Updates: 1459 |
6 |
Category: Informational |
7 |
|
8 |
Internet Relay Chat: Client 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 |
IESG NOTE: |
21 |
|
22 |
The IRC protocol itself enables several possibilities of transferring |
23 |
data between clients, and just like with other transfer mechanisms |
24 |
like email, the receiver of the data has to be careful about how the |
25 |
data is handled. For more information on security issues with the IRC |
26 |
protocol, see for example http://www.irchelp.org/irchelp/security/. |
27 |
|
28 |
Abstract |
29 |
|
30 |
The IRC (Internet Relay Chat) protocol is for use with text based |
31 |
conferencing; the simplest client being any socket program capable of |
32 |
connecting to the server. |
33 |
|
34 |
This document defines the Client Protocol, and assumes that the |
35 |
reader is familiar with the IRC Architecture [IRC-ARCH]. |
36 |
|
37 |
Table of Contents |
38 |
|
39 |
1. Labels ..................................................... 3 |
40 |
1.1 Servers ................................................ 3 |
41 |
1.2 Clients ................................................ 3 |
42 |
1.2.1 Users ............................................. 4 |
43 |
1.2.1.1 Operators .................................... 4 |
44 |
1.2.2 Services .......................................... 4 |
45 |
1.3 Channels ............................................... 4 |
46 |
2. The IRC Client Specification ............................... 5 |
47 |
2.1 Overview ............................................... 5 |
48 |
2.2 Character codes ........................................ 5 |
49 |
2.3 Messages ............................................... 5 |
50 |
|
51 |
2.3.1 Message format in Augmented BNF ................... 6 |
52 |
2.4 Numeric replies ........................................ 8 |
53 |
2.5 Wildcard expressions ................................... 9 |
54 |
3. Message Details ............................................ 9 |
55 |
3.1 Connection Registration ................................ 10 |
56 |
3.1.1 Password message .................................. 10 |
57 |
3.1.2 Nick message ...................................... 10 |
58 |
3.1.3 User message ...................................... 11 |
59 |
3.1.4 Oper message ...................................... 12 |
60 |
3.1.5 User mode message ................................. 12 |
61 |
3.1.6 Service message ................................... 13 |
62 |
3.1.7 Quit .............................................. 14 |
63 |
3.1.8 Squit ............................................. 15 |
64 |
3.2 Channel operations ..................................... 15 |
65 |
3.2.1 Join message ...................................... 16 |
66 |
3.2.2 Part message ...................................... 17 |
67 |
3.2.3 Channel mode message .............................. 18 |
68 |
3.2.4 Topic message ..................................... 19 |
69 |
3.2.5 Names message ..................................... 20 |
70 |
3.2.6 List message ...................................... 21 |
71 |
3.2.7 Invite message .................................... 21 |
72 |
3.2.8 Kick command ...................................... 22 |
73 |
3.3 Sending messages ....................................... 23 |
74 |
3.3.1 Private messages .................................. 23 |
75 |
3.3.2 Notice ............................................ 24 |
76 |
3.4 Server queries and commands ............................ 25 |
77 |
3.4.1 Motd message ...................................... 25 |
78 |
3.4.2 Lusers message .................................... 25 |
79 |
3.4.3 Version message ................................... 26 |
80 |
3.4.4 Stats message ..................................... 26 |
81 |
3.4.5 Links message ..................................... 27 |
82 |
3.4.6 Time message ...................................... 28 |
83 |
3.4.7 Connect message ................................... 28 |
84 |
3.4.8 Trace message ..................................... 29 |
85 |
3.4.9 Admin command ..................................... 30 |
86 |
3.4.10 Info command ...................................... 31 |
87 |
3.5 Service Query and Commands ............................. 31 |
88 |
3.5.1 Servlist message .................................. 31 |
89 |
3.5.2 Squery ............................................ 32 |
90 |
3.6 User based queries ..................................... 32 |
91 |
3.6.1 Who query ......................................... 32 |
92 |
3.6.2 Whois query ....................................... 33 |
93 |
3.6.3 Whowas ............................................ 34 |
94 |
3.7 Miscellaneous messages ................................. 34 |
95 |
3.7.1 Kill message ...................................... 35 |
96 |
3.7.2 Ping message ...................................... 36 |
97 |
3.7.3 Pong message ...................................... 37 |
98 |
3.7.4 Error ............................................. 37 |
99 |
|
100 |
4. Optional features .......................................... 38 |
101 |
4.1 Away ................................................... 38 |
102 |
4.2 Rehash message ......................................... 39 |
103 |
4.3 Die message ............................................ 39 |
104 |
4.4 Restart message ........................................ 40 |
105 |
4.5 Summon message ......................................... 40 |
106 |
4.6 Users .................................................. 41 |
107 |
4.7 Operwall message ....................................... 41 |
108 |
4.8 Userhost message ....................................... 42 |
109 |
4.9 Ison message ........................................... 42 |
110 |
5. Replies .................................................... 43 |
111 |
5.1 Command responses ...................................... 43 |
112 |
5.2 Error Replies .......................................... 53 |
113 |
5.3 Reserved numerics ...................................... 59 |
114 |
6. Current implementations .................................... 60 |
115 |
7. Current problems ........................................... 60 |
116 |
7.1 Nicknames .............................................. 60 |
117 |
7.2 Limitation of wildcards ................................ 61 |
118 |
7.3 Security considerations ................................ 61 |
119 |
8. Current support and availability ........................... 61 |
120 |
9. Acknowledgements ........................................... 61 |
121 |
10. References ................................................ 62 |
122 |
11. Author's Address .......................................... 62 |
123 |
12. Full Copyright Statement .................................. 63 |
124 |
|
125 |
1. Labels |
126 |
|
127 |
This section defines the identifiers used for the various components |
128 |
of the IRC protocol. |
129 |
|
130 |
1.1 Servers |
131 |
|
132 |
Servers are uniquely identified by their name, which has a maximum |
133 |
length of sixty three (63) characters. See the protocol grammar |
134 |
rules (section 2.3.1) for what may and may not be used in a server |
135 |
name. |
136 |
|
137 |
1.2 Clients |
138 |
|
139 |
For each client all servers MUST have the following information: a |
140 |
netwide unique identifier (whose format depends on the type of |
141 |
client) and the server which introduced the client. |
142 |
|
143 |
1.2.1 Users |
144 |
|
145 |
Each user is distinguished from other users by a unique nickname |
146 |
having a maximum length of nine (9) characters. See the protocol |
147 |
grammar rules (section 2.3.1) for what may and may not be used in a |
148 |
nickname. |
149 |
|
150 |
While the maximum length is limited to nine characters, clients |
151 |
SHOULD accept longer strings as they may become used in future |
152 |
evolutions of the protocol. |
153 |
|
154 |
1.2.1.1 Operators |
155 |
|
156 |
To allow a reasonable amount of order to be kept within the IRC |
157 |
network, a special class of users (operators) is allowed to perform |
158 |
general maintenance functions on the network. Although the powers |
159 |
granted to an operator can be considered as 'dangerous', they are |
160 |
nonetheless often necessary. Operators SHOULD be able to perform |
161 |
basic network tasks such as disconnecting and reconnecting servers as |
162 |
needed. In recognition of this need, the protocol discussed herein |
163 |
provides for operators only to be able to perform such functions. |
164 |
See sections 3.1.8 (SQUIT) and 3.4.7 (CONNECT). |
165 |
|
166 |
A more controversial power of operators is the ability to remove a |
167 |
user from the connected network by 'force', i.e., operators are able |
168 |
to close the connection between any client and server. The |
169 |
justification for this is very delicate since its abuse is both |
170 |
destructive and annoying, and its benefits close to inexistent. For |
171 |
further details on this type of action, see section 3.7.1 (KILL). |
172 |
|
173 |
1.2.2 Services |
174 |
|
175 |
Each service is distinguished from other services by a service name |
176 |
composed of a nickname and a server name. As for users, the nickname |
177 |
has a maximum length of nine (9) characters. See the protocol |
178 |
grammar rules (section 2.3.1) for what may and may not be used in a |
179 |
nickname. |
180 |
|
181 |
1.3 Channels |
182 |
|
183 |
Channels names are strings (beginning with a '&', '#', '+' or '!' |
184 |
character) of length up to fifty (50) characters. Apart from the |
185 |
requirement that the first character is either '&', '#', '+' or '!', |
186 |
the only restriction on a channel name is that it SHALL NOT contain |
187 |
any spaces (' '), a control G (^G or ASCII 7), a comma (','). Space |
188 |
is used as parameter separator and command is used as a list item |
189 |
separator by the protocol). A colon (':') can also be used as a |
190 |
delimiter for the channel mask. Channel names are case insensitive. |
191 |
|
192 |
See the protocol grammar rules (section 2.3.1) for the exact syntax |
193 |
of a channel name. |
194 |
|
195 |
Each prefix characterizes a different channel type. The definition |
196 |
of the channel types is not relevant to the client-server protocol |
197 |
and thus it is beyond the scope of this document. More details can |
198 |
be found in "Internet Relay Chat: Channel Management" [IRC-CHAN]. |
199 |
|
200 |
2. The IRC Client Specification |
201 |
|
202 |
2.1 Overview |
203 |
|
204 |
The protocol as described herein is for use only with client to |
205 |
server connections when the client registers as a user. |
206 |
|
207 |
2.2 Character codes |
208 |
|
209 |
No specific character set is specified. The protocol is based on a |
210 |
set of codes which are composed of eight (8) bits, making up an |
211 |
octet. Each message may be composed of any number of these octets; |
212 |
however, some octet values are used for control codes, which act as |
213 |
message delimiters. |
214 |
|
215 |
Regardless of being an 8-bit protocol, the delimiters and keywords |
216 |
are such that protocol is mostly usable from US-ASCII terminal and a |
217 |
telnet connection. |
218 |
|
219 |
Because of IRC's Scandinavian origin, the characters {}|^ are |
220 |
considered to be the lower case equivalents of the characters []\~, |
221 |
respectively. This is a critical issue when determining the |
222 |
equivalence of two nicknames or channel names. |
223 |
|
224 |
2.3 Messages |
225 |
|
226 |
Servers and clients send each other messages, which may or may not |
227 |
generate a reply. If the message contains a valid command, as |
228 |
described in later sections, the client should expect a reply as |
229 |
specified but it is not advised to wait forever for the reply; client |
230 |
to server and server to server communication is essentially |
231 |
asynchronous by nature. |
232 |
|
233 |
Each IRC message may consist of up to three main parts: the prefix |
234 |
(OPTIONAL), the command, and the command parameters (maximum of |
235 |
fifteen (15)). The prefix, command, and all parameters are separated |
236 |
by one ASCII space character (0x20) each. |
237 |
|
238 |
The presence of a prefix is indicated with a single leading ASCII |
239 |
colon character (':', 0x3b), which MUST be the first character of the |
240 |
message itself. There MUST be NO gap (whitespace) between the colon |
241 |
and the prefix. The prefix is used by servers to indicate the true |
242 |
origin of the message. If the prefix is missing from the message, it |
243 |
is assumed to have originated from the connection from which it was |
244 |
received from. Clients SHOULD NOT use a prefix when sending a |
245 |
message; if they use one, the only valid prefix is the registered |
246 |
nickname associated with the client. |
247 |
|
248 |
The command MUST either be a valid IRC command or a three (3) digit |
249 |
number represented in ASCII text. |
250 |
|
251 |
IRC messages are always lines of characters terminated with a CR-LF |
252 |
(Carriage Return - Line Feed) pair, and these messages SHALL NOT |
253 |
exceed 512 characters in length, counting all characters including |
254 |
the trailing CR-LF. Thus, there are 510 characters maximum allowed |
255 |
for the command and its parameters. There is no provision for |
256 |
continuation of message lines. See section 6 for more details about |
257 |
current implementations. |
258 |
|
259 |
2.3.1 Message format in Augmented BNF |
260 |
|
261 |
The protocol messages must be extracted from the contiguous stream of |
262 |
octets. The current solution is to designate two characters, CR and |
263 |
LF, as message separators. Empty messages are silently ignored, |
264 |
which permits use of the sequence CR-LF between messages without |
265 |
extra problems. |
266 |
|
267 |
The extracted message is parsed into the components <prefix>, |
268 |
<command> and list of parameters (<params>). |
269 |
|
270 |
The Augmented BNF representation for this is: |
271 |
|
272 |
message = [ ":" prefix SPACE ] command [ params ] crlf |
273 |
prefix = servername / ( nickname [ [ "!" user ] "@" host ] ) |
274 |
command = 1*letter / 3digit |
275 |
params = *14( SPACE middle ) [ SPACE ":" trailing ] |
276 |
=/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ] |
277 |
|
278 |
nospcrlfcl = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF |
279 |
; any octet except NUL, CR, LF, " " and ":" |
280 |
middle = nospcrlfcl *( ":" / nospcrlfcl ) |
281 |
trailing = *( ":" / " " / nospcrlfcl ) |
282 |
|
283 |
SPACE = %x20 ; space character |
284 |
crlf = %x0D %x0A ; "carriage return" "linefeed" |
285 |
|
286 |
NOTES: |
287 |
1) After extracting the parameter list, all parameters are equal |
288 |
whether matched by <middle> or <trailing>. <trailing> is just a |
289 |
syntactic trick to allow SPACE within the parameter. |
290 |
|
291 |
2) The NUL (%x00) character is not special in message framing, and |
292 |
basically could end up inside a parameter, but it would cause |
293 |
extra complexities in normal C string handling. Therefore, NUL |
294 |
is not allowed within messages. |
295 |
|
296 |
Most protocol messages specify additional semantics and syntax for |
297 |
the extracted parameter strings dictated by their position in the |
298 |
list. For example, many server commands will assume that the first |
299 |
parameter after the command is the list of targets, which can be |
300 |
described with: |
301 |
|
302 |
target = nickname / server |
303 |
msgtarget = msgto *( "," msgto ) |
304 |
msgto = channel / ( user [ "%" host ] "@" servername ) |
305 |
msgto =/ ( user "%" host ) / targetmask |
306 |
msgto =/ nickname / ( nickname "!" user "@" host ) |
307 |
channel = ( "#" / "+" / ( "!" channelid ) / "&" ) chanstring |
308 |
[ ":" chanstring ] |
309 |
servername = hostname |
310 |
host = hostname / hostaddr |
311 |
hostname = shortname *( "." shortname ) |
312 |
shortname = ( letter / digit ) *( letter / digit / "-" ) |
313 |
*( letter / digit ) |
314 |
; as specified in RFC 1123 [HNAME] |
315 |
hostaddr = ip4addr / ip6addr |
316 |
ip4addr = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit |
317 |
ip6addr = 1*hexdigit 7( ":" 1*hexdigit ) |
318 |
ip6addr =/ "0:0:0:0:0:" ( "0" / "FFFF" ) ":" ip4addr |
319 |
nickname = ( letter / special ) *8( letter / digit / special / "-" ) |
320 |
targetmask = ( "$" / "#" ) mask |
321 |
; see details on allowed masks in section 3.3.1 |
322 |
chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B |
323 |
chanstring =/ %x2D-39 / %x3B-FF |
324 |
; any octet except NUL, BELL, CR, LF, " ", "," and ":" |
325 |
channelid = 5( %x41-5A / digit ) ; 5( A-Z / 0-9 ) |
326 |
|
327 |
Other parameter syntaxes are: |
328 |
|
329 |
user = 1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF ) |
330 |
; any octet except NUL, CR, LF, " " and "@" |
331 |
key = 1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F ) |
332 |
; any 7-bit US_ASCII character, |
333 |
; except NUL, CR, LF, FF, h/v TABs, and " " |
334 |
letter = %x41-5A / %x61-7A ; A-Z / a-z |
335 |
digit = %x30-39 ; 0-9 |
336 |
hexdigit = digit / "A" / "B" / "C" / "D" / "E" / "F" |
337 |
special = %x5B-60 / %x7B-7D |
338 |
; "[", "]", "\", "`", "_", "^", "{", "|", "}" |
339 |
|
340 |
NOTES: |
341 |
1) The <hostaddr> syntax is given here for the sole purpose of |
342 |
indicating the format to follow for IP addresses. This |
343 |
reflects the fact that the only available implementations of |
344 |
this protocol uses TCP/IP as underlying network protocol but is |
345 |
not meant to prevent other protocols to be used. |
346 |
|
347 |
2) <hostname> has a maximum length of 63 characters. This is a |
348 |
limitation of the protocol as internet hostnames (in |
349 |
particular) can be longer. Such restriction is necessary |
350 |
because IRC messages are limited to 512 characters in length. |
351 |
Clients connecting from a host which name is longer than 63 |
352 |
characters are registered using the host (numeric) address |
353 |
instead of the host name. |
354 |
|
355 |
3) Some parameters used in the following sections of this |
356 |
documents are not defined here as there is nothing specific |
357 |
about them besides the name that is used for convenience. |
358 |
These parameters follow the general syntax defined for |
359 |
<params>. |
360 |
|
361 |
2.4 Numeric replies |
362 |
|
363 |
Most of the messages sent to the server generate a reply of some |
364 |
sort. The most common reply is the numeric reply, used for both |
365 |
errors and normal replies. The numeric reply MUST be sent as one |
366 |
message consisting of the sender prefix, the three-digit numeric, and |
367 |
the target of the reply. A numeric reply is not allowed to originate |
368 |
from a client. In all other respects, a numeric reply is just like a |
369 |
normal message, except that the keyword is made up of 3 numeric |
370 |
digits rather than a string of letters. A list of different replies |
371 |
is supplied in section 5 (Replies). |
372 |
|
373 |
2.5 Wildcard expressions |
374 |
|
375 |
When wildcards are allowed in a string, it is referred as a "mask". |
376 |
|
377 |
For string matching purposes, the protocol allows the use of two |
378 |
special characters: '?' (%x3F) to match one and only one character, |
379 |
and '*' (%x2A) to match any number of any characters. These two |
380 |
characters can be escaped using the character '\' (%x5C). |
381 |
|
382 |
The Augmented BNF syntax for this is: |
383 |
|
384 |
mask = *( nowild / noesc wildone / noesc wildmany ) |
385 |
wildone = %x3F |
386 |
wildmany = %x2A |
387 |
nowild = %x01-29 / %x2B-3E / %x40-FF |
388 |
; any octet except NUL, "*", "?" |
389 |
noesc = %x01-5B / %x5D-FF |
390 |
; any octet except NUL and "\" |
391 |
matchone = %x01-FF |
392 |
; matches wildone |
393 |
matchmany = *matchone |
394 |
; matches wildmany |
395 |
|
396 |
Examples: |
397 |
|
398 |
a?c ; Matches any string of 3 characters in length starting |
399 |
with "a" and ending with "c" |
400 |
|
401 |
a*c ; Matches any string of at least 2 characters in length |
402 |
starting with "a" and ending with "c" |
403 |
|
404 |
3. Message Details |
405 |
|
406 |
On the following pages there are descriptions of each message |
407 |
recognized by the IRC server and client. All commands described in |
408 |
this section MUST be implemented by any server for this protocol. |
409 |
|
410 |
Where the reply ERR_NOSUCHSERVER is returned, it means that the |
411 |
target of the message could not be found. The server MUST NOT send |
412 |
any other replies after this error for that command. |
413 |
|
414 |
The server to which a client is connected is required to parse the |
415 |
complete message, and return any appropriate errors. |
416 |
|
417 |
If multiple parameters is presented, then each MUST be checked for |
418 |
validity and appropriate responses MUST be sent back to the client. |
419 |
In the case of incorrect messages which use parameter lists with |
420 |
comma as an item separator, a reply MUST be sent for each item. |
421 |
|
422 |
3.1 Connection Registration |
423 |
|
424 |
The commands described here are used to register a connection with an |
425 |
IRC server as a user as well as to correctly disconnect. |
426 |
|
427 |
A "PASS" command is not required for a client connection to be |
428 |
registered, but it MUST precede the latter of the NICK/USER |
429 |
combination (for a user connection) or the SERVICE command (for a |
430 |
service connection). The RECOMMENDED order for a client to register |
431 |
is as follows: |
432 |
|
433 |
1. Pass message |
434 |
2. Nick message 2. Service message |
435 |
3. User message |
436 |
|
437 |
Upon success, the client will receive an RPL_WELCOME (for users) or |
438 |
RPL_YOURESERVICE (for services) message indicating that the |
439 |
connection is now registered and known the to the entire IRC network. |
440 |
The reply message MUST contain the full client identifier upon which |
441 |
it was registered. |
442 |
|
443 |
3.1.1 Password message |
444 |
|
445 |
Command: PASS |
446 |
Parameters: <password> |
447 |
|
448 |
The PASS command is used to set a 'connection password'. The |
449 |
optional password can and MUST be set before any attempt to register |
450 |
the connection is made. Currently this requires that user send a |
451 |
PASS command before sending the NICK/USER combination. |
452 |
|
453 |
Numeric Replies: |
454 |
|
455 |
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED |
456 |
|
457 |
Example: |
458 |
|
459 |
PASS secretpasswordhere |
460 |
|
461 |
3.1.2 Nick message |
462 |
|
463 |
Command: NICK |
464 |
Parameters: <nickname> |
465 |
|
466 |
NICK command is used to give user a nickname or change the existing |
467 |
one. |
468 |
|
469 |
Numeric Replies: |
470 |
|
471 |
ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME |
472 |
ERR_NICKNAMEINUSE ERR_NICKCOLLISION |
473 |
ERR_UNAVAILRESOURCE ERR_RESTRICTED |
474 |
|
475 |
Examples: |
476 |
|
477 |
NICK Wiz ; Introducing new nick "Wiz" if session is |
478 |
still unregistered, or user changing his |
479 |
nickname to "Wiz" |
480 |
|
481 |
:WiZ!jto@tolsun.oulu.fi NICK Kilroy |
482 |
; Server telling that WiZ changed his |
483 |
nickname to Kilroy. |
484 |
|
485 |
3.1.3 User message |
486 |
|
487 |
Command: USER |
488 |
Parameters: <user> <mode> <unused> <realname> |
489 |
|
490 |
The USER command is used at the beginning of connection to specify |
491 |
the username, hostname and realname of a new user. |
492 |
|
493 |
The <mode> parameter should be a numeric, and can be used to |
494 |
automatically set user modes when registering with the server. This |
495 |
parameter is a bitmask, with only 2 bits having any signification: if |
496 |
the bit 2 is set, the user mode 'w' will be set and if the bit 3 is |
497 |
set, the user mode 'i' will be set. (See Section 3.1.5 "User |
498 |
Modes"). |
499 |
|
500 |
The <realname> may contain space characters. |
501 |
|
502 |
Numeric Replies: |
503 |
|
504 |
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED |
505 |
|
506 |
Example: |
507 |
|
508 |
USER guest 0 * :Ronnie Reagan ; User registering themselves with a |
509 |
username of "guest" and real name |
510 |
"Ronnie Reagan". |
511 |
|
512 |
USER guest 8 * :Ronnie Reagan ; User registering themselves with a |
513 |
username of "guest" and real name |
514 |
"Ronnie Reagan", and asking to be set |
515 |
invisible. |
516 |
|
517 |
3.1.4 Oper message |
518 |
|
519 |
Command: OPER |
520 |
Parameters: <name> <password> |
521 |
|
522 |
A normal user uses the OPER command to obtain operator privileges. |
523 |
The combination of <name> and <password> are REQUIRED to gain |
524 |
Operator privileges. Upon success, the user will receive a MODE |
525 |
message (see section 3.1.5) indicating the new user modes. |
526 |
|
527 |
Numeric Replies: |
528 |
|
529 |
ERR_NEEDMOREPARAMS RPL_YOUREOPER |
530 |
ERR_NOOPERHOST ERR_PASSWDMISMATCH |
531 |
|
532 |
Example: |
533 |
|
534 |
OPER foo bar ; Attempt to register as an operator |
535 |
using a username of "foo" and "bar" |
536 |
as the password. |
537 |
|
538 |
3.1.5 User mode message |
539 |
|
540 |
Command: MODE |
541 |
Parameters: <nickname> |
542 |
*( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) ) |
543 |
|
544 |
The user MODE's are typically changes which affect either how the |
545 |
client is seen by others or what 'extra' messages the client is sent. |
546 |
|
547 |
A user MODE command MUST only be accepted if both the sender of the |
548 |
message and the nickname given as a parameter are both the same. If |
549 |
no other parameter is given, then the server will return the current |
550 |
settings for the nick. |
551 |
|
552 |
The available modes are as follows: |
553 |
|
554 |
a - user is flagged as away; |
555 |
i - marks a users as invisible; |
556 |
w - user receives wallops; |
557 |
r - restricted user connection; |
558 |
o - operator flag; |
559 |
O - local operator flag; |
560 |
s - marks a user for receipt of server notices. |
561 |
|
562 |
Additional modes may be available later on. |
563 |
|
564 |
The flag 'a' SHALL NOT be toggled by the user using the MODE command, |
565 |
instead use of the AWAY command is REQUIRED. |
566 |
|
567 |
If a user attempts to make themselves an operator using the "+o" or |
568 |
"+O" flag, the attempt SHOULD be ignored as users could bypass the |
569 |
authentication mechanisms of the OPER command. There is no |
570 |
restriction, however, on anyone `deopping' themselves (using "-o" or |
571 |
"-O"). |
572 |
|
573 |
On the other hand, if a user attempts to make themselves unrestricted |
574 |
using the "-r" flag, the attempt SHOULD be ignored. There is no |
575 |
restriction, however, on anyone `deopping' themselves (using "+r"). |
576 |
This flag is typically set by the server upon connection for |
577 |
administrative reasons. While the restrictions imposed are left up |
578 |
to the implementation, it is typical that a restricted user not be |
579 |
allowed to change nicknames, nor make use of the channel operator |
580 |
status on channels. |
581 |
|
582 |
The flag 's' is obsolete but MAY still be used. |
583 |
|
584 |
Numeric Replies: |
585 |
|
586 |
ERR_NEEDMOREPARAMS ERR_USERSDONTMATCH |
587 |
ERR_UMODEUNKNOWNFLAG RPL_UMODEIS |
588 |
|
589 |
Examples: |
590 |
|
591 |
MODE WiZ -w ; Command by WiZ to turn off |
592 |
reception of WALLOPS messages. |
593 |
|
594 |
MODE Angel +i ; Command from Angel to make herself |
595 |
invisible. |
596 |
|
597 |
MODE WiZ -o ; WiZ 'deopping' (removing operator |
598 |
status). |
599 |
|
600 |
3.1.6 Service message |
601 |
|
602 |
Command: SERVICE |
603 |
Parameters: <nickname> <reserved> <distribution> <type> |
604 |
<reserved> <info> |
605 |
|
606 |
The SERVICE command to register a new service. Command parameters |
607 |
specify the service nickname, distribution, type and info of a new |
608 |
service. |
609 |
|
610 |
The <distribution> parameter is used to specify the visibility of a |
611 |
service. The service may only be known to servers which have a name |
612 |
matching the distribution. For a matching server to have knowledge |
613 |
of the service, the network path between that server and the server |
614 |
on which the service is connected MUST be composed of servers which |
615 |
names all match the mask. |
616 |
|
617 |
The <type> parameter is currently reserved for future usage. |
618 |
|
619 |
Numeric Replies: |
620 |
|
621 |
ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS |
622 |
ERR_ERRONEUSNICKNAME |
623 |
RPL_YOURESERVICE RPL_YOURHOST |
624 |
RPL_MYINFO |
625 |
|
626 |
Example: |
627 |
|
628 |
SERVICE dict * *.fr 0 0 :French Dictionary ; Service registering |
629 |
itself with a name of "dict". This |
630 |
service will only be available on |
631 |
servers which name matches "*.fr". |
632 |
|
633 |
3.1.7 Quit |
634 |
|
635 |
Command: QUIT |
636 |
Parameters: [ <Quit Message> ] |
637 |
|
638 |
A client session is terminated with a quit message. The server |
639 |
acknowledges this by sending an ERROR message to the client. |
640 |
|
641 |
Numeric Replies: |
642 |
|
643 |
None. |
644 |
|
645 |
Example: |
646 |
|
647 |
QUIT :Gone to have lunch ; Preferred message format. |
648 |
|
649 |
:syrk!kalt@millennium.stealth.net QUIT :Gone to have lunch ; User |
650 |
syrk has quit IRC to have lunch. |
651 |
|
652 |
3.1.8 Squit |
653 |
|
654 |
Command: SQUIT |
655 |
Parameters: <server> <comment> |
656 |
|
657 |
The SQUIT command is available only to operators. It is used to |
658 |
disconnect server links. Also servers can generate SQUIT messages on |
659 |
error conditions. A SQUIT message may also target a remote server |
660 |
connection. In this case, the SQUIT message will simply be sent to |
661 |
the remote server without affecting the servers in between the |
662 |
operator and the remote server. |
663 |
|
664 |
The <comment> SHOULD be supplied by all operators who execute a SQUIT |
665 |
for a remote server. The server ordered to disconnect its peer |
666 |
generates a WALLOPS message with <comment> included, so that other |
667 |
users may be aware of the reason of this action. |
668 |
|
669 |
Numeric replies: |
670 |
|
671 |
ERR_NOPRIVILEGES ERR_NOSUCHSERVER |
672 |
ERR_NEEDMOREPARAMS |
673 |
|
674 |
Examples: |
675 |
|
676 |
SQUIT tolsun.oulu.fi :Bad Link ? ; Command to uplink of the server |
677 |
tolson.oulu.fi to terminate its |
678 |
connection with comment "Bad Link". |
679 |
|
680 |
:Trillian SQUIT cm22.eng.umd.edu :Server out of control ; Command |
681 |
from Trillian from to disconnect |
682 |
"cm22.eng.umd.edu" from the net with |
683 |
comment "Server out of control". |
684 |
|
685 |
3.2 Channel operations |
686 |
|
687 |
This group of messages is concerned with manipulating channels, their |
688 |
properties (channel modes), and their contents (typically users). |
689 |
For this reason, these messages SHALL NOT be made available to |
690 |
services. |
691 |
|
692 |
All of these messages are requests which will or will not be granted |
693 |
by the server. The server MUST send a reply informing the user |
694 |
whether the request was granted, denied or generated an error. When |
695 |
the server grants the request, the message is typically sent back |
696 |
(eventually reformatted) to the user with the prefix set to the user |
697 |
itself. |
698 |
|
699 |
The rules governing how channels are managed are enforced by the |
700 |
servers. These rules are beyond the scope of this document. More |
701 |
details are found in "Internet Relay Chat: Channel Management" [IRC- |
702 |
CHAN]. |
703 |
|
704 |
3.2.1 Join message |
705 |
|
706 |
Command: JOIN |
707 |
Parameters: ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] ) |
708 |
/ "0" |
709 |
|
710 |
The JOIN command is used by a user to request to start listening to |
711 |
the specific channel. Servers MUST be able to parse arguments in the |
712 |
form of a list of target, but SHOULD NOT use lists when sending JOIN |
713 |
messages to clients. |
714 |
|
715 |
Once a user has joined a channel, he receives information about |
716 |
all commands his server receives affecting the channel. This |
717 |
includes JOIN, MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. |
718 |
This allows channel members to keep track of the other channel |
719 |
members, as well as channel modes. |
720 |
|
721 |
If a JOIN is successful, the user receives a JOIN message as |
722 |
confirmation and is then sent the channel's topic (using RPL_TOPIC) and |
723 |
the list of users who are on the channel (using RPL_NAMREPLY), which |
724 |
MUST include the user joining. |
725 |
|
726 |
Note that this message accepts a special argument ("0"), which is |
727 |
a special request to leave all channels the user is currently a member |
728 |
of. The server will process this message as if the user had sent |
729 |
a PART command (See Section 3.2.2) for each channel he is a member |
730 |
of. |
731 |
|
732 |
Numeric Replies: |
733 |
|
734 |
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN |
735 |
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY |
736 |
ERR_CHANNELISFULL ERR_BADCHANMASK |
737 |
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS |
738 |
ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE |
739 |
RPL_TOPIC |
740 |
|
741 |
Examples: |
742 |
|
743 |
JOIN #foobar ; Command to join channel #foobar. |
744 |
|
745 |
JOIN &foo fubar ; Command to join channel &foo using |
746 |
key "fubar". |
747 |
|
748 |
JOIN #foo,&bar fubar ; Command to join channel #foo using |
749 |
key "fubar" and &bar using no key. |
750 |
|
751 |
JOIN #foo,#bar fubar,foobar ; Command to join channel #foo using |
752 |
key "fubar", and channel #bar using |
753 |
key "foobar". |
754 |
|
755 |
JOIN #foo,#bar ; Command to join channels #foo and |
756 |
#bar. |
757 |
|
758 |
JOIN 0 ; Leave all currently joined |
759 |
channels. |
760 |
|
761 |
:WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone ; JOIN message from WiZ |
762 |
on channel #Twilight_zone |
763 |
|
764 |
3.2.2 Part message |
765 |
|
766 |
Command: PART |
767 |
Parameters: <channel> *( "," <channel> ) [ <Part Message> ] |
768 |
|
769 |
The PART command causes the user sending the message to be removed |
770 |
from the list of active members for all given channels listed in the |
771 |
parameter string. If a "Part Message" is given, this will be sent |
772 |
instead of the default message, the nickname. This request is always |
773 |
granted by the server. |
774 |
|
775 |
Servers MUST be able to parse arguments in the form of a list of |
776 |
target, but SHOULD NOT use lists when sending PART messages to |
777 |
clients. |
778 |
|
779 |
Numeric Replies: |
780 |
|
781 |
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL |
782 |
ERR_NOTONCHANNEL |
783 |
|
784 |
Examples: |
785 |
|
786 |
PART #twilight_zone ; Command to leave channel |
787 |
"#twilight_zone" |
788 |
|
789 |
PART #oz-ops,&group5 ; Command to leave both channels |
790 |
"&group5" and "#oz-ops". |
791 |
|
792 |
:WiZ!jto@tolsun.oulu.fi PART #playzone :I lost |
793 |
; User WiZ leaving channel |
794 |
"#playzone" with the message "I |
795 |
lost". |
796 |
|
797 |
3.2.3 Channel mode message |
798 |
|
799 |
Command: MODE |
800 |
Parameters: <channel> *( ( "-" / "+" ) *<modes> *<modeparams> ) |
801 |
|
802 |
The MODE command is provided so that users may query and change the |
803 |
characteristics of a channel. For more details on available modes |
804 |
and their uses, see "Internet Relay Chat: Channel Management" [IRC- |
805 |
CHAN]. Note that there is a maximum limit of three (3) changes per |
806 |
command for modes that take a parameter. |
807 |
|
808 |
Numeric Replies: |
809 |
|
810 |
ERR_NEEDMOREPARAMS ERR_KEYSET |
811 |
ERR_NOCHANMODES ERR_CHANOPRIVSNEEDED |
812 |
ERR_USERNOTINCHANNEL ERR_UNKNOWNMODE |
813 |
RPL_CHANNELMODEIS |
814 |
RPL_BANLIST RPL_ENDOFBANLIST |
815 |
RPL_EXCEPTLIST RPL_ENDOFEXCEPTLIST |
816 |
RPL_INVITELIST RPL_ENDOFINVITELIST |
817 |
RPL_UNIQOPIS |
818 |
|
819 |
The following examples are given to help understanding the syntax of |
820 |
the MODE command, but refer to modes defined in "Internet Relay Chat: |
821 |
Channel Management" [IRC-CHAN]. |
822 |
|
823 |
Examples: |
824 |
|
825 |
MODE #Finnish +imI *!*@*.fi ; Command to make #Finnish channel |
826 |
moderated and 'invite-only' with user |
827 |
with a hostname matching *.fi |
828 |
automatically invited. |
829 |
|
830 |
MODE #Finnish +o Kilroy ; Command to give 'chanop' privileges |
831 |
to Kilroy on channel #Finnish. |
832 |
|
833 |
MODE #Finnish +v Wiz ; Command to allow WiZ to speak on |
834 |
#Finnish. |
835 |
|
836 |
MODE #Fins -s ; Command to remove 'secret' flag |
837 |
from channel #Fins. |
838 |
|
839 |
MODE #42 +k oulu ; Command to set the channel key to |
840 |
"oulu". |
841 |
|
842 |
MODE #42 -k oulu ; Command to remove the "oulu" |
843 |
channel key on channel "#42". |
844 |
|
845 |
MODE #eu-opers +l 10 ; Command to set the limit for the |
846 |
number of users on channel |
847 |
"#eu-opers" to 10. |
848 |
|
849 |
:WiZ!jto@tolsun.oulu.fi MODE #eu-opers -l |
850 |
; User "WiZ" removing the limit for |
851 |
the number of users on channel "#eu- |
852 |
opers". |
853 |
|
854 |
MODE &oulu +b ; Command to list ban masks set for |
855 |
the channel "&oulu". |
856 |
|
857 |
MODE &oulu +b *!*@* ; Command to prevent all users from |
858 |
joining. |
859 |
|
860 |
MODE &oulu +b *!*@*.edu +e *!*@*.bu.edu |
861 |
; Command to prevent any user from a |
862 |
hostname matching *.edu from joining, |
863 |
except if matching *.bu.edu |
864 |
|
865 |
MODE #bu +be *!*@*.edu *!*@*.bu.edu |
866 |
; Comment to prevent any user from a |
867 |
hostname matching *.edu from joining, |
868 |
except if matching *.bu.edu |
869 |
|
870 |
MODE #meditation e ; Command to list exception masks set |
871 |
for the channel "#meditation". |
872 |
|
873 |
MODE #meditation I ; Command to list invitations masks |
874 |
set for the channel "#meditation". |
875 |
|
876 |
MODE !12345ircd O ; Command to ask who the channel |
877 |
creator for "!12345ircd" is |
878 |
|
879 |
3.2.4 Topic message |
880 |
|
881 |
Command: TOPIC |
882 |
Parameters: <channel> [ <topic> ] |
883 |
|
884 |
The TOPIC command is used to change or view the topic of a channel. |
885 |
The topic for channel <channel> is returned if there is no <topic> |
886 |
given. If the <topic> parameter is present, the topic for that |
887 |
channel will be changed, if this action is allowed for the user |
888 |
requesting it. If the <topic> parameter is an empty string, the |
889 |
topic for that channel will be removed. |
890 |
|
891 |
Numeric Replies: |
892 |
|
893 |
ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL |
894 |
RPL_NOTOPIC RPL_TOPIC |
895 |
ERR_CHANOPRIVSNEEDED ERR_NOCHANMODES |
896 |
|
897 |
Examples: |
898 |
|
899 |
:WiZ!jto@tolsun.oulu.fi TOPIC #test :New topic ; User Wiz setting the |
900 |
topic. |
901 |
|
902 |
TOPIC #test :another topic ; Command to set the topic on #test |
903 |
to "another topic". |
904 |
|
905 |
TOPIC #test : ; Command to clear the topic on |
906 |
#test. |
907 |
|
908 |
TOPIC #test ; Command to check the topic for |
909 |
#test. |
910 |
|
911 |
3.2.5 Names message |
912 |
|
913 |
Command: NAMES |
914 |
Parameters: [ <channel> *( "," <channel> ) [ <target> ] ] |
915 |
|
916 |
By using the NAMES command, a user can list all nicknames that are |
917 |
visible to him. For more details on what is visible and what is not, |
918 |
see "Internet Relay Chat: Channel Management" [IRC-CHAN]. The |
919 |
<channel> parameter specifies which channel(s) to return information |
920 |
about. There is no error reply for bad channel names. |
921 |
|
922 |
If no <channel> parameter is given, a list of all channels and their |
923 |
occupants is returned. At the end of this list, a list of users who |
924 |
are visible but either not on any channel or not on a visible channel |
925 |
are listed as being on `channel' "*". |
926 |
|
927 |
If the <target> parameter is specified, the request is forwarded to |
928 |
that server which will generate the reply. |
929 |
|
930 |
Wildcards are allowed in the <target> parameter. |
931 |
|
932 |
Numerics: |
933 |
|
934 |
ERR_TOOMANYMATCHES ERR_NOSUCHSERVER |
935 |
RPL_NAMREPLY RPL_ENDOFNAMES |
936 |
|
937 |
Examples: |
938 |
|
939 |
NAMES #twilight_zone,#42 ; Command to list visible users on |
940 |
#twilight_zone and #42 |
941 |
|
942 |
NAMES ; Command to list all visible |
943 |
channels and users |
944 |
|
945 |
3.2.6 List message |
946 |
|
947 |
Command: LIST |
948 |
Parameters: [ <channel> *( "," <channel> ) [ <target> ] ] |
949 |
|
950 |
The list command is used to list channels and their topics. If the |
951 |
<channel> parameter is used, only the status of that channel is |
952 |
displayed. |
953 |
|
954 |
If the <target> parameter is specified, the request is forwarded to |
955 |
that server which will generate the reply. |
956 |
|
957 |
Wildcards are allowed in the <target> parameter. |
958 |
|
959 |
Numeric Replies: |
960 |
|
961 |
ERR_TOOMANYMATCHES ERR_NOSUCHSERVER |
962 |
RPL_LIST RPL_LISTEND |
963 |
|
964 |
Examples: |
965 |
|
966 |
LIST ; Command to list all channels. |
967 |
|
968 |
LIST #twilight_zone,#42 ; Command to list channels |
969 |
#twilight_zone and #42 |
970 |
|
971 |
3.2.7 Invite message |
972 |
|
973 |
Command: INVITE |
974 |
Parameters: <nickname> <channel> |
975 |
|
976 |
The INVITE command is used to invite a user to a channel. The |
977 |
parameter <nickname> is the nickname of the person to be invited to |
978 |
the target channel <channel>. There is no requirement that the |
979 |
channel the target user is being invited to must exist or be a valid |
980 |
channel. However, if the channel exists, only members of the channel |
981 |
are allowed to invite other users. When the channel has invite-only |
982 |
flag set, only channel operators may issue INVITE command. |
983 |
|
984 |
Only the user inviting and the user being invited will receive |
985 |
notification of the invitation. Other channel members are not |
986 |
notified. (This is unlike the MODE changes, and is occasionally the |
987 |
source of trouble for users.) |
988 |
|
989 |
Numeric Replies: |
990 |
|
991 |
ERR_NEEDMOREPARAMS ERR_NOSUCHNICK |
992 |
ERR_NOTONCHANNEL ERR_USERONCHANNEL |
993 |
ERR_CHANOPRIVSNEEDED |
994 |
RPL_INVITING RPL_AWAY |
995 |
|
996 |
Examples: |
997 |
|
998 |
:Angel!wings@irc.org INVITE Wiz #Dust |
999 |
|
1000 |
; Message to WiZ when he has been |
1001 |
invited by user Angel to channel |
1002 |
#Dust |
1003 |
|
1004 |
INVITE Wiz #Twilight_Zone ; Command to invite WiZ to |
1005 |
#Twilight_zone |
1006 |
|
1007 |
3.2.8 Kick command |
1008 |
|
1009 |
Command: KICK |
1010 |
Parameters: <channel> *( "," <channel> ) <user> *( "," <user> ) |
1011 |
[<comment>] |
1012 |
|
1013 |
The KICK command can be used to request the forced removal of a user |
1014 |
from a channel. It causes the <user> to PART from the <channel> by |
1015 |
force. For the message to be syntactically correct, there MUST be |
1016 |
either one channel parameter and multiple user parameter, or as many |
1017 |
channel parameters as there are user parameters. If a "comment" is |
1018 |
given, this will be sent instead of the default message, the nickname |
1019 |
of the user issuing the KICK. |
1020 |
|
1021 |
The server MUST NOT send KICK messages with multiple channels or |
1022 |
users to clients. This is necessarily to maintain backward |
1023 |
compatibility with old client software. |
1024 |
|
1025 |
Numeric Replies: |
1026 |
|
1027 |
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL |
1028 |
ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED |
1029 |
ERR_USERNOTINCHANNEL ERR_NOTONCHANNEL |
1030 |
|
1031 |
Examples: |
1032 |
|
1033 |
KICK &Melbourne Matthew ; Command to kick Matthew from |
1034 |
&Melbourne |
1035 |
|
1036 |
KICK #Finnish John :Speaking English |
1037 |
; Command to kick John from #Finnish |
1038 |
using "Speaking English" as the |
1039 |
reason (comment). |
1040 |
|
1041 |
:WiZ!jto@tolsun.oulu.fi KICK #Finnish John |
1042 |
; KICK message on channel #Finnish |
1043 |
from WiZ to remove John from channel |
1044 |
|
1045 |
3.3 Sending messages |
1046 |
|
1047 |
The main purpose of the IRC protocol is to provide a base for clients |
1048 |
to communicate with each other. PRIVMSG, NOTICE and SQUERY |
1049 |
(described in Section 3.5 on Service Query and Commands) are the only |
1050 |
messages available which actually perform delivery of a text message |
1051 |
from one client to another - the rest just make it possible and try |
1052 |
to ensure it happens in a reliable and structured manner. |
1053 |
|
1054 |
3.3.1 Private messages |
1055 |
|
1056 |
Command: PRIVMSG |
1057 |
Parameters: <msgtarget> <text to be sent> |
1058 |
|
1059 |
PRIVMSG is used to send private messages between users, as well as to |
1060 |
send messages to channels. <msgtarget> is usually the nickname of |
1061 |
the recipient of the message, or a channel name. |
1062 |
|
1063 |
The <msgtarget> parameter may also be a host mask (#<mask>) or server |
1064 |
mask ($<mask>). In both cases the server will only send the PRIVMSG |
1065 |
to those who have a server or host matching the mask. The mask MUST |
1066 |
have at least 1 (one) "." in it and no wildcards following the last |
1067 |
".". This requirement exists to prevent people sending messages to |
1068 |
"#*" or "$*", which would broadcast to all users. Wildcards are the |
1069 |
'*' and '?' characters. This extension to the PRIVMSG command is |
1070 |
only available to operators. |
1071 |
|
1072 |
Numeric Replies: |
1073 |
|
1074 |
ERR_NORECIPIENT ERR_NOTEXTTOSEND |
1075 |
ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL |
1076 |
ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS |
1077 |
ERR_NOSUCHNICK |
1078 |
RPL_AWAY |
1079 |
|
1080 |
Examples: |
1081 |
|
1082 |
:Angel!wings@irc.org PRIVMSG Wiz :Are you receiving this message ? |
1083 |
; Message from Angel to Wiz. |
1084 |
|
1085 |
PRIVMSG Angel :yes I'm receiving it ! |
1086 |
; Command to send a message to Angel. |
1087 |
|
1088 |
PRIVMSG jto@tolsun.oulu.fi :Hello ! |
1089 |
; Command to send a message to a user |
1090 |
on server tolsun.oulu.fi with |
1091 |
username of "jto". |
1092 |
|
1093 |
PRIVMSG kalt%millennium.stealth.net@irc.stealth.net :Are you a frog? |
1094 |
; Message to a user on server |
1095 |
irc.stealth.net with username of |
1096 |
"kalt", and connected from the host |
1097 |
millennium.stealth.net. |
1098 |
|
1099 |
PRIVMSG kalt%millennium.stealth.net :Do you like cheese? |
1100 |
; Message to a user on the local |
1101 |
server with username of "kalt", and |
1102 |
connected from the host |
1103 |
millennium.stealth.net. |
1104 |
|
1105 |
PRIVMSG Wiz!jto@tolsun.oulu.fi :Hello ! |
1106 |
; Message to the user with nickname |
1107 |
Wiz who is connected from the host |
1108 |
tolsun.oulu.fi and has the username |
1109 |
"jto". |
1110 |
|
1111 |
PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting. |
1112 |
; Message to everyone on a server |
1113 |
which has a name matching *.fi. |
1114 |
|
1115 |
PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions |
1116 |
; Message to all users who come from |
1117 |
a host which has a name matching |
1118 |
*.edu. |
1119 |
|
1120 |
3.3.2 Notice |
1121 |
|
1122 |
Command: NOTICE |
1123 |
Parameters: <msgtarget> <text> |
1124 |
|
1125 |
The NOTICE command is used similarly to PRIVMSG. The difference |
1126 |
between NOTICE and PRIVMSG is that automatic replies MUST NEVER be |
1127 |
sent in response to a NOTICE message. This rule applies to servers |
1128 |
|
1129 |
too - they MUST NOT send any error reply back to the client on |
1130 |
receipt of a notice. The object of this rule is to avoid loops |
1131 |
between clients automatically sending something in response to |
1132 |
something it received. |
1133 |
|
1134 |
This command is available to services as well as users. |
1135 |
|
1136 |
This is typically used by services, and automatons (clients with |
1137 |
either an AI or other interactive program controlling their actions). |
1138 |
|
1139 |
See PRIVMSG for more details on replies and examples. |
1140 |
|
1141 |
3.4 Server queries and commands |
1142 |
|
1143 |
The server query group of commands has been designed to return |
1144 |
information about any server which is connected to the network. |
1145 |
|
1146 |
In these queries, where a parameter appears as <target>, wildcard |
1147 |
masks are usually valid. For each parameter, however, only one query |
1148 |
and set of replies is to be generated. In most cases, if a nickname |
1149 |
is given, it will mean the server to which the user is connected. |
1150 |
|
1151 |
These messages typically have little value for services, it is |
1152 |
therefore RECOMMENDED to forbid services from using them. |
1153 |
|
1154 |
3.4.1 Motd message |
1155 |
|
1156 |
Command: MOTD |
1157 |
Parameters: [ <target> ] |
1158 |
|
1159 |
The MOTD command is used to get the "Message Of The Day" of the given |
1160 |
server, or current server if <target> is omitted. |
1161 |
|
1162 |
Wildcards are allowed in the <target> parameter. |
1163 |
|
1164 |
Numeric Replies: |
1165 |
RPL_MOTDSTART RPL_MOTD |
1166 |
RPL_ENDOFMOTD ERR_NOMOTD |
1167 |
|
1168 |
3.4.2 Lusers message |
1169 |
|
1170 |
Command: LUSERS |
1171 |
Parameters: [ <mask> [ <target> ] ] |
1172 |
|
1173 |
The LUSERS command is used to get statistics about the size of the |
1174 |
IRC network. If no parameter is given, the reply will be about the |
1175 |
whole net. If a <mask> is specified, then the reply will only |
1176 |
|
1177 |
concern the part of the network formed by the servers matching the |
1178 |
mask. Finally, if the <target> parameter is specified, the request |
1179 |
is forwarded to that server which will generate the reply. |
1180 |
|
1181 |
Wildcards are allowed in the <target> parameter. |
1182 |
|
1183 |
Numeric Replies: |
1184 |
|
1185 |
RPL_LUSERCLIENT RPL_LUSEROP |
1186 |
RPL_LUSERUNKOWN RPL_LUSERCHANNELS |
1187 |
RPL_LUSERME ERR_NOSUCHSERVER |
1188 |
|
1189 |
3.4.3 Version message |
1190 |
|
1191 |
Command: VERSION |
1192 |
Parameters: [ <target> ] |
1193 |
|
1194 |
The VERSION command is used to query the version of the server |
1195 |
program. An optional parameter <target> is used to query the version |
1196 |
of the server program which a client is not directly connected to. |
1197 |
|
1198 |
Wildcards are allowed in the <target> parameter. |
1199 |
|
1200 |
Numeric Replies: |
1201 |
|
1202 |
ERR_NOSUCHSERVER RPL_VERSION |
1203 |
|
1204 |
Examples: |
1205 |
|
1206 |
VERSION tolsun.oulu.fi ; Command to check the version of |
1207 |
server "tolsun.oulu.fi". |
1208 |
|
1209 |
3.4.4 Stats message |
1210 |
|
1211 |
Command: STATS |
1212 |
Parameters: [ <query> [ <target> ] ] |
1213 |
|
1214 |
The stats command is used to query statistics of certain server. If |
1215 |
<query> parameter is omitted, only the end of stats reply is sent |
1216 |
back. |
1217 |
|
1218 |
A query may be given for any single letter which is only checked by |
1219 |
the destination server and is otherwise passed on by intermediate |
1220 |
servers, ignored and unaltered. |
1221 |
|
1222 |
Wildcards are allowed in the <target> parameter. |
1223 |
|
1224 |
Except for the ones below, the list of valid queries is |
1225 |
implementation dependent. The standard queries below SHOULD be |
1226 |
supported by the server: |
1227 |
|
1228 |
l - returns a list of the server's connections, showing how |
1229 |
long each connection has been established and the |
1230 |
traffic over that connection in Kbytes and messages for |
1231 |
each direction; |
1232 |
m - returns the usage count for each of commands supported |
1233 |
by the server; commands for which the usage count is |
1234 |
zero MAY be omitted; |
1235 |
o - returns a list of configured privileged users, |
1236 |
operators; |
1237 |
u - returns a string showing how long the server has been |
1238 |
up. |
1239 |
|
1240 |
It is also RECOMMENDED that client and server access configuration be |
1241 |
published this way. |
1242 |
|
1243 |
Numeric Replies: |
1244 |
|
1245 |
ERR_NOSUCHSERVER |
1246 |
RPL_STATSLINKINFO RPL_STATSUPTIME |
1247 |
RPL_STATSCOMMANDS RPL_STATSOLINE |
1248 |
RPL_ENDOFSTATS |
1249 |
|
1250 |
Examples: |
1251 |
|
1252 |
STATS m ; Command to check the command usage |
1253 |
for the server you are connected to |
1254 |
|
1255 |
3.4.5 Links message |
1256 |
|
1257 |
Command: LINKS |
1258 |
Parameters: [ [ <remote server> ] <server mask> ] |
1259 |
|
1260 |
With LINKS, a user can list all servernames, which are known by the |
1261 |
server answering the query. The returned list of servers MUST match |
1262 |
the mask, or if no mask is given, the full list is returned. |
1263 |
|
1264 |
If <remote server> is given in addition to <server mask>, the LINKS |
1265 |
command is forwarded to the first server found that matches that name |
1266 |
(if any), and that server is then required to answer the query. |
1267 |
|
1268 |
Numeric Replies: |
1269 |
|
1270 |
ERR_NOSUCHSERVER |
1271 |
RPL_LINKS RPL_ENDOFLINKS |
1272 |
|
1273 |
Examples: |
1274 |
|
1275 |
LINKS *.au ; Command to list all servers which |
1276 |
have a name that matches *.au; |
1277 |
|
1278 |
LINKS *.edu *.bu.edu ; Command to list servers matching |
1279 |
*.bu.edu as seen by the first server |
1280 |
matching *.edu. |
1281 |
|
1282 |
3.4.6 Time message |
1283 |
|
1284 |
Command: TIME |
1285 |
Parameters: [ <target> ] |
1286 |
|
1287 |
The time command is used to query local time from the specified |
1288 |
server. If the <target> parameter is not given, the server receiving |
1289 |
the command must reply to the query. |
1290 |
|
1291 |
Wildcards are allowed in the <target> parameter. |
1292 |
|
1293 |
Numeric Replies: |
1294 |
|
1295 |
ERR_NOSUCHSERVER RPL_TIME |
1296 |
|
1297 |
Examples: |
1298 |
TIME tolsun.oulu.fi ; check the time on the server |
1299 |
"tolson.oulu.fi" |
1300 |
|
1301 |
3.4.7 Connect message |
1302 |
|
1303 |
Command: CONNECT |
1304 |
Parameters: <target server> <port> [ <remote server> ] |
1305 |
|
1306 |
The CONNECT command can be used to request a server to try to |
1307 |
establish a new connection to another server immediately. CONNECT is |
1308 |
a privileged command and SHOULD be available only to IRC Operators. |
1309 |
If a <remote server> is given and its mask doesn't match name of the |
1310 |
parsing server, the CONNECT attempt is sent to the first match of |
1311 |
remote server. Otherwise the CONNECT attempt is made by the server |
1312 |
processing the request. |
1313 |
|
1314 |
The server receiving a remote CONNECT command SHOULD generate a |
1315 |
WALLOPS message describing the source and target of the request. |
1316 |
|
1317 |
Numeric Replies: |
1318 |
|
1319 |
ERR_NOSUCHSERVER ERR_NOPRIVILEGES |
1320 |
ERR_NEEDMOREPARAMS |
1321 |
|
1322 |
Examples: |
1323 |
|
1324 |
CONNECT tolsun.oulu.fi 6667 ; Command to attempt to connect local |
1325 |
server to tolsun.oulu.fi on port 6667 |
1326 |
|
1327 |
3.4.8 Trace message |
1328 |
|
1329 |
Command: TRACE |
1330 |
Parameters: [ <target> ] |
1331 |
|
1332 |
TRACE command is used to find the route to specific server and |
1333 |
information about its peers. Each server that processes this command |
1334 |
MUST report to the sender about it. The replies from pass-through |
1335 |
links form a chain, which shows route to destination. After sending |
1336 |
this reply back, the query MUST be sent to the next server until |
1337 |
given <target> server is reached. |
1338 |
|
1339 |
TRACE command is used to find the route to specific server. Each |
1340 |
server that processes this message MUST tell the sender about it by |
1341 |
sending a reply indicating it is a pass-through link, forming a chain |
1342 |
of replies. After sending this reply back, it MUST then send the |
1343 |
TRACE message to the next server until given server is reached. If |
1344 |
the <target> parameter is omitted, it is RECOMMENDED that TRACE |
1345 |
command sends a message to the sender telling which servers the local |
1346 |
server has direct connection to. |
1347 |
|
1348 |
If the destination given by <target> is an actual server, the |
1349 |
destination server is REQUIRED to report all servers, services and |
1350 |
operators which are connected to it; if the command was issued by an |
1351 |
operator, the server MAY also report all users which are connected to |
1352 |
it. If the destination given by <target> is a nickname, then only a |
1353 |
reply for that nickname is given. If the <target> parameter is |
1354 |
omitted, it is RECOMMENDED that the TRACE command is parsed as |
1355 |
targeted to the processing server. |
1356 |
|
1357 |
Wildcards are allowed in the <target> parameter. |
1358 |
|
1359 |
Numeric Replies: |
1360 |
|
1361 |
ERR_NOSUCHSERVER |
1362 |
|
1363 |
If the TRACE message is destined for another server, all |
1364 |
intermediate servers must return a RPL_TRACELINK reply to indicate |
1365 |
that the TRACE passed through it and where it is going next. |
1366 |
|
1367 |
RPL_TRACELINK |
1368 |
|
1369 |
A TRACE reply may be composed of any number of the following |
1370 |
numeric replies. |
1371 |
|
1372 |
RPL_TRACECONNECTING RPL_TRACEHANDSHAKE |
1373 |
RPL_TRACEUNKNOWN RPL_TRACEOPERATOR |
1374 |
RPL_TRACEUSER RPL_TRACESERVER |
1375 |
RPL_TRACESERVICE RPL_TRACENEWTYPE |
1376 |
RPL_TRACECLASS RPL_TRACELOG |
1377 |
RPL_TRACEEND |
1378 |
|
1379 |
Examples: |
1380 |
|
1381 |
TRACE *.oulu.fi ; TRACE to a server matching |
1382 |
*.oulu.fi |
1383 |
|
1384 |
3.4.9 Admin command |
1385 |
|
1386 |
Command: ADMIN |
1387 |
Parameters: [ <target> ] |
1388 |
|
1389 |
The admin command is used to find information about the administrator |
1390 |
of the given server, or current server if <target> parameter is |
1391 |
omitted. Each server MUST have the ability to forward ADMIN messages |
1392 |
to other servers. |
1393 |
|
1394 |
Wildcards are allowed in the <target> parameter. |
1395 |
|
1396 |
Numeric Replies: |
1397 |
|
1398 |
ERR_NOSUCHSERVER |
1399 |
RPL_ADMINME RPL_ADMINLOC1 |
1400 |
RPL_ADMINLOC2 RPL_ADMINEMAIL |
1401 |
|
1402 |
Examples: |
1403 |
|
1404 |
ADMIN tolsun.oulu.fi ; request an ADMIN reply from |
1405 |
tolsun.oulu.fi |
1406 |
|
1407 |
ADMIN syrk ; ADMIN request for the server to |
1408 |
which the user syrk is connected |
1409 |
|
1410 |
3.4.10 Info command |
1411 |
|
1412 |
Command: INFO |
1413 |
Parameters: [ <target> ] |
1414 |
|
1415 |
The INFO command is REQUIRED to return information describing the |
1416 |
server: its version, when it was compiled, the patchlevel, when it |
1417 |
was started, and any other miscellaneous information which may be |
1418 |
considered to be relevant. |
1419 |
|
1420 |
Wildcards are allowed in the <target> parameter. |
1421 |
|
1422 |
Numeric Replies: |
1423 |
|
1424 |
ERR_NOSUCHSERVER |
1425 |
RPL_INFO RPL_ENDOFINFO |
1426 |
|
1427 |
Examples: |
1428 |
|
1429 |
INFO csd.bu.edu ; request an INFO reply from |
1430 |
csd.bu.edu |
1431 |
|
1432 |
INFO Angel ; request info from the server that |
1433 |
Angel is connected to. |
1434 |
|
1435 |
3.5 Service Query and Commands |
1436 |
|
1437 |
The service query group of commands has been designed to return |
1438 |
information about any service which is connected to the network. |
1439 |
|
1440 |
3.5.1 Servlist message |
1441 |
|
1442 |
Command: SERVLIST |
1443 |
Parameters: [ <mask> [ <type> ] ] |
1444 |
|
1445 |
The SERVLIST command is used to list services currently connected to |
1446 |
the network and visible to the user issuing the command. The |
1447 |
optional parameters may be used to restrict the result of the query |
1448 |
(to matching services names, and services type). |
1449 |
|
1450 |
Numeric Replies: |
1451 |
|
1452 |
RPL_SERVLIST RPL_SERVLISTEND |
1453 |
|
1454 |
3.5.2 Squery |
1455 |
|
1456 |
Command: SQUERY |
1457 |
Parameters: <servicename> <text> |
1458 |
|
1459 |
The SQUERY command is used similarly to PRIVMSG. The only difference |
1460 |
is that the recipient MUST be a service. This is the only way for a |
1461 |
text message to be delivered to a service. |
1462 |
|
1463 |
See PRIVMSG for more details on replies and example. |
1464 |
|
1465 |
Examples: |
1466 |
|
1467 |
SQUERY irchelp :HELP privmsg |
1468 |
; Message to the service with |
1469 |
nickname irchelp. |
1470 |
|
1471 |
SQUERY dict@irc.fr :fr2en blaireau |
1472 |
; Message to the service with name |
1473 |
dict@irc.fr. |
1474 |
|
1475 |
3.6 User based queries |
1476 |
|
1477 |
User queries are a group of commands which are primarily concerned |
1478 |
with finding details on a particular user or group users. When using |
1479 |
wildcards with any of these commands, if they match, they will only |
1480 |
return information on users who are 'visible' to you. The visibility |
1481 |
of a user is determined as a combination of the user's mode and the |
1482 |
common set of channels you are both on. |
1483 |
|
1484 |
Although services SHOULD NOT be using this class of message, they are |
1485 |
allowed to. |
1486 |
|
1487 |
3.6.1 Who query |
1488 |
|
1489 |
Command: WHO |
1490 |
Parameters: [ <mask> [ "o" ] ] |
1491 |
|
1492 |
The WHO command is used by a client to generate a query which returns |
1493 |
a list of information which 'matches' the <mask> parameter given by |
1494 |
the client. In the absence of the <mask> parameter, all visible |
1495 |
(users who aren't invisible (user mode +i) and who don't have a |
1496 |
common channel with the requesting client) are listed. The same |
1497 |
result can be achieved by using a <mask> of "0" or any wildcard which |
1498 |
will end up matching every visible user. |
1499 |
|
1500 |
The <mask> passed to WHO is matched against users' host, server, real |
1501 |
name and nickname if the channel <mask> cannot be found. |
1502 |
|
1503 |
If the "o" parameter is passed only operators are returned according |
1504 |
to the <mask> supplied. |
1505 |
|
1506 |
Numeric Replies: |
1507 |
|
1508 |
ERR_NOSUCHSERVER |
1509 |
RPL_WHOREPLY RPL_ENDOFWHO |
1510 |
|
1511 |
Examples: |
1512 |
|
1513 |
WHO *.fi ; Command to list all users who match |
1514 |
against "*.fi". |
1515 |
|
1516 |
WHO jto* o ; Command to list all users with a |
1517 |
match against "jto*" if they are an |
1518 |
operator. |
1519 |
|
1520 |
3.6.2 Whois query |
1521 |
|
1522 |
Command: WHOIS |
1523 |
Parameters: [ <target> ] <mask> *( "," <mask> ) |
1524 |
|
1525 |
This command is used to query information about particular user. |
1526 |
The server will answer this command with several numeric messages |
1527 |
indicating different statuses of each user which matches the mask (if |
1528 |
you are entitled to see them). If no wildcard is present in the |
1529 |
<mask>, any information about that nick which you are allowed to see |
1530 |
is presented. |
1531 |
|
1532 |
If the <target> parameter is specified, it sends the query to a |
1533 |
specific server. It is useful if you want to know how long the user |
1534 |
in question has been idle as only local server (i.e., the server the |
1535 |
user is directly connected to) knows that information, while |
1536 |
everything else is globally known. |
1537 |
|
1538 |
Wildcards are allowed in the <target> parameter. |
1539 |
|
1540 |
Numeric Replies: |
1541 |
|
1542 |
ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN |
1543 |
RPL_WHOISUSER RPL_WHOISCHANNELS |
1544 |
RPL_WHOISCHANNELS RPL_WHOISSERVER |
1545 |
RPL_AWAY RPL_WHOISOPERATOR |
1546 |
RPL_WHOISIDLE ERR_NOSUCHNICK |
1547 |
RPL_ENDOFWHOIS |
1548 |
|
1549 |
Examples: |
1550 |
|
1551 |
WHOIS wiz ; return available user information |
1552 |
about nick WiZ |
1553 |
|
1554 |
WHOIS eff.org trillian ; ask server eff.org for user |
1555 |
information about trillian |
1556 |
|
1557 |
3.6.3 Whowas |
1558 |
|
1559 |
Command: WHOWAS |
1560 |
Parameters: <nickname> *( "," <nickname> ) [ <count> [ <target> ] ] |
1561 |
|
1562 |
Whowas asks for information about a nickname which no longer exists. |
1563 |
This may either be due to a nickname change or the user leaving IRC. |
1564 |
In response to this query, the server searches through its nickname |
1565 |
history, looking for any nicks which are lexically the same (no wild |
1566 |
card matching here). The history is searched backward, returning the |
1567 |
most recent entry first. If there are multiple entries, up to |
1568 |
<count> replies will be returned (or all of them if no <count> |
1569 |
parameter is given). If a non-positive number is passed as being |
1570 |
<count>, then a full search is done. |
1571 |
|
1572 |
Wildcards are allowed in the <target> parameter. |
1573 |
|
1574 |
Numeric Replies: |
1575 |
|
1576 |
ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK |
1577 |
RPL_WHOWASUSER RPL_WHOISSERVER |
1578 |
RPL_ENDOFWHOWAS |
1579 |
|
1580 |
Examples: |
1581 |
|
1582 |
WHOWAS Wiz ; return all information in the nick |
1583 |
history about nick "WiZ"; |
1584 |
|
1585 |
WHOWAS Mermaid 9 ; return at most, the 9 most recent |
1586 |
entries in the nick history for |
1587 |
"Mermaid"; |
1588 |
|
1589 |
WHOWAS Trillian 1 *.edu ; return the most recent history for |
1590 |
"Trillian" from the first server |
1591 |
found to match "*.edu". |
1592 |
|
1593 |
3.7 Miscellaneous messages |
1594 |
|
1595 |
Messages in this category do not fit into any of the above categories |
1596 |
but are nonetheless still a part of and REQUIRED by the protocol. |
1597 |
|
1598 |
3.7.1 Kill message |
1599 |
|
1600 |
Command: KILL |
1601 |
Parameters: <nickname> <comment> |
1602 |
|
1603 |
The KILL command is used to cause a client-server connection to be |
1604 |
closed by the server which has the actual connection. Servers |
1605 |
generate KILL messages on nickname collisions. It MAY also be |
1606 |
available available to users who have the operator status. |
1607 |
|
1608 |
Clients which have automatic reconnect algorithms effectively make |
1609 |
this command useless since the disconnection is only brief. It does |
1610 |
however break the flow of data and can be used to stop large amounts |
1611 |
of 'flooding' from abusive users or accidents. Abusive users usually |
1612 |
don't care as they will reconnect promptly and resume their abusive |
1613 |
behaviour. To prevent this command from being abused, any user may |
1614 |
elect to receive KILL messages generated for others to keep an 'eye' |
1615 |
on would be trouble spots. |
1616 |
|
1617 |
In an arena where nicknames are REQUIRED to be globally unique at all |
1618 |
times, KILL messages are sent whenever 'duplicates' are detected |
1619 |
(that is an attempt to register two users with the same nickname) in |
1620 |
the hope that both of them will disappear and only 1 reappear. |
1621 |
|
1622 |
When a client is removed as the result of a KILL message, the server |
1623 |
SHOULD add the nickname to the list of unavailable nicknames in an |
1624 |
attempt to avoid clients to reuse this name immediately which is |
1625 |
usually the pattern of abusive behaviour often leading to useless |
1626 |
"KILL loops". See the "IRC Server Protocol" document [IRC-SERVER] |
1627 |
for more information on this procedure. |
1628 |
|
1629 |
The comment given MUST reflect the actual reason for the KILL. For |
1630 |
server-generated KILLs it usually is made up of details concerning |
1631 |
the origins of the two conflicting nicknames. For users it is left |
1632 |
up to them to provide an adequate reason to satisfy others who see |
1633 |
it. To prevent/discourage fake KILLs from being generated to hide |
1634 |
the identify of the KILLer, the comment also shows a 'kill-path' |
1635 |
which is updated by each server it passes through, each prepending |
1636 |
its name to the path. |
1637 |
|
1638 |
Numeric Replies: |
1639 |
|
1640 |
ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS |
1641 |
ERR_NOSUCHNICK ERR_CANTKILLSERVER |
1642 |
|
1643 |
NOTE: |
1644 |
It is RECOMMENDED that only Operators be allowed to kill other users |
1645 |
with KILL command. This command has been the subject of many |
1646 |
controversies over the years, and along with the above |
1647 |
recommendation, it is also widely recognized that not even operators |
1648 |
should be allowed to kill users on remote servers. |
1649 |
|
1650 |
3.7.2 Ping message |
1651 |
|
1652 |
Command: PING |
1653 |
Parameters: <server1> [ <server2> ] |
1654 |
|
1655 |
The PING command is used to test the presence of an active client or |
1656 |
server at the other end of the connection. Servers send a PING |
1657 |
message at regular intervals if no other activity detected coming |
1658 |
from a connection. If a connection fails to respond to a PING |
1659 |
message within a set amount of time, that connection is closed. A |
1660 |
PING message MAY be sent even if the connection is active. |
1661 |
|
1662 |
When a PING message is received, the appropriate PONG message MUST be |
1663 |
sent as reply to <server1> (server which sent the PING message out) |
1664 |
as soon as possible. If the <server2> parameter is specified, it |
1665 |
represents the target of the ping, and the message gets forwarded |
1666 |
there. |
1667 |
|
1668 |
Numeric Replies: |
1669 |
|
1670 |
ERR_NOORIGIN ERR_NOSUCHSERVER |
1671 |
|
1672 |
Examples: |
1673 |
|
1674 |
PING tolsun.oulu.fi ; Command to send a PING message to |
1675 |
server |
1676 |
|
1677 |
PING WiZ tolsun.oulu.fi ; Command from WiZ to send a PING |
1678 |
message to server "tolsun.oulu.fi" |
1679 |
|
1680 |
PING :irc.funet.fi ; Ping message sent by server |
1681 |
"irc.funet.fi" |
1682 |
|
1683 |
3.7.3 Pong message |
1684 |
|
1685 |
Command: PONG |
1686 |
Parameters: <server> [ <server2> ] |
1687 |
|
1688 |
PONG message is a reply to ping message. If parameter <server2> is |
1689 |
given, this message MUST be forwarded to given target. The <server> |
1690 |
parameter is the name of the entity who has responded to PING message |
1691 |
and generated this message. |
1692 |
|
1693 |
Numeric Replies: |
1694 |
|
1695 |
ERR_NOORIGIN ERR_NOSUCHSERVER |
1696 |
|
1697 |
Example: |
1698 |
|
1699 |
PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to |
1700 |
tolsun.oulu.fi |
1701 |
|
1702 |
3.7.4 Error |
1703 |
|
1704 |
Command: ERROR |
1705 |
Parameters: <error message> |
1706 |
|
1707 |
The ERROR command is for use by servers when reporting a serious or |
1708 |
fatal error to its peers. It may also be sent from one server to |
1709 |
another but MUST NOT be accepted from any normal unknown clients. |
1710 |
|
1711 |
Only an ERROR message SHOULD be used for reporting errors which occur |
1712 |
with a server-to-server link. An ERROR message is sent to the server |
1713 |
at the other end (which reports it to appropriate local users and |
1714 |
logs) and to appropriate local users and logs. It is not to be |
1715 |
passed onto any other servers by a server if it is received from a |
1716 |
server. |
1717 |
|
1718 |
The ERROR message is also used before terminating a client |
1719 |
connection. |
1720 |
|
1721 |
When a server sends a received ERROR message to its operators, the |
1722 |
message SHOULD be encapsulated inside a NOTICE message, indicating |
1723 |
that the client was not responsible for the error. |
1724 |
|
1725 |
Numerics: |
1726 |
|
1727 |
None. |
1728 |
|
1729 |
Examples: |
1730 |
|
1731 |
ERROR :Server *.fi already exists ; ERROR message to the other server |
1732 |
which caused this error. |
1733 |
|
1734 |
NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists |
1735 |
; Same ERROR message as above but |
1736 |
sent to user WiZ on the other server. |
1737 |
|
1738 |
4. Optional features |
1739 |
|
1740 |
This section describes OPTIONAL messages. They are not required in a |
1741 |
working server implementation of the protocol described herein. In |
1742 |
the absence of the feature, an error reply message MUST be generated |
1743 |
or an unknown command error. If the message is destined for another |
1744 |
server to answer then it MUST be passed on (elementary parsing |
1745 |
REQUIRED) The allocated numerics for this are listed with the |
1746 |
messages below. |
1747 |
|
1748 |
From this section, only the USERHOST and ISON messages are available |
1749 |
to services. |
1750 |
|
1751 |
4.1 Away |
1752 |
|
1753 |
Command: AWAY |
1754 |
Parameters: [ <text> ] |
1755 |
|
1756 |
With the AWAY command, clients can set an automatic reply string for |
1757 |
any PRIVMSG commands directed at them (not to a channel they are on). |
1758 |
The server sends an automatic reply to the client sending the PRIVMSG |
1759 |
command. The only replying server is the one to which the sending |
1760 |
client is connected to. |
1761 |
|
1762 |
The AWAY command is used either with one parameter, to set an AWAY |
1763 |
message, or with no parameters, to remove the AWAY message. |
1764 |
|
1765 |
Because of its high cost (memory and bandwidth wise), the AWAY |
1766 |
message SHOULD only be used for client-server communication. A |
1767 |
server MAY choose to silently ignore AWAY messages received from |
1768 |
other servers. To update the away status of a client across servers, |
1769 |
the user mode 'a' SHOULD be used instead. (See Section 3.1.5) |
1770 |
|
1771 |
Numeric Replies: |
1772 |
|
1773 |
RPL_UNAWAY RPL_NOWAWAY |
1774 |
|
1775 |
Example: |
1776 |
|
1777 |
AWAY :Gone to lunch. Back in 5 ; Command to set away message to |
1778 |
"Gone to lunch. Back in 5". |
1779 |
|
1780 |
4.2 Rehash message |
1781 |
|
1782 |
Command: REHASH |
1783 |
Parameters: None |
1784 |
|
1785 |
The rehash command is an administrative command which can be used by |
1786 |
an operator to force the server to re-read and process its |
1787 |
configuration file. |
1788 |
|
1789 |
Numeric Replies: |
1790 |
|
1791 |
RPL_REHASHING ERR_NOPRIVILEGES |
1792 |
|
1793 |
Example: |
1794 |
|
1795 |
REHASH ; message from user with operator |
1796 |
status to server asking it to reread |
1797 |
its configuration file. |
1798 |
|
1799 |
4.3 Die message |
1800 |
|
1801 |
Command: DIE |
1802 |
Parameters: None |
1803 |
|
1804 |
An operator can use the DIE command to shutdown the server. This |
1805 |
message is optional since it may be viewed as a risk to allow |
1806 |
arbitrary people to connect to a server as an operator and execute |
1807 |
this command. |
1808 |
|
1809 |
The DIE command MUST always be fully processed by the server to which |
1810 |
the sending client is connected and MUST NOT be passed onto other |
1811 |
connected servers. |
1812 |
|
1813 |
Numeric Replies: |
1814 |
|
1815 |
ERR_NOPRIVILEGES |
1816 |
|
1817 |
Example: |
1818 |
|
1819 |
DIE ; no parameters required. |
1820 |
|
1821 |
4.4 Restart message |
1822 |
|
1823 |
Command: RESTART |
1824 |
Parameters: None |
1825 |
|
1826 |
An operator can use the restart command to force the server to |
1827 |
restart itself. This message is optional since it may be viewed as a |
1828 |
risk to allow arbitrary people to connect to a server as an operator |
1829 |
and execute this command, causing (at least) a disruption to service. |
1830 |
|
1831 |
The RESTART command MUST always be fully processed by the server to |
1832 |
which the sending client is connected and MUST NOT be passed onto |
1833 |
other connected servers. |
1834 |
|
1835 |
Numeric Replies: |
1836 |
|
1837 |
ERR_NOPRIVILEGES |
1838 |
|
1839 |
Example: |
1840 |
|
1841 |
RESTART ; no parameters required. |
1842 |
|
1843 |
4.5 Summon message |
1844 |
|
1845 |
Command: SUMMON |
1846 |
Parameters: <user> [ <target> [ <channel> ] ] |
1847 |
|
1848 |
The SUMMON command can be used to give users who are on a host |
1849 |
running an IRC server a message asking them to please join IRC. This |
1850 |
message is only sent if the target server (a) has SUMMON enabled, (b) |
1851 |
the user is logged in and (c) the server process can write to the |
1852 |
user's tty (or similar). |
1853 |
|
1854 |
If no <server> parameter is given it tries to summon <user> from the |
1855 |
server the client is connected to is assumed as the target. |
1856 |
|
1857 |
If summon is not enabled in a server, it MUST return the |
1858 |
ERR_SUMMONDISABLED numeric. |
1859 |
|
1860 |
Numeric Replies: |
1861 |
|
1862 |
ERR_NORECIPIENT ERR_FILEERROR |
1863 |
ERR_NOLOGIN ERR_NOSUCHSERVER |
1864 |
ERR_SUMMONDISABLED RPL_SUMMONING |
1865 |
|
1866 |
Examples: |
1867 |
|
1868 |
SUMMON jto ; summon user jto on the server's |
1869 |
host |
1870 |
|
1871 |
SUMMON jto tolsun.oulu.fi ; summon user jto on the host which a |
1872 |
server named "tolsun.oulu.fi" is |
1873 |
running. |
1874 |
|
1875 |
4.6 Users |
1876 |
|
1877 |
Command: USERS |
1878 |
Parameters: [ <target> ] |
1879 |
|
1880 |
The USERS command returns a list of users logged into the server in a |
1881 |
format similar to the UNIX commands who(1), rusers(1) and finger(1). |
1882 |
If disabled, the correct numeric MUST be returned to indicate this. |
1883 |
|
1884 |
Because of the security implications of such a command, it SHOULD be |
1885 |
disabled by default in server implementations. Enabling it SHOULD |
1886 |
require recompiling the server or some equivalent change rather than |
1887 |
simply toggling an option and restarting the server. The procedure |
1888 |
to enable this command SHOULD also include suitable large comments. |
1889 |
|
1890 |
Numeric Replies: |
1891 |
|
1892 |
ERR_NOSUCHSERVER ERR_FILEERROR |
1893 |
RPL_USERSSTART RPL_USERS |
1894 |
RPL_NOUSERS RPL_ENDOFUSERS |
1895 |
ERR_USERSDISABLED |
1896 |
|
1897 |
Disabled Reply: |
1898 |
|
1899 |
ERR_USERSDISABLED |
1900 |
|
1901 |
Example: |
1902 |
|
1903 |
USERS eff.org ; request a list of users logged in |
1904 |
on server eff.org |
1905 |
|
1906 |
4.7 Operwall message |
1907 |
|
1908 |
Command: WALLOPS |
1909 |
Parameters: <Text to be sent> |
1910 |
|
1911 |
The WALLOPS command is used to send a message to all currently |
1912 |
connected users who have set the 'w' user mode for themselves. (See |
1913 |
Section 3.1.5 "User modes"). |
1914 |
|
1915 |
After implementing WALLOPS as a user command it was found that it was |
1916 |
often and commonly abused as a means of sending a message to a lot of |
1917 |
people. Due to this, it is RECOMMENDED that the implementation of |
1918 |
WALLOPS allows and recognizes only servers as the originators of |
1919 |
WALLOPS. |
1920 |
|
1921 |
Numeric Replies: |
1922 |
|
1923 |
ERR_NEEDMOREPARAMS |
1924 |
|
1925 |
Example: |
1926 |
|
1927 |
:csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua ; WALLOPS |
1928 |
message from csd.bu.edu announcing a |
1929 |
CONNECT message it received from |
1930 |
Joshua and acted upon. |
1931 |
|
1932 |
4.8 Userhost message |
1933 |
|
1934 |
Command: USERHOST |
1935 |
Parameters: <nickname> *( SPACE <nickname> ) |
1936 |
|
1937 |
The USERHOST command takes a list of up to 5 nicknames, each |
1938 |
separated by a space character and returns a list of information |
1939 |
about each nickname that it found. The returned list has each reply |
1940 |
separated by a space. |
1941 |
|
1942 |
Numeric Replies: |
1943 |
|
1944 |
RPL_USERHOST ERR_NEEDMOREPARAMS |
1945 |
|
1946 |
Example: |
1947 |
|
1948 |
USERHOST Wiz Michael syrk ; USERHOST request for information on |
1949 |
nicks "Wiz", "Michael", and "syrk" |
1950 |
|
1951 |
:ircd.stealth.net 302 yournick :syrk=+syrk@millennium.stealth.net |
1952 |
; Reply for user syrk |
1953 |
|
1954 |
4.9 Ison message |
1955 |
|
1956 |
Command: ISON |
1957 |
Parameters: <nickname> *( SPACE <nickname> ) |
1958 |
|
1959 |
The ISON command was implemented to provide a quick and efficient |
1960 |
means to get a response about whether a given nickname was currently |
1961 |
on IRC. ISON only takes one (1) type of parameter: a space-separated |
1962 |
list of nicks. For each nickname in the list that is present, the |
1963 |
|
1964 |
server adds that to its reply string. Thus the reply string may |
1965 |
return empty (none of the given nicks are present), an exact copy of |
1966 |
the parameter string (all of them present) or any other subset of the |
1967 |
set of nicks given in the parameter. The only limit on the number of |
1968 |
nicks that may be checked is that the combined length MUST NOT be too |
1969 |
large as to cause the server to chop it off so it fits in 512 |
1970 |
characters. |
1971 |
|
1972 |
ISON is only processed by the server local to the client sending the |
1973 |
command and thus not passed onto other servers for further |
1974 |
processing. |
1975 |
|
1976 |
Numeric Replies: |
1977 |
|
1978 |
RPL_ISON ERR_NEEDMOREPARAMS |
1979 |
|
1980 |
Example: |
1981 |
|
1982 |
ISON phone trillian WiZ jarlek Avalon Angel Monstah syrk |
1983 |
; Sample ISON request for 7 nicks. |
1984 |
|
1985 |
5. Replies |
1986 |
|
1987 |
The following is a list of numeric replies which are generated in |
1988 |
response to the commands given above. Each numeric is given with its |
1989 |
number, name and reply string. |
1990 |
|
1991 |
5.1 Command responses |
1992 |
|
1993 |
Numerics in the range from 001 to 099 are used for client-server |
1994 |
connections only and should never travel between servers. Replies |
1995 |
generated in the response to commands are found in the range from 200 |
1996 |
to 399. |
1997 |
|
1998 |
001 RPL_WELCOME |
1999 |
"Welcome to the Internet Relay Network |
2000 |
<nick>!<user>@<host>" |
2001 |
002 RPL_YOURHOST |
2002 |
"Your host is <servername>, running version <ver>" |
2003 |
003 RPL_CREATED |
2004 |
"This server was created <date>" |
2005 |
004 RPL_MYINFO |
2006 |
"<servername> <version> <available user modes> |
2007 |
<available channel modes>" |
2008 |
|
2009 |
- The server sends Replies 001 to 004 to a user upon |
2010 |
successful registration. |
2011 |
|
2012 |
005 RPL_BOUNCE |
2013 |
"Try server <server name>, port <port number>" |
2014 |
|
2015 |
- Sent by the server to a user to suggest an alternative |
2016 |
server. This is often used when the connection is |
2017 |
refused because the server is already full. |
2018 |
|
2019 |
302 RPL_USERHOST |
2020 |
":*1<reply> *( " " <reply> )" |
2021 |
|
2022 |
- Reply format used by USERHOST to list replies to |
2023 |
the query list. The reply string is composed as |
2024 |
follows: |
2025 |
|
2026 |
reply = nickname [ "*" ] "=" ( "+" / "-" ) hostname |
2027 |
|
2028 |
The '*' indicates whether the client has registered |
2029 |
as an Operator. The '-' or '+' characters represent |
2030 |
whether the client has set an AWAY message or not |
2031 |
respectively. |
2032 |
|
2033 |
303 RPL_ISON |
2034 |
":*1<nick> *( " " <nick> )" |
2035 |
|
2036 |
- Reply format used by ISON to list replies to the |
2037 |
query list. |
2038 |
|
2039 |
301 RPL_AWAY |
2040 |
"<nick> :<away message>" |
2041 |
305 RPL_UNAWAY |
2042 |
":You are no longer marked as being away" |
2043 |
306 RPL_NOWAWAY |
2044 |
":You have been marked as being away" |
2045 |
|
2046 |
- These replies are used with the AWAY command (if |
2047 |
allowed). RPL_AWAY is sent to any client sending a |
2048 |
PRIVMSG to a client which is away. RPL_AWAY is only |
2049 |
sent by the server to which the client is connected. |
2050 |
Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the |
2051 |
client removes and sets an AWAY message. |
2052 |
|
2053 |
311 RPL_WHOISUSER |
2054 |
"<nick> <user> <host> * :<real name>" |
2055 |
312 RPL_WHOISSERVER |
2056 |
"<nick> <server> :<server info>" |
2057 |
313 RPL_WHOISOPERATOR |
2058 |
"<nick> :is an IRC operator" |
2059 |
|
2060 |
317 RPL_WHOISIDLE |
2061 |
"<nick> <integer> :seconds idle" |
2062 |
318 RPL_ENDOFWHOIS |
2063 |
"<nick> :End of WHOIS list" |
2064 |
319 RPL_WHOISCHANNELS |
2065 |
"<nick> :*( ( "@" / "+" ) <channel> " " )" |
2066 |
|
2067 |
- Replies 311 - 313, 317 - 319 are all replies |
2068 |
generated in response to a WHOIS message. Given that |
2069 |
there are enough parameters present, the answering |
2070 |
server MUST either formulate a reply out of the above |
2071 |
numerics (if the query nick is found) or return an |
2072 |
error reply. The '*' in RPL_WHOISUSER is there as |
2073 |
the literal character and not as a wild card. For |
2074 |
each reply set, only RPL_WHOISCHANNELS may appear |
2075 |
more than once (for long lists of channel names). |
2076 |
The '@' and '+' characters next to the channel name |
2077 |
indicate whether a client is a channel operator or |
2078 |
has been granted permission to speak on a moderated |
2079 |
channel. The RPL_ENDOFWHOIS reply is used to mark |
2080 |
the end of processing a WHOIS message. |
2081 |
|
2082 |
314 RPL_WHOWASUSER |
2083 |
"<nick> <user> <host> * :<real name>" |
2084 |
369 RPL_ENDOFWHOWAS |
2085 |
"<nick> :End of WHOWAS" |
2086 |
|
2087 |
- When replying to a WHOWAS message, a server MUST use |
2088 |
the replies RPL_WHOWASUSER, RPL_WHOISSERVER or |
2089 |
ERR_WASNOSUCHNICK for each nickname in the presented |
2090 |
list. At the end of all reply batches, there MUST |
2091 |
be RPL_ENDOFWHOWAS (even if there was only one reply |
2092 |
and it was an error). |
2093 |
|
2094 |
321 RPL_LISTSTART |
2095 |
Obsolete. Not used. |
2096 |
|
2097 |
322 RPL_LIST |
2098 |
"<channel> <# visible> :<topic>" |
2099 |
323 RPL_LISTEND |
2100 |
":End of LIST" |
2101 |
|
2102 |
- Replies RPL_LIST, RPL_LISTEND mark the actual replies |
2103 |
with data and end of the server's response to a LIST |
2104 |
command. If there are no channels available to return, |
2105 |
only the end reply MUST be sent. |
2106 |
|
2107 |
325 RPL_UNIQOPIS |
2108 |
"<channel> <nickname>" |
2109 |
|
2110 |
324 RPL_CHANNELMODEIS |
2111 |
"<channel> <mode> <mode params>" |
2112 |
|
2113 |
331 RPL_NOTOPIC |
2114 |
"<channel> :No topic is set" |
2115 |
332 RPL_TOPIC |
2116 |
"<channel> :<topic>" |
2117 |
|
2118 |
- When sending a TOPIC message to determine the |
2119 |
channel topic, one of two replies is sent. If |
2120 |
the topic is set, RPL_TOPIC is sent back else |
2121 |
RPL_NOTOPIC. |
2122 |
|
2123 |
341 RPL_INVITING |
2124 |
"<channel> <nick>" |
2125 |
|
2126 |
- Returned by the server to indicate that the |
2127 |
attempted INVITE message was successful and is |
2128 |
being passed onto the end client. |
2129 |
|
2130 |
342 RPL_SUMMONING |
2131 |
"<user> :Summoning user to IRC" |
2132 |
|
2133 |
- Returned by a server answering a SUMMON message to |
2134 |
indicate that it is summoning that user. |
2135 |
|
2136 |
346 RPL_INVITELIST |
2137 |
"<channel> <invitemask>" |
2138 |
347 RPL_ENDOFINVITELIST |
2139 |
"<channel> :End of channel invite list" |
2140 |
|
2141 |
- When listing the 'invitations masks' for a given channel, |
2142 |
a server is required to send the list back using the |
2143 |
RPL_INVITELIST and RPL_ENDOFINVITELIST messages. A |
2144 |
separate RPL_INVITELIST is sent for each active mask. |
2145 |
After the masks have been listed (or if none present) a |
2146 |
RPL_ENDOFINVITELIST MUST be sent. |
2147 |
|
2148 |
348 RPL_EXCEPTLIST |
2149 |
"<channel> <exceptionmask>" |
2150 |
349 RPL_ENDOFEXCEPTLIST |
2151 |
"<channel> :End of channel exception list" |
2152 |
|
2153 |
- When listing the 'exception masks' for a given channel, |
2154 |
a server is required to send the list back using the |
2155 |
RPL_EXCEPTLIST and RPL_ENDOFEXCEPTLIST messages. A |
2156 |
separate RPL_EXCEPTLIST is sent for each active mask. |
2157 |
After the masks have been listed (or if none present) |
2158 |
a RPL_ENDOFEXCEPTLIST MUST be sent. |
2159 |
|
2160 |
351 RPL_VERSION |
2161 |
"<version>.<debuglevel> <server> :<comments>" |
2162 |
|
2163 |
- Reply by the server showing its version details. |
2164 |
The <version> is the version of the software being |
2165 |
used (including any patchlevel revisions) and the |
2166 |
<debuglevel> is used to indicate if the server is |
2167 |
running in "debug mode". |
2168 |
|
2169 |
The "comments" field may contain any comments about |
2170 |
the version or further version details. |
2171 |
|
2172 |
352 RPL_WHOREPLY |
2173 |
"<channel> <user> <host> <server> <nick> |
2174 |
( "H" / "G" > ["*"] [ ( "@" / "+" ) ] |
2175 |
:<hopcount> <real name>" |
2176 |
|
2177 |
315 RPL_ENDOFWHO |
2178 |
"<name> :End of WHO list" |
2179 |
|
2180 |
- The RPL_WHOREPLY and RPL_ENDOFWHO pair are used |
2181 |
to answer a WHO message. The RPL_WHOREPLY is only |
2182 |
sent if there is an appropriate match to the WHO |
2183 |
query. If there is a list of parameters supplied |
2184 |
with a WHO message, a RPL_ENDOFWHO MUST be sent |
2185 |
after processing each list item with <name> being |
2186 |
the item. |
2187 |
|
2188 |
353 RPL_NAMREPLY |
2189 |
"( "=" / "*" / "@" ) <channel> |
2190 |
:[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> ) |
2191 |
- "@" is used for secret channels, "*" for private |
2192 |
channels, and "=" for others (public channels). |
2193 |
|
2194 |
366 RPL_ENDOFNAMES |
2195 |
"<channel> :End of NAMES list" |
2196 |
|
2197 |
- To reply to a NAMES message, a reply pair consisting |
2198 |
of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the |
2199 |
server back to the client. If there is no channel |
2200 |
found as in the query, then only RPL_ENDOFNAMES is |
2201 |
|
2202 |
returned. The exception to this is when a NAMES |
2203 |
message is sent with no parameters and all visible |
2204 |
channels and contents are sent back in a series of |
2205 |
RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark |
2206 |
the end. |
2207 |
|
2208 |
364 RPL_LINKS |
2209 |
"<mask> <server> :<hopcount> <server info>" |
2210 |
365 RPL_ENDOFLINKS |
2211 |
"<mask> :End of LINKS list" |
2212 |
|
2213 |
- In replying to the LINKS message, a server MUST send |
2214 |
replies back using the RPL_LINKS numeric and mark the |
2215 |
end of the list using an RPL_ENDOFLINKS reply. |
2216 |
|
2217 |
367 RPL_BANLIST |
2218 |
"<channel> <banmask>" |
2219 |
368 RPL_ENDOFBANLIST |
2220 |
"<channel> :End of channel ban list" |
2221 |
|
2222 |
- When listing the active 'bans' for a given channel, |
2223 |
a server is required to send the list back using the |
2224 |
RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate |
2225 |
RPL_BANLIST is sent for each active banmask. After the |
2226 |
banmasks have been listed (or if none present) a |
2227 |
RPL_ENDOFBANLIST MUST be sent. |
2228 |
|
2229 |
371 RPL_INFO |
2230 |
":<string>" |
2231 |
374 RPL_ENDOFINFO |
2232 |
":End of INFO list" |
2233 |
|
2234 |
- A server responding to an INFO message is required to |
2235 |
send all its 'info' in a series of RPL_INFO messages |
2236 |
with a RPL_ENDOFINFO reply to indicate the end of the |
2237 |
replies. |
2238 |
|
2239 |
375 RPL_MOTDSTART |
2240 |
":- <server> Message of the day - " |
2241 |
372 RPL_MOTD |
2242 |
":- <text>" |
2243 |
376 RPL_ENDOFMOTD |
2244 |
":End of MOTD command" |
2245 |
|
2246 |
- When responding to the MOTD message and the MOTD file |
2247 |
is found, the file is displayed line by line, with |
2248 |
each line no longer than 80 characters, using |
2249 |
|
2250 |
RPL_MOTD format replies. These MUST be surrounded |
2251 |
by a RPL_MOTDSTART (before the RPL_MOTDs) and an |
2252 |
RPL_ENDOFMOTD (after). |
2253 |
|
2254 |
381 RPL_YOUREOPER |
2255 |
":You are now an IRC operator" |
2256 |
|
2257 |
- RPL_YOUREOPER is sent back to a client which has |
2258 |
just successfully issued an OPER message and gained |
2259 |
operator status. |
2260 |
|
2261 |
382 RPL_REHASHING |
2262 |
"<config file> :Rehashing" |
2263 |
|
2264 |
- If the REHASH option is used and an operator sends |
2265 |
a REHASH message, an RPL_REHASHING is sent back to |
2266 |
the operator. |
2267 |
|
2268 |
383 RPL_YOURESERVICE |
2269 |
"You are service <servicename>" |
2270 |
|
2271 |
- Sent by the server to a service upon successful |
2272 |
registration. |
2273 |
|
2274 |
391 RPL_TIME |
2275 |
"<server> :<string showing server's local time>" |
2276 |
|
2277 |
- When replying to the TIME message, a server MUST send |
2278 |
the reply using the RPL_TIME format above. The string |
2279 |
showing the time need only contain the correct day and |
2280 |
time there. There is no further requirement for the |
2281 |
time string. |
2282 |
|
2283 |
392 RPL_USERSSTART |
2284 |
":UserID Terminal Host" |
2285 |
393 RPL_USERS |
2286 |
":<username> <ttyline> <hostname>" |
2287 |
394 RPL_ENDOFUSERS |
2288 |
":End of users" |
2289 |
395 RPL_NOUSERS |
2290 |
":Nobody logged in" |
2291 |
|
2292 |
- If the USERS message is handled by a server, the |
2293 |
replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and |
2294 |
RPL_NOUSERS are used. RPL_USERSSTART MUST be sent |
2295 |
first, following by either a sequence of RPL_USERS |
2296 |
or a single RPL_NOUSER. Following this is |
2297 |
RPL_ENDOFUSERS. |
2298 |
|
2299 |
200 RPL_TRACELINK |
2300 |
"Link <version & debug level> <destination> |
2301 |
<next server> V<protocol version> |
2302 |
<link uptime in seconds> <backstream sendq> |
2303 |
<upstream sendq>" |
2304 |
201 RPL_TRACECONNECTING |
2305 |
"Try. <class> <server>" |
2306 |
202 RPL_TRACEHANDSHAKE |
2307 |
"H.S. <class> <server>" |
2308 |
203 RPL_TRACEUNKNOWN |
2309 |
"???? <class> [<client IP address in dot form>]" |
2310 |
204 RPL_TRACEOPERATOR |
2311 |
"Oper <class> <nick>" |
2312 |
205 RPL_TRACEUSER |
2313 |
"User <class> <nick>" |
2314 |
206 RPL_TRACESERVER |
2315 |
"Serv <class> <int>S <int>C <server> |
2316 |
<nick!user|*!*>@<host|server> V<protocol version>" |
2317 |
207 RPL_TRACESERVICE |
2318 |
"Service <class> <name> <type> <active type>" |
2319 |
208 RPL_TRACENEWTYPE |
2320 |
"<newtype> 0 <client name>" |
2321 |
209 RPL_TRACECLASS |
2322 |
"Class <class> <count>" |
2323 |
210 RPL_TRACERECONNECT |
2324 |
Unused. |
2325 |
261 RPL_TRACELOG |
2326 |
"File <logfile> <debug level>" |
2327 |
262 RPL_TRACEEND |
2328 |
"<server name> <version & debug level> :End of TRACE" |
2329 |
|
2330 |
- The RPL_TRACE* are all returned by the server in |
2331 |
response to the TRACE message. How many are |
2332 |
returned is dependent on the TRACE message and |
2333 |
whether it was sent by an operator or not. There |
2334 |
is no predefined order for which occurs first. |
2335 |
Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and |
2336 |
RPL_TRACEHANDSHAKE are all used for connections |
2337 |
which have not been fully established and are either |
2338 |
unknown, still attempting to connect or in the |
2339 |
process of completing the 'server handshake'. |
2340 |
RPL_TRACELINK is sent by any server which handles |
2341 |
a TRACE message and has to pass it on to another |
2342 |
server. The list of RPL_TRACELINKs sent in |
2343 |
response to a TRACE command traversing the IRC |
2344 |
network should reflect the actual connectivity of |
2345 |
the servers themselves along that path. |
2346 |
|
2347 |
RPL_TRACENEWTYPE is to be used for any connection |
2348 |
which does not fit in the other categories but is |
2349 |
being displayed anyway. |
2350 |
RPL_TRACEEND is sent to indicate the end of the list. |
2351 |
|
2352 |
211 RPL_STATSLINKINFO |
2353 |
"<linkname> <sendq> <sent messages> |
2354 |
<sent Kbytes> <received messages> |
2355 |
<received Kbytes> <time open>" |
2356 |
|
2357 |
- reports statistics on a connection. <linkname> |
2358 |
identifies the particular connection, <sendq> is |
2359 |
the amount of data that is queued and waiting to be |
2360 |
sent <sent messages> the number of messages sent, |
2361 |
and <sent Kbytes> the amount of data sent, in |
2362 |
Kbytes. <received messages> and <received Kbytes> |
2363 |
are the equivalent of <sent messages> and <sent |
2364 |
Kbytes> for received data, respectively. <time |
2365 |
open> indicates how long ago the connection was |
2366 |
opened, in seconds. |
2367 |
|
2368 |
212 RPL_STATSCOMMANDS |
2369 |
"<command> <count> <byte count> <remote count>" |
2370 |
|
2371 |
- reports statistics on commands usage. |
2372 |
|
2373 |
219 RPL_ENDOFSTATS |
2374 |
"<stats letter> :End of STATS report" |
2375 |
|
2376 |
242 RPL_STATSUPTIME |
2377 |
":Server Up %d days %d:%02d:%02d" |
2378 |
|
2379 |
- reports the server uptime. |
2380 |
|
2381 |
243 RPL_STATSOLINE |
2382 |
"O <hostmask> * <name>" |
2383 |
|
2384 |
- reports the allowed hosts from where user may become IRC |
2385 |
operators. |
2386 |
|
2387 |
221 RPL_UMODEIS |
2388 |
"<user mode string>" |
2389 |
|
2390 |
- To answer a query about a client's own mode, |
2391 |
RPL_UMODEIS is sent back. |
2392 |
|
2393 |
234 RPL_SERVLIST |
2394 |
"<name> <server> <mask> <type> <hopcount> <info>" |
2395 |
|
2396 |
235 RPL_SERVLISTEND |
2397 |
"<mask> <type> :End of service listing" |
2398 |
|
2399 |
- When listing services in reply to a SERVLIST message, |
2400 |
a server is required to send the list back using the |
2401 |
RPL_SERVLIST and RPL_SERVLISTEND messages. A separate |
2402 |
RPL_SERVLIST is sent for each service. After the |
2403 |
services have been listed (or if none present) a |
2404 |
RPL_SERVLISTEND MUST be sent. |
2405 |
|
2406 |
251 RPL_LUSERCLIENT |
2407 |
":There are <integer> users and <integer> |
2408 |
services on <integer> servers" |
2409 |
252 RPL_LUSEROP |
2410 |
"<integer> :operator(s) online" |
2411 |
253 RPL_LUSERUNKNOWN |
2412 |
"<integer> :unknown connection(s)" |
2413 |
254 RPL_LUSERCHANNELS |
2414 |
"<integer> :channels formed" |
2415 |
255 RPL_LUSERME |
2416 |
":I have <integer> clients and <integer> |
2417 |
servers" |
2418 |
|
2419 |
- In processing an LUSERS message, the server |
2420 |
sends a set of replies from RPL_LUSERCLIENT, |
2421 |
RPL_LUSEROP, RPL_USERUNKNOWN, |
2422 |
RPL_LUSERCHANNELS and RPL_LUSERME. When |
2423 |
replying, a server MUST send back |
2424 |
RPL_LUSERCLIENT and RPL_LUSERME. The other |
2425 |
replies are only sent back if a non-zero count |
2426 |
is found for them. |
2427 |
|
2428 |
256 RPL_ADMINME |
2429 |
"<server> :Administrative info" |
2430 |
257 RPL_ADMINLOC1 |
2431 |
":<admin info>" |
2432 |
258 RPL_ADMINLOC2 |
2433 |
":<admin info>" |
2434 |
259 RPL_ADMINEMAIL |
2435 |
":<admin info>" |
2436 |
|
2437 |
- When replying to an ADMIN message, a server |
2438 |
is expected to use replies RPL_ADMINME |
2439 |
through to RPL_ADMINEMAIL and provide a text |
2440 |
message with each. For RPL_ADMINLOC1 a |
2441 |
description of what city, state and country |
2442 |
the server is in is expected, followed by |
2443 |
details of the institution (RPL_ADMINLOC2) |
2444 |
|
2445 |
and finally the administrative contact for the |
2446 |
server (an email address here is REQUIRED) |
2447 |
in RPL_ADMINEMAIL. |
2448 |
|
2449 |
263 RPL_TRYAGAIN |
2450 |
"<command> :Please wait a while and try again." |
2451 |
|
2452 |
- When a server drops a command without processing it, |
2453 |
it MUST use the reply RPL_TRYAGAIN to inform the |
2454 |
originating client. |
2455 |
|
2456 |
5.2 Error Replies |
2457 |
|
2458 |
Error replies are found in the range from 400 to 599. |
2459 |
|
2460 |
401 ERR_NOSUCHNICK |
2461 |
"<nickname> :No such nick/channel" |
2462 |
|
2463 |
- Used to indicate the nickname parameter supplied to a |
2464 |
command is currently unused. |
2465 |
|
2466 |
402 ERR_NOSUCHSERVER |
2467 |
"<server name> :No such server" |
2468 |
|
2469 |
- Used to indicate the server name given currently |
2470 |
does not exist. |
2471 |
|
2472 |
403 ERR_NOSUCHCHANNEL |
2473 |
"<channel name> :No such channel" |
2474 |
|
2475 |
- Used to indicate the given channel name is invalid. |
2476 |
|
2477 |
404 ERR_CANNOTSENDTOCHAN |
2478 |
"<channel name> :Cannot send to channel" |
2479 |
|
2480 |
- Sent to a user who is either (a) not on a channel |
2481 |
which is mode +n or (b) not a chanop (or mode +v) on |
2482 |
a channel which has mode +m set or where the user is |
2483 |
banned and is trying to send a PRIVMSG message to |
2484 |
that channel. |
2485 |
|
2486 |
405 ERR_TOOMANYCHANNELS |
2487 |
"<channel name> :You have joined too many channels" |
2488 |
|
2489 |
- Sent to a user when they have joined the maximum |
2490 |
number of allowed channels and they try to join |
2491 |
another channel. |
2492 |
|
2493 |
406 ERR_WASNOSUCHNICK |
2494 |
"<nickname> :There was no such nickname" |
2495 |
|
2496 |
- Returned by WHOWAS to indicate there is no history |
2497 |
information for that nickname. |
2498 |
|
2499 |
407 ERR_TOOMANYTARGETS |
2500 |
"<target> :<error code> recipients. <abort message>" |
2501 |
|
2502 |
- Returned to a client which is attempting to send a |
2503 |
PRIVMSG/NOTICE using the user@host destination format |
2504 |
and for a user@host which has several occurrences. |
2505 |
|
2506 |
- Returned to a client which trying to send a |
2507 |
PRIVMSG/NOTICE to too many recipients. |
2508 |
|
2509 |
- Returned to a client which is attempting to JOIN a safe |
2510 |
channel using the shortname when there are more than one |
2511 |
such channel. |
2512 |
|
2513 |
408 ERR_NOSUCHSERVICE |
2514 |
"<service name> :No such service" |
2515 |
|
2516 |
- Returned to a client which is attempting to send a SQUERY |
2517 |
to a service which does not exist. |
2518 |
|
2519 |
409 ERR_NOORIGIN |
2520 |
":No origin specified" |
2521 |
|
2522 |
- PING or PONG message missing the originator parameter. |
2523 |
|
2524 |
411 ERR_NORECIPIENT |
2525 |
":No recipient given (<command>)" |
2526 |
412 ERR_NOTEXTTOSEND |
2527 |
":No text to send" |
2528 |
413 ERR_NOTOPLEVEL |
2529 |
"<mask> :No toplevel domain specified" |
2530 |
414 ERR_WILDTOPLEVEL |
2531 |
"<mask> :Wildcard in toplevel domain" |
2532 |
415 ERR_BADMASK |
2533 |
"<mask> :Bad Server/host mask" |
2534 |
|
2535 |
- 412 - 415 are returned by PRIVMSG to indicate that |
2536 |
the message wasn't delivered for some reason. |
2537 |
ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that |
2538 |
are returned when an invalid use of |
2539 |
"PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted. |
2540 |
|
2541 |
421 ERR_UNKNOWNCOMMAND |
2542 |
"<command> :Unknown command" |
2543 |
|
2544 |
- Returned to a registered client to indicate that the |
2545 |
command sent is unknown by the server. |
2546 |
|
2547 |
422 ERR_NOMOTD |
2548 |
":MOTD File is missing" |
2549 |
|
2550 |
- Server's MOTD file could not be opened by the server. |
2551 |
|
2552 |
423 ERR_NOADMININFO |
2553 |
"<server> :No administrative info available" |
2554 |
|
2555 |
- Returned by a server in response to an ADMIN message |
2556 |
when there is an error in finding the appropriate |
2557 |
information. |
2558 |
|
2559 |
424 ERR_FILEERROR |
2560 |
":File error doing <file op> on <file>" |
2561 |
|
2562 |
- Generic error message used to report a failed file |
2563 |
operation during the processing of a message. |
2564 |
|
2565 |
431 ERR_NONICKNAMEGIVEN |
2566 |
":No nickname given" |
2567 |
|
2568 |
- Returned when a nickname parameter expected for a |
2569 |
command and isn't found. |
2570 |
|
2571 |
432 ERR_ERRONEUSNICKNAME |
2572 |
"<nick> :Erroneous nickname" |
2573 |
|
2574 |
- Returned after receiving a NICK message which contains |
2575 |
characters which do not fall in the defined set. See |
2576 |
section 2.3.1 for details on valid nicknames. |
2577 |
|
2578 |
433 ERR_NICKNAMEINUSE |
2579 |
"<nick> :Nickname is already in use" |
2580 |
|
2581 |
- Returned when a NICK message is processed that results |
2582 |
in an attempt to change to a currently existing |
2583 |
nickname. |
2584 |
|
2585 |
436 ERR_NICKCOLLISION |
2586 |
"<nick> :Nickname collision KILL from <user>@<host>" |
2587 |
|
2588 |
- Returned by a server to a client when it detects a |
2589 |
nickname collision (registered of a NICK that |
2590 |
already exists by another server). |
2591 |
|
2592 |
437 ERR_UNAVAILRESOURCE |
2593 |
"<nick/channel> :Nick/channel is temporarily unavailable" |
2594 |
|
2595 |
- Returned by a server to a user trying to join a channel |
2596 |
currently blocked by the channel delay mechanism. |
2597 |
|
2598 |
- Returned by a server to a user trying to change nickname |
2599 |
when the desired nickname is blocked by the nick delay |
2600 |
mechanism. |
2601 |
|
2602 |
441 ERR_USERNOTINCHANNEL |
2603 |
"<nick> <channel> :They aren't on that channel" |
2604 |
|
2605 |
- Returned by the server to indicate that the target |
2606 |
user of the command is not on the given channel. |
2607 |
|
2608 |
442 ERR_NOTONCHANNEL |
2609 |
"<channel> :You're not on that channel" |
2610 |
|
2611 |
- Returned by the server whenever a client tries to |
2612 |
perform a channel affecting command for which the |
2613 |
client isn't a member. |
2614 |
|
2615 |
443 ERR_USERONCHANNEL |
2616 |
"<user> <channel> :is already on channel" |
2617 |
|
2618 |
- Returned when a client tries to invite a user to a |
2619 |
channel they are already on. |
2620 |
|
2621 |
444 ERR_NOLOGIN |
2622 |
"<user> :User not logged in" |
2623 |
|
2624 |
- Returned by the summon after a SUMMON command for a |
2625 |
user was unable to be performed since they were not |
2626 |
logged in. |
2627 |
|
2628 |
445 ERR_SUMMONDISABLED |
2629 |
":SUMMON has been disabled" |
2630 |
|
2631 |
- Returned as a response to the SUMMON command. MUST be |
2632 |
returned by any server which doesn't implement it. |
2633 |
|
2634 |
446 ERR_USERSDISABLED |
2635 |
":USERS has been disabled" |
2636 |
|
2637 |
- Returned as a response to the USERS command. MUST be |
2638 |
returned by any server which does not implement it. |
2639 |
|
2640 |
451 ERR_NOTREGISTERED |
2641 |
":You have not registered" |
2642 |
|
2643 |
- Returned by the server to indicate that the client |
2644 |
MUST be registered before the server will allow it |
2645 |
to be parsed in detail. |
2646 |
|
2647 |
461 ERR_NEEDMOREPARAMS |
2648 |
"<command> :Not enough parameters" |
2649 |
|
2650 |
- Returned by the server by numerous commands to |
2651 |
indicate to the client that it didn't supply enough |
2652 |
parameters. |
2653 |
|
2654 |
462 ERR_ALREADYREGISTRED |
2655 |
":Unauthorized command (already registered)" |
2656 |
|
2657 |
- Returned by the server to any link which tries to |
2658 |
change part of the registered details (such as |
2659 |
password or user details from second USER message). |
2660 |
|
2661 |
463 ERR_NOPERMFORHOST |
2662 |
":Your host isn't among the privileged" |
2663 |
|
2664 |
- Returned to a client which attempts to register with |
2665 |
a server which does not been setup to allow |
2666 |
connections from the host the attempted connection |
2667 |
is tried. |
2668 |
|
2669 |
464 ERR_PASSWDMISMATCH |
2670 |
":Password incorrect" |
2671 |
|
2672 |
- Returned to indicate a failed attempt at registering |
2673 |
a connection for which a password was required and |
2674 |
was either not given or incorrect. |
2675 |
|
2676 |
465 ERR_YOUREBANNEDCREEP |
2677 |
":You are banned from this server" |
2678 |
|
2679 |
- Returned after an attempt to connect and register |
2680 |
yourself with a server which has been setup to |
2681 |
explicitly deny connections to you. |
2682 |
|
2683 |
466 ERR_YOUWILLBEBANNED |
2684 |
|
2685 |
- Sent by a server to a user to inform that access to the |
2686 |
server will soon be denied. |
2687 |
|
2688 |
467 ERR_KEYSET |
2689 |
"<channel> :Channel key already set" |
2690 |
471 ERR_CHANNELISFULL |
2691 |
"<channel> :Cannot join channel (+l)" |
2692 |
472 ERR_UNKNOWNMODE |
2693 |
"<char> :is unknown mode char to me for <channel>" |
2694 |
473 ERR_INVITEONLYCHAN |
2695 |
"<channel> :Cannot join channel (+i)" |
2696 |
474 ERR_BANNEDFROMCHAN |
2697 |
"<channel> :Cannot join channel (+b)" |
2698 |
475 ERR_BADCHANNELKEY |
2699 |
"<channel> :Cannot join channel (+k)" |
2700 |
476 ERR_BADCHANMASK |
2701 |
"<channel> :Bad Channel Mask" |
2702 |
477 ERR_NOCHANMODES |
2703 |
"<channel> :Channel doesn't support modes" |
2704 |
478 ERR_BANLISTFULL |
2705 |
"<channel> <char> :Channel list is full" |
2706 |
|
2707 |
481 ERR_NOPRIVILEGES |
2708 |
":Permission Denied- You're not an IRC operator" |
2709 |
|
2710 |
- Any command requiring operator privileges to operate |
2711 |
MUST return this error to indicate the attempt was |
2712 |
unsuccessful. |
2713 |
|
2714 |
482 ERR_CHANOPRIVSNEEDED |
2715 |
"<channel> :You're not channel operator" |
2716 |
|
2717 |
- Any command requiring 'chanop' privileges (such as |
2718 |
MODE messages) MUST return this error if the client |
2719 |
making the attempt is not a chanop on the specified |
2720 |
channel. |
2721 |
|
2722 |
483 ERR_CANTKILLSERVER |
2723 |
":You can't kill a server!" |
2724 |
|
2725 |
- Any attempts to use the KILL command on a server |
2726 |
are to be refused and this error returned directly |
2727 |
to the client. |
2728 |
|
2729 |
484 ERR_RESTRICTED |
2730 |
":Your connection is restricted!" |
2731 |
|
2732 |
- Sent by the server to a user upon connection to indicate |
2733 |
the restricted nature of the connection (user mode "+r"). |
2734 |
|
2735 |
485 ERR_UNIQOPPRIVSNEEDED |
2736 |
":You're not the original channel operator" |
2737 |
|
2738 |
- Any MODE requiring "channel creator" privileges MUST |
2739 |
return this error if the client making the attempt is not |
2740 |
a chanop on the specified channel. |
2741 |
|
2742 |
491 ERR_NOOPERHOST |
2743 |
":No O-lines for your host" |
2744 |
|
2745 |
- If a client sends an OPER message and the server has |
2746 |
not been configured to allow connections from the |
2747 |
client's host as an operator, this error MUST be |
2748 |
returned. |
2749 |
|
2750 |
501 ERR_UMODEUNKNOWNFLAG |
2751 |
":Unknown MODE flag" |
2752 |
|
2753 |
- Returned by the server to indicate that a MODE |
2754 |
message was sent with a nickname parameter and that |
2755 |
the a mode flag sent was not recognized. |
2756 |
|
2757 |
502 ERR_USERSDONTMATCH |
2758 |
":Cannot change mode for other users" |
2759 |
|
2760 |
- Error sent to any user trying to view or change the |
2761 |
user mode for a user other than themselves. |
2762 |
|
2763 |
5.3 Reserved numerics |
2764 |
|
2765 |
These numerics are not described above since they fall into one of |
2766 |
the following categories: |
2767 |
|
2768 |
1. no longer in use; |
2769 |
|
2770 |
2. reserved for future planned use; |
2771 |
|
2772 |
3. in current use but are part of a non-generic 'feature' of |
2773 |
the current IRC server. |
2774 |
|
2775 |
231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES |
2776 |
233 RPL_SERVICE |
2777 |
300 RPL_NONE 316 RPL_WHOISCHANOP |
2778 |
361 RPL_KILLDONE 362 RPL_CLOSING |
2779 |
363 RPL_CLOSEEND 373 RPL_INFOSTART |
2780 |
384 RPL_MYPORTIS |
2781 |
|
2782 |
213 RPL_STATSCLINE 214 RPL_STATSNLINE |
2783 |
215 RPL_STATSILINE 216 RPL_STATSKLINE |
2784 |
217 RPL_STATSQLINE 218 RPL_STATSYLINE |
2785 |
240 RPL_STATSVLINE 241 RPL_STATSLLINE |
2786 |
244 RPL_STATSHLINE 244 RPL_STATSSLINE |
2787 |
246 RPL_STATSPING 247 RPL_STATSBLINE |
2788 |
250 RPL_STATSDLINE |
2789 |
|
2790 |
492 ERR_NOSERVICEHOST |
2791 |
|
2792 |
6. Current implementations |
2793 |
|
2794 |
The IRC software, version 2.10 is the only complete implementation of |
2795 |
the IRC protocol (client and server). Because of the small amount of |
2796 |
changes in the client protocol since the publication of RFC 1459 |
2797 |
[IRC], implementations that follow it are likely to be compliant with |
2798 |
this protocol or to require a small amount of changes to reach |
2799 |
compliance. |
2800 |
|
2801 |
7. Current problems |
2802 |
|
2803 |
There are a number of recognized problems with the IRC Client |
2804 |
Protocol, and more generally with the IRC Server Protocol. In order |
2805 |
to preserve backward compatibility with old clients, this protocol |
2806 |
has almost not evolved since the publication of RFC 1459 [IRC]. |
2807 |
|
2808 |
7.1 Nicknames |
2809 |
|
2810 |
The idea of the nickname on IRC is very convenient for users to use |
2811 |
when talking to each other outside of a channel, but there is only a |
2812 |
finite nickname space and being what they are, it's not uncommon for |
2813 |
several people to want to use the same nick. If a nickname is chosen |
2814 |
by two people using this protocol, either one will not succeed or |
2815 |
both will removed by use of a server KILL (See Section 3.7.1). |
2816 |
|
2817 |
7.2 Limitation of wildcards |
2818 |
|
2819 |
There is no way to escape the escape character "\" (%x5C). While |
2820 |
this isn't usually a problem, it makes it impossible to form a mask |
2821 |
with a backslash character ("\") preceding a wildcard. |
2822 |
|
2823 |
7.3 Security considerations |
2824 |
|
2825 |
Security issues related to this protocol are discussed in the "IRC |
2826 |
Server Protocol" [IRC-SERVER] as they are mostly an issue for the |
2827 |
server side of the connection. |
2828 |
|
2829 |
8. Current support and availability |
2830 |
|
2831 |
Mailing lists for IRC related discussion: |
2832 |
General discussion: ircd-users@irc.org |
2833 |
Protocol development: ircd-dev@irc.org |
2834 |
|
2835 |
Software implementations: |
2836 |
ftp://ftp.irc.org/irc/server |
2837 |
ftp://ftp.funet.fi/pub/unix/irc |
2838 |
ftp://ftp.irc.org/irc/clients |
2839 |
|
2840 |
Newsgroup: alt.irc |
2841 |
|
2842 |
9. Acknowledgements |
2843 |
|
2844 |
Parts of this document were copied from the RFC 1459 [IRC] which |
2845 |
first formally documented the IRC Protocol. It has also benefited |
2846 |
from many rounds of review and comments. In particular, the |
2847 |
following people have made significant contributions to this |
2848 |
document: |
2849 |
|
2850 |
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa |
2851 |
Ruokonen, Magnus Tjernstrom, Stefan Zehl. |
2852 |
|
2853 |
10. References |
2854 |
|
2855 |
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate |
2856 |
Requirement Levels", BCP 14, RFC 2119, March 1997. |
2857 |
|
2858 |
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax |
2859 |
Specifications: ABNF", RFC 2234, November 1997. |
2860 |
|
2861 |
[HNAME] Braden, R., "Requirements for Internet Hosts -- |
2862 |
Application and Support", STD 3, RFC 1123, October 1989. |
2863 |
|
2864 |
[IRC] Oikarinen, J. & D. Reed, "Internet Relay Chat Protocol", |
2865 |
RFC 1459, May 1993. |
2866 |
|
2867 |
[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, |
2868 |
April 2000. |
2869 |
|
2870 |
[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC |
2871 |
2811, April 2000. |
2872 |
|
2873 |
[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC |
2874 |
2813, April 2000. |
2875 |
|
2876 |
11. Author's Address |
2877 |
|
2878 |
Christophe Kalt |
2879 |
99 Teaneck Rd, Apt #117 |
2880 |
Ridgefield Park, NJ 07660 |
2881 |
USA |
2882 |
|
2883 |
EMail: kalt@stealth.net |
2884 |
|
2885 |
12. Full Copyright Statement |
2886 |
|
2887 |
Copyright (C) The Internet Society (2000). All Rights Reserved. |
2888 |
|
2889 |
This document and translations of it may be copied and furnished to |
2890 |
others, and derivative works that comment on or otherwise explain it |
2891 |
or assist in its implementation may be prepared, copied, published |
2892 |
and distributed, in whole or in part, without restriction of any |
2893 |
kind, provided that the above copyright notice and this paragraph are |
2894 |
included on all such copies and derivative works. However, this |
2895 |
document itself may not be modified in any way, such as by removing |
2896 |
the copyright notice or references to the Internet Society or other |
2897 |
Internet organizations, except as needed for the purpose of |
2898 |
developing Internet standards in which case the procedures for |
2899 |
copyrights defined in the Internet Standards process must be |
2900 |
followed, or as required to translate it into languages other than |
2901 |
English. |
2902 |
|
2903 |
The limited permissions granted above are perpetual and will not be |
2904 |
revoked by the Internet Society or its successors or assigns. |
2905 |
|
2906 |
This document and the information contained herein is provided on an |
2907 |
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING |
2908 |
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING |
2909 |
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION |
2910 |
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF |
2911 |
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
2912 |
|
2913 |
Acknowledgement |
2914 |
|
2915 |
Funding for the RFC Editor function is currently provided by the |
2916 |
Internet Society. |