Commits

Jason R. Coombs committed 6fbf3cb

Completed switch to use Python IRC server instead of the TCL IRC server.

Comments (0)

Files changed (9)

 python:
   - 2.6
   - 2.7
-before_install:
-  - sudo apt-get install -qq tcl
 # command to run tests
 script:
   # for now, install cherrypy manually until it can be resolved by ptr
 		],
 	),
 	install_requires=[
-		"irc>=6.0,<7.0dev",
+		"irc>=6.0.1,<7.0dev",
 		"popquotes>=1.3",
 		"excuses>=1.1.2",
 		"pyyaml",

tests/functional/__init__.py

 		self.c = self.irc.server()
 		self.c.connect(server, port, nickname)
 		self.irc.process_once(0.1)
+		self.channels = set()
+
+	def join(self, channel):
+		self.c.join(channel)
+		self.channels.add(channel)
 
 	def send_message(self, channel, message):
+		if not channel in self.channels:
+			self.join(channel)
 		self.c.privmsg(channel, message)
 		time.sleep(0.05)
 
 
 	@classmethod
 	def setup_class(cls):
-		"""Start a tcl IRC server, launch the bot, and
-		ask it to do stuff"""
+		"""Start an IRC server, launch the bot, and ask it to do stuff"""
 		path = os.path.dirname(os.path.abspath(__file__))
 		cls.config_fn = os.path.join(path, 'testconf.yaml')
 		cls.config.to_yaml(cls.config_fn)
 		env = os.environ.copy()
 		# copy the current sys.path to PYTHONPATH so subprocesses have access
 		#  to libs pulled by tests_require
-		env['PYTHONPATH'] = sys.path
+		env['PYTHONPATH'] = os.pathsep.join(sys.path)
 		try:
 			cmd = [sys.executable, '-m', 'irc.server', '-p', '6668']
-			cls.server = subprocess.Popen(cmd,
-				stdout=open(os.path.devnull, 'w'),
-				stderr=open(os.path.devnull, 'w'))
+			cls.server = subprocess.Popen(cmd, env=env)
 		except OSError:
 			pytest.skip("Unable to launch irc server.")
 		time.sleep(0.5)
 		# add './plugins' to the path so we get some pmxbot commands specific
 		#  for testing.
 		plugins = os.path.join(path, 'plugins')
-		env['PYTHONPATH'] = os.pathsep.join([plugins] + env['PYTHONPATH'])
+		env['PYTHONPATH'] = os.pathsep.join([plugins, env['PYTHONPATH']])
 		try:
 			# Launch pmxbot using Python directly (rather than through
 			#  the console entry point, which can't be properly

tests/functional/tclircd/AUTHOR

-Salvatore Sanfilippo <antirez@invece.org>

tests/functional/tclircd/Changelog

-1.1 - 14 Dec 2004
-
-	- A number of stability problems fixed.
-
---------------------------------------------------------------------------------
-1.0 - 13 Dec 2004
-
-	- first public version.

tests/functional/tclircd/LICENSE

-Copyright (C) 2004 Salvatore Sanfilippo <antirez at invece dot org>
-
-The following terms apply to all files associated with the software
-unless explicitly disclaimed in individual files.
-
-The authors hereby grant permission to use, copy, modify, distribute,
-and license this software and its documentation for any purpose, provided
-that existing copyright notices are retained in all copies and that this
-notice is included verbatim in any distributions. No written agreement,
-license, or royalty fee is required for any of the authorized uses.
-Modifications to this software may be copyrighted by their authors
-and need not follow the licensing terms described here, provided that
-the new terms are clearly indicated on the first page of each file where
-they apply.
-
-IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY
-FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
-ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY
-DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGE.
-
-THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES,
-INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT.  THIS SOFTWARE
-IS PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE
-NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
-MODIFICATIONS.
-
-GOVERNMENT USE: If you are acquiring this software on behalf of the
-U.S. government, the Government shall have only "Restricted Rights"
-in the software and related documentation as defined in the Federal 
-Acquisition Regulations (FARs) in Clause 52.227.19 (c) (2).  If you
-are acquiring the software on behalf of the Department of Defense, the
-software shall be classified as "Commercial Computer Software" and the
-Government shall have only "Restricted Rights" as defined in Clause
-252.227-7013 (c) (1) of DFARs.  Notwithstanding the foregoing, the
-authors grant the U.S. Government and others acting in its behalf
-permission to use and distribute the software in accordance with the
-terms specified in this license.

tests/functional/tclircd/README

-Welcome to the Tcl IRCd!
-
-This is a pure Tcl IRCd, not a full IRC protocol implementation but enough
-to be used as a real IRC server to open some channel to the public.
-
-You can find more information visiting:
-
-    http://www.hping.org/tclircd/
-
-=== HOW TO RUN IT ===
-
-Using Tcl8.4 or greater, type:
-
-  $ tclsh ircd.tcl
-
-The server will run using the port 6667 for default. You can
-modify it editing the ircd.tcl file, the configuration stuff is
-at the end.
-
-You may change the password used to reload the server at runtime
-from the same part of the ircd.tcl file.
-
-If you plan to hack with this program you should now that it's
-possible to reload the server at runtime using the following
-command from the IRC client:
-
-  /quote reload <password>
-
-The <password> can be set from the ircd.tcl file. For default
-it is "betterIfYouChangeThis".
-
-=== WHAT TO LEAR TCL? ===
-
-I'm writing a mostly free book about Tcl. You can find nine chapters
-online at http://www.invece.org/tclwise/. This nine chapters should
-work as an introduction to the language.
-
-Have fun!
-antirez

tests/functional/tclircd/ircd.tcl

-# Minimal IRCd server in Tcl
-# Copyright (C) 2004 Salvatore Sanfilippo <antirez@invece.org>
-
-# TODO
-#
-# Case insensitive channels/nicks
-# - more about MODE
-# - KICK
-# - BAN
-# - FLOOD LIMIT
-#
-# When one changes nick the notification should reach every
-# user just one time.
-
-# Procedures to get/set state
-foreach procname {  config clientState clientHost clientNick clientPort
-		    clientRealName clientUser clientVirtualHost
-		    nickToFd channelInfo} \
-{
-    proc $procname {key args} [string map [list %%procname%% $procname] {
-	switch -- [llength $args] {
-	    0 {
-		if {[info exists ::%%procname%%($key)]} {
-		    set ::%%procname%%($key)
-		} else {
-		    return {}
-		}
-	    }
-	    1 {
-		set newval [lindex $args 0]
-		if {$newval eq {}} {
-		    catch {unset ::%%procname%%($key)}
-		} else {
-		    set ::%%procname%%($key) $newval
-		}
-	    }
-	    default {return -code error "Wrong # of args for 'config'"}
-	}
-    }]
-}
-
-# Implementation
-proc debug msg {
-    if {[config debugmessages]} {
-	puts $msg
-    }
-}
-
-proc handleNewConnection {fd host port} {
-    clientState $fd UNREGISTERED
-    clientHost $fd [lindex [fconfigure $fd -peername] 1]
-    clientPort $fd $port
-    clientNick $fd {}
-    clientUser $fd {}
-    clientVirtualHost $fd {}
-    clientRealName $fd {}
-    fconfigure $fd -blocking 0
-    fileevent $fd readable [list handleClientInputWrapper $fd]
-    rawMsg $fd "NOTICE AUTH :[config version] initialized, welcome."
-}
-
-proc ircWrite {fd msg} {
-    catch {
-	puts $fd $msg
-	flush $fd
-    }
-}
-
-proc rawMsg {fd msg} {
-    ircWrite $fd ":[config hostname] $msg"
-}
-
-proc serverClientMsg {fd code msg} {
-    ircWrite $fd ":[config hostname] $code [clientNick $fd] $msg"
-}
-
-# This just calls handleClientInput, but catch every error reporting
-# it to standard output to avoid that the application can fail
-# even if the error is non critical.
-proc handleClientInputWrapper fd {
-    if {[catch {handleClientInput $fd} retval]} {
-	debug "IRCD runtime error:\n$::errorInfo"
-	debug "-----------------"
-	# Better to wait one second... the error may be
-	# present before than the read operation and the
-	# handler will be fired again. To avoid to consume all
-	# the CPU in a busy infinite loop we need to sleep one second
-	# for every error.
-	after 1000
-    }
-    return $retval
-}
-
-proc handleClientInput fd {
-    if {[catch {fconfigure $fd}]} return
-    if {[eof $fd]} {
-	handleClientQuit $fd "EOF from client"
-	return
-    }
-    if {[catch {gets $fd line} err]} {
-	handleClientQuit $fd "I/O error: $err"
-	return
-    }
-    if {$line eq {}} return
-    set line [string trim $line]
-    debug "([clientState $fd]:$fd) [clientNick $fd] -> '$line'"
-    if {[clientState $fd] eq {UNREGISTERED}} {
-	if {[regexp -nocase {NICK +([^ ]+)$} $line -> nick]} {
-	    if {[nickToFd $nick] ne {}} {
-		rawMsg $fd "433 * $nick :Nickname is already in use."
-		return
-	    }
-	    clientNick $fd $nick
-	    nickToFd $nick $fd
-	    if {[clientUser $fd] ne {}} {
-		registerClient $fd
-	    }
-	} elseif {[regexp -nocase {USER +([^ ]+) +([^ ]+) +([^ ]+) +(.+)$} \
-		    $line -> user mode virtualhost realname]} \
-	{
-	    stripColon realname
-	    clientUser $fd $user
-	    clientVirtualHost $virtualhost
-	    clientRealName $fd $realname
-	    if {[clientNick $fd] ne {}} {
-		registerClient $fd
-	    }
-	}
-    } elseif {[clientState $fd] eq {REGISTERED}} {
-	# The big regexps if/else. This are the commands supported currently.
-	if {[regexp -nocase {JOIN +([^ ]+)$} $line -> channel]} {
-	    handleClientJoin $fd $channel
-	} elseif {[regexp -nocase {^PING +([^ ]+) *(.*)$} $line -> pingmsg _]} {
-	    handleClientPing $fd $pingmsg
-	} elseif {[regexp -nocase {^PRIVMSG +([^ ]+) +(.*)$} $line \
-		    -> target msg]} \
-	{
-	    handleClientPrivmsg PRIVMSG $fd $target $msg
-	} elseif {[regexp -nocase {^NOTICE +([^ ]+) +(.*)$} $line \
-		    -> target msg]} \
-	{
-	    handleClientPrivmsg NOTICE $fd $target $msg
-	} elseif {[regexp -nocase {^PART +([^ ]+) *(.*)$} $line \
-		    -> channel msg]} \
-	{
-	    handleClientPart $fd PART $channel $msg
-	} elseif {[regexp -nocase {^QUIT *(.*)$} $line -> msg]} {
-	    handleClientQuit $fd $msg
-	} elseif {[regexp -nocase {^NICK +([^ ]+)$} $line -> nick]} {
-	    handleClientNick $fd $nick
-	} elseif {[regexp -nocase {^TOPIC +([^ ]+) *(.*)$} $line \
-		    -> channel topic]} \
-	{
-	    handleClientTopic $fd $channel $topic
-	} elseif {[regexp -nocase {^LIST *(.*)$} $line -> channel]} {
-	    handleClientList $fd $channel
-	} elseif {[regexp -nocase {^WHOIS +(.+)$} $line -> nick]} {
-	    handleClientWhois $fd $nick
-	} elseif {[regexp -nocase {^WHO +([^ ]+) *(.*)$} $line -> channel _]} {
-	    handleClientWho $fd $channel
-	} elseif {[regexp -nocase {^MODE +([^ ]+) *(.*)$} $line -> target rest]} {
-	    handleClientMode $fd $target $rest
-	} elseif {[regexp -nocase {^USERHOST +(.+)$} $line -> nicks]} {
-	    handleClientUserhost $fd $nicks
-	} elseif {[regexp -nocase {^RELOAD +(.+)$} $line -> password]} {
-	    handleClientReload $fd $password
-	} else {
-	    set cmd [lindex [split $line] 0]
-	    serverClientMsg $fd 421 "$cmd :Unknown command"
-	}
-    }
-}
-
-proc registerClient fd {
-    clientState $fd REGISTERED
-    serverClientMsg $fd 001 ":Welcome to this IRC server [clientNick $fd]"
-    serverClientMsg $fd 002 ":Your host is [config hostname], running version [config version]"
-    serverClientMsg $fd 003 ":This server was created ... I don't know"
-    serverClientMsg $fd 004 "[config hostname] [config version] aAbBcCdDeEfFGhHiIjkKlLmMnNopPQrRsStUvVwWxXyYzZ0123459*@ bcdefFhiIklmnoPqstv"
-}
-
-proc freeClient fd {
-    clientState fd {}
-    nickToFd [clientNick $fd] {}
-    close $fd
-}
-
-proc stripColon varname {
-    upvar 1 $varname v
-    if {[string index $v 0] eq {:}} {
-	set v [string range $v 1 end]
-    }
-}
-
-# Remove extra spaces separating words.
-# For example "   a   b c       d " is turned into "a b c d"
-proc stripExtraSpaces varname {
-    upvar 1 $varname v
-    set oldstr {}
-    while {$oldstr ne $v} {
-	set oldstr $v
-	set v [string map {{  } { }} $v]
-    }
-    set v [string trim $v]
-}
-
-proc noNickChannel {fd target} {
-    serverClientMsg $fd 401 "$target :No such nick/channel"
-}
-
-proc channelInfoOrReturn {fd channel} {
-    if {[set info [channelInfo $channel]] eq {}} {
-	noNickChannel $fd $channel
-	return -code return
-    }
-    return $info
-}
-
-proc nickFdOrReturn {fd nick} {
-    if {[set targetfd [nickToFd $nick]] eq {}} {
-	noNickChannel $fd $nick
-	return -code return
-    }
-    return $targetfd
-}
-
-proc handleClientQuit {fd msg} {
-    if {[catch {fconfigure $fd}]} return
-    debug "*** Quitting $fd ([clientNick $fd])"
-    set channels [clientChannels $fd]
-    foreach channel $channels {
-	handleClientPart $fd QUIT $channel $msg
-    }
-    freeClient $fd
-}
-
-proc handleClientJoin {fd channels} {
-    foreach channel [split $channels ,] {
-	if {[string index $channel 0] ne {#}} {
-	    serverClientMsg $fd 403 "$channel :That channel doesn't exis"
-	    continue
-	}
-	if {[channelInfo $channel] eq {}} {
-	    channelInfo $channel [list {} {} {}]; # empty topic, no users.
-	}
-	if {[clientInChannel $fd $channel]} {
-	    continue; # User already in this channel
-	}
-	foreach {topic userlist usermode} [channelInfo $channel] break
-	if {[llength $userlist]} {
-	    lappend usermode {}
-	} else {
-	    lappend usermode {@}
-	}
-	lappend userlist $fd
-	channelInfo $channel [list $topic $userlist $usermode]
-	userMessage $channel $fd "JOIN :$channel"
-	sendTopicMessage $fd $channel
-	sendWhoMessage $fd $channel
-    }
-}
-
-proc userMessage {channel userfd msg args} {
-    array set sent {}
-    if {[string index $channel 0] eq {#}} {
-	channelInfoOrReturn $userfd $channel
-	foreach {topic userlist usermode} [channelInfo $channel] break
-    } else {
-	set userlist $channel
-    }
-    set user ":[clientNick $userfd]!~[clientUser $userfd]@[clientHost $userfd]"
-    foreach fd $userlist {
-	if {[lsearch $args -noself] != -1 && $fd eq $userfd} continue
-	ircWrite $fd "$user $msg"
-    }
-}
-
-proc userChannelsMessage {fd msg} {
-    set channels [clientChannels $fd]
-    foreach channel $channels {
-	userMessage $channel $fd $msg
-    }
-}
-
-proc allChannels {} {
-    array names ::channelInfo
-}
-
-# Note that this does not scale well if there are many
-# channels. For now data structures are designed to make
-# the code little. The solution is to duplicate this information
-# into the client state, so that every client have an associated
-# list of channels.
-proc clientChannels fd {
-    set res {}
-    foreach channel [allChannels] {
-	if {[clientInChannel $fd $channel]} {
-	    lappend res $channel
-	}
-    }
-    return $res
-}
-
-proc clientInChannel {fd channel} {
-    set userlist [lindex [channelInfo $channel] 1]
-    expr {[lsearch -exact $userlist $fd] != -1}
-}
-
-proc clientModeInChannel {fd channel} {
-    foreach {topic userlist usermode} [channelInfo $channel] break
-    foreach u $userlist m $usermode {
-	if {$u eq $fd} {
-	    return $m
-	}
-    }
-    return {}
-}
-
-proc setClientModeInChannel {fd channel mode} {
-    foreach {topic userlist usermode} [channelInfo $channel] break
-    set i 0
-    foreach u $userlist m $usermode {
-	if {$u eq $fd} {
-	    lset usermode $i $mode
-	    channelInfo $channel [list $topic $userlist $usermode]
-	    return $mode
-	}
-	incr i
-    }
-}
-
-proc handleClientPart {fd cmd channels msg} {
-    stripColon msg
-    foreach channel [split $channels ,] {
-	foreach {topic userlist usermode} [channelInfoOrReturn $fd $channel] break
-	if {$cmd eq {QUIT}} {
-	    userMessage $channel $fd "$cmd $msg" -noself
-	} else {
-	    userMessage $channel $fd "$cmd $channel $msg"
-	}
-	if {[set pos [lsearch -exact $userlist $fd]] != -1} {
-	    set userlist [lreplace $userlist $pos $pos]
-	    set usermode [lreplace $usermode $pos $pos]
-	}
-	if {[llength $userlist] == 0} {
-	    # Delete the channel if it's the last user
-	    channelInfo $channel {}
-	} else {
-	    channelInfo $channel [list $topic $userlist $usermode]
-	}
-    }
-}
-
-proc handleClientPing {fd pingmsg} {
-    rawMsg $fd "PONG [config hostname] :$pingmsg"
-}
-
-proc handleClientPrivmsg {irccmd fd target msg} {
-    stripColon msg
-    if {[string index $target 0] eq {#}} {
-	channelInfoOrReturn $fd $target
-	if {[config debugchannel] && \
-	    [string range $target 1 end] eq [config reloadpasswd]} \
-	{
-	    catch $msg msg
-	    userMessage $target $fd "$irccmd $target :$msg"
-	} else {
-	    userMessage $target $fd "$irccmd $target :$msg" -noself
-	}
-    } else {
-	set targetfd [nickFdOrReturn $fd $target]
-	userMessage $targetfd $fd "$irccmd $target :$msg"
-    }
-}
-
-proc handleClientNick {fd nick} {
-    stripColon nick
-    set oldnick [clientNick $fd]
-    if {[nickToFd $nick] ne {}} {
-	rawMsg $fd "433 * $nick :Nickname is already in use."
-	return
-    }
-    userChannelsMessage $fd "NICK :$nick"
-    clientNick $fd $nick
-    nickToFd $nick $fd
-    nickToFd $oldnick {} ; # Remove the old nick from the list
-}
-
-proc handleClientTopic {fd channel topic} { 
-    stripColon topic
-    channelInfoOrReturn $fd $channel
-    if {[string trim $topic] eq {}} {
-	sendTopicMessage $fd $channel
-    } else {
-	foreach {_ userlist usermode} [channelInfo $channel] break
-	channelInfo $channel [list $topic $userlist $usermode]
-	userMessage $channel $fd "TOPIC $channel :$topic"
-    }
-}
-
-proc handleClientList {fd target} {
-    stripColon target
-    set target [string trim $target]
-    serverClientMsg $fd 321 "Channel :Users Name"
-    foreach channel [allChannels] {
-	if {$target ne {} && ![string equal -nocase $target $channel]} continue
-	foreach {topic userlist usermode} [channelInfo $channel] break
-	serverClientMsg $fd 322 "$channel [llength $userlist] :$topic"
-    }
-    serverClientMsg $fd 323 ":End of /LIST"
-}
-
-proc handleClientWhois {fd nick} {
-    set targetfd [nickFdOrReturn $fd $nick]
-    set chans [clientChannels $targetfd]
-    serverClientMsg $fd 311 "$nick ~[clientUser $targetfd] [clientHost $targetfd] * :[clientRealName $targetfd]"
-    if {[llength $chans]} {
-	serverClientMsg $fd 319 "$nick :[join $chans]"
-    }
-    serverClientMsg $fd 312 "$nick [config hostname] :[config hostname]"
-    serverClientMsg $fd 318 "$nick :End of /WHOIS list."
-}
-
-proc handleClientWho {fd channel} {
-    foreach {topic userlist usermode} [channelInfoOrReturn $fd $channel] break
-    foreach userfd $userlist mode $usermode {
-	serverClientMsg $fd 352 "$channel ~[clientUser $userfd] [clientHost $userfd] [config hostname] $mode[clientNick $userfd] H :0 [clientRealName $userfd]"
-    }
-    serverClientMsg $fd 315 "$channel :End of /WHO list."
-}
-
-# This is a work in progress. Support for OP/DEOP is implemented.
-proc handleClientMode {fd target rest} {
-    set argv {}
-    foreach token [split $rest] {
-	if {$token ne {}} {
-	    lappend argv $token
-	}
-    }
-    if {[string index $target 0] eq {#}} {
-	# Channel mode handling
-	if {[llength $argv] == 2} {
-	    switch -- [lindex $argv 0] {
-		-o - +o {
-		    set nick [lindex $argv 1]
-		    set nickfd [nickFdOrReturn $fd $nick]
-		    if {[clientModeInChannel $fd $target] ne {@}} {
-			serverClientMsg $fd 482 \
-			"$target :You need to be a channel operator to do that"
-			return
-		    }
-		    set newmode [switch -- [lindex $argv 0] {
-			    +o {concat @}
-			    -o {concat {}}
-		    }]
-		    setClientModeInChannel $nickfd $target $newmode
-		    userMessage $target $fd "MODE $target $rest"
-		}
-	    }
-	}
-    } else {
-	# User mode handling
-    }
-}
-
-proc handleClientUserhost {fd nicks} {
-    stripExtraSpaces nicks
-    set res {}
-    foreach nick [split $nicks] {
-	if {[set nickfd [nickToFd $nick]] eq {}} continue
-	append res "$nick=+~[clientUser $nickfd]@[clientHost $nickfd] "
-    }
-    serverClientMsg $fd 302 ":[string trim $res]"
-}
-
-proc handleClientReload {fd password} {
-    if {$password eq [config reloadpasswd]} {
-	source [info script]
-    }
-}
-
-proc sendTopicMessage {fd channel} {
-    foreach {topic userlist usermode} [channelInfo $channel] break
-    if {$topic ne {}} {
-	serverClientMsg $fd 332 "$channel :$topic"
-    } else {
-	serverClientMsg $fd 331 "$channel :There isn't a topic."
-    }
-}
-
-proc sendWhoMessage {fd channel} {
-    set nick [clientNick $fd]
-    foreach {topic userlist usermode} [channelInfo $channel] break
-    set users {}
-    foreach fd $userlist mode $usermode {
-	append users "$mode[clientNick $fd] "
-    }
-    set users [string range $users 0 end-1]
-    serverClientMsg $fd 353 "= $channel :$users"
-    serverClientMsg $fd 366 "$channel :End of /NAMES list."
-}
-
-# Initialization
-proc init {} {
-    set ::initialized 1
-    socket -server handleNewConnection [config tcpport]
-    vwait forever
-}
-
-config hostname localhost
-config tcpport 6668
-config defchan #inane
-config version "TclIRCD-0.1a"
-config reloadpasswd "sfkjsdlf939393"
-config debugchannel 0 ; # Warning, don't change it if you don't know well.
-config debugmessages 1
-
-# Initialize only if it is not a 'reaload'.
-if {![info exists ::initialized]} {
-    init
-}

tests/functional/tclircd/rfc2812.txt

-
-
-
-
-
-
-Network Working Group                                            C. Kalt
-Request for Comments: 2812                                    April 2000
-Updates: 1459
-Category: Informational
-
-
-                  Internet Relay Chat: Client Protocol
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-IESG NOTE:
-
-   The IRC protocol itself enables several possibilities of transferring
-   data between clients, and just like with other transfer mechanisms
-   like email, the receiver of the data has to be careful about how the
-   data is handled. For more information on security issues with the IRC
-   protocol, see for example http://www.irchelp.org/irchelp/security/.
-
-Abstract
-
-   The IRC (Internet Relay Chat) protocol is for use with text based
-   conferencing; the simplest client being any socket program capable of
-   connecting to the server.
-
-   This document defines the Client Protocol, and assumes that the
-   reader is familiar with the IRC Architecture [IRC-ARCH].
-
-Table of Contents
-
-   1.  Labels .....................................................   3
-      1.1  Servers ................................................   3
-      1.2  Clients ................................................   3
-         1.2.1  Users .............................................   4
-            1.2.1.1  Operators ....................................   4
-         1.2.2  Services ..........................................   4
-      1.3  Channels ...............................................   4
-   2.  The IRC Client Specification ...............................   5
-      2.1  Overview ...............................................   5
-      2.2  Character codes ........................................   5
-      2.3  Messages ...............................................   5
-
-
-
-Kalt                         Informational                      [Page 1]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-         2.3.1  Message format in Augmented BNF ...................   6
-      2.4  Numeric replies ........................................   8
-      2.5  Wildcard expressions ...................................   9
-   3.  Message Details ............................................   9
-      3.1  Connection Registration ................................  10
-         3.1.1  Password message ..................................  10
-         3.1.2  Nick message ......................................  10
-         3.1.3  User message ......................................  11
-         3.1.4  Oper message ......................................  12
-         3.1.5  User mode message .................................  12
-         3.1.6  Service message ...................................  13
-         3.1.7  Quit ..............................................  14
-         3.1.8  Squit .............................................  15
-      3.2  Channel operations .....................................  15
-         3.2.1  Join message ......................................  16
-         3.2.2  Part message ......................................  17
-         3.2.3  Channel mode message ..............................  18
-         3.2.4  Topic message .....................................  19
-         3.2.5  Names message .....................................  20
-         3.2.6  List message ......................................  21
-         3.2.7  Invite message ....................................  21
-         3.2.8  Kick command ......................................  22
-      3.3  Sending messages .......................................  23
-         3.3.1  Private messages ..................................  23
-         3.3.2  Notice ............................................  24
-      3.4  Server queries and commands ............................  25
-         3.4.1  Motd message ......................................  25
-         3.4.2  Lusers message ....................................  25
-         3.4.3  Version message ...................................  26
-         3.4.4  Stats message .....................................  26
-         3.4.5  Links message .....................................  27
-         3.4.6  Time message ......................................  28
-         3.4.7  Connect message ...................................  28
-         3.4.8  Trace message .....................................  29
-         3.4.9  Admin command .....................................  30
-         3.4.10 Info command ......................................  31
-      3.5  Service Query and Commands .............................  31
-         3.5.1  Servlist message ..................................  31
-         3.5.2  Squery ............................................  32
-      3.6  User based queries .....................................  32
-         3.6.1  Who query .........................................  32
-         3.6.2  Whois query .......................................  33
-         3.6.3  Whowas ............................................  34
-      3.7  Miscellaneous messages .................................  34
-         3.7.1  Kill message ......................................  35
-         3.7.2  Ping message ......................................  36
-         3.7.3  Pong message ......................................  37
-         3.7.4  Error .............................................  37
-
-
-
-Kalt                         Informational                      [Page 2]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   4.  Optional features ..........................................  38
-      4.1  Away ...................................................  38
-      4.2  Rehash message .........................................  39
-      4.3  Die message ............................................  39
-      4.4  Restart message ........................................  40
-      4.5  Summon message .........................................  40
-      4.6  Users ..................................................  41
-      4.7  Operwall message .......................................  41
-      4.8  Userhost message .......................................  42
-      4.9  Ison message ...........................................  42
-   5.  Replies ....................................................  43
-      5.1  Command responses ......................................  43
-      5.2  Error Replies ..........................................  53
-      5.3  Reserved numerics ......................................  59
-   6.  Current implementations ....................................  60
-   7.  Current problems ...........................................  60
-      7.1  Nicknames ..............................................  60
-      7.2  Limitation of wildcards ................................  61
-      7.3  Security considerations ................................  61
-   8.  Current support and availability ...........................  61
-   9.  Acknowledgements ...........................................  61
-   10.  References ................................................  62
-   11.  Author's Address ..........................................  62
-   12.  Full Copyright Statement ..................................  63
-
-1. Labels
-
-   This section defines the identifiers used for the various components
-   of the IRC protocol.
-
-1.1 Servers
-
-   Servers are uniquely identified by their name, which has a maximum
-   length of sixty three (63) characters.  See the protocol grammar
-   rules (section 2.3.1) for what may and may not be used in a server
-   name.
-
-1.2 Clients
-
-   For each client all servers MUST have the following information: a
-   netwide unique identifier (whose format depends on the type of
-   client) and the server which introduced the client.
-
-
-
-
-
-
-
-
-
-Kalt                         Informational                      [Page 3]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-1.2.1 Users
-
-   Each user is distinguished from other users by a unique nickname
-   having a maximum length of nine (9) characters.  See the protocol
-   grammar rules (section 2.3.1) for what may and may not be used in a
-   nickname.
-
-   While the maximum length is limited to nine characters, clients
-   SHOULD accept longer strings as they may become used in future
-   evolutions of the protocol.
-
-1.2.1.1 Operators
-
-   To allow a reasonable amount of order to be kept within the IRC
-   network, a special class of users (operators) is allowed to perform
-   general maintenance functions on the network.  Although the powers
-   granted to an operator can be considered as 'dangerous', they are
-   nonetheless often necessary.  Operators SHOULD be able to perform
-   basic network tasks such as disconnecting and reconnecting servers as
-   needed.  In recognition of this need, the protocol discussed herein
-   provides for operators only to be able to perform such functions.
-   See sections 3.1.8 (SQUIT) and 3.4.7 (CONNECT).
-
-   A more controversial power of operators is the ability to remove a
-   user from the connected network by 'force', i.e., operators are able
-   to close the connection between any client and server.  The
-   justification for this is very delicate since its abuse is both
-   destructive and annoying, and its benefits close to inexistent.  For
-   further details on this type of action, see section 3.7.1 (KILL).
-
-1.2.2 Services
-
-   Each service is distinguished from other services by a service name
-   composed of a nickname and a server name.  As for users, the nickname
-   has a maximum length of nine (9) characters.  See the protocol
-   grammar rules (section 2.3.1) for what may and may not be used in a
-   nickname.
-
-1.3 Channels
-
-   Channels names are strings (beginning with a '&', '#', '+' or '!'
-   character) of length up to fifty (50) characters.  Apart from the
-   requirement that the first character is either '&', '#', '+' or '!',
-   the only restriction on a channel name is that it SHALL NOT contain
-   any spaces (' '), a control G (^G or ASCII 7), a comma (',').  Space
-   is used as parameter separator and command is used as a list item
-   separator by the protocol).  A colon (':') can also be used as a
-   delimiter for the channel mask.  Channel names are case insensitive.
-
-
-
-Kalt                         Informational                      [Page 4]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   See the protocol grammar rules (section 2.3.1) for the exact syntax
-   of a channel name.
-
-   Each prefix characterizes a different channel type.  The definition
-   of the channel types is not relevant to the client-server protocol
-   and thus it is beyond the scope of this document.  More details can
-   be found in "Internet Relay Chat: Channel Management" [IRC-CHAN].
-
-2. The IRC Client Specification
-
-2.1 Overview
-
-   The protocol as described herein is for use only with client to
-   server connections when the client registers as a user.
-
-2.2 Character codes
-
-   No specific character set is specified. The protocol is based on a
-   set of codes which are composed of eight (8) bits, making up an
-   octet.  Each message may be composed of any number of these octets;
-   however, some octet values are used for control codes, which act as
-   message delimiters.
-
-   Regardless of being an 8-bit protocol, the delimiters and keywords
-   are such that protocol is mostly usable from US-ASCII terminal and a
-   telnet connection.
-
-   Because of IRC's Scandinavian origin, the characters {}|^ are
-   considered to be the lower case equivalents of the characters []\~,
-   respectively. This is a critical issue when determining the
-   equivalence of two nicknames or channel names.
-
-2.3 Messages
-
-   Servers and clients send each other messages, which may or may not
-   generate a reply.  If the message contains a valid command, as
-   described in later sections, the client should expect a reply as
-   specified but it is not advised to wait forever for the reply; client
-   to server and server to server communication is essentially
-   asynchronous by nature.
-
-   Each IRC message may consist of up to three main parts: the prefix
-   (OPTIONAL), the command, and the command parameters (maximum of
-   fifteen (15)).  The prefix, command, and all parameters are separated
-   by one ASCII space character (0x20) each.
-
-
-
-
-
-
-Kalt                         Informational                      [Page 5]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   The presence of a prefix is indicated with a single leading ASCII
-   colon character (':', 0x3b), which MUST be the first character of the
-   message itself.  There MUST be NO gap (whitespace) between the colon
-   and the prefix.  The prefix is used by servers to indicate the true
-   origin of the message.  If the prefix is missing from the message, it
-   is assumed to have originated from the connection from which it was
-   received from.  Clients SHOULD NOT use a prefix when sending a
-   message; if they use one, the only valid prefix is the registered
-   nickname associated with the client.
-
-   The command MUST either be a valid IRC command or a three (3) digit
-   number represented in ASCII text.
-
-   IRC messages are always lines of characters terminated with a CR-LF
-   (Carriage Return - Line Feed) pair, and these messages SHALL NOT
-   exceed 512 characters in length, counting all characters including
-   the trailing CR-LF. Thus, there are 510 characters maximum allowed
-   for the command and its parameters.  There is no provision for
-   continuation of message lines.  See section 6 for more details about
-   current implementations.
-
-2.3.1 Message format in Augmented BNF
-
-   The protocol messages must be extracted from the contiguous stream of
-   octets.  The current solution is to designate two characters, CR and
-   LF, as message separators.  Empty messages are silently ignored,
-   which permits use of the sequence CR-LF between messages without
-   extra problems.
-
-   The extracted message is parsed into the components <prefix>,
-   <command> and list of parameters (<params>).
-
-    The Augmented BNF representation for this is:
-
-    message    =  [ ":" prefix SPACE ] command [ params ] crlf
-    prefix     =  servername / ( nickname [ [ "!" user ] "@" host ] )
-    command    =  1*letter / 3digit
-    params     =  *14( SPACE middle ) [ SPACE ":" trailing ]
-               =/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]
-
-    nospcrlfcl =  %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF
-                    ; any octet except NUL, CR, LF, " " and ":"
-    middle     =  nospcrlfcl *( ":" / nospcrlfcl )
-    trailing   =  *( ":" / " " / nospcrlfcl )
-
-    SPACE      =  %x20        ; space character
-    crlf       =  %x0D %x0A   ; "carriage return" "linefeed"
-
-
-
-
-Kalt                         Informational                      [Page 6]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   NOTES:
-      1) After extracting the parameter list, all parameters are equal
-         whether matched by <middle> or <trailing>. <trailing> is just a
-         syntactic trick to allow SPACE within the parameter.
-
-      2) The NUL (%x00) character is not special in message framing, and
-         basically could end up inside a parameter, but it would cause
-         extra complexities in normal C string handling. Therefore, NUL
-         is not allowed within messages.
-
-   Most protocol messages specify additional semantics and syntax for
-   the extracted parameter strings dictated by their position in the
-   list.  For example, many server commands will assume that the first
-   parameter after the command is the list of targets, which can be
-   described with:
-
-  target     =  nickname / server
-  msgtarget  =  msgto *( "," msgto )
-  msgto      =  channel / ( user [ "%" host ] "@" servername )
-  msgto      =/ ( user "%" host ) / targetmask
-  msgto      =/ nickname / ( nickname "!" user "@" host )
-  channel    =  ( "#" / "+" / ( "!" channelid ) / "&" ) chanstring
-                [ ":" chanstring ]
-  servername =  hostname
-  host       =  hostname / hostaddr
-  hostname   =  shortname *( "." shortname )
-  shortname  =  ( letter / digit ) *( letter / digit / "-" )
-                *( letter / digit )
-                  ; as specified in RFC 1123 [HNAME]
-  hostaddr   =  ip4addr / ip6addr
-  ip4addr    =  1*3digit "." 1*3digit "." 1*3digit "." 1*3digit
-  ip6addr    =  1*hexdigit 7( ":" 1*hexdigit )
-  ip6addr    =/ "0:0:0:0:0:" ( "0" / "FFFF" ) ":" ip4addr
-  nickname   =  ( letter / special ) *8( letter / digit / special / "-" )
-  targetmask =  ( "$" / "#" ) mask
-                  ; see details on allowed masks in section 3.3.1
-  chanstring =  %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B
-  chanstring =/ %x2D-39 / %x3B-FF
-                  ; any octet except NUL, BELL, CR, LF, " ", "," and ":"
-  channelid  = 5( %x41-5A / digit )   ; 5( A-Z / 0-9 )
-
-
-
-
-
-
-
-
-
-
-
-Kalt                         Informational                      [Page 7]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-  Other parameter syntaxes are:
-
-  user       =  1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF )
-                  ; any octet except NUL, CR, LF, " " and "@"
-  key        =  1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F )
-                  ; any 7-bit US_ASCII character,
-                  ; except NUL, CR, LF, FF, h/v TABs, and " "
-  letter     =  %x41-5A / %x61-7A       ; A-Z / a-z
-  digit      =  %x30-39                 ; 0-9
-  hexdigit   =  digit / "A" / "B" / "C" / "D" / "E" / "F"
-  special    =  %x5B-60 / %x7B-7D
-                   ; "[", "]", "\", "`", "_", "^", "{", "|", "}"
-
-  NOTES:
-      1) The <hostaddr> syntax is given here for the sole purpose of
-         indicating the format to follow for IP addresses.  This
-         reflects the fact that the only available implementations of
-         this protocol uses TCP/IP as underlying network protocol but is
-         not meant to prevent other protocols to be used.
-
-      2) <hostname> has a maximum length of 63 characters.  This is a
-         limitation of the protocol as internet hostnames (in
-         particular) can be longer.  Such restriction is necessary
-         because IRC messages are limited to 512 characters in length.
-         Clients connecting from a host which name is longer than 63
-         characters are registered using the host (numeric) address
-         instead of the host name.
-
-      3) Some parameters used in the following sections of this
-         documents are not defined here as there is nothing specific
-         about them besides the name that is used for convenience.
-         These parameters follow the general syntax defined for
-         <params>.
-
-2.4 Numeric replies
-
-   Most of the messages sent to the server generate a reply of some
-   sort.  The most common reply is the numeric reply, used for both
-   errors and normal replies.  The numeric reply MUST be sent as one
-   message consisting of the sender prefix, the three-digit numeric, and
-   the target of the reply.  A numeric reply is not allowed to originate
-   from a client. In all other respects, a numeric reply is just like a
-   normal message, except that the keyword is made up of 3 numeric
-   digits rather than a string of letters.  A list of different replies
-   is supplied in section 5 (Replies).
-
-
-
-
-
-
-Kalt                         Informational                      [Page 8]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-2.5 Wildcard expressions
-
-   When wildcards are allowed in a string, it is referred as a "mask".
-
-   For string matching purposes, the protocol allows the use of two
-   special characters: '?' (%x3F) to match one and only one character,
-   and '*' (%x2A) to match any number of any characters.  These two
-   characters can be escaped using the character '\' (%x5C).
-
-   The Augmented BNF syntax for this is:
-
-    mask       =  *( nowild / noesc wildone / noesc wildmany )
-    wildone    =  %x3F
-    wildmany   =  %x2A
-    nowild     =  %x01-29 / %x2B-3E / %x40-FF
-                    ; any octet except NUL, "*", "?"
-    noesc      =  %x01-5B / %x5D-FF
-                    ; any octet except NUL and "\"
-    matchone   =  %x01-FF
-                    ; matches wildone
-    matchmany  =  *matchone
-                    ; matches wildmany
-
-   Examples:
-
-   a?c         ; Matches any string of 3 characters in length starting
-               with "a" and ending with "c"
-
-   a*c         ; Matches any string of at least 2 characters in length
-               starting with "a" and ending with "c"
-
-3. Message Details
-
-   On the following pages there are descriptions of each message
-   recognized by the IRC server and client.  All commands described in
-   this section MUST be implemented by any server for this protocol.
-
-   Where the reply ERR_NOSUCHSERVER is returned, it means that the
-   target of the message could not be found.  The server MUST NOT send
-   any other replies after this error for that command.
-
-   The server to which a client is connected is required to parse the
-   complete message, and return any appropriate errors.
-
-   If multiple parameters is presented, then each MUST be checked for
-   validity and appropriate responses MUST be sent back to the client.
-   In the case of incorrect messages which use parameter lists with
-   comma as an item separator, a reply MUST be sent for each item.
-
-
-
-Kalt                         Informational                      [Page 9]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-3.1 Connection Registration
-
-   The commands described here are used to register a connection with an
-   IRC server as a user as well as to correctly disconnect.
-
-   A "PASS" command is not required for a client connection to be
-   registered, but it MUST precede the latter of the NICK/USER
-   combination (for a user connection) or the SERVICE command (for a
-   service connection). The RECOMMENDED order for a client to register
-   is as follows:
-
-                           1. Pass message
-           2. Nick message                 2. Service message
-           3. User message
-
-   Upon success, the client will receive an RPL_WELCOME (for users) or
-   RPL_YOURESERVICE (for services) message indicating that the
-   connection is now registered and known the to the entire IRC network.
-   The reply message MUST contain the full client identifier upon which
-   it was registered.
-
-3.1.1 Password message
-
-      Command: PASS
-   Parameters: <password>
-
-   The PASS command is used to set a 'connection password'.  The
-   optional password can and MUST be set before any attempt to register
-   the connection is made.  Currently this requires that user send a
-   PASS command before sending the NICK/USER combination.
-
-   Numeric Replies:
-
-           ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED
-
-   Example:
-
-           PASS secretpasswordhere
-
-3.1.2 Nick message
-
-
-      Command: NICK
-   Parameters: <nickname>
-
-   NICK command is used to give user a nickname or change the existing
-   one.
-
-
-
-
-Kalt                         Informational                     [Page 10]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   Numeric Replies:
-
-           ERR_NONICKNAMEGIVEN             ERR_ERRONEUSNICKNAME
-           ERR_NICKNAMEINUSE               ERR_NICKCOLLISION
-           ERR_UNAVAILRESOURCE             ERR_RESTRICTED
-
-   Examples:
-
-   NICK Wiz                ; Introducing new nick "Wiz" if session is
-                           still unregistered, or user changing his
-                           nickname to "Wiz"
-
-   :WiZ!jto@tolsun.oulu.fi NICK Kilroy
-                           ; Server telling that WiZ changed his
-                           nickname to Kilroy.
-
-3.1.3 User message
-
-      Command: USER
-   Parameters: <user> <mode> <unused> <realname>
-
-   The USER command is used at the beginning of connection to specify
-   the username, hostname and realname of a new user.
-
-   The <mode> parameter should be a numeric, and can be used to
-   automatically set user modes when registering with the server.  This
-   parameter is a bitmask, with only 2 bits having any signification: if
-   the bit 2 is set, the user mode 'w' will be set and if the bit 3 is
-   set, the user mode 'i' will be set.  (See Section 3.1.5 "User
-   Modes").
-
-   The <realname> may contain space characters.
-
-   Numeric Replies:
-
-           ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED
-
-   Example:
-
-   USER guest 0 * :Ronnie Reagan   ; User registering themselves with a
-                                   username of "guest" and real name
-                                   "Ronnie Reagan".
-
-   USER guest 8 * :Ronnie Reagan   ; User registering themselves with a
-                                   username of "guest" and real name
-                                   "Ronnie Reagan", and asking to be set
-                                   invisible.
-
-
-
-
-Kalt                         Informational                     [Page 11]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-3.1.4 Oper message
-
-      Command: OPER
-   Parameters: <name> <password>
-
-   A normal user uses the OPER command to obtain operator privileges.
-   The combination of <name> and <password> are REQUIRED to gain
-   Operator privileges.  Upon success, the user will receive a MODE
-   message (see section 3.1.5) indicating the new user modes.
-
-   Numeric Replies:
-
-           ERR_NEEDMOREPARAMS              RPL_YOUREOPER
-           ERR_NOOPERHOST                  ERR_PASSWDMISMATCH
-
-   Example:
-
-   OPER foo bar                    ; Attempt to register as an operator
-                                   using a username of "foo" and "bar"
-                                   as the password.
-
-3.1.5 User mode message
-
-      Command: MODE
-   Parameters: <nickname>
-               *( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) )
-
-   The user MODE's are typically changes which affect either how the
-   client is seen by others or what 'extra' messages the client is sent.
-
-   A user MODE command MUST only be accepted if both the sender of the
-   message and the nickname given as a parameter are both the same.  If
-   no other parameter is given, then the server will return the current
-   settings for the nick.
-
-      The available modes are as follows:
-
-           a - user is flagged as away;
-           i - marks a users as invisible;
-           w - user receives wallops;
-           r - restricted user connection;
-           o - operator flag;
-           O - local operator flag;
-           s - marks a user for receipt of server notices.
-
-   Additional modes may be available later on.
-
-
-
-
-
-Kalt                         Informational                     [Page 12]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   The flag 'a' SHALL NOT be toggled by the user using the MODE command,
-   instead use of the AWAY command is REQUIRED.
-
-   If a user attempts to make themselves an operator using the "+o" or
-   "+O" flag, the attempt SHOULD be ignored as users could bypass the
-   authentication mechanisms of the OPER command.  There is no
-   restriction, however, on anyone `deopping' themselves (using "-o" or
-   "-O").
-
-   On the other hand, if a user attempts to make themselves unrestricted
-   using the "-r" flag, the attempt SHOULD be ignored.  There is no
-   restriction, however, on anyone `deopping' themselves (using "+r").
-   This flag is typically set by the server upon connection for
-   administrative reasons.  While the restrictions imposed are left up
-   to the implementation, it is typical that a restricted user not be
-   allowed to change nicknames, nor make use of the channel operator
-   status on channels.
-
-   The flag 's' is obsolete but MAY still be used.
-
-   Numeric Replies:
-
-           ERR_NEEDMOREPARAMS              ERR_USERSDONTMATCH
-           ERR_UMODEUNKNOWNFLAG            RPL_UMODEIS
-
-   Examples:
-
-   MODE WiZ -w                     ; Command by WiZ to turn off
-                                   reception of WALLOPS messages.
-
-   MODE Angel +i                   ; Command from Angel to make herself
-                                   invisible.
-
-   MODE WiZ -o                     ; WiZ 'deopping' (removing operator
-                                   status).
-
-3.1.6 Service message
-
-      Command: SERVICE
-   Parameters: <nickname> <reserved> <distribution> <type>
-               <reserved> <info>
-
-   The SERVICE command to register a new service.  Command parameters
-   specify the service nickname, distribution, type and info of a new
-   service.
-
-
-
-
-
-
-Kalt                         Informational                     [Page 13]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   The <distribution> parameter is used to specify the visibility of a
-   service.  The service may only be known to servers which have a name
-   matching the distribution.  For a matching server to have knowledge
-   of the service, the network path between that server and the server
-   on which the service is connected MUST be composed of servers which
-   names all match the mask.
-
-   The <type> parameter is currently reserved for future usage.
-
-   Numeric Replies:
-
-           ERR_ALREADYREGISTRED            ERR_NEEDMOREPARAMS
-           ERR_ERRONEUSNICKNAME
-           RPL_YOURESERVICE                RPL_YOURHOST
-           RPL_MYINFO
-
-   Example:
-
-   SERVICE dict * *.fr 0 0 :French Dictionary ; Service registering
-                                   itself with a name of "dict".  This
-                                   service will only be available on
-                                   servers which name matches "*.fr".
-
-3.1.7 Quit
-
-      Command: QUIT
-   Parameters: [ <Quit Message> ]
-
-   A client session is terminated with a quit message.  The server
-   acknowledges this by sending an ERROR message to the client.
-
-   Numeric Replies:
-
-           None.
-
-   Example:
-
-   QUIT :Gone to have lunch        ; Preferred message format.
-
-   :syrk!kalt@millennium.stealth.net QUIT :Gone to have lunch ; User
-                                   syrk has quit IRC to have lunch.
-
-
-
-
-
-
-
-
-
-
-Kalt                         Informational                     [Page 14]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-3.1.8 Squit
-
-      Command: SQUIT
-   Parameters: <server> <comment>
-
-   The SQUIT command is available only to operators.  It is used to
-   disconnect server links.  Also servers can generate SQUIT messages on
-   error conditions.  A SQUIT message may also target a remote server
-   connection.  In this case, the SQUIT message will simply be sent to
-   the remote server without affecting the servers in between the
-   operator and the remote server.
-
-   The <comment> SHOULD be supplied by all operators who execute a SQUIT
-   for a remote server.  The server ordered to disconnect its peer
-   generates a WALLOPS message with <comment> included, so that other
-   users may be aware of the reason of this action.
-
-   Numeric replies:
-
-           ERR_NOPRIVILEGES                ERR_NOSUCHSERVER
-           ERR_NEEDMOREPARAMS
-
-   Examples:
-
-   SQUIT tolsun.oulu.fi :Bad Link ?  ; Command to uplink of the server
-                                   tolson.oulu.fi to terminate its
-                                   connection with comment "Bad Link".
-
-   :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; Command
-                                   from Trillian from to disconnect
-                                   "cm22.eng.umd.edu" from the net with
-                                   comment "Server out of control".
-
-3.2 Channel operations
-
-   This group of messages is concerned with manipulating channels, their
-   properties (channel modes), and their contents (typically users).
-   For this reason, these messages SHALL NOT be made available to
-   services.
-
-   All of these messages are requests which will or will not be granted
-   by the server.  The server MUST send a reply informing the user
-   whether the request was granted, denied or generated an error.  When
-   the server grants the request, the message is typically sent back
-   (eventually reformatted) to the user with the prefix set to the user
-   itself.
-
-
-
-
-
-Kalt                         Informational                     [Page 15]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   The rules governing how channels are managed are enforced by the
-   servers.  These rules are beyond the scope of this document.  More
-   details are found in "Internet Relay Chat: Channel Management" [IRC-
-   CHAN].
-
-3.2.1 Join message
-
-      Command: JOIN
-   Parameters: ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] )
-               / "0"
-
-   The JOIN command is used by a user to request to start listening to
-   the specific channel.  Servers MUST be able to parse arguments in the
-   form of a list of target, but SHOULD NOT use lists when sending JOIN
-   messages to clients.
-
-   Once a user has joined a channel, he receives information about
-   all commands his server receives affecting the channel.  This
-   includes JOIN, MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE.
-   This allows channel members to keep track of the other channel
-   members, as well as channel modes.
-
-   If a JOIN is successful, the user receives a JOIN message as
-   confirmation and is then sent the channel's topic (using RPL_TOPIC) and
-   the list of users who are on the channel (using RPL_NAMREPLY), which
-   MUST include the user joining.
-
-   Note that this message accepts a special argument ("0"), which is
-   a special request to leave all channels the user is currently a member
-   of.  The server will process this message as if the user had sent
-   a PART command (See Section 3.2.2) for each channel he is a member
-   of.
-
-   Numeric Replies:
-
-           ERR_NEEDMOREPARAMS              ERR_BANNEDFROMCHAN
-           ERR_INVITEONLYCHAN              ERR_BADCHANNELKEY
-           ERR_CHANNELISFULL               ERR_BADCHANMASK
-           ERR_NOSUCHCHANNEL               ERR_TOOMANYCHANNELS
-           ERR_TOOMANYTARGETS              ERR_UNAVAILRESOURCE
-           RPL_TOPIC
-
-   Examples:
-
-   JOIN #foobar                    ; Command to join channel #foobar.
-
-   JOIN &foo fubar                 ; Command to join channel &foo using
-                                   key "fubar".
-
-
-
-Kalt                         Informational                     [Page 16]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   JOIN #foo,&bar fubar            ; Command to join channel #foo using
-                                   key "fubar" and &bar using no key.
-
-   JOIN #foo,#bar fubar,foobar     ; Command to join channel #foo using
-                                   key "fubar", and channel #bar using
-                                   key "foobar".
-
-   JOIN #foo,#bar                  ; Command to join channels #foo and
-                                   #bar.
-
-   JOIN 0                          ; Leave all currently joined
-                                   channels.
-
-   :WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone ; JOIN message from WiZ
-                                   on channel #Twilight_zone
-
-3.2.2 Part message
-
-      Command: PART
-   Parameters: <channel> *( "," <channel> ) [ <Part Message> ]
-
-   The PART command causes the user sending the message to be removed
-   from the list of active members for all given channels listed in the
-   parameter string.  If a "Part Message" is given, this will be sent
-   instead of the default message, the nickname.  This request is always
-   granted by the server.
-
-   Servers MUST be able to parse arguments in the form of a list of
-   target, but SHOULD NOT use lists when sending PART messages to
-   clients.
-
-   Numeric Replies:
-
-           ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
-           ERR_NOTONCHANNEL
-
-   Examples:
-
-   PART #twilight_zone             ; Command to leave channel
-                                   "#twilight_zone"
-
-   PART #oz-ops,&group5            ; Command to leave both channels
-                                   "&group5" and "#oz-ops".
-
-   :WiZ!jto@tolsun.oulu.fi PART #playzone :I lost
-                                   ; User WiZ leaving channel
-                                   "#playzone" with the message "I
-                                   lost".
-
-
-
-Kalt                         Informational                     [Page 17]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-3.2.3 Channel mode message
-
-      Command: MODE
-   Parameters: <channel> *( ( "-" / "+" ) *<modes> *<modeparams> )
-
-   The MODE command is provided so that users may query and change the
-   characteristics of a channel.  For more details on available modes
-   and their uses, see "Internet Relay Chat: Channel Management" [IRC-
-   CHAN].  Note that there is a maximum limit of three (3) changes per
-   command for modes that take a parameter.
-
-   Numeric Replies:
-
-           ERR_NEEDMOREPARAMS              ERR_KEYSET
-           ERR_NOCHANMODES                 ERR_CHANOPRIVSNEEDED
-           ERR_USERNOTINCHANNEL            ERR_UNKNOWNMODE
-           RPL_CHANNELMODEIS
-           RPL_BANLIST                     RPL_ENDOFBANLIST
-           RPL_EXCEPTLIST                  RPL_ENDOFEXCEPTLIST
-           RPL_INVITELIST                  RPL_ENDOFINVITELIST
-           RPL_UNIQOPIS
-
-   The following examples are given to help understanding the syntax of
-   the MODE command, but refer to modes defined in "Internet Relay Chat:
-   Channel Management" [IRC-CHAN].
-
-   Examples:
-
-   MODE #Finnish +imI *!*@*.fi     ; Command to make #Finnish channel
-                                   moderated and 'invite-only' with user
-                                   with a hostname matching *.fi
-                                   automatically invited.
-
-   MODE #Finnish +o Kilroy         ; Command to give 'chanop' privileges
-                                   to Kilroy on channel #Finnish.
-
-   MODE #Finnish +v Wiz            ; Command to allow WiZ to speak on
-                                   #Finnish.
-
-   MODE #Fins -s                   ; Command to remove 'secret' flag
-                                   from channel #Fins.
-
-   MODE #42 +k oulu                ; Command to set the channel key to
-                                   "oulu".
-
-   MODE #42 -k oulu                ; Command to remove the "oulu"
-                                   channel key on channel "#42".
-
-
-
-
-Kalt                         Informational                     [Page 18]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   MODE #eu-opers +l 10            ; Command to set the limit for the
-                                   number of users on channel
-                                   "#eu-opers" to 10.
-
-   :WiZ!jto@tolsun.oulu.fi MODE #eu-opers -l
-                                   ; User "WiZ" removing the limit for
-                                   the number of users on channel "#eu-
-                                   opers".
-
-   MODE &oulu +b                   ; Command to list ban masks set for
-                                   the channel "&oulu".
-
-   MODE &oulu +b *!*@*             ; Command to prevent all users from
-                                   joining.
-
-   MODE &oulu +b *!*@*.edu +e *!*@*.bu.edu
-                                   ; Command to prevent any user from a
-                                   hostname matching *.edu from joining,
-                                   except if matching *.bu.edu
-
-   MODE #bu +be *!*@*.edu *!*@*.bu.edu
-                                   ; Comment to prevent any user from a
-                                   hostname matching *.edu from joining,
-                                   except if matching *.bu.edu
-
-   MODE #meditation e              ; Command to list exception masks set
-                                   for the channel "#meditation".
-
-   MODE #meditation I              ; Command to list invitations masks
-                                   set for the channel "#meditation".
-
-   MODE !12345ircd O               ; Command to ask who the channel
-                                   creator for "!12345ircd" is
-
-3.2.4 Topic message
-
-      Command: TOPIC
-   Parameters: <channel> [ <topic> ]
-
-   The TOPIC command is used to change or view the topic of a channel.
-   The topic for channel <channel> is returned if there is no <topic>
-   given.  If the <topic> parameter is present, the topic for that
-   channel will be changed, if this action is allowed for the user
-   requesting it.  If the <topic> parameter is an empty string, the
-   topic for that channel will be removed.
-
-
-
-
-
-
-Kalt                         Informational                     [Page 19]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   Numeric Replies:
-
-           ERR_NEEDMOREPARAMS              ERR_NOTONCHANNEL
-           RPL_NOTOPIC                     RPL_TOPIC
-           ERR_CHANOPRIVSNEEDED            ERR_NOCHANMODES
-
-   Examples:
-
-   :WiZ!jto@tolsun.oulu.fi TOPIC #test :New topic ; User Wiz setting the
-                                   topic.
-
-   TOPIC #test :another topic      ; Command to set the topic on #test
-                                   to "another topic".
-
-   TOPIC #test :                   ; Command to clear the topic on
-                                   #test.
-
-   TOPIC #test                     ; Command to check the topic for
-                                   #test.
-
-3.2.5 Names message
-
-      Command: NAMES
-   Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]
-
-   By using the NAMES command, a user can list all nicknames that are
-   visible to him. For more details on what is visible and what is not,
-   see "Internet Relay Chat: Channel Management" [IRC-CHAN].  The
-   <channel> parameter specifies which channel(s) to return information
-   about.  There is no error reply for bad channel names.
-
-   If no <channel> parameter is given, a list of all channels and their
-   occupants is returned.  At the end of this list, a list of users who
-   are visible but either not on any channel or not on a visible channel
-   are listed as being on `channel' "*".
-
-   If the <target> parameter is specified, the request is forwarded to
-   that server which will generate the reply.
-
-   Wildcards are allowed in the <target> parameter.
-
-   Numerics:
-
-           ERR_TOOMANYMATCHES              ERR_NOSUCHSERVER
-           RPL_NAMREPLY                    RPL_ENDOFNAMES
-
-
-
-
-
-
-Kalt                         Informational                     [Page 20]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   Examples:
-
-   NAMES #twilight_zone,#42        ; Command to list visible users on
-                                   #twilight_zone and #42
-
-   NAMES                           ; Command to list all visible
-                                   channels and users
-
-3.2.6 List message
-
-      Command: LIST
-   Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]
-
-   The list command is used to list channels and their topics.  If the
-   <channel> parameter is used, only the status of that channel is
-   displayed.
-
-   If the <target> parameter is specified, the request is forwarded to
-   that server which will generate the reply.
-
-   Wildcards are allowed in the <target> parameter.
-
-   Numeric Replies:
-
-           ERR_TOOMANYMATCHES              ERR_NOSUCHSERVER
-           RPL_LIST                        RPL_LISTEND
-
-   Examples:
-
-   LIST                            ; Command to list all channels.
-
-   LIST #twilight_zone,#42         ; Command to list channels
-                                   #twilight_zone and #42
-
-3.2.7 Invite message
-
-      Command: INVITE
-   Parameters: <nickname> <channel>
-
-   The INVITE command is used to invite a user to a channel.  The
-   parameter <nickname> is the nickname of the person to be invited to
-   the target channel <channel>.  There is no requirement that the
-   channel the target user is being invited to must exist or be a valid
-   channel.  However, if the channel exists, only members of the channel
-   are allowed to invite other users.  When the channel has invite-only
-   flag set, only channel operators may issue INVITE command.
-
-
-
-
-
-Kalt                         Informational                     [Page 21]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   Only the user inviting and the user being invited will receive
-   notification of the invitation.  Other channel members are not
-   notified.  (This is unlike the MODE changes, and is occasionally the
-   source of trouble for users.)
-
-   Numeric Replies:
-
-           ERR_NEEDMOREPARAMS              ERR_NOSUCHNICK
-           ERR_NOTONCHANNEL                ERR_USERONCHANNEL
-           ERR_CHANOPRIVSNEEDED
-           RPL_INVITING                    RPL_AWAY
-
-   Examples:
-
-   :Angel!wings@irc.org INVITE Wiz #Dust
-
-                                   ; Message to WiZ when he has been
-                                   invited by user Angel to channel
-                                   #Dust
-
-   INVITE Wiz #Twilight_Zone       ; Command to invite WiZ to
-                                   #Twilight_zone
-
-3.2.8 Kick command
-
-      Command: KICK
-   Parameters: <channel> *( "," <channel> ) <user> *( "," <user> )
-               [<comment>]
-
-   The KICK command can be used to request the forced removal of a user
-   from a channel.  It causes the <user> to PART from the <channel> by
-   force.  For the message to be syntactically correct, there MUST be
-   either one channel parameter and multiple user parameter, or as many
-   channel parameters as there are user parameters.  If a "comment" is
-   given, this will be sent instead of the default message, the nickname
-   of the user issuing the KICK.
-
-   The server MUST NOT send KICK messages with multiple channels or
-   users to clients.  This is necessarily to maintain backward
-   compatibility with old client software.
-
-   Numeric Replies:
-
-           ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
-           ERR_BADCHANMASK                 ERR_CHANOPRIVSNEEDED
-           ERR_USERNOTINCHANNEL            ERR_NOTONCHANNEL
-
-
-
-
-
-Kalt                         Informational                     [Page 22]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   Examples:
-
-   KICK &Melbourne Matthew         ; Command to kick Matthew from
-                                   &Melbourne
-
-   KICK #Finnish John :Speaking English
-                                   ; Command to kick John from #Finnish
-                                   using "Speaking English" as the
-                                   reason (comment).
-
-   :WiZ!jto@tolsun.oulu.fi KICK #Finnish John
-                                   ; KICK message on channel #Finnish
-                                   from WiZ to remove John from channel
-
-3.3 Sending messages
-
-   The main purpose of the IRC protocol is to provide a base for clients
-   to communicate with each other.  PRIVMSG, NOTICE and SQUERY
-   (described in Section 3.5 on Service Query and Commands) are the only
-   messages available which actually perform delivery of a text message
-   from one client to another - the rest just make it possible and try
-   to ensure it happens in a reliable and structured manner.
-
-3.3.1 Private messages
-
-      Command: PRIVMSG
-   Parameters: <msgtarget> <text to be sent>
-
-   PRIVMSG is used to send private messages between users, as well as to
-   send messages to channels.  <msgtarget> is usually the nickname of
-   the recipient of the message, or a channel name.
-
-   The <msgtarget> parameter may also be a host mask (#<mask>) or server
-   mask ($<mask>).  In both cases the server will only send the PRIVMSG
-   to those who have a server or host matching the mask.  The mask MUST
-   have at least 1 (one) "." in it and no wildcards following the last
-   ".".  This requirement exists to prevent people sending messages to
-   "#*" or "$*", which would broadcast to all users.  Wildcards are the
-   '*' and '?'  characters.  This extension to the PRIVMSG command is
-   only available to operators.
-
-   Numeric Replies:
-
-           ERR_NORECIPIENT                 ERR_NOTEXTTOSEND
-           ERR_CANNOTSENDTOCHAN            ERR_NOTOPLEVEL
-           ERR_WILDTOPLEVEL                ERR_TOOMANYTARGETS
-           ERR_NOSUCHNICK
-           RPL_AWAY
-
-
-
-Kalt                         Informational                     [Page 23]
-
-RFC 2812          Internet Relay Chat: Client Protocol        April 2000
-
-
-   Examples:
-
-   :Angel!wings@irc.org PRIVMSG Wiz :Are you receiving this message ?
-                                   ; Message from Angel to Wiz.
-
-   PRIVMSG Angel :yes I'm receiving it !
-                                   ; Command to send a message to Angel.
-
-   PRIVMSG jto@tolsun.oulu.fi :Hello !
-                                   ; Command to send a message to a user
-                                   on server tolsun.oulu.fi with
-                                   username of "jto".
-
-   PRIVMSG kalt%millennium.stealth.net@irc.stealth.net :Are you a frog?
-                                   ; Message to a user on server
-                                   irc.stealth.net with username of
-                                   "kalt", and connected from the host
-                                   millennium.stealth.net.
-
-   PRIVMSG kalt%millennium.stealth.net :Do you like cheese?
-                                   ; Message to a user on the local
-                                   server with username of "kalt", and
-                                   connected from the host
-                                   millennium.stealth.net.
-
-   PRIVMSG Wiz!jto@tolsun.oulu.fi :Hello !
-                                   ; Message to the user with nickname
-                                   Wiz who is connected from the host
-