Commands.txt: Update more descriptions

[ngircd-alex.git] / doc / Commands.txt

diff --git a/doc/Commands.txt b/doc/Commands.txt
index 642dfb0b09db8a360b7627090396f3475217f00c..7765d3a440cc6fe4431081b10b34120d426defa8 100644 (file)
--- a/doc/Commands.txt
+++ b/doc/Commands.txt
@@ -101,49 +101,117 @@ Connection Handling Commands
         - doc/Protocol.txt
 
 - NICK
         - doc/Protocol.txt
 
 - NICK

-       NICK <nick>
+       NICK <nickname>
+       NICK <nickname> [<hops>]
+       NICK <nickname> <hops> <username> <host> <servertoken> <usermodes> <realname>

        .
        .

-       Change your nickname to <nick>.
+       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

+       PASS <password>

        PASS <password> <version> <flags> [<options>]
        .
        PASS <password> <version> <flags> [<options>]
        .

-       Set a connection <password>. This command must be sent before the
-       NICK/USER registration combination.
+       Set a connection <password>. This command must be the first command
+       sent to the server, even before the NICK/USER or SERVER commands.

        .
        .

-       See doc/Protocol.txt for more info.
+       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)
+        - doc/Protocol.txt

 
 - PING
 
 - PING

-       PING <server1> [<server2>]
+       PING <token> [<target>]
+       .
+       Tests the presence of a connection to a client or server.

        .
        .

-       Tests the presence of a connection. A PING message results in a PONG
-       reply. If <server2> is specified, the message gets passed on to it.
+       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 forwared 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

-       PONG <server1> [<server2>]
+       PONG <target> [<token>]
+       .
+       Reply to a "PING" command, indicate that the connection is alive.

        .
        .

-       This command is a reply to the PING command and works in much the
-       same way.
+       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>]
        .
 
 - QUIT
        QUIT [<quit-message>]
        .

-       End IRC session and disconnect from the server.
+       Terminate a user session.

        .
        .

-       If a <quit-message> has been given, it is displayed to all the
-       channels that you are a member of when leaving.
+       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

-       USER <user> <modes> <realname>
+       USER <username> <hostname> <unused> <realname>

        .
        .

-       This command is used at the beginning of a connection to specify the
-       <user>name, hostname, <realname> and initial user <modes> of the
-       connecting client.
+       Register (and authenticate) a new user session with a short <username>
+       and a human-readable <realname>.

        .
        .

-       <realname> may contain spaces, and thus must be prefixed with a colon.
+       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

-       See doc/Protocol.txt
+       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:
+        - doc/Protocol.txt, II.4: "Update webchat/proxy client information"

 
 
 General Commands
 
 
 General Commands


@@ -184,21 +252,60 @@ General Commands
        See doc/Modes.txt for more information.
 
 - NOTICE
        See doc/Modes.txt for more information.
 
 - NOTICE

-       NOTICE <target> <notice>
+       NOTICE <target>[,<target>[,...]] <message>

        .
        .

-       Send <notice> to <target> (nick or channel).
+       Send a <message> to a given <target>, which can be a user or a
+       channel, but DON'T report any error.

        .
        .

-       This command works similarly to PRIVMSG, except automatic replies must
-       never be sent in reply to NOTICE messages.
+       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

-       PRIVMSG <target> <message>
+       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>

        .
        .

-       Send <message> to <target> (nick or channel).
+       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>.

        .
        .

-       Common IRC clients use MSG as PRIVMSG alias.
-       (Some clients use "QUERY <nick> [<message>]" to open a private chat.)
+       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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Status and Informational Commands
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


@@ -210,7 +317,7 @@ Status and Informational Commands
        .
        <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.
        .
        <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.
+       The server of the current connection is used when <target> is omitted.

 
        References:
         - RFC 2812, 3.4.9 "Admin command"
 
        References:
         - RFC 2812, 3.4.9 "Admin command"


@@ -222,7 +329,7 @@ Status and Informational Commands
        .
        <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.
        .
        <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.
+       The server of the current connection is used when <target> is omitted.

 
        References:
         - RFC 2812, 3.4.10 "Info command"
 
        References:
         - RFC 2812, 3.4.10 "Info command"


@@ -231,7 +338,7 @@ Status and Informational Commands
        ISON <nickname> [<nickname> [...]]
        .
        Query online status of a list of nicknames. The server replies with
        ISON <nickname> [<nickname> [...]]
        .
        Query online status of a list of nicknames. The server replies with

-       a list only containing nicknes actually connected to a server in
+       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.
 
        the network. If no nicknames of the given list are online, an empty
        list is returned to the client requesting the information.
 


@@ -263,7 +370,7 @@ Status and Informational Commands
        .
        <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.
        .
        <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.
+       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.
 
        Please note that ngIRCd ignores the <mask> parameter entirely: it
        is not possible to get information for a part of the network only.


@@ -278,7 +385,7 @@ Status and Informational Commands
        .
        <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.
        .
        <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.
+       The server of the current connection is used when <target> is omitted.

 
        References:
         - RFC 2812, 3.4.1 "Motd message"
 
        References:
         - RFC 2812, 3.4.1 "Motd message"


@@ -297,7 +404,7 @@ Status and Informational Commands
        .
        <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.
        .
        <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.
+       The server of the current connection is used when <target> is omitted.

 
        References:
         - RFC 2812, 3.2.5 "Names message"
 
        References:
         - RFC 2812, 3.2.5 "Names message"


@@ -318,7 +425,7 @@ Status and Informational Commands
        .
        <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.
        .
        <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.
+       The server of the current connection is used when <target> is omitted.

 
        References:
         - RFC 2812, 3.4.4 "Stats message"
 
        References:
         - RFC 2812, 3.4.4 "Stats message"


@@ -330,7 +437,7 @@ Status and Informational Commands
        .
        <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.
        .
        <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.
+       The server of the current connection is used when <target> is omitted.

 
        References
         - RFC 2812, 3.4.6 "Time message"
 
        References
         - RFC 2812, 3.4.6 "Time message"


@@ -342,56 +449,94 @@ Status and Informational Commands
        of a specific <server>, in a similar method to traceroute.
 
 - USERHOST
        of a specific <server>, in a similar method to traceroute.
 
 - USERHOST

-       USERHOST <nicknames>
+       USERHOST <nickname> [<nickname> [...]]
+       .
+       Show flags and the hostmasks (<user>@<host>) of the <nickname>s,
+       separated by spaces. The following flags are used:

        .
        .

-       Show the user-host of <nicknames> (seperated by space).
-       "-" means <nick> is away,
-       "+" means <nick> is available,
-       "*" indicates your connection.
+        - "-"  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

-       VERSION [<server>]
+       VERSION [<target>]
+       .
+       Show version information about a particular IRC server in the network.

        .
        .

-       Show the ngIRCd version of the current server, or specified <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 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

-       WHO [<target> ["o"]]
+       WHO [<mask> ["o"]]

        .
        .

-       Returns a list of users who match <target> (nick, hostmask or channel).
+       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.
 
        .
        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

-       WHOIS [<server>] <nicknames>
+       WHOIS [<target>] <mask>[,<mask>[,...]]

        .
        .

-       Returns information about the comma-separated list of <nicknames>.
+       Query information about users matching the <mask> parameter(s) as seen
+       by the server <target>; up to 3 <masks> are supported.

        .
        .

-       If <server> is given, the command is forwarded to it for processing.
+       <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

-       WHOWAS <nickname> [<count> [<server>]]
+       WHOWAS <nickname>[,<nickname>[,...]] [<count> [<target>]]

        .
        .

-       Used to return information about <nicknames> that are no longer in use
-       (due to client disconnection, or nickname changes).
+       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).

        .
        .

-       If given, the server will return information from the last <count> times
-       the nickname has been used.
-       If <server> is given, the command is forwarded to it for processing.
+       <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
 
 
 Channel Commands
 ~~~~~~~~~~~~~~~~
 
 - INVITE

-       INVITE <nick> <channel>
+       INVITE <nickname> <channel>

        .
        .

-       Invites <nick> to <channel>.
-       <channel> does not have to exist, but if it does, only members of the
-       channel are allowed to invite other clients.
+       Invite <nickname> to join channel <channel>.

        .
        .

-       If the <channel> mode "+i" is set, only <channel> operators may invite
-       other clients.
+       <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 <channels> [<channel-keys>]
 
 - JOIN
        JOIN <channels> [<channel-keys>]


@@ -403,11 +548,18 @@ Channel Commands
        If the channel(s) do not exist, then they will be created.
 
 - KICK
        If the channel(s) do not exist, then they will be created.
 
 - KICK

-       KICK <channel> <nick> [<kick-message>]
+       KICK <channel>[,<channel>[,...]] <nickname>[,<nickname>[,...]] [<reason>]

        .
        .

-       Remove <nick> from <channel>, optional with a <kick-message>.
+       Remove users(s) with <nickname>(s) from <channel>(s).

        .
        .

-       Only <channel> operators are able to KICK.
+       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 [<channels> [<server>]]
 
 - LIST
        LIST [<channels> [<server>]]


@@ -468,9 +620,16 @@ Administrative Commands
        To list the G-Lines, type "STATS g".
 
 - KILL
        To list the G-Lines, type "STATS g".
 
 - KILL

-       KILL <nick> <reason>
+       KILL <nickname> <reason>
+       .
+       Forcibly remove all users with a given <nickname> from the IRC
+       network and display the given <reason> to them.

        .
        .

-       Forcibly removes <nick> from the IRC network with a <reason>.
+       This command is used internally between servers, too, for example
+       to disconnect duplicate <nickname>'s after a "net split".
+
+       References:
+        - RFC 2812, 3.7.1 "Kill message"

 
 - KLINE
        KLINE <nick!user@hostmask> <seconds> :<reason>
 
 - KLINE
        KLINE <nick!user@hostmask> <seconds> :<reason>


@@ -507,12 +666,69 @@ IRC Service Commands
 ~~~~~~~~~~~~~~~~~~~~
 
 - SERVICE
 ~~~~~~~~~~~~~~~~~~~~
 
 - 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

+       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

+       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

+       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
 
 
 Server Protocol Commands


@@ -529,11 +745,18 @@ Server Protocol Commands
 - ERROR
        ERROR [<message> [<> [...]]]
        .
 - ERROR
        ERROR [<message> [<> [...]]]
        .

-       Return an error message to the server. The first parameter, if given,
-       will be logged by the server, all further parameters are silently
-       ignored.
+       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.

        .
        .

-       This command is silently ignored on non-server and non-service links.
+       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>
 
 - METADATA
        METADATA <target> <key> <value>


@@ -558,8 +781,27 @@ Dummy Commands
 ~~~~~~~~~~~~~~
 
 - SUMMON
 ~~~~~~~~~~~~~~
 
 - 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

+       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