~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- CAP
- See doc/Capabilities.txt
+ 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
- See doc/Protocol.txt
+ 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:
+ - <http://ngircd.barton.de/doc/Protocol.txt>
+ - doc/Protocol.txt
- NICK
NICK <nick>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- ADMIN
- ADMIN [<server>]
+ ADMIN [<target>]
.
Show administrative information about an IRC server in the network.
- If no server name has been given, the local server will respond.
+ .
+ <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 connecion is used when <target> is omitted.
+
+ References:
+ - RFC 2812, 3.4.9 "Admin command"
- INFO
- INFO [<server>]
+ INFO [<target>]
+ .
+ Show the version, birth & online time of an IRC server in the network.
.
- Show the version, birth & online time of the current IRC server.
- If <server> has been given, it shows the INFO of the specific <server>.
+ <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 connecion is used when <target> is omitted.
+
+ References:
+ - RFC 2812, 3.4.10 "Info command"
- ISON
- ISON <nicknames>
+ ISON <nickname> [<nickname> [...]]
.
- Queries the server to see if the clients in the space-separated list
- <nicknames> are currently on the network.
- .
- The server returns only the <nicknames> that are on the network in a
- space-separated list. If none of the clients are on the network the
- server returns an empty list.
+ Query online status of a list of nicknames. The server replies with
+ a list only containing nicknes 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 behaviour, too.
+
+ References:
+ - RFC 2812, 4.9 "Ison message"
- LINKS
LINKS [<remote server> [<server mask>]]