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