]> arthur.barton.de Git - ngircd-alex.git/blobdiff - doc/Commands.txt
Commands.txt: Update more descriptions
[ngircd-alex.git] / doc / Commands.txt
index 3d9363e68b3226e7ab042f6a5383b1b85dbf86f4..7765d3a440cc6fe4431081b10b34120d426defa8 100644 (file)
@@ -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. A PING message results in a PONG
-       reply. If <server2> is specified, the message gets passed on to it.
+       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 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.
+       .
+       The <token> is the arbitrary text received in the "PING" command and
+       can be used to identify the correct PONG sent as answer.
        .
        .
-       This command is a reply to the PING command and works in much the
-       same way.
+       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>
+       .
+       Register (and authenticate) a new user session with a short <username>
+       and a human-readable <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.
+       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.
        .
        .
-       <realname> may contain spaces, and thus must be prefixed with a colon.
+       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 <message> to <target> (nick or channel).
+       Send a <message> to a given <target>, which can be a user or a
+       channel, and report all errors.
        .
        .
-       Common IRC clients use MSG as PRIVMSG alias.
-       (Some clients use "QUERY <nick> [<message>]" to open a private chat.)
+       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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 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"
@@ -345,7 +452,7 @@ Status and Informational Commands
        USERHOST <nickname> [<nickname> [...]]
        .
        Show flags and the hostmasks (<user>@<host>) of the <nickname>s,
        USERHOST <nickname> [<nickname> [...]]
        .
        Show flags and the hostmasks (<user>@<host>) of the <nickname>s,
-       seperated by spaces. The following flags are used:
+       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 "away" (the mode "+a" is set on this client).
         - "+"  Client seems to be available, at least it isn't marked "away".
@@ -361,7 +468,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: in normal operation, the version number ends in a dot
        (".", for example "ngIRCd-20.1."). If it ends in ".1" (for example
        .
        Please note: in normal operation, the version number ends in a dot
        (".", for example "ngIRCd-20.1."). If it ends in ".1" (for example
@@ -393,7 +500,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. The
        .
        <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.
+       server of the current connection is used when <target> is omitted.
 
        References:
         - RFC 2812, 3.6.2 "Whois query"
 
        References:
         - RFC 2812, 3.6.2 "Whois query"
@@ -409,7 +516,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. The
        .
        <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.
+       server of the current connection is used when <target> is omitted.
 
        References:
         - RFC 2812, 3.6.3 "Whowas"
 
        References:
         - RFC 2812, 3.6.3 "Whowas"
@@ -419,14 +526,17 @@ Channel Commands
 ~~~~~~~~~~~~~~~~
 
 - INVITE
 ~~~~~~~~~~~~~~~~
 
 - 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>]
@@ -438,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>]]
@@ -503,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 removes <nick> from the IRC network with a <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".
+
+       References:
+        - RFC 2812, 3.7.1 "Kill message"
 
 - KLINE
        KLINE <nick!user@hostmask> <seconds> :<reason>
 
 - KLINE
        KLINE <nick!user@hostmask> <seconds> :<reason>
@@ -542,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
@@ -564,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.
+       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>
 
 - METADATA
        METADATA <target> <key> <value>
@@ -593,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