add ircd

1 files changed, 996 insertions, 0 deletions

diff --git a/ngircd/doc/Commands.txt b/ngircd/doc/Commands.txt
new file mode 100644
index 0000000..0ca8703
--- /dev/null
+++ b/ngircd/doc/Commands.txt
@@ -0,0 +1,996 @@
+
+                     ngIRCd - Next Generation IRC Server
+                           http://ngircd.barton.de/
+
+               (c)2001-2019 Alexander Barton and Contributors.
+               ngIRCd is free software and published under the
+                   terms of the GNU General Public License.
+
+                              -- Commands.txt --
+
+
+This file lists all commands available on ngIRCd. It is written in a format
+that is human readable as well as machine parseable and therefore can be used
+as "help text file" of the daemon.
+
+In short, the daemon reads this file on startup and parses it as following
+when an user issues a "HELP <cmd>" command:
+
+ 1. Search the file for a line "- <cmd>",
+ 2. Output all subsequent lines that start with a TAB (ASCII 9) character
+    to the client using NOTICE commands, treat lines containing a single "."
+    after the TAB as empty lines.
+ 3. Break at the first line not starting with a TAB character.
+
+This format allows to have information to each command stored in this file
+which will not be sent to an IRC user requesting help which enables us to
+have additional annotations stored here which further describe the origin,
+implementation details, or limits of the specific command which are not
+relevant to an end-user but administrators and developers.
+
+A special "Intro" block is returned to the user when the HELP command is
+used without a command name:
+
+
+- Intro
+	This is ngIRCd, a server software for Internet Relay Chat (IRC)
+	networks. You can find more information about ngIRCd on its homepage:
+		<http://ngircd.barton.de>
+	.
+	Use "HELP COMMANDS" to get a list of all available commands and
+	"HELP <command-name>" to get help for a specific IRC command, for
+	example "HELP quit" or "HELP privmsg".
+
+
+Connection Handling Commands
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- CAP
+	CAP LS
+	CAP LIST
+	CAP REQ <capabilities>
+	CAP ACK <capabilities>
+	CAP NAK <capabilities>
+	CAP CLEAR
+	CAP END
+	.
+	List, request, and clear "IRC Capabilities".
+	.
+	Using this command, an IRC client can request additional "IRC
+	capabilities" during login or later on, which influences the
+	communication between server and client. Normally, these commands
+	aren't directly used by humans, but automatically by their client
+	software. And please note that issuing such commands manually can
+	irritate the client software used, because of the "non-standard"
+	behavior of the server!
+	.
+	- CAP LS: list all available capabilities.
+	- CAP LIST: list active capabilities of this connection.
+	- CAP REQ: Request particular capabilities.
+	- CAP ACK: Acknowledge a set of capabilities to be enabled/disabled.
+	- CAP NAK: Reject a set of capabilities.
+	- CAP CLEAR: Clear all set capabilities.
+	- CAP END: Indicate end of capability negotiation during login,
+	  ignored in an fully registered session.
+
+	Please note that the <capabilities> must be given in a single
+	parameter but whitespace separated, therefore a command could look
+	like this: "CAP REQ :capability1 capability2 capability3" for example.
+
+	References:
+	 - <http://ircv3.net/specs/core/capability-negotiation-3.1.html>
+	 - <http://ngircd.barton.de/doc/Capabilities.txt>
+	 - doc/Capabilities.txt
+
+- CHARCONV
+	CHARCONV <client-charset>
+	.
+	Set client character set encoding to <client-charset>.
+	.
+	After receiving such a command, the server translates all message
+	data received from the client using the set <client-charset> to the
+	server encoding (UTF-8), and all message data which is to be sent to
+	the client from the server encoding (UTF-8) to <client-charset>.
+	.
+	This enables older clients and clients using "strange" character sets
+	to transparently participate in channels and direct messages to
+	clients using UTF-8, which should be the default today.
+
+	References:
+	 - IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
+	 - IRC+, doc/Protocol.txt
+
+- NICK
+	NICK <nickname>
+	NICK <nickname> [<hops>]
+	NICK <nickname> <hops> <username> <host> <servertoken> <usermodes> <realname>
+	.
+	Set or change the <nickname> of a client (first form) and register
+	remote clients (second and third form; servers only).
+
+	References:
+	 - RFC 1459, 4.1.2 "Nick message" (old client and server protocol)
+	 - RFC 2812, 3.1.2 "Nick message" (client protocol)
+	 - RFC 2813, 4.1.3 "Nick" (server protocol)
+
+- PASS
+	PASS <password>
+	PASS <password> <version> <flags> [<options>]
+	.
+	Set a connection <password>. This command must be the first command
+	sent to the server, even before the NICK/USER or SERVER commands.
+	.
+	The first form is used by user sessions or (old) RFC 1459 servers,
+	the second form is used by RFC 2812 or IRC+ compliant servers and
+	enables the server to indicate its version and supported protocol
+	features.
+
+	References:
+	 - RFC 1459, 4.1.1 "Password message" (old client and server protocol)
+	 - RFC 2812, 3.1.1 "Password message" (client protocol)
+	 - RFC 2813, 4.1.1 "Password message" (server protocol)
+	 - IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
+	 - IRC+, doc/Protocol.txt
+
+- PING
+	PING <token> [<target>]
+	.
+	Tests the presence of a connection to a client or server.
+	.
+	If no <target> has been given, the local server is used. User clients
+	can only use other servers as <target>, no user clients.
+	.
+	A PING message results in a PONG reply containing the <token>, which
+	can be arbitrary text.
+
+	Please note:
+	The RFCs state that the <token> parameter is used to specify the
+	origin of the PING command when forwarded in the network, but this
+	is not the case: the sender is specified using the prefix as usual,
+	and the parameter is used to identify the PONG reply in practice.
+
+	References:
+	 - RFC 2812, 3.7.2 "Ping message"
+
+- PONG
+	PONG <target> [<token>]
+	.
+	Reply to a "PING" command, indicate that the connection is alive.
+	.
+	The <token> is the arbitrary text received in the "PING" command and
+	can be used to identify the correct PONG sent as answer.
+	.
+	When the "PONG" command is received from a user session, the <target>
+	parameter is ignored; otherwise the PONG is forwarded to this client.
+
+	References:
+	 - RFC 2812, 3.7.3 "Pong message"
+
+- QUIT
+	QUIT [<quit-message>]
+	.
+	Terminate a user session.
+	.
+	When received from a user, the server acknowledges this by sending
+	an "ERROR" message back to the client and terminates the connection.
+	.
+	When a <quit-message> has been given, it is sent to all the channels
+	that the client is a member of when leaving.
+
+	References:
+	 - RFC 2812, 3.1.7 "Quit"
+	 - RFC 2813, 4.1.5 "Quit"
+
+- USER
+	USER <username> <hostname> <unused> <realname>
+	.
+	Register (and authenticate) a new user session with a short <username>
+	and a human-readable <realname>.
+	.
+	The parameter <hostname> is only used when received by an other server
+	and ignored otherwise; and the parameter <unused> is always ignored.
+	But both parameters are required on each invocation by the protocol
+	and can be set to arbitrary characters/text when not used.
+	.
+	If <username> contains an "@" character, the full <username> is used
+	for authentication, but only the first part up to this character is
+	set as "user name" for this session.
+
+	References:
+	 - RFC 2812, 3.1.3 "User message"
+
+- WEBIRC
+	WEBIRC <password> <username> <hostname> <ip-address>
+	.
+	Allow Web-to-IRC gateway software (for example) to set the correct
+	user name and host name of users instead of their own.
+	.
+	It must be the very first command sent to the server, even before
+	USER and NICK commands!
+	.
+	The <password> must be set in the server configuration file to prevent
+	unauthorized clients to fake their identity; it is an arbitrary string.
+
+	References:
+	 - IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
+	 - IRC+, doc/Protocol.txt
+
+
+General Commands
+~~~~~~~~~~~~~~~~
+
+- AWAY
+	AWAY [<message>]
+	.
+	Provides the server with a message to automatically send in reply to a
+	PRIVMSG directed at the user, but not to a channel they are on.
+	.
+	If <message> is omitted, the away status is removed.
+
+	References:
+	 - RFC 2812, 4.1 "Away"
+
+- HELP
+	HELP [<command>]
+	.
+	Show help information for a specific IRC <command>. The <command> name
+	is case-insensitive.
+	.
+	Use the command "HELP Commands" to get a list of all available commands.
+
+	The HELP command isn't specified by any RFC but implemented by most
+	daemons. If no help text could be read in, ngIRCd outputs a list of all
+	implemented commands when receiving a plain "HELP" command as well as
+	on "HELP Commands".
+
+	ngIRCd replies using "NOTICE" commands like ircd 2.10/2.11; other
+	implementations are using numerics 704, 705, and 706.
+
+- MODE
+	MODE <nickname> [{+|-}<mode>[<mode>] [{+|-}<mode>[<mode>] [...]]]
+	MODE <channel> [{+|-}<mode>[<mode>] [<arg> [<arg> [...]]] [{+|-}<mode>[<mode>] [<arg> [<arg> [...]]] [...]]]
+	.
+	Set and get user and channel modes.
+	.
+	When no mode parameters are given, the currently set user or channel
+	modes are returned. Otherwise the modes are adjusted accordingly
+	and the changes will be reported back to the client.
+	.
+	All user and channel "modes" are indicated by single case-sensitive
+	characters.
+	.
+	Please note that a user can only get and set his own modes, and not
+	all user "levels" are allowed to change all channel modes ...
+	.
+	The mode parameters can become quite complex, especially when dealing
+	with channel modes that require additional arguments:
+	.
+	  {+|-}<mode(s}>  -- set or unset one or more modes.
+	  +<mode(s)> -<mode(s)>  -- set some modes and unset others.
+	  +<modes> <arg1> <arg2>  -- set (at least) two modes with arguments.
+	.
+	Some examples:
+	.
+	  MODE nick +i  -- set user to "invisible".
+	  MODE #chan +tn  -- set "topic lock" and "no external messages".
+	  MODE #chan -t +l 50  -- remove "topic lock", set "user limit" to 50.
+	  MODE #chan +ov nick1 nick2  -- set "channel op" and "voice" mode
+	                                 to nick1 and nick2 in channel #chan.
+	.
+	A complete list of all modes supported by ngIRCd can be found online
+	here: <http://ngircd.barton.de/doc/Modes.txt>.
+
+	References:
+	 - RFC 2811, 4. "Channel Modes"
+	 - RFC 2812, 3.1.5 "User mode message"
+	 - RFC 2812, 3.2.3 "Channel mode message"
+	 - <http://ngircd.barton.de/doc/Modes.txt>
+	 - doc/Modes.txt
+
+- NOTICE
+	NOTICE <target>[,<target>[,...]] <message>
+	.
+	Send a <message> to a given <target>, which can be a user or a
+	channel, but DON'T report any error.
+	.
+	The "NOTICE" command exactly behaves like the "PRIVMSG" command, but
+	doesn't report any errors it encounters (like an unknown <target>).
+	Please see the help text of the "PRIVMSG" command for a detailed
+	description of the parameters!
+
+	References:
+	 - RFC 2812, 2.3.1 "Message format in Augmented BNF"
+	 - RFC 2812, 3.3 "Sending messages"
+	 - RFC 2812, 3.3.2 "Notice"
+
+- PRIVMSG
+	PRIVMSG <target>[,<target>[,...]] <message>
+	.
+	Send a <message> to a given <target>, which can be a user or a
+	channel, and report all errors.
+	.
+	The <target> must follow one of these syntax variants:
+	.
+	 - <nickname>
+	 - <channel>
+	 - <user>[%<host>]@<server>
+	 - <user>%<host>
+	 - <nickname>!<user>@<host>
+	.
+	If the <target> is a user, a private message is sent directly to this
+	user; if it resolves to a channel name, a public message is sent
+	to all the members of that channel.
+	.
+	In addition, IRC Ops can use these two forms to specify the <target>:
+	.
+	 - #<hostmask>
+	 - $<servermask>
+	.
+	The <mask> can contain the wildcard characters "*" and "?", but must
+	contain at least one dot (".") and no wildcard after the last one.
+	Then, the <message> is sent to all users matching this <mask>.
+	.
+	All warnings and errors are reported back to the initiator using
+	numeric status codes, which is the only difference to the "NOTICE"
+	command, which doesn't report back any errors or warnings at all.
+	.
+	Please note that clients often use "MSG" as an alias to PRIVMSG, and
+	a command "QUERY <nick> [<message>]" to initiate private chats. Both
+	are command extensions of the client and never sent to the server.
+
+	References:
+	 - RFC 2812, 2.3.1 "Message format in Augmented BNF"
+	 - RFC 2812, 3.3 "Sending messages"
+	 - RFC 2812, 3.3.1 "Private messages"
+
+Status and Informational Commands
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- ADMIN
+	ADMIN [<target>]
+	.
+	Show administrative information about an IRC server in the network.
+	.
+	<target> can be a server name, the nickname of a client connected to
+	a specific server, or a mask matching a server name in the network.
+	The server of the current connection is used when <target> is omitted.
+
+	References:
+	 - RFC 2812, 3.4.9 "Admin command"
+
+- INFO
+	INFO [<target>]
+	.
+	Show the version, birth & online time of an IRC server in the network.
+	.
+	<target> can be a server name, the nickname of a client connected to
+	a specific server, or a mask matching a server name in the network.
+	The server of the current connection is used when <target> is omitted.
+
+	References:
+	 - RFC 2812, 3.4.10 "Info command"
+
+- ISON
+	ISON <nickname> [<nickname> [...]]
+	.
+	Query online status of a list of nicknames. The server replies with
+	a list only containing nicknames actually connected to a server in
+	the network. If no nicknames of the given list are online, an empty
+	list is returned to the client requesting the information.
+
+	Please note that "all" IRC daemons even parse separate nicknames in
+	a single parameter (like ":nick1 nick2"), and therefore ngIRCd
+	implements this behavior, too.
+
+	References:
+	 - RFC 2812, 4.9 "Ison message"
+
+- LINKS
+	LINKS [[<target>] <mask>]
+	.
+	List all servers currently registered in the network matching <mask>,
+	or all servers if <mask> has been omitted, as seen by the server
+	specified by <target> or the local server when <target> is omitted.
+	.
+	<target> can be a server name, the nickname of a client connected to
+	a specific server, or a mask matching a server name in the network.
+
+	References:
+	 - RFC 2812, 3.4.5 "Links message"
+
+- LUSERS
+	LUSERS [<mask> [<target>]]
+	.
+	Return statistics about the number of clients (users, servers,
+	services, ...) in the network as seen by the server <target>.
+	.
+	<target> can be a server name, the nickname of a client connected to
+	a specific server, or a mask matching a server name in the network.
+	The server of the current connection is used when <target> is omitted.
+
+	Please note that ngIRCd ignores the <mask> parameter entirely: it
+	is not possible to get information for a part of the network only.
+
+	References:
+	 - RFC 2812, 3.4.2 "Lusers message"
+
+- MOTD
+	MOTD [<target>]
+	.
+	Show the "Message of the Day" (MOTD) of an IRC server in the network.
+	.
+	<target> can be a server name, the nickname of a client connected to
+	a specific server, or a mask matching a server name in the network.
+	The server of the current connection is used when <target> is omitted.
+
+	References:
+	 - RFC 2812, 3.4.1 "Motd message"
+
+- NAMES
+	NAMES [<channel>[,<channel>[,...]] [<target>]]
+	.
+	Show the list of users that are members of a particular <channel>
+	(and that are visible for the client requesting this information) as
+	seen by the server <target>. More than one <channel> can be given
+	separated by "," (but not whitespaces!).
+	.
+	If <channel> has been omitted, all visible users are shown, grouped
+	by channel name, and all visible users not being members of at least
+	one channel are shown as members of the pseudo channel "*".
+	.
+	<target> can be a server name, the nickname of a client connected to
+	a specific server, or a mask matching a server name in the network.
+	The server of the current connection is used when <target> is omitted.
+
+	References:
+	 - RFC 2812, 3.2.5 "Names message"
+
+- STATS
+	STATS [<query> [<target>]]
+	.
+	Show statistics and other information of type <query> of a particular
+	IRC server in the network.
+	.
+	The following <query> types are supported (case-insensitive where
+	applicable):
+	.
+	 - g  Network-wide bans ("G-Lines").
+	 - k  Server-local bans ("K-Lines").
+	 - L  Link status (servers and user links).
+	 - l  Link status (servers and own link).
+	 - m  Command usage count.
+	 - u  Server uptime.
+	.
+	<target> can be a server name, the nickname of a client connected to
+	a specific server, or a mask matching a server name in the network.
+	The server of the current connection is used when <target> is omitted.
+	.
+	To use "STATS L" the user must be an IRC Operator.
+
+	References:
+	 - RFC 2812, 3.4.4 "Stats message"
+
+- TIME
+	TIME [<target>]
+	.
+	Show the local time of an IRC server in the network.
+	.
+	<target> can be a server name, the nickname of a client connected to
+	a specific server, or a mask matching a server name in the network.
+	The server of the current connection is used when <target> is omitted.
+
+	References
+	 - RFC 2812, 3.4.6 "Time message"
+
+- TRACE
+	TRACE [<target>]
+	.
+	Find the route to a specific server and send information about its
+	peers. Each server that processes this command reports back to the
+	sender about it: the replies from pass-through servers form a chain
+	which shows the route to the destination.
+	.
+	<target> can be a server name, the nickname of a client connected to
+	a specific server, or a mask matching a server name in the network.
+	The server of the current connection is used when <target> is omitted.
+
+	References:
+	 - RFC 2812, 3.4.8 "Trace message"
+
+- USERHOST
+	USERHOST <nickname> [<nickname> [...]]
+	.
+	Show flags and the hostmasks (<user>@<host>) of the <nickname>s,
+	separated by spaces. The following flags are used:
+	.
+	 - "-"  The client is "away" (the mode "+a" is set on this client).
+	 - "+"  Client seems to be available, at least it isn't marked "away".
+	 - "*"  The client is an IRC operator (the mode "+o" is set).
+
+	References:
+	 - RFC 2812, 4.8 "Userhost message"
+
+- VERSION
+	VERSION [<target>]
+	.
+	Show version information about a particular IRC server in the network.
+	.
+	<target> can be a server name, the nickname of a client connected to
+	a specific server, or a mask matching a server name in the network.
+	The server of the current connection is used when <target> is omitted.
+	.
+	Please note: in normal operation, the version number ends in a dot
+	(".", for example "ngIRCd-20.1."). If it ends in ".1" (for example
+	"ngIRCd-20.1.1", same version than before!), the server is running in
+	debug-mode; and if it ends in ".2", the "network sniffer" is active!
+	Keep your privacy in mind ...
+
+	References:
+	 - RFC 2812, 3.4.3 "Version message"
+
+- WHO
+	WHO [<mask> ["o"]]
+	.
+	Show a list of users who match the <mask>, or all visible users when
+	the <mask> has been omitted. (Special case: the <mask> "0" is
+	equivalent to "*")
+	.
+	If the flag "o" is given, the server will only return information about
+	IRC Operators.
+
+	References:
+	 - RFC 2812, 3.6.1 "Who query"
+
+- WHOIS
+	WHOIS [<target>] <mask>[,<mask>[,...]]
+	.
+	Query information about users matching the <mask> parameter(s) as seen
+	by the server <target>; up to 3 <masks> are supported.
+	.
+	<target> can be a server name, the nickname of a client connected to a
+	specific server, or a mask matching a server name in the network. The
+	server of the current connection is used when <target> is omitted.
+
+	References:
+	 - RFC 2812, 3.6.2 "Whois query"
+
+- WHOWAS
+	WHOWAS <nickname>[,<nickname>[,...]] [<count> [<target>]]
+	.
+	Query information about nicknames no longer in use in the network,
+	either because of nickname changes or disconnects. The history is
+	searched backwards, returning the most recent entry first. If there
+	are multiple entries, up to <count> entries will be shown (or all of
+	them, if no <count> has been given).
+	.
+	<target> can be a server name, the nickname of a client connected to a
+	specific server, or a mask matching a server name in the network. The
+	server of the current connection is used when <target> is omitted.
+
+	References:
+	 - RFC 2812, 3.6.3 "Whowas"
+
+
+Channel Commands
+~~~~~~~~~~~~~~~~
+
+- INVITE
+	INVITE <nickname> <channel>
+	.
+	Invite <nickname> to join channel <channel>.
+	.
+	<channel> does not have to exist, but if it does, only members of the
+	channel are allowed to invite other users. If the channel mode "+i"
+	is set, only channel "half-ops" (and above) may invite other clients,
+	and if channel mode "+V" is set, nobody can invite other users.
+
+	References:
+	 - RFC 2812, 3.2.7 "Invite message"
+
+- JOIN
+	JOIN {<channel>[,<channel>[,...]] [<key>[,<key>[,...]]] | 0}
+	.
+	Makes the client join the <channel> (comma-separated list), specifying
+	the channel keys ("passwords"). A <channel-key> is only needed if the
+	<channel> has the mode "+k" set.
+	.
+	If the channel(s) do not exist, then they will be created.
+	.
+	Using "JOIN 0" parts all channels at once.
+
+	References:
+	 - RFC 2812, 3.2.1 "Join message" (client protocol)
+	 - RFC 2813, 4.2.1 "Join message" (server protocol)
+
+- KICK
+	KICK <channel>[,<channel>[,...]] <nickname>[,<nickname>[,...]] [<reason>]
+	.
+	Remove users(s) with <nickname>(s) from <channel>(s).
+	.
+	There must be either exactly one <channel> parameter and multiple
+	<nickname> parameters, or as many <channel> parameters as there are
+	<nickname> parameters. The <reason> is shown to the users being
+	kicked, and the nickname of the current user is used when <reason>
+	is omitted.
+
+	References:
+	 - RFC 2812, 3.2.8 "Kick command"
+
+- LIST
+	LIST [<mask>[,<mask>[,...]] [<server>]]
+	.
+	List all visible channels matching the <mask> (comma-separated list),
+	or all channels when no <mask> was specified.
+	.
+	If <server> is given, the command will be forwarded to <server> for
+	evaluation.
+
+	References:
+	 - RFC 2812, 3.2.6 "List message"
+
+- PART
+	PART <channel>[,<channel>[,...]] [<part-message>]
+	.
+	Leave <channel> (comma-separated list), optionally with sending a
+	<part-message> to all the other channel members.
+
+	References:
+	 - RFC 2812, 3.2.2 "Part message"
+
+- TOPIC
+	TOPIC <channel> [<topic>]
+	.
+	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.
+
+	References:
+	 - RFC 2812, 3.2.4 "Topic message"
+
+
+Administrative Commands
+~~~~~~~~~~~~~~~~~~~~~~~
+
+- CONNECT
+	CONNECT <server> [<port> [<remote-server> [<my-pwd> <peer-pwd>]]]
+	.
+	Instructs the current server, or <remote-server> if specified,
+	to connect to the server named <server>, which must be configured
+	in the server configuration file.
+	.
+	To use this command, the user must be an IRC Operator. To establish
+	a connection on a <remote-server>, you must have remote IRC operator
+	privileges.
+	.
+	If <port>, <my-pwd> and <peer-pwd> are given, these values override
+	the ones specified in the server configuration file.
+
+	References:
+	 - RFC 2812, 3.4.7 "Connect message"
+
+- DIE
+	DIE [<message>]
+	.
+	Instructs the server to shut down.
+	.
+	The optional (and non-standard) <message> text is sent to each client
+	connected to this server before all connections are closed.
+	.
+	To use this command, the user must be an IRC Operator.
+
+	References:
+	 - RFC 2812, 4.3 "Die message"
+
+- DISCONNECT
+	DISCONNECT <server>
+	.
+	Disconnect and disable a locally linked server.
+	.
+	To use this command, the user must be an IRC Operator.
+
+	References:
+	 - This command is not specified in the IRC RFCs, it is an extension
+	   of ngIRCd.
+
+- GLINE
+	GLINE <nick!user@hostmask> [<timeout> :<reason>]
+	.
+	This command provides timed G-Lines (network-wide bans).
+	.
+	If a client matches a G-Line, it cannot connect to any server on
+	the IRC network for <timeout> seconds. When <timeout> is 0, it make
+	the G-Line permanent.
+	.
+	If no <timeout> and no <reason> is given, the G-Line is removed.
+	.
+	To use this command, the user must be an IRC Operator.
+	.
+	"STATS g" can be used to list all currently active G-Lines.
+
+	References:
+	 - This command is not specified in the IRC RFCs, it is an extension
+	   of ngIRCd.
+
+- KILL
+	KILL <nickname> <reason>
+	.
+	Forcibly remove all users with a given <nickname> from the IRC
+	network and display the given <reason> to them.
+	.
+	This command is used internally between servers, too, for example
+	to disconnect duplicate <nickname>'s after a "net split".
+	.
+	To use this command, the user must be an IRC Operator.
+
+	References:
+	 - RFC 2812, 3.7.1 "Kill message"
+
+- KLINE
+	KLINE <nick!user@hostmask> [<timeout> :<reason>]
+	.
+	This command provides timed K-Lines (server-local bans).
+	.
+	If a client matches a K-Line, it cannot connect to this server for
+	<timeout> seconds. When <timeout> is 0, it makes the K-Line permanent.
+	.
+	If no <timeout> and no <reason> is given, the K-Line is removed.
+	.
+	To use this command, the user must be an IRC Operator.
+	.
+	"STATS k" can be used to list all currently active K-Lines.
+
+	References:
+	 - This command is not specified in the IRC RFCs, it is an extension
+	   of ngIRCd.
+
+- OPER
+	OPER <name> <password>
+	.
+	Authenticates a user named <name> as an IRC operator on the current
+	server/network.
+	.
+	This operator <name> must be configured in the server configuration.
+	.
+	Please note that <name> is NOT related to a nickname at all!
+
+	References:
+	 - RFC 2812, 3.1.4 "Oper message"
+
+- REHASH
+	REHASH
+	.
+	Causes the server to re-read and re-process its configuration file(s).
+	.
+	While rehashing, no new connections are accepted, but all already
+	established connections stay connected.
+	.
+	To use this command, the user must be an IRC Operator.
+
+	References:
+	 - RFC 2812, 4.2 "Rehash message"
+
+- RESTART
+	RESTART
+	.
+	Restart the server.
+	.
+	While restarting, all connections are reset and no new connections
+	are accepted.
+	.
+	To use this command, the user must be an IRC Operator.
+
+	References:
+	 - RFC 2812, 4.4 "Restart message"
+
+- WALLOPS
+	WALLOPS <message>
+	.
+	Sends <message> to all users with user mode "+w".
+	.
+	To use this command, the user must be an IRC Operator.
+
+	References:
+	 - RFC 2812, 4.7 "Operwall message"
+
+IRC Service Commands
+~~~~~~~~~~~~~~~~~~~~
+
+- SERVICE
+	SERVICE <name> <reserved1> <distribution> <type> <reserved2> <info>
+	SERVICE <name> <servertoken> <distribution> {<type>|+<modes>} <hops> <info>
+	.
+	Register a new service in the network.
+	.
+	The first form is used by directly linked services and isn't supported
+	by ngIRCd at the moment. The second form announces services connected
+	to remote "pseudo-servers" ("services hubs").
+	.
+	The <distribution> and <type> parameters are ignored by ngIRCd.
+
+	References:
+	 - RFC 2812, 3.1.6 "Service message"
+	 - RFC 2813, 4.1.4 "Service message"
+
+- SERVLIST
+	SERVLIST [<mask> [<type>]]
+	.
+	List all IRC services currently registered in the network.
+	.
+	The optional <mask> and <type> parameters can be used to limit the
+	listing to services matching the <mask> and that are of type <type>.
+	.
+	Please note that ngIRCd doesn't use any service types at the moment
+	and therefore all services are of type "0".
+
+	References:
+	 - RFC 2812, 3.5.1 "Servlist message"
+
+- SQUERY
+	SQUERY <target>[,<target>[,...]] <message>
+	.
+	Send a <message> to a given <target> IRC service, and report all
+	errors.
+	.
+	The "SQUERY" command exactly behaves like the "PRIVMSG" command, but
+	enforces that the <target> of the <message> is an IRC service.
+	Please see the help text of the "PRIVMSG" command for a detailed
+	description of the parameters!
+	.
+	If a user wants to interact with IRC services, he should use "SQUERY"
+	instead of "PRIVMSG" or "NOTICE": only "SQUERY makes sure that no
+	regular user, which uses the nickname of an IRC service, receives
+	the command in error, for example during a "net split"!
+
+	References:
+	 - RFC 2812, 2.3.1 "Message format in Augmented BNF"
+	 - RFC 2812, 3.3 "Sending messages"
+	 - RFC 2812, 3.3.2 "Notice"
+
+- SVSNICK
+	SVSNICK <oldnick> <newnick>
+	.
+	Forcefully change foreign user nicknames. This command is allowed
+	for servers only.
+	.
+	The "SVSNICK" command is forwarded to the server to which the user
+	with nickname <oldnick> is connected to, which in turn generates a
+	regular "NICK" command that then is sent to the client, so no special
+	support in the client software is required.
+
+	References:
+	 - ngIRCd GIT commit e3f300d3231f
+
+
+Server Protocol Commands
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+- CHANINFO
+	CHANINFO <channel> +<modes> [[<key> <limit>] <topic>]
+	.
+	CHANINFO is used by servers to inform each other about a channel:
+	its modes, channel key, user limits and its topic.
+	.
+	Note: even when <modes> don't include "k" (key) or "l" (limit), both
+	parameters must be given when used; use "*" for "no key" and 0 for
+	"no limit" for the unused parameter in this case.
+	.
+	The CHANINFO command is allowed on server-links only.
+
+	References:
+	 - IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
+	 - IRC+, doc/Protocol.txt
+
+- ERROR
+	ERROR [<message> [<> [...]]]
+	.
+	Inform a client or a server about an error condition. The first
+	parameter, if given, is logged by the server receiving the message,
+	all other parameters are silently ignored.
+	.
+	This command is silently ignored on non-server and non-service links
+	and shouldn't be used by regular IRC clients.
+	.
+	The ERROR message is also sent before terminating a regular client
+	connection.
+
+	References:
+	 - RFC 2812, 3.7.4 "Error message"
+
+- METADATA
+	METADATA <target> <key> <value>
+	.
+	The METADATA command is used on server-links to update "metadata"
+	information of clients, like the hostname, the info text ("real name"),
+	or the user name.
+	.
+	The METADATA command is allowed on server-links only.
+
+	References:
+	 - IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
+	 - IRC+, doc/Protocol.txt
+
+- NJOIN
+	NJOIN <channel> [<mode>]<nick>[,[<mode>]<nick>[,...]]
+	.
+	The NJOIN command is used on server-links to add users with <nick>
+	and <mode> to a <channel> while peering.
+	.
+	The NJOIN command is allowed on server-links only.
+
+	References:
+	 - RFC 2813, 4.2.2 "Njoin message"
+
+- SERVER
+	SERVER <servername> <info>
+	SERVER <servername> <hopcount> <info>
+	SERVER <servername> <hopcount> <token> <info>
+	.
+	The first form registers the local connection as a new server in the
+	network, the second (RFC 1459) and third (RFC 2812) form announce a
+	new remote server in the network.
+	.
+	The SERVER command is allowed on unregistered or server-links only.
+
+	References:
+	 - RFC 1459, 4.1.4 "Server message"
+	 - RFC 2813, 4.1.2 "Server message"
+
+- SQUIT
+	SQUIT <server> <comment>
+	.
+	Disconnects an IRC Server from the network.
+	.
+	This command is used on server-links, but can be used by IRC Operators
+	to forcefully disconnect servers from the network, too.
+
+	References:
+	 - RFC 2812, 3.1.8 "Squit"
+	 - RFC 2813, 4.1.6 "Server quit message"
+
+Dummy Commands
+~~~~~~~~~~~~~~
+
+- SUMMON
+	SUMMON <user> [<target> [<channel>]]
+	.
+	This command was intended to call people into IRC who are directly
+	connected to the terminal console of the IRC server -- but is
+	deprecated today. Therefore ngIRCd doesn't really implement this
+	command and always returns an error message, regardless of the
+	parameters given.
+
+	References:
+	 - RFC 2812, 4.5 "Summon message"
+
+- USERS
+	USERS [<target>]
+	.
+	This command was intended to list users directly logged in into the
+	console of the IRC server -- but is deprecated today. Therefore ngIRCd
+	doesn't really implement this command and always returns an error
+	message, regardless of the parameters given.
+
+	References:
+	 - RFC 2812, 4.6 "Users"
+
+- GET
+	GET [...]
+	.
+	Fake HTTP GET command. When received, the connection is shut down
+	immediately again to protect against crazy web browsers ...
+
+	References:
+	 - ngIRCd GIT commit 33e8c2480649
+
+- POST
+	POST [...]
+	.
+	Fake HTTP POST command. When received, the connection is shut down
+	immediately again to protect against crazy web browsers ...
+
+	References:
+	 - ngIRCd GIT commit 33e8c2480649