Check-in [84ca00fb7b]
Overview
SHA1:84ca00fb7bafb9c87466e2f8d036995d27180293
Date: 2016-09-13 20:34:14
User: rkeene
Comment:Added tclircd-0.1a.tar.gz (sha1: adbd16a5d187f6e1b3c4c0c663920d6151061626)
Timelines: family | ancestors | descendants | both | trunk
Downloads: Tarball | ZIP archive
Other Links: files | file ages | folders | manifest
Tags And Properties
Context
2016-09-13
20:35
[f0e00464c6] A few changes to tclircd more usable (user: rkeene, tags: trunk)
20:34
[84ca00fb7b] Added tclircd-0.1a.tar.gz (sha1: adbd16a5d187f6e1b3c4c0c663920d6151061626) (user: rkeene, tags: trunk)
20:32
[74f3f8d28a] initial empty check-in (user: rkeene, tags: trunk)
Changes

Added AUTHOR version [088d6c23fe].

            1  +Salvatore Sanfilippo <antirez@invece.org>

Added Changelog version [07d2f80c9e].

            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.

Added LICENSE version [9a77f080a5].

            1  +Copyright (C) 2004 Salvatore Sanfilippo <antirez at invece dot org>
            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.

Added README version [df75cd4695].

            1  +Welcome to the Tcl IRCd!
            2  +
            3  +This is a pure Tcl IRCd, not a full IRC protocol implementation but enough
            4  +to be used as a real IRC server to open some channel to the public.
            5  +
            6  +You can find more information visiting:
            7  +
            8  +    http://www.hping.org/tclircd/
            9  +
           10  +=== HOW TO RUN IT ===
           11  +
           12  +Using Tcl8.4 or greater, type:
           13  +
           14  +  $ tclsh ircd.tcl
           15  +
           16  +The server will run using the port 6667 for default. You can
           17  +modify it editing the ircd.tcl file, the configuration stuff is
           18  +at the end.
           19  +
           20  +You may change the password used to reload the server at runtime
           21  +from the same part of the ircd.tcl file.
           22  +
           23  +If you plan to hack with this program you should now that it's
           24  +possible to reload the server at runtime using the following
           25  +command from the IRC client:
           26  +
           27  +  /quote reload <password>
           28  +
           29  +The <password> can be set from the ircd.tcl file. For default
           30  +it is "betterIfYouChangeThis".
           31  +
           32  +=== WHAT TO LEAR TCL? ===
           33  +
           34  +I'm writing a mostly free book about Tcl. You can find nine chapters
           35  +online at http://www.invece.org/tclwise/. This nine chapters should
           36  +work as an introduction to the language.
           37  +
           38  +Have fun!
           39  +antirez

Added ircd.tcl version [2540825ff6].

            1  +# Minimal IRCd server in Tcl
            2  +# Copyright (C) 2004 Salvatore Sanfilippo <antirez@invece.org>
            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  +}

Added rfc2812.txt version [a4b9b680ec].

            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 <prefix>,
          317  +   <command> and list of parameters (<params>).
          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 <middle> or <trailing>. <trailing> 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 <hostaddr> 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) <hostname> 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  +         <params>.
          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: <password>
          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: <nickname>
          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: <user> <mode> <unused> <realname>
          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 <mode> 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 <realname> 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: <name> <password>
          627  +
          628  +   A normal user uses the OPER command to obtain operator privileges.
          629  +   The combination of <name> and <password> 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: <nickname>
          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: <nickname> <reserved> <distribution> <type>
          719  +               <reserved> <info>
          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 <distribution> 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 <type> 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: [ <Quit Message> ]
          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: <server> <comment>
          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 <comment> 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 <comment> 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: ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] )
          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: <channel> *( "," <channel> ) [ <Part Message> ]
          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: <channel> *( ( "-" / "+" ) *<modes> *<modeparams> )
          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: <channel> [ <topic> ]
         1053  +
         1054  +   The TOPIC command is used to change or view the topic of a channel.
         1055  +   The topic for channel <channel> is returned if there is no <topic>
         1056  +   given.  If the <topic> 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 <topic> 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: [ <channel> *( "," <channel> ) [ <target> ] ]
         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  +   <channel> parameter specifies which channel(s) to return information
         1100  +   about.  There is no error reply for bad channel names.
         1101  +
         1102  +   If no <channel> 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 <target> parameter is specified, the request is forwarded to
         1108  +   that server which will generate the reply.
         1109  +
         1110  +   Wildcards are allowed in the <target> 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: [ <channel> *( "," <channel> ) [ <target> ] ]
         1139  +
         1140  +   The list command is used to list channels and their topics.  If the
         1141  +   <channel> parameter is used, only the status of that channel is
         1142  +   displayed.
         1143  +
         1144  +   If the <target> parameter is specified, the request is forwarded to
         1145  +   that server which will generate the reply.
         1146  +
         1147  +   Wildcards are allowed in the <target> 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: <nickname> <channel>
         1165  +
         1166  +   The INVITE command is used to invite a user to a channel.  The
         1167  +   parameter <nickname> is the nickname of the person to be invited to
         1168  +   the target channel <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: <channel> *( "," <channel> ) <user> *( "," <user> )
         1210  +               [<comment>]
         1211  +
         1212  +   The KICK command can be used to request the forced removal of a user
         1213  +   from a channel.  It causes the <user> to PART from the <channel> 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: <msgtarget> <text to be sent>
         1266  +
         1267  +   PRIVMSG is used to send private messages between users, as well as to
         1268  +   send messages to channels.  <msgtarget> is usually the nickname of
         1269  +   the recipient of the message, or a channel name.
         1270  +
         1271  +   The <msgtarget> parameter may also be a host mask (#<mask>) or server
         1272  +   mask ($<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: <msgtarget> <text>
         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 <target>, 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: [ <target> ]
         1380  +
         1381  +   The MOTD command is used to get the "Message Of The Day" of the given
         1382  +   server, or current server if <target> is omitted.
         1383  +
         1384  +   Wildcards are allowed in the <target> 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: [ <mask> [ <target> ] ]
         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 <mask> 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 <target> parameter is specified, the request
         1409  +   is forwarded to that server which will generate the reply.
         1410  +
         1411  +   Wildcards are allowed in the <target> 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: [ <target> ]
         1423  +
         1424  +   The VERSION command is used to query the version of the server
         1425  +   program.  An optional parameter <target> 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 <target> 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: [ <query> [ <target> ] ]
         1443  +
         1444  +   The stats command is used to query statistics of certain server.  If
         1445  +   <query> 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 <target> 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: [ [ <remote server> ] <server mask> ]
         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 <remote server> is given in addition to <server mask>, 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: [ <target> ]
         1532  +
         1533  +   The time command is used to query local time from the specified
         1534  +   server. If the <target> parameter is not given, the server receiving
         1535  +   the command must reply to the query.
         1536  +
         1537  +   Wildcards are allowed in the <target> 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: <target server> <port> [ <remote server> ]
         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 <remote server> 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: [ <target> ]
         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 <target> 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 <target> 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 <target> 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 <target> is a nickname, then only a
         1606  +   reply for that nickname is given.  If the <target> 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 <target> 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: [ <target> ]
         1650  +
         1651  +   The admin command is used to find information about the administrator
         1652  +   of the given server, or current server if <target> 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 <target> 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: [ <target> ]
         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 <target> 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: [ <mask> [ <type> ] ]
         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: <servicename> <text>
         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: [ <mask> [ "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 <mask> parameter given by
         1783  +   the client.  In the absence of the <mask> 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 <mask> of "0" or any wildcard which
         1787  +   will end up matching every visible user.
         1788  +
         1789  +   The <mask> passed to WHO is matched against users' host, server, real
         1790  +   name and nickname if the channel <mask> 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 <mask> 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: [ <target> ] <mask> *( "," <mask> )
         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  +   <mask>, any information about that nick which you are allowed to see
         1826  +   is presented.
         1827  +
         1828  +   If the <target> 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 <target> 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: <nickname> *( "," <nickname> ) [ <count> [ <target> ] ]
         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  +   <count> replies will be returned (or all of them if no <count>
         1875  +   parameter is given).  If a non-positive number is passed as being
         1876  +   <count>, then a full search is done.
         1877  +
         1878  +   Wildcards are allowed in the <target> 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: <nickname> <comment>
         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: <server1> [ <server2> ]
         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 <server1> (server which sent the PING message out)
         1988  +   as soon as possible.  If the <server2> 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: <server> [ <server2> ]
         2027  +
         2028  +   PONG message is a reply to ping message.  If parameter <server2> is
         2029  +   given, this message MUST be forwarded to given target.  The <server>
         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: <error message>
         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: [ <text> ]
         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: <user> [ <target> [ <channel> ] ]
         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 <server> parameter is given it tries to summon <user> 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: [ <target> ]
         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: <Text to be sent>
         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: <nickname> *( SPACE <nickname> )
         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: <nickname> *( SPACE <nickname> )
         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  +               <nick>!<user>@<host>"
         2396  +       002    RPL_YOURHOST
         2397  +              "Your host is <servername>, running version <ver>"
         2398  +       003    RPL_CREATED
         2399  +              "This server was created <date>"
         2400  +       004    RPL_MYINFO
         2401  +              "<servername> <version> <available user modes>
         2402  +               <available channel modes>"
         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 <server name>, port <port number>"
         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<reply> *( " " <reply> )"
         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<nick> *( " " <nick> )"
         2438  +
         2439  +         - Reply format used by ISON to list replies to the
         2440  +           query list.
         2441  +
         2442  +       301    RPL_AWAY
         2443  +              "<nick> :<away message>"
         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  +              "<nick> <user> <host> * :<real name>"
         2458  +       312    RPL_WHOISSERVER
         2459  +              "<nick> <server> :<server info>"
         2460  +       313    RPL_WHOISOPERATOR
         2461  +              "<nick> :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  +              "<nick> <integer> :seconds idle"
         2473  +       318    RPL_ENDOFWHOIS
         2474  +              "<nick> :End of WHOIS list"
         2475  +       319    RPL_WHOISCHANNELS
         2476  +              "<nick> :*( ( "@" / "+" ) <channel> " " )"
         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  +              "<nick> <user> <host> * :<real name>"
         2495  +       369    RPL_ENDOFWHOWAS
         2496  +              "<nick> :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  +              "<channel> <# visible> :<topic>"
         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  +              "<channel> <nickname>"
         2529  +
         2530  +       324    RPL_CHANNELMODEIS
         2531  +              "<channel> <mode> <mode params>"
         2532  +
         2533  +       331    RPL_NOTOPIC
         2534  +              "<channel> :No topic is set"
         2535  +       332    RPL_TOPIC
         2536  +              "<channel> :<topic>"
         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  +              "<channel> <nick>"
         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  +              "<user> :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  +              "<channel> <invitemask>"
         2558  +       347    RPL_ENDOFINVITELIST
         2559  +              "<channel> :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  +              "<channel> <exceptionmask>"
         2570  +       349    RPL_ENDOFEXCEPTLIST
         2571  +              "<channel> :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  +              "<version>.<debuglevel> <server> :<comments>"
         2592  +
         2593  +         - Reply by the server showing its version details.
         2594  +           The <version> is the version of the software being
         2595  +           used (including any patchlevel revisions) and the
         2596  +           <debuglevel> 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  +              "<channel> <user> <host> <server> <nick>
         2604  +              ( "H" / "G" > ["*"] [ ( "@" / "+" ) ]
         2605  +              :<hopcount> <real name>"
         2606  +
         2607  +       315    RPL_ENDOFWHO
         2608  +              "<name> :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 <name> being
         2616  +           the item.
         2617  +
         2618  +       353    RPL_NAMREPLY
         2619  +              "( "=" / "*" / "@" ) <channel>
         2620  +               :[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )
         2621  +         - "@" is used for secret channels, "*" for private
         2622  +           channels, and "=" for others (public channels).
         2623  +
         2624  +       366    RPL_ENDOFNAMES
         2625  +              "<channel> :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  +              "<mask> <server> :<hopcount> <server info>"
         2647  +       365    RPL_ENDOFLINKS
         2648  +              "<mask> :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  +              "<channel> <banmask>"
         2656  +       368    RPL_ENDOFBANLIST
         2657  +              "<channel> :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  +              ":<string>"
         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  +              ":- <server> Message of the day - "
         2678  +       372    RPL_MOTD
         2679  +              ":- <text>"
         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  +              "<config file> :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 <servicename>"
         2715  +
         2716  +         - Sent by the server to a service upon successful
         2717  +           registration.
         2718  +
         2719  +       391    RPL_TIME
         2720  +              "<server> :<string showing server's local time>"
         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  +              ":<username> <ttyline> <hostname>"
         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 <version & debug level> <destination>
         2753  +               <next server> V<protocol version>
         2754  +               <link uptime in seconds> <backstream sendq>
         2755  +               <upstream sendq>"
         2756  +       201    RPL_TRACECONNECTING
         2757  +              "Try. <class> <server>"
         2758  +       202    RPL_TRACEHANDSHAKE
         2759  +              "H.S. <class> <server>"
         2760  +       203    RPL_TRACEUNKNOWN
         2761  +              "???? <class> [<client IP address in dot form>]"
         2762  +       204    RPL_TRACEOPERATOR
         2763  +              "Oper <class> <nick>"
         2764  +       205    RPL_TRACEUSER
         2765  +              "User <class> <nick>"
         2766  +       206    RPL_TRACESERVER
         2767  +              "Serv <class> <int>S <int>C <server>
         2768  +               <nick!user|*!*>@<host|server> V<protocol version>"
         2769  +       207    RPL_TRACESERVICE
         2770  +              "Service <class> <name> <type> <active type>"
         2771  +       208    RPL_TRACENEWTYPE
         2772  +              "<newtype> 0 <client name>"
         2773  +       209    RPL_TRACECLASS
         2774  +              "Class <class> <count>"
         2775  +       210    RPL_TRACERECONNECT
         2776  +              Unused.
         2777  +       261    RPL_TRACELOG
         2778  +              "File <logfile> <debug level>"
         2779  +       262    RPL_TRACEEND
         2780  +              "<server name> <version & debug level> :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  +              "<linkname> <sendq> <sent messages>
         2814  +               <sent Kbytes> <received messages>
         2815  +               <received Kbytes> <time open>"
         2816  +
         2817  +         - reports statistics on a connection.  <linkname>
         2818  +           identifies the particular connection, <sendq> is
         2819  +           the amount of data that is queued and waiting to be
         2820  +           sent <sent messages> the number of messages sent,
         2821  +           and <sent Kbytes> the amount of data sent, in
         2822  +           Kbytes. <received messages> and <received Kbytes>
         2823  +           are the equivalent of <sent messages> and <sent
         2824  +           Kbytes> for received data, respectively.  <time
         2825  +           open> indicates how long ago the connection was
         2826  +           opened, in seconds.
         2827  +
         2828  +       212    RPL_STATSCOMMANDS
         2829  +              "<command> <count> <byte count> <remote count>"
         2830  +
         2831  +         - reports statistics on commands usage.
         2832  +
         2833  +       219    RPL_ENDOFSTATS
         2834  +              "<stats letter> :End of STATS report"
         2835  +
         2836  +       242    RPL_STATSUPTIME
         2837  +              ":Server Up %d days %d:%02d:%02d"
         2838  +
         2839  +         - reports the server uptime.
         2840  +
         2841  +       243    RPL_STATSOLINE
         2842  +              "O <hostmask> * <name>"
         2843  +
         2844  +         - reports the allowed hosts from where user may become IRC
         2845  +           operators.
         2846  +
         2847  +       221    RPL_UMODEIS
         2848  +              "<user mode string>"
         2849  +
         2850  +         - To answer a query about a client's own mode,
         2851  +           RPL_UMODEIS is sent back.
         2852  +
         2853  +       234    RPL_SERVLIST
         2854  +              "<name> <server> <mask> <type> <hopcount> <info>"
         2855  +
         2856  +
         2857  +
         2858  +Kalt                         Informational                     [Page 51]
         2859  +
         2860  +RFC 2812          Internet Relay Chat: Client Protocol        April 2000
         2861  +
         2862  +
         2863  +       235    RPL_SERVLISTEND
         2864  +              "<mask> <type> :End of service listing"
         2865  +
         2866  +         - When listing services in reply to a SERVLIST message,
         2867  +           a server is required to send the list back using the
         2868  +           RPL_SERVLIST and RPL_SERVLISTEND messages.  A separate
         2869  +           RPL_SERVLIST is sent for each service.  After the
         2870  +           services have been listed (or if none present) a
         2871  +           RPL_SERVLISTEND MUST be sent.
         2872  +
         2873  +       251    RPL_LUSERCLIENT
         2874  +              ":There are <integer> users and <integer>
         2875  +               services on <integer> servers"
         2876  +       252    RPL_LUSEROP
         2877  +              "<integer> :operator(s) online"
         2878  +       253    RPL_LUSERUNKNOWN
         2879  +              "<integer> :unknown connection(s)"
         2880  +       254    RPL_LUSERCHANNELS
         2881  +              "<integer> :channels formed"
         2882  +       255    RPL_LUSERME
         2883  +              ":I have <integer> clients and <integer>
         2884  +                servers"
         2885  +
         2886  +         - In processing an LUSERS message, the server
         2887  +           sends a set of replies from RPL_LUSERCLIENT,
         2888  +           RPL_LUSEROP, RPL_USERUNKNOWN,
         2889  +           RPL_LUSERCHANNELS and RPL_LUSERME.  When
         2890  +           replying, a server MUST send back
         2891  +           RPL_LUSERCLIENT and RPL_LUSERME.  The other
         2892  +           replies are only sent back if a non-zero count
         2893  +           is found for them.
         2894  +
         2895  +       256    RPL_ADMINME
         2896  +              "<server> :Administrative info"
         2897  +       257    RPL_ADMINLOC1
         2898  +              ":<admin info>"
         2899  +       258    RPL_ADMINLOC2
         2900  +              ":<admin info>"
         2901  +       259    RPL_ADMINEMAIL
         2902  +              ":<admin info>"
         2903  +
         2904  +         - When replying to an ADMIN message, a server
         2905  +           is expected to use replies RPL_ADMINME
         2906  +           through to RPL_ADMINEMAIL and provide a text
         2907  +           message with each.  For RPL_ADMINLOC1 a
         2908  +           description of what city, state and country
         2909  +           the server is in is expected, followed by
         2910  +           details of the institution (RPL_ADMINLOC2)
         2911  +
         2912  +
         2913  +
         2914  +Kalt                         Informational                     [Page 52]
         2915  +
         2916  +RFC 2812          Internet Relay Chat: Client Protocol        April 2000
         2917  +
         2918  +
         2919  +           and finally the administrative contact for the
         2920  +           server (an email address here is REQUIRED)
         2921  +           in RPL_ADMINEMAIL.
         2922  +
         2923  +       263    RPL_TRYAGAIN
         2924  +              "<command> :Please wait a while and try again."
         2925  +
         2926  +         - When a server drops a command without processing it,
         2927  +           it MUST use the reply RPL_TRYAGAIN to inform the
         2928  +           originating client.
         2929  +
         2930  +5.2 Error Replies
         2931  +
         2932  +       Error replies are found in the range from 400 to 599.
         2933  +
         2934  +       401    ERR_NOSUCHNICK
         2935  +              "<nickname> :No such nick/channel"
         2936  +
         2937  +          - Used to indicate the nickname parameter supplied to a
         2938  +            command is currently unused.
         2939  +
         2940  +       402    ERR_NOSUCHSERVER
         2941  +              "<server name> :No such server"
         2942  +
         2943  +         - Used to indicate the server name given currently
         2944  +           does not exist.
         2945  +
         2946  +       403    ERR_NOSUCHCHANNEL
         2947  +              "<channel name> :No such channel"
         2948  +
         2949  +         - Used to indicate the given channel name is invalid.
         2950  +
         2951  +       404    ERR_CANNOTSENDTOCHAN
         2952  +              "<channel name> :Cannot send to channel"
         2953  +
         2954  +         - Sent to a user who is either (a) not on a channel
         2955  +           which is mode +n or (b) not a chanop (or mode +v) on
         2956  +           a channel which has mode +m set or where the user is
         2957  +           banned and is trying to send a PRIVMSG message to
         2958  +           that channel.
         2959  +
         2960  +       405    ERR_TOOMANYCHANNELS
         2961  +              "<channel name> :You have joined too many channels"
         2962  +
         2963  +         - Sent to a user when they have joined the maximum
         2964  +           number of allowed channels and they try to join
         2965  +           another channel.
         2966  +
         2967  +
         2968  +
         2969  +
         2970  +Kalt                         Informational                     [Page 53]
         2971  +
         2972  +RFC 2812          Internet Relay Chat: Client Protocol        April 2000
         2973  +
         2974  +
         2975  +       406    ERR_WASNOSUCHNICK
         2976  +              "<nickname> :There was no such nickname"
         2977  +
         2978  +         - Returned by WHOWAS to indicate there is no history
         2979  +           information for that nickname.
         2980  +
         2981  +       407    ERR_TOOMANYTARGETS
         2982  +              "<target> :<error code> recipients. <abort message>"
         2983  +
         2984  +         - Returned to a client which is attempting to send a
         2985  +           PRIVMSG/NOTICE using the user@host destination format
         2986  +           and for a user@host which has several occurrences.
         2987  +
         2988  +         - Returned to a client which trying to send a
         2989  +           PRIVMSG/NOTICE to too many recipients.
         2990  +
         2991  +         - Returned to a client which is attempting to JOIN a safe
         2992  +           channel using the shortname when there are more than one
         2993  +           such channel.
         2994  +
         2995  +       408    ERR_NOSUCHSERVICE
         2996  +              "<service name> :No such service"
         2997  +
         2998  +         - Returned to a client which is attempting to send a SQUERY
         2999  +           to a service which does not exist.
         3000  +
         3001  +       409    ERR_NOORIGIN
         3002  +              ":No origin specified"
         3003  +
         3004  +         - PING or PONG message missing the originator parameter.
         3005  +
         3006  +       411    ERR_NORECIPIENT
         3007  +              ":No recipient given (<command>)"
         3008  +       412    ERR_NOTEXTTOSEND
         3009  +              ":No text to send"
         3010  +       413    ERR_NOTOPLEVEL
         3011  +              "<mask> :No toplevel domain specified"
         3012  +       414    ERR_WILDTOPLEVEL
         3013  +              "<mask> :Wildcard in toplevel domain"
         3014  +       415    ERR_BADMASK
         3015  +              "<mask> :Bad Server/host mask"
         3016  +
         3017  +         - 412 - 415 are returned by PRIVMSG to indicate that
         3018  +           the message wasn't delivered for some reason.
         3019  +           ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
         3020  +           are returned when an invalid use of
         3021  +           "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
         3022  +
         3023  +
         3024  +
         3025  +
         3026  +Kalt                         Informational                     [Page 54]
         3027  +
         3028  +RFC 2812          Internet Relay Chat: Client Protocol        April 2000
         3029  +
         3030  +
         3031  +       421    ERR_UNKNOWNCOMMAND
         3032  +              "<command> :Unknown command"
         3033  +
         3034  +         - Returned to a registered client to indicate that the
         3035  +           command sent is unknown by the server.
         3036  +
         3037  +       422    ERR_NOMOTD
         3038  +              ":MOTD File is missing"
         3039  +
         3040  +         - Server's MOTD file could not be opened by the server.
         3041  +
         3042  +       423    ERR_NOADMININFO
         3043  +              "<server> :No administrative info available"
         3044  +
         3045  +         - Returned by a server in response to an ADMIN message
         3046  +           when there is an error in finding the appropriate
         3047  +           information.
         3048  +
         3049  +       424    ERR_FILEERROR
         3050  +              ":File error doing <file op> on <file>"
         3051  +
         3052  +         - Generic error message used to report a failed file
         3053  +           operation during the processing of a message.
         3054  +
         3055  +       431    ERR_NONICKNAMEGIVEN
         3056  +              ":No nickname given"
         3057  +
         3058  +         - Returned when a nickname parameter expected for a
         3059  +           command and isn't found.
         3060  +
         3061  +       432    ERR_ERRONEUSNICKNAME
         3062  +              "<nick> :Erroneous nickname"
         3063  +
         3064  +         - Returned after receiving a NICK message which contains
         3065  +           characters which do not fall in the defined set.  See
         3066  +           section 2.3.1 for details on valid nicknames.
         3067  +
         3068  +       433    ERR_NICKNAMEINUSE
         3069  +              "<nick> :Nickname is already in use"
         3070  +
         3071  +         - Returned when a NICK message is processed that results
         3072  +           in an attempt to change to a currently existing
         3073  +           nickname.
         3074  +
         3075  +
         3076  +
         3077  +
         3078  +
         3079  +
         3080  +
         3081  +
         3082  +Kalt                         Informational                     [Page 55]
         3083  +
         3084  +RFC 2812          Internet Relay Chat: Client Protocol        April 2000
         3085  +
         3086  +
         3087  +       436    ERR_NICKCOLLISION
         3088  +              "<nick> :Nickname collision KILL from <user>@<host>"
         3089  +
         3090  +         - Returned by a server to a client when it detects a
         3091  +           nickname collision (registered of a NICK that
         3092  +           already exists by another server).
         3093  +
         3094  +       437    ERR_UNAVAILRESOURCE
         3095  +              "<nick/channel> :Nick/channel is temporarily unavailable"
         3096  +
         3097  +         - Returned by a server to a user trying to join a channel
         3098  +           currently blocked by the channel delay mechanism.
         3099  +
         3100  +         - Returned by a server to a user trying to change nickname
         3101  +           when the desired nickname is blocked by the nick delay
         3102  +           mechanism.
         3103  +
         3104  +       441    ERR_USERNOTINCHANNEL
         3105  +              "<nick> <channel> :They aren't on that channel"
         3106  +
         3107  +         - Returned by the server to indicate that the target
         3108  +           user of the command is not on the given channel.
         3109  +
         3110  +       442    ERR_NOTONCHANNEL
         3111  +              "<channel> :You're not on that channel"
         3112  +
         3113  +         - Returned by the server whenever a client tries to
         3114  +           perform a channel affecting command for which the
         3115  +           client isn't a member.
         3116  +
         3117  +       443    ERR_USERONCHANNEL
         3118  +              "<user> <channel> :is already on channel"
         3119  +
         3120  +         - Returned when a client tries to invite a user to a
         3121  +           channel they are already on.
         3122  +
         3123  +       444    ERR_NOLOGIN
         3124  +              "<user> :User not logged in"
         3125  +
         3126  +         - Returned by the summon after a SUMMON command for a
         3127  +           user was unable to be performed since they were not
         3128  +           logged in.
         3129  +
         3130  +
         3131  +
         3132  +
         3133  +
         3134  +
         3135  +
         3136  +
         3137  +
         3138  +Kalt                         Informational                     [Page 56]
         3139  +
         3140  +RFC 2812          Internet Relay Chat: Client Protocol        April 2000
         3141  +
         3142  +
         3143  +       445    ERR_SUMMONDISABLED
         3144  +              ":SUMMON has been disabled"
         3145  +
         3146  +         - Returned as a response to the SUMMON command.  MUST be
         3147  +           returned by any server which doesn't implement it.
         3148  +
         3149  +       446    ERR_USERSDISABLED
         3150  +              ":USERS has been disabled"
         3151  +
         3152  +         - Returned as a response to the USERS command.  MUST be
         3153  +           returned by any server which does not implement it.
         3154  +
         3155  +       451    ERR_NOTREGISTERED
         3156  +              ":You have not registered"
         3157  +
         3158  +         - Returned by the server to indicate that the client
         3159  +           MUST be registered before the server will allow it
         3160  +           to be parsed in detail.
         3161  +
         3162  +       461    ERR_NEEDMOREPARAMS
         3163  +              "<command> :Not enough parameters"
         3164  +
         3165  +         - Returned by the server by numerous commands to
         3166  +           indicate to the client that it didn't supply enough
         3167  +           parameters.
         3168  +
         3169  +       462    ERR_ALREADYREGISTRED
         3170  +              ":Unauthorized command (already registered)"
         3171  +
         3172  +         - Returned by the server to any link which tries to
         3173  +           change part of the registered details (such as
         3174  +           password or user details from second USER message).
         3175  +
         3176  +       463    ERR_NOPERMFORHOST
         3177  +              ":Your host isn't among the privileged"
         3178  +
         3179  +         - Returned to a client which attempts to register with
         3180  +           a server which does not been setup to allow
         3181  +           connections from the host the attempted connection
         3182  +           is tried.
         3183  +
         3184  +       464    ERR_PASSWDMISMATCH
         3185  +              ":Password incorrect"
         3186  +
         3187  +         - Returned to indicate a failed attempt at registering
         3188  +           a connection for which a password was required and
         3189  +           was either not given or incorrect.
         3190  +
         3191  +
         3192  +
         3193  +
         3194  +Kalt                         Informational                     [Page 57]
         3195  +
         3196  +RFC 2812          Internet Relay Chat: Client Protocol        April 2000
         3197  +
         3198  +
         3199  +       465    ERR_YOUREBANNEDCREEP
         3200  +              ":You are banned from this server"
         3201  +
         3202  +         - Returned after an attempt to connect and register
         3203  +           yourself with a server which has been setup to
         3204  +           explicitly deny connections to you.
         3205  +
         3206  +       466    ERR_YOUWILLBEBANNED
         3207  +
         3208  +         - Sent by a server to a user to inform that access to the
         3209  +           server will soon be denied.
         3210  +
         3211  +       467    ERR_KEYSET
         3212  +              "<channel> :Channel key already set"
         3213  +       471    ERR_CHANNELISFULL
         3214  +              "<channel> :Cannot join channel (+l)"
         3215  +       472    ERR_UNKNOWNMODE
         3216  +              "<char> :is unknown mode char to me for <channel>"
         3217  +       473    ERR_INVITEONLYCHAN
         3218  +              "<channel> :Cannot join channel (+i)"
         3219  +       474    ERR_BANNEDFROMCHAN
         3220  +              "<channel> :Cannot join channel (+b)"
         3221  +       475    ERR_BADCHANNELKEY
         3222  +              "<channel> :Cannot join channel (+k)"
         3223  +       476    ERR_BADCHANMASK
         3224  +              "<channel> :Bad Channel Mask"
         3225  +       477    ERR_NOCHANMODES
         3226  +              "<channel> :Channel doesn't support modes"
         3227  +       478    ERR_BANLISTFULL
         3228  +              "<channel> <char> :Channel list is full"
         3229  +
         3230  +       481    ERR_NOPRIVILEGES
         3231  +              ":Permission Denied- You're not an IRC operator"
         3232  +
         3233  +         - Any command requiring operator privileges to operate
         3234  +           MUST return this error to indicate the attempt was
         3235  +           unsuccessful.
         3236  +
         3237  +       482    ERR_CHANOPRIVSNEEDED
         3238  +              "<channel> :You're not channel operator"
         3239  +
         3240  +         - Any command requiring 'chanop' privileges (such as
         3241  +           MODE messages) MUST return this error if the client
         3242  +           making the attempt is not a chanop on the specified
         3243  +           channel.
         3244  +
         3245  +
         3246  +
         3247  +
         3248  +
         3249  +
         3250  +Kalt                         Informational                     [Page 58]
         3251  +
         3252  +RFC 2812          Internet Relay Chat: Client Protocol        April 2000
         3253  +
         3254  +
         3255  +       483    ERR_CANTKILLSERVER
         3256  +              ":You can't kill a server!"
         3257  +
         3258  +         - Any attempts to use the KILL command on a server
         3259  +           are to be refused and this error returned directly
         3260  +           to the client.
         3261  +
         3262  +       484    ERR_RESTRICTED
         3263  +              ":Your connection is restricted!"
         3264  +
         3265  +         - Sent by the server to a user upon connection to indicate
         3266  +           the restricted nature of the connection (user mode "+r").
         3267  +
         3268  +       485    ERR_UNIQOPPRIVSNEEDED
         3269  +              ":You're not the original channel operator"
         3270  +
         3271  +         - Any MODE requiring "channel creator" privileges MUST
         3272  +           return this error if the client making the attempt is not
         3273  +           a chanop on the specified channel.
         3274  +
         3275  +       491    ERR_NOOPERHOST
         3276  +              ":No O-lines for your host"
         3277  +
         3278  +         - If a client sends an OPER message and the server has
         3279  +           not been configured to allow connections from the
         3280  +           client's host as an operator, this error MUST be
         3281  +           returned.
         3282  +
         3283  +       501    ERR_UMODEUNKNOWNFLAG
         3284  +              ":Unknown MODE flag"
         3285  +
         3286  +         - Returned by the server to indicate that a MODE
         3287  +           message was sent with a nickname parameter and that
         3288  +           the a mode flag sent was not recognized.
         3289  +
         3290  +       502    ERR_USERSDONTMATCH
         3291  +              ":Cannot change mode for other users"
         3292  +
         3293  +         - Error sent to any user trying to view or change the
         3294  +           user mode for a user other than themselves.
         3295  +
         3296  +5.3 Reserved numerics
         3297  +
         3298  +   These numerics are not described above since they fall into one of
         3299  +   the following categories:
         3300  +
         3301  +   1. no longer in use;
         3302  +
         3303  +
         3304  +
         3305  +
         3306  +Kalt                         Informational                     [Page 59]
         3307  +
         3308  +RFC 2812          Internet Relay Chat: Client Protocol        April 2000
         3309  +
         3310  +
         3311  +   2. reserved for future planned use;
         3312  +
         3313  +   3. in current use but are part of a non-generic 'feature' of
         3314  +      the current IRC server.
         3315  +
         3316  +            231    RPL_SERVICEINFO     232  RPL_ENDOFSERVICES
         3317  +            233    RPL_SERVICE
         3318  +            300    RPL_NONE            316  RPL_WHOISCHANOP
         3319  +            361    RPL_KILLDONE        362  RPL_CLOSING
         3320  +            363    RPL_CLOSEEND        373  RPL_INFOSTART
         3321  +            384    RPL_MYPORTIS
         3322  +
         3323  +            213    RPL_STATSCLINE      214  RPL_STATSNLINE
         3324  +            215    RPL_STATSILINE      216  RPL_STATSKLINE
         3325  +            217    RPL_STATSQLINE      218  RPL_STATSYLINE
         3326  +            240    RPL_STATSVLINE      241  RPL_STATSLLINE
         3327  +            244    RPL_STATSHLINE      244  RPL_STATSSLINE
         3328  +            246    RPL_STATSPING       247  RPL_STATSBLINE
         3329  +            250    RPL_STATSDLINE
         3330  +
         3331  +            492    ERR_NOSERVICEHOST
         3332  +
         3333  +6. Current implementations
         3334  +
         3335  +   The IRC software, version 2.10 is the only complete implementation of
         3336  +   the IRC protocol (client and server).  Because of the small amount of
         3337  +   changes in the client protocol since the publication of RFC 1459
         3338  +   [IRC], implementations that follow it are likely to be compliant with
         3339  +   this protocol or to require a small amount of changes to reach
         3340  +   compliance.
         3341  +
         3342  +7. Current problems
         3343  +
         3344  +   There are a number of recognized problems with the IRC Client
         3345  +   Protocol, and more generally with the IRC Server Protocol.  In order
         3346  +   to preserve backward compatibility with old clients, this protocol
         3347  +   has almost not evolved since the publication of RFC 1459 [IRC].
         3348  +
         3349  +7.1 Nicknames
         3350  +
         3351  +   The idea of the nickname on IRC is very convenient for users to use
         3352  +   when talking to each other outside of a channel, but there is only a
         3353  +   finite nickname space and being what they are, it's not uncommon for
         3354  +   several people to want to use the same nick.  If a nickname is chosen
         3355  +   by two people using this protocol, either one will not succeed or
         3356  +   both will removed by use of a server KILL (See Section 3.7.1).
         3357  +
         3358  +
         3359  +
         3360  +
         3361  +
         3362  +Kalt                         Informational                     [Page 60]
         3363  +
         3364  +RFC 2812          Internet Relay Chat: Client Protocol        April 2000
         3365  +
         3366  +
         3367  +7.2 Limitation of wildcards
         3368  +
         3369  +   There is no way to escape the escape character "\" (%x5C).  While
         3370  +   this isn't usually a problem, it makes it impossible to form a mask
         3371  +   with a backslash character ("\") preceding a wildcard.
         3372  +
         3373  +7.3 Security considerations
         3374  +
         3375  +   Security issues related to this protocol are discussed in the "IRC
         3376  +   Server Protocol" [IRC-SERVER] as they are mostly an issue for the
         3377  +   server side of the connection.
         3378  +
         3379  +8. Current support and availability
         3380  +
         3381  +        Mailing lists for IRC related discussion:
         3382  +          General discussion: ircd-users@irc.org
         3383  +          Protocol development: ircd-dev@irc.org
         3384  +
         3385  +        Software implementations:
         3386  +          ftp://ftp.irc.org/irc/server
         3387  +          ftp://ftp.funet.fi/pub/unix/irc
         3388  +          ftp://ftp.irc.org/irc/clients
         3389  +
         3390  +        Newsgroup: alt.irc
         3391  +
         3392  +9. Acknowledgements
         3393  +
         3394  +   Parts of this document were copied from the RFC 1459 [IRC] which
         3395  +   first formally documented the IRC Protocol.  It has also benefited
         3396  +   from many rounds of review and comments.  In particular, the
         3397  +   following people have made significant contributions to this
         3398  +   document:
         3399  +
         3400  +   Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
         3401  +   Ruokonen, Magnus Tjernstrom, Stefan Zehl.
         3402  +
         3403  +
         3404  +
         3405  +
         3406  +
         3407  +
         3408  +
         3409  +
         3410  +
         3411  +
         3412  +
         3413  +
         3414  +
         3415  +
         3416  +
         3417  +
         3418  +Kalt                         Informational                     [Page 61]
         3419  +
         3420  +RFC 2812          Internet Relay Chat: Client Protocol        April 2000
         3421  +
         3422  +
         3423  +10. References
         3424  +
         3425  +   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
         3426  +                Requirement Levels", BCP 14, RFC 2119, March 1997.
         3427  +
         3428  +   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
         3429  +                Specifications: ABNF", RFC 2234, November 1997.
         3430  +
         3431  +   [HNAME]      Braden, R., "Requirements for Internet Hosts --
         3432  +                Application and Support", STD 3, RFC 1123, October 1989.
         3433  +
         3434  +   [IRC]        Oikarinen, J. & D. Reed, "Internet Relay Chat Protocol",
         3435  +                RFC 1459, May 1993.
         3436  +
         3437  +   [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
         3438  +                April 2000.
         3439  +
         3440  +   [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
         3441  +                2811, April 2000.
         3442  +
         3443  +   [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
         3444  +                2813, April 2000.
         3445  +
         3446  +11. Author's Address
         3447  +
         3448  +   Christophe Kalt
         3449  +   99 Teaneck Rd, Apt #117
         3450  +   Ridgefield Park, NJ 07660
         3451  +   USA
         3452  +
         3453  +   EMail: kalt@stealth.net
         3454  +
         3455  +
         3456  +
         3457  +
         3458  +
         3459  +
         3460  +
         3461  +
         3462  +
         3463  +
         3464  +
         3465  +
         3466  +
         3467  +
         3468  +
         3469  +
         3470  +
         3471  +
         3472  +
         3473  +
         3474  +Kalt                         Informational                     [Page 62]
         3475  +
         3476  +RFC 2812          Internet Relay Chat: Client Protocol        April 2000
         3477  +
         3478  +
         3479  +12.  Full Copyright Statement
         3480  +
         3481  +   Copyright (C) The Internet Society (2000).  All Rights Reserved.
         3482  +
         3483  +   This document and translations of it may be copied and furnished to
         3484  +   others, and derivative works that comment on or otherwise explain it
         3485  +   or assist in its implementation may be prepared, copied, published
         3486  +   and distributed, in whole or in part, without restriction of any
         3487  +   kind, provided that the above copyright notice and this paragraph are
         3488  +   included on all such copies and derivative works.  However, this
         3489  +   document itself may not be modified in any way, such as by removing
         3490  +   the copyright notice or references to the Internet Society or other
         3491  +   Internet organizations, except as needed for the purpose of
         3492  +   developing Internet standards in which case the procedures for
         3493  +   copyrights defined in the Internet Standards process must be
         3494  +   followed, or as required to translate it into languages other than
         3495  +   English.
         3496  +
         3497  +   The limited permissions granted above are perpetual and will not be
         3498  +   revoked by the Internet Society or its successors or assigns.
         3499  +
         3500  +   This document and the information contained herein is provided on an
         3501  +   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
         3502  +   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
         3503  +   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
         3504  +   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
         3505  +   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
         3506  +
         3507  +Acknowledgement
         3508  +
         3509  +   Funding for the RFC Editor function is currently provided by the
         3510  +   Internet Society.
         3511  +
         3512  +
         3513  +
         3514  +
         3515  +
         3516  +
         3517  +
         3518  +
         3519  +
         3520  +
         3521  +
         3522  +
         3523  +
         3524  +
         3525  +
         3526  +
         3527  +
         3528  +
         3529  +
         3530  +Kalt                         Informational                     [Page 63]
         3531  +