+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.atheme.org/specification/capability-negotiation-3.1>
+ - <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
+
+