From 473acc61c8392dc7ae303d91568e179c4f105a76 Mon Sep 17 00:00:00 2001 From: Dimitri Sokolyuk Date: Tue, 2 Jul 2019 12:12:53 +0200 Subject: add black list --- vendor/github.com/fluffle/goirc/doc/rfc2811.txt | 1067 ------ vendor/github.com/fluffle/goirc/doc/rfc2812.txt | 3531 ------------------- .../github.com/fluffle/goirc/doc/unreal32docs.html | 3666 -------------------- 3 files changed, 8264 deletions(-) delete mode 100644 vendor/github.com/fluffle/goirc/doc/rfc2811.txt delete mode 100644 vendor/github.com/fluffle/goirc/doc/rfc2812.txt delete mode 100644 vendor/github.com/fluffle/goirc/doc/unreal32docs.html (limited to 'vendor/github.com/fluffle/goirc/doc') diff --git a/vendor/github.com/fluffle/goirc/doc/rfc2811.txt b/vendor/github.com/fluffle/goirc/doc/rfc2811.txt deleted file mode 100644 index 7c2c4ea..0000000 --- a/vendor/github.com/fluffle/goirc/doc/rfc2811.txt +++ /dev/null @@ -1,1067 +0,0 @@ - - - - - - -Network Working Group C. Kalt -Request for Comments: 2811 April 2000 -Updates: 1459 -Category: Informational - - - Internet Relay Chat: Channel Management - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - One of the most notable characteristics of the IRC (Internet Relay - Chat) protocol is to allow for users to be grouped in forums, called - channels, providing a mean for multiple users to communicate - together. - - There was originally a unique type of channels, but with the years, - new types appeared either as a response to a need, or for - experimental purposes. - - This document specifies how channels, their characteristics and - properties are managed by IRC servers. - -Table of Contents - - 1. Introduction ............................................... 2 - 2. Channel Characteristics .................................... 3 - 2.1 Namespace .............................................. 3 - 2.2 Channel Scope .......................................... 3 - 2.3 Channel Properties ..................................... 4 - 2.4 Privileged Channel Members ............................. 4 - 2.4.1 Channel Operators ................................. 5 - 2.4.2 Channel Creator ................................... 5 - 3. Channel lifetime ........................................... 5 - 3.1 Standard channels ...................................... 5 - 3.2 Safe Channels .......................................... 6 - 4. Channel Modes .............................................. 7 - 4.1 Member Status .......................................... 7 - 4.1.1 "Channel Creator" Status .......................... 7 - - - -Kalt Informational [Page 1] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - - 4.1.2 Channel Operator Status ........................... 8 - 4.1.3 Voice Privilege ................................... 8 - 4.2 Channel Flags .......................................... 8 - 4.2.1 Anonymous Flag .................................... 8 - 4.2.2 Invite Only Flag .................................. 8 - 4.2.3 Moderated Channel Flag ............................ 9 - 4.2.4 No Messages To Channel From Clients On The Outside 9 - 4.2.5 Quiet Channel ..................................... 9 - 4.2.6 Private and Secret Channels ....................... 9 - 4.2.7 Server Reop Flag .................................. 10 - 4.2.8 Topic ............................................. 10 - 4.2.9 User Limit ........................................ 10 - 4.2.10 Channel Key ...................................... 10 - 4.3 Channel Access Control ................................. 10 - 4.3.1 Channel Ban and Exception ......................... 11 - 4.3.2 Channel Invitation ................................ 11 - 5. Current Implementations .................................... 11 - 5.1 Tracking Recently Used Channels ........................ 11 - 5.2 Safe Channels .......................................... 12 - 5.2.1 Channel Identifier ................................ 12 - 5.2.2 Channel Delay ..................................... 12 - 5.2.3 Abuse Window ...................................... 13 - 5.2.4 Preserving Sanity In The Name Space ............... 13 - 5.2.5 Server Reop Mechanism ............................. 13 - 6. Current problems ........................................... 14 - 6.1 Labels ................................................. 14 - 6.1.1 Channel Delay ..................................... 14 - 6.1.2 Safe Channels ..................................... 15 - 6.2 Mode Propagation Delays ................................ 15 - 6.3 Collisions And Channel Modes ........................... 15 - 6.4 Resource Exhaustion .................................... 16 - 7. Security Considerations .................................... 16 - 7.1 Access Control ......................................... 16 - 7.2 Channel Privacy ........................................ 16 - 7.3 Anonymity ............................................... 17 - 8. Current support and availability ........................... 17 - 9. Acknowledgements ........................................... 17 - 10. References ................................................ 18 - 11. Author's Address .......................................... 18 - 12. Full Copyright Statement ................................... 19 - -1. Introduction - - This document defines in detail on how channels are managed by the - IRC servers and will be mostly useful to people working on - implementing an IRC server. - - - - - -Kalt Informational [Page 2] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - - While the concepts defined here are an important part of IRC, they - remain non essential for implementing clients. While the trend seems - to be towards more and more complex and "intelligent" clients which - are able to take advantage of knowing the internal workings of - channels to provide the users with a more friendly interface, simple - clients can be implemented without reading this document. - - Many of the concepts defined here were designed with the IRC - architecture [IRC-ARCH] in mind and mostly make sense in this - context. However, many others could be applied to other - architectures in order to provide forums for a conferencing system. - - Finally, it is to be noted that IRC users may find some of the - following sections of interest, in particular sections 2 (Channel - Characteristics) and 4 (Channel Modes). - -2. Channel Characteristics - - A channel is a named group of one or more users which will all - receive messages addressed to that channel. A channel is - characterized by its name, properties and current members. - -2.1 Namespace - - Channels names are strings (beginning with a '&', '#', '+' or '!' - character) of length up to fifty (50) characters. Channel names are - case insensitive. - - Apart from the the requirement that the first character being either - '&', '#', '+' or '!' (hereafter called "channel prefix"). The only - restriction on a channel name is that it SHALL NOT contain any spaces - (' '), a control G (^G or ASCII 7), a comma (',' which is used as a - list item separator by the protocol). Also, a colon (':') is used as - a delimiter for the channel mask. The exact syntax of a channel name - is defined in "IRC Server Protocol" [IRC-SERVER]. - - The use of different prefixes effectively creates four (4) distinct - namespaces for channel names. This is important because of the - protocol limitations regarding namespaces (in general). See section - 6.1 (Labels) for more details on these limitations. - -2.2 Channel Scope - - A channel entity is known by one or more servers on the IRC network. - A user can only become member of a channel known by the server to - which the user is directly connected. The list of servers which know - - - - - -Kalt Informational [Page 3] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - - of the existence of a particular channel MUST be a contiguous part of - the IRC network, in order for the messages addressed to the channel - to be sent to all the channel members. - - Channels with '&' as prefix are local to the server where they are - created. - - Other channels are known to one (1) or more servers that are - connected to the network, depending on the channel mask: - - If there is no channel mask, then the channel is known to all - the servers. - - If there is a channel mask, then the channel MUST only be known - to servers which has a local user on the channel, and to its - neighbours if the mask matches both the local and neighbouring - server names. Since other servers have absolutely no knowledge of - the existence of such a channel, the area formed by the servers - having a name matching the mask has to be contiguous for the - channel to be known by all these servers. Channel masks are best - used in conjunction with server hostmasking [IRC-SERVER]. - -2.3 Channel Properties - - Each channel has its own properties, which are defined by channel - modes. Channel modes can be manipulated by the channel members. The - modes affect the way servers manage the channels. - - Channels with '+' as prefix do not support channel modes. This means - that all the modes are unset, with the exception of the 't' channel - flag which is set. - -2.4 Privileged Channel Members - - In order for the channel members to keep some control over a channel, - and some kind of sanity, some channel members are privileged. Only - these members are allowed to perform the following actions on the - channel: - - INVITE - Invite a client to an invite-only channel (mode +i) - KICK - Eject a client from the channel - MODE - Change the channel's mode, as well as - members' privileges - PRIVMSG - Sending messages to the channel (mode +n, +m, +v) - TOPIC - Change the channel topic in a mode +t channel - - - - - - -Kalt Informational [Page 4] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - -2.4.1 Channel Operators - - The channel operators (also referred to as a "chop" or "chanop") on a - given channel are considered to 'own' that channel. Ownership of a - channel is shared among channel operators. - - Channel operators are identified by the '@' symbol next to their - nickname whenever it is associated with a channel (i.e., replies to - the NAMES, WHO and WHOIS commands). - - Since channels starting with the character '+' as prefix do not - support channel modes, no member can therefore have the status of - channel operator. - -2.4.2 Channel Creator - - A user who creates a channel with the character '!' as prefix is - identified as the "channel creator". Upon creation of the channel, - this user is also given channel operator status. - - In recognition of this status, the channel creators are endowed with - the ability to toggle certain modes of the channel which channel - operators may not manipulate. - - A "channel creator" can be distinguished from a channel operator by - issuing the proper MODE command. See the "IRC Client Protocol" - [IRC-CLIENT] for more information on this topic. - -3. Channel lifetime - - In regard to the lifetime of a channel, there are typically two - groups of channels: standard channels which prefix is either '&', '#' - or '+', and "safe channels" which prefix is '!'. - -3.1 Standard channels - - These channels are created implicitly when the first user joins it, - and cease to exist when the last user leaves it. While the channel - exists, any client can reference the channel using the name of the - channel. - - The user creating a channel automatically becomes channel operator - with the notable exception of channels which name is prefixed by the - character '+', see section 4 (Channel modes). See section 2.4.1 - (Channel Operators) for more details on this title. - - - - - - -Kalt Informational [Page 5] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - - In order to avoid the creation of duplicate channels (typically when - the IRC network becomes disjoint because of a split between two - servers), channel names SHOULD NOT be allowed to be reused by a user - if a channel operator (See Section 2.4.1 (Channel Operators)) has - recently left the channel because of a network split. If this - happens, the channel name is temporarily unavailable. The duration - while a channel remains unavailable should be tuned on a per IRC - network basis. It is important to note that this prevents local - users from creating a channel using the same name, but does not - prevent the channel to be recreated by a remote user. The latter - typically happens when the IRC network rejoins. Obviously, this - mechanism only makes sense for channels which name begins with the - character '#', but MAY be used for channels which name begins with - the character '+'. This mechanism is commonly known as "Channel - Delay". - -3.2 Safe Channels - - Unlike other channels, "safe channels" are not implicitly created. A - user wishing to create such a channel MUST request the creation by - sending a special JOIN command to the server in which the channel - identifier (then unknown) is replaced by the character '!'. The - creation process for this type of channel is strictly controlled. - The user only chooses part of the channel name (known as the channel - "short name"), the server automatically prepends the user provided - name with a channel identifier consisting of five (5) characters. - The channel name resulting from the combination of these two elements - is unique, making the channel safe from abuses based on network - splits. - - The user who creates such a channel automatically becomes "channel - creator". See section 2.4.2 (Channel Creator) for more details on - this title. - - A server MUST NOT allow the creation of a new channel if another - channel with the same short name exists; or if another channel with - the same short name existed recently AND any of its member(s) left - because of a network split. Such channel ceases to exist after last - user leaves AND no other member recently left the channel because of - a network split. - - Unlike the mechanism described in section 5.2.2 (Channel Delay), in - this case, channel names do not become unavailable: these channels - may continue to exist after the last user left. Only the user - creating the channel becomes "channel creator", users joining an - existing empty channel do not automatically become "channel creator" - nor "channel operator". - - - - -Kalt Informational [Page 6] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - - To ensure the uniqueness of the channel names, the channel identifier - created by the server MUST follow specific rules. For more details - on this, see section 5.2.1 (Channel Identifier). - -4. Channel Modes - - The various modes available for channels are as follows: - - O - give "channel creator" status; - o - give/take channel operator privilege; - v - give/take the voice privilege; - - a - toggle the anonymous channel flag; - i - toggle the invite-only channel flag; - m - toggle the moderated channel; - n - toggle the no messages to channel from clients on the - outside; - q - toggle the quiet channel flag; - p - toggle the private channel flag; - s - toggle the secret channel flag; - r - toggle the server reop channel flag; - t - toggle the topic settable by channel operator only flag; - - k - set/remove the channel key (password); - l - set/remove the user limit to channel; - - b - set/remove ban mask to keep users out; - e - set/remove an exception mask to override a ban mask; - I - set/remove an invitation mask to automatically override - the invite-only flag; - - Unless mentioned otherwise below, all these modes can be manipulated - by "channel operators" by using the MODE command defined in "IRC - Client Protocol" [IRC-CLIENT]. - -4.1 Member Status - - The modes in this category take a channel member nickname as argument - and affect the privileges given to this user. - -4.1.1 "Channel Creator" Status - - The mode 'O' is only used in conjunction with "safe channels" and - SHALL NOT be manipulated by users. Servers use it to give the user - creating the channel the status of "channel creator". - - - - - - -Kalt Informational [Page 7] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - -4.1.2 Channel Operator Status - - The mode 'o' is used to toggle the operator status of a channel - member. - -4.1.3 Voice Privilege - - The mode 'v' is used to give and take voice privilege to/from a - channel member. Users with this privilege can talk on moderated - channels. (See section 4.2.3 (Moderated Channel Flag). - -4.2 Channel Flags - - The modes in this category are used to define properties which - affects how channels operate. - -4.2.1 Anonymous Flag - - The channel flag 'a' defines an anonymous channel. This means that - when a message sent to the channel is sent by the server to users, - and the origin is a user, then it MUST be masked. To mask the - message, the origin is changed to "anonymous!anonymous@anonymous." - (e.g., a user with the nickname "anonymous", the username "anonymous" - and from a host called "anonymous."). Because of this, servers MUST - forbid users from using the nickname "anonymous". Servers MUST also - NOT send QUIT messages for users leaving such channels to the other - channel members but generate a PART message instead. - - On channels with the character '&' as prefix, this flag MAY be - toggled by channel operators, but on channels with the character '!' - as prefix, this flag can be set (but SHALL NOT be unset) by the - "channel creator" only. This flag MUST NOT be made available on - other types of channels. - - Replies to the WHOIS, WHO and NAMES commands MUST NOT reveal the - presence of other users on channels for which the anonymous flag is - set. - -4.2.2 Invite Only Flag - - When the channel flag 'i' is set, new members are only accepted if - their mask matches Invite-list (See section 4.3.2) or they have been - invited by a channel operator. This flag also restricts the usage of - the INVITE command (See "IRC Client Protocol" [IRC-CLIENT]) to - channel operators. - - - - - - -Kalt Informational [Page 8] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - -4.2.3 Moderated Channel Flag - - The channel flag 'm' is used to control who may speak on a channel. - When it is set, only channel operators, and members who have been - given the voice privilege may send messages to the channel. - - This flag only affects users. - -4.2.4 No Messages To Channel From Clients On The Outside - - When the channel flag 'n' is set, only channel members MAY send - messages to the channel. - - This flag only affects users. - -4.2.5 Quiet Channel - - The channel flag 'q' is for use by servers only. When set, it - restricts the type of data sent to users about the channel - operations: other user joins, parts and nick changes are not sent. - From a user's point of view, the channel contains only one user. - - This is typically used to create special local channels on which the - server sends notices related to its operations. This was used as a - more efficient and flexible way to replace the user mode 's' defined - in RFC 1459 [IRC]. - -4.2.6 Private and Secret Channels - - The channel flag 'p' is used to mark a channel "private" and the - channel flag 's' to mark a channel "secret". Both properties are - similar and conceal the existence of the channel from other users. - - This means that there is no way of getting this channel's name from - the server without being a member. In other words, these channels - MUST be omitted from replies to queries like the WHOIS command. - - When a channel is "secret", in addition to the restriction above, the - server will act as if the channel does not exist for queries like the - TOPIC, LIST, NAMES commands. Note that there is one exception to - this rule: servers will correctly reply to the MODE command. - Finally, secret channels are not accounted for in the reply to the - LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC- - CLIENT]) when the parameter is specified. - - - - - - - -Kalt Informational [Page 9] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - - The channel flags 'p' and 's' MUST NOT both be set at the same time. - If a MODE message originating from a server sets the flag 'p' and the - flag 's' is already set for the channel, the change is silently - ignored. This should only happen during a split healing phase - (mentioned in the "IRC Server Protocol" document [IRC-SERVER]). - -4.2.7 Server Reop Flag - - The channel flag 'r' is only available on channels which name begins - with the character '!' and MAY only be toggled by the "channel - creator". - - This flag is used to prevent a channel from having no channel - operator for an extended period of time. When this flag is set, any - channel that has lost all its channel operators for longer than the - "reop delay" period triggers a mechanism in servers to reop some or - all of the channel inhabitants. This mechanism is described more in - detail in section 5.2.4 (Channel Reop Mechanism). - -4.2.8 Topic - - The channel flag 't' is used to restrict the usage of the TOPIC - command to channel operators. - -4.2.9 User Limit - - A user limit may be set on channels by using the channel flag 'l'. - When the limit is reached, servers MUST forbid their local users to - join the channel. - - The value of the limit MUST only be made available to the channel - members in the reply sent by the server to a MODE query. - -4.2.10 Channel Key - - When a channel key is set (by using the mode 'k'), servers MUST - reject their local users request to join the channel unless this key - is given. - - The channel key MUST only be made visible to the channel members in - the reply sent by the server to a MODE query. - -4.3 Channel Access Control - - The last category of modes is used to control access to the channel, - they take a mask as argument. - - - - - -Kalt Informational [Page 10] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - - In order to reduce the size of the global database for control access - modes set for channels, servers MAY put a maximum limit on the number - of such modes set for a particular channel. If such restriction is - imposed, it MUST only affect user requests. The limit SHOULD be - homogeneous on a per IRC network basis. - -4.3.1 Channel Ban and Exception - - When a user requests to join a channel, his local server checks if - the user's address matches any of the ban masks set for the channel. - If a match is found, the user request is denied unless the address - also matches an exception mask set for the channel. - - Servers MUST NOT allow a channel member who is banned from the - channel to speak on the channel, unless this member is a channel - operator or has voice privilege. (See Section 4.1.3 (Voice - Privilege)). - - A user who is banned from a channel and who carries an invitation - sent by a channel operator is allowed to join the channel. - -4.3.2 Channel Invitation - - For channels which have the invite-only flag set (See Section 4.2.2 - (Invite Only Flag)), users whose address matches an invitation mask - set for the channel are allowed to join the channel without any - invitation. - -5. Current Implementations - - The only current implementation of these rules as part of the IRC - protocol is the IRC server, version 2.10. - - The rest of this section deals with issues that are mostly of - importance to those who wish to implement a server but some parts may - also be of interest for client writers. - -5.1 Tracking Recently Used Channels - - This mechanism is commonly known as "Channel Delay" and generally - only applies to channels which names is prefixed with the character - '#' (See Section 3.1 "Standard channels"). - - When a network split occurs, servers SHOULD keep track of which - channels lost a "channel operator" as the result of the break. These - channels are then in a special state which lasts for a certain period - of time. In this particular state, the channels cannot cease to - - - - -Kalt Informational [Page 11] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - - exist. If all the channel members leave the channel, the channel - becomes unavailable: the server local clients cannot join the channel - as long as it is empty. - - Once a channel is unavailable, it will become available again either - because a remote user has joined the channel (most likely because the - network is healing), or because the delay period has expired (in - which case the channel ceases to exist and may be re-created). - - The duration for which a channel death is delayed SHOULD be set - considering many factors among which are the size (user wise) of the - IRC network, and the usual duration of network splits. It SHOULD be - uniform on all servers for a given IRC network. - -5.2 Safe Channels - - This document introduces the notion of "safe channels". These - channels have a name prefixed with the character '!' and great effort - is made to avoid collisions in this name space. Collisions are not - impossible, however they are very unlikely. - -5.2.1 Channel Identifier - - The channel identifier is a function of the time. The current time - (as defined under UNIX by the number of seconds elapsed since - 00:00:00 GMT, January 1, 1970) is converted in a string of five (5) - characters using the following base: - "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890" (each character has a decimal - value starting from 0 for 'A' to 35 for '0'). - - The channel identifier therefore has a periodicity of 36^5 seconds - (about 700 days). - -5.2.2 Channel Delay - - These channels MUST be subject to the "channel delay" mechanism - described in section 5.1 (Channel Delay). However, the mechanism is - slightly adapted to fit better. - - Servers MUST keep track of all such channels which lose members as - the result of a network split, no matter whether the user is a - "channel operator" or not. - - However, these channels do NOT ever become unavailable, it is always - possible to join them even when they are empty. - - - - - - -Kalt Informational [Page 12] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - -5.2.3 Abuse Window - - Because the periodicity is so long, attacks on a particular channel - (name) may only occur once in a very long while. However, with luck - and patience, it is still possible for a user to cause a channel - collision. In order to avoid this, servers MUST "look in the future" - and keep a list of channel names which identifier is about to be used - (in the coming few days for example). Such list should remain small, - not be a burden for servers to maintain and be used to avoid channel - collisions by preventing the re-creation of such channel for a longer - period of time than channel delay does. - - Eventually a server MAY choose to extend this procedure to forbid - creation of channels with the same shortname only (then ignoring the - channel identifier). - -5.2.4 Preserving Sanity In The Name Space - - The combination of the mechanisms described in sections 5.2.2 and - 5.2.3 makes it quite difficult for a user to create a channel - collision. However, another type of abuse consists of creating many - channels having the same shortname, but different identifiers. To - prevent this from happening, servers MUST forbid the creation of a - new channel which has the same shortname of a channel currently - existing. - -5.2.5 Server Reop Mechanism - - When a channel has been opless for longer than the "reop delay" - period and has the channel flag 'r' set (See Section 4.2.7 (Server - Reop Flag)), IRC servers are responsible for giving the channel - operator status randomly to some of the members. - - The exact logic used for this mechanism by the current implementation - is described below. Servers MAY use a different logic, but that it - is strongly RECOMMENDED that all servers use the same logic on a - particular IRC network to maintain coherence as well as fairness. - For the same reason, the "reop delay" SHOULD be uniform on all - servers for a given IRC network. As for the "channel delay", the - value of the "reop delay" SHOULD be set considering many factors - among which are the size (user wise) of the IRC network, and the - usual duration of network splits. - - a) the reop mechanism is triggered after a random time following the - expiration of the "reop delay". This should limit the eventuality - of the mechanism being triggered at the same time (for the same - channel) on two separate servers. - - - - -Kalt Informational [Page 13] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - - b) If the channel is small (five (5) users or less), and the "channel - delay" for this channel has expired, - Then reop all channel members if at least one member is local to - the server. - - c) If the channel is small (five (5) users or less), and the "channel - delay" for this channel has expired, and the "reop delay" has - expired for longer than its value, - Then reop all channel members. - - d) For other cases, reop at most one member on the channel, based on - some method build into the server. If you don't reop a member, the - method should be such that another server will probably op - someone. The method SHOULD be the same over the whole network. A - good heuristic could be just random reop. - (The current implementation actually tries to choose a member - local to the server who has not been idle for too long, eventually - postponing action, therefore letting other servers have a chance - to find a "not too idle" member. This is over complicated due to - the fact that servers only know the "idle" time of their local - users) - -6. Current problems - - There are a number of recognized problems with the way IRC channels - are managed. Some of these can be directly attributed to the rules - defined in this document, while others are the result of the - underlying "IRC Server Protocol" [IRC-SERVER]. Although derived from - RFC 1459 [IRC], this document introduces several novelties in an - attempt to solve some of the known problems. - -6.1 Labels - - This document defines one of the many labels used by the IRC - protocol. Although there are several distinct namespaces (based on - the channel name prefix), duplicates inside each of these are not - allowed. Currently, it is possible for users on different servers to - pick the label which may result in collisions (with the exception of - channels known to only one server where they can be averted). - -6.1.1 Channel Delay - - The channel delay mechanism described in section 5.1 (Tracking - Recently Used Channels) and used for channels prefixed with the - character '#' is a simple attempt at preventing collisions from - happening. Experience has shown that, under normal circumstances, it - - - - - -Kalt Informational [Page 14] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - - is very efficient; however, it obviously has severe limitations - keeping it from being an adequate solution to the problem discussed - here. - -6.1.2 Safe Channels - - "Safe channels" described in section 3.2 (Safe Channels) are a better - way to prevent collisions from happening as it prevents users from - having total control over the label they choose. The obvious - drawback for such labels is that they are not user friendly. - However, it is fairly trivial for a client program to improve on - this. - -6.2 Mode Propagation Delays - - Because of network delays induced by the network, and because each - server on the path is REQUIRED to check the validity of mode changes - (e.g., user exists and has the right privileges), it is not unusual - for a MODE message to only affect part of the network, often creating - a discrepancy between servers on the current state of a channel. - - While this may seem easy to fix (by having only the original server - check the validity of mode changes), it was decided not to do so for - various reasons. One concern is that servers cannot trust each - other, and that a misbehaving servers can easily be detected. This - way of doing so also stops wave effects on channels which are out of - synch when mode changes are issued from different directions. - -6.3 Collisions And Channel Modes - - The "Internet Relay Chat: Server Protocol" document [IRC-SERVER] - describes how channel data is exchanged when two servers connect to - each other. Channel collisions (either legitimate or not) are - treated as inclusive events, meaning that the resulting channel has - for members all the users who are members of the channel on either - server prior to the connection. - - Similarly, each server sends the channel modes to the other one. - Therefore, each server also receives these channel modes. There are - three types of modes for a given channel: flags, masks, and data. - The first two types are easy to deal with as they are either set or - unset. If such a mode is set on one server, it MUST be set on the - other server as a result of the connection. - - - - - - - - -Kalt Informational [Page 15] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - - As topics are not sent as part of this exchange, they are not a - problem. However, channel modes 'l' and 'k' are exchanged, and if - they are set on both servers prior to the connection, there is no - mechanism to decide which of the two values takes precedence. It is - left up to the users to fix the resulting discrepancy. - -6.4 Resource Exhaustion - - The mode based on masks defined in section 4.3 make the IRC servers - (and network) vulnerable to a simple abuse of the system: a single - channel operator can set as many different masks as possible on a - particular channel. This can easily cause the server to waste - memory, as well as network bandwidth (since the info is propagated to - other servers). For this reason it is RECOMMENDED that a limit be - put on the number of such masks per channels as mentioned in section - 4.3. - - Moreover, more complex mechanisms MAY be used to avoid having - redundant masks set for the same channel. - -7. Security Considerations - -7.1 Access Control - - One of the main ways to control access to a channel is to use masks - which are based on the username and hostname of the user connections. - This mechanism can only be efficient and safe if the IRC servers have - an accurate way of authenticating user connections, and if users - cannot easily get around it. While it is in theory possible to - implement such a strict authentication mechanism, most IRC networks - (especially public networks) do not have anything like this in place - and provide little guaranty about the accuracy of the username and - hostname for a particular client connection. - - Another way to control access is to use a channel key, but since this - key is sent in plaintext, it is vulnerable to traditional man in the - middle attacks. - -7.2 Channel Privacy - - Because channel collisions are treated as inclusive events (See - Section 6.3), it is possible for users to join a channel overriding - its access control settings. This method has long been used by - individuals to "take over" channels by "illegitimately" gaining - channel operator status on the channel. The same method can be used - to find out the exact list of members of a channel, as well as to - eventually receive some of the messages sent to the channel. - - - - -Kalt Informational [Page 16] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - -7.3 Anonymity - - The anonymous channel flag (See Section 4.2.1) can be used to render - all users on such channel "anonymous" by presenting all messages to - the channel as originating from a pseudo user which nickname is - "anonymous". This is done at the client-server level, and no - anonymity is provided at the server-server level. - - It should be obvious to readers, that the level of anonymity offered - is quite poor and insecure, and that clients SHOULD display strong - warnings for users joining such channels. - -8. Current support and availability - - Mailing lists for IRC related discussion: - General discussion: ircd-users@irc.org - Protocol development: ircd-dev@irc.org - - Software implementations: - ftp://ftp.irc.org/irc/server - ftp://ftp.funet.fi/pub/unix/irc - ftp://coombs.anu.edu.au/pub/irc - - Newsgroup: alt.irc - -9. Acknowledgements - - Parts of this document were copied from the RFC 1459 [IRC] which - first formally documented the IRC Protocol. It has also benefited - from many rounds of review and comments. In particular, the - following people have made significant contributions to this - document: - - Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa - Ruokonen, Magnus Tjernstrom, Stefan Zehl. - - - - - - - - - - - - - - - - -Kalt Informational [Page 17] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - -10. References - - [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat - Protocol", RFC 1459, May 1993. - - [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, - April 2000. - - [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC - 2812, April 2000. - - [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC - 2813, April 2000. - -11. Author's Address - - Christophe Kalt - 99 Teaneck Rd, Apt #117 - Ridgefield Park, NJ 07660 - USA - - EMail: kalt@stealth.net - - - - - - - - - - - - - - - - - - - - - - - - - - -Kalt Informational [Page 18] - -RFC 2811 Internet Relay Chat: Channel Management April 2000 - - -12. Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Kalt Informational [Page 19] - diff --git a/vendor/github.com/fluffle/goirc/doc/rfc2812.txt b/vendor/github.com/fluffle/goirc/doc/rfc2812.txt deleted file mode 100644 index 7f1b162..0000000 --- a/vendor/github.com/fluffle/goirc/doc/rfc2812.txt +++ /dev/null @@ -1,3531 +0,0 @@ - - - - - - -Network Working Group C. Kalt -Request for Comments: 2812 April 2000 -Updates: 1459 -Category: Informational - - - Internet Relay Chat: Client Protocol - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -IESG NOTE: - - The IRC protocol itself enables several possibilities of transferring - data between clients, and just like with other transfer mechanisms - like email, the receiver of the data has to be careful about how the - data is handled. For more information on security issues with the IRC - protocol, see for example http://www.irchelp.org/irchelp/security/. - -Abstract - - The IRC (Internet Relay Chat) protocol is for use with text based - conferencing; the simplest client being any socket program capable of - connecting to the server. - - This document defines the Client Protocol, and assumes that the - reader is familiar with the IRC Architecture [IRC-ARCH]. - -Table of Contents - - 1. Labels ..................................................... 3 - 1.1 Servers ................................................ 3 - 1.2 Clients ................................................ 3 - 1.2.1 Users ............................................. 4 - 1.2.1.1 Operators .................................... 4 - 1.2.2 Services .......................................... 4 - 1.3 Channels ............................................... 4 - 2. The IRC Client Specification ............................... 5 - 2.1 Overview ............................................... 5 - 2.2 Character codes ........................................ 5 - 2.3 Messages ............................................... 5 - - - -Kalt Informational [Page 1] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - 2.3.1 Message format in Augmented BNF ................... 6 - 2.4 Numeric replies ........................................ 8 - 2.5 Wildcard expressions ................................... 9 - 3. Message Details ............................................ 9 - 3.1 Connection Registration ................................ 10 - 3.1.1 Password message .................................. 10 - 3.1.2 Nick message ...................................... 10 - 3.1.3 User message ...................................... 11 - 3.1.4 Oper message ...................................... 12 - 3.1.5 User mode message ................................. 12 - 3.1.6 Service message ................................... 13 - 3.1.7 Quit .............................................. 14 - 3.1.8 Squit ............................................. 15 - 3.2 Channel operations ..................................... 15 - 3.2.1 Join message ...................................... 16 - 3.2.2 Part message ...................................... 17 - 3.2.3 Channel mode message .............................. 18 - 3.2.4 Topic message ..................................... 19 - 3.2.5 Names message ..................................... 20 - 3.2.6 List message ...................................... 21 - 3.2.7 Invite message .................................... 21 - 3.2.8 Kick command ...................................... 22 - 3.3 Sending messages ....................................... 23 - 3.3.1 Private messages .................................. 23 - 3.3.2 Notice ............................................ 24 - 3.4 Server queries and commands ............................ 25 - 3.4.1 Motd message ...................................... 25 - 3.4.2 Lusers message .................................... 25 - 3.4.3 Version message ................................... 26 - 3.4.4 Stats message ..................................... 26 - 3.4.5 Links message ..................................... 27 - 3.4.6 Time message ...................................... 28 - 3.4.7 Connect message ................................... 28 - 3.4.8 Trace message ..................................... 29 - 3.4.9 Admin command ..................................... 30 - 3.4.10 Info command ...................................... 31 - 3.5 Service Query and Commands ............................. 31 - 3.5.1 Servlist message .................................. 31 - 3.5.2 Squery ............................................ 32 - 3.6 User based queries ..................................... 32 - 3.6.1 Who query ......................................... 32 - 3.6.2 Whois query ....................................... 33 - 3.6.3 Whowas ............................................ 34 - 3.7 Miscellaneous messages ................................. 34 - 3.7.1 Kill message ...................................... 35 - 3.7.2 Ping message ...................................... 36 - 3.7.3 Pong message ...................................... 37 - 3.7.4 Error ............................................. 37 - - - -Kalt Informational [Page 2] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - 4. Optional features .......................................... 38 - 4.1 Away ................................................... 38 - 4.2 Rehash message ......................................... 39 - 4.3 Die message ............................................ 39 - 4.4 Restart message ........................................ 40 - 4.5 Summon message ......................................... 40 - 4.6 Users .................................................. 41 - 4.7 Operwall message ....................................... 41 - 4.8 Userhost message ....................................... 42 - 4.9 Ison message ........................................... 42 - 5. Replies .................................................... 43 - 5.1 Command responses ...................................... 43 - 5.2 Error Replies .......................................... 53 - 5.3 Reserved numerics ...................................... 59 - 6. Current implementations .................................... 60 - 7. Current problems ........................................... 60 - 7.1 Nicknames .............................................. 60 - 7.2 Limitation of wildcards ................................ 61 - 7.3 Security considerations ................................ 61 - 8. Current support and availability ........................... 61 - 9. Acknowledgements ........................................... 61 - 10. References ................................................ 62 - 11. Author's Address .......................................... 62 - 12. Full Copyright Statement .................................. 63 - -1. Labels - - This section defines the identifiers used for the various components - of the IRC protocol. - -1.1 Servers - - Servers are uniquely identified by their name, which has a maximum - length of sixty three (63) characters. See the protocol grammar - rules (section 2.3.1) for what may and may not be used in a server - name. - -1.2 Clients - - For each client all servers MUST have the following information: a - netwide unique identifier (whose format depends on the type of - client) and the server which introduced the client. - - - - - - - - - -Kalt Informational [Page 3] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - -1.2.1 Users - - Each user is distinguished from other users by a unique nickname - having a maximum length of nine (9) characters. See the protocol - grammar rules (section 2.3.1) for what may and may not be used in a - nickname. - - While the maximum length is limited to nine characters, clients - SHOULD accept longer strings as they may become used in future - evolutions of the protocol. - -1.2.1.1 Operators - - To allow a reasonable amount of order to be kept within the IRC - network, a special class of users (operators) is allowed to perform - general maintenance functions on the network. Although the powers - granted to an operator can be considered as 'dangerous', they are - nonetheless often necessary. Operators SHOULD be able to perform - basic network tasks such as disconnecting and reconnecting servers as - needed. In recognition of this need, the protocol discussed herein - provides for operators only to be able to perform such functions. - See sections 3.1.8 (SQUIT) and 3.4.7 (CONNECT). - - A more controversial power of operators is the ability to remove a - user from the connected network by 'force', i.e., operators are able - to close the connection between any client and server. The - justification for this is very delicate since its abuse is both - destructive and annoying, and its benefits close to inexistent. For - further details on this type of action, see section 3.7.1 (KILL). - -1.2.2 Services - - Each service is distinguished from other services by a service name - composed of a nickname and a server name. As for users, the nickname - has a maximum length of nine (9) characters. See the protocol - grammar rules (section 2.3.1) for what may and may not be used in a - nickname. - -1.3 Channels - - Channels names are strings (beginning with a '&', '#', '+' or '!' - character) of length up to fifty (50) characters. Apart from the - requirement that the first character is either '&', '#', '+' or '!', - the only restriction on a channel name is that it SHALL NOT contain - any spaces (' '), a control G (^G or ASCII 7), a comma (','). Space - is used as parameter separator and command is used as a list item - separator by the protocol). A colon (':') can also be used as a - delimiter for the channel mask. Channel names are case insensitive. - - - -Kalt Informational [Page 4] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - See the protocol grammar rules (section 2.3.1) for the exact syntax - of a channel name. - - Each prefix characterizes a different channel type. The definition - of the channel types is not relevant to the client-server protocol - and thus it is beyond the scope of this document. More details can - be found in "Internet Relay Chat: Channel Management" [IRC-CHAN]. - -2. The IRC Client Specification - -2.1 Overview - - The protocol as described herein is for use only with client to - server connections when the client registers as a user. - -2.2 Character codes - - No specific character set is specified. The protocol is based on a - set of codes which are composed of eight (8) bits, making up an - octet. Each message may be composed of any number of these octets; - however, some octet values are used for control codes, which act as - message delimiters. - - Regardless of being an 8-bit protocol, the delimiters and keywords - are such that protocol is mostly usable from US-ASCII terminal and a - telnet connection. - - Because of IRC's Scandinavian origin, the characters {}|^ are - considered to be the lower case equivalents of the characters []\~, - respectively. This is a critical issue when determining the - equivalence of two nicknames or channel names. - -2.3 Messages - - Servers and clients send each other messages, which may or may not - generate a reply. If the message contains a valid command, as - described in later sections, the client should expect a reply as - specified but it is not advised to wait forever for the reply; client - to server and server to server communication is essentially - asynchronous by nature. - - Each IRC message may consist of up to three main parts: the prefix - (OPTIONAL), the command, and the command parameters (maximum of - fifteen (15)). The prefix, command, and all parameters are separated - by one ASCII space character (0x20) each. - - - - - - -Kalt Informational [Page 5] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - The presence of a prefix is indicated with a single leading ASCII - colon character (':', 0x3b), which MUST be the first character of the - message itself. There MUST be NO gap (whitespace) between the colon - and the prefix. The prefix is used by servers to indicate the true - origin of the message. If the prefix is missing from the message, it - is assumed to have originated from the connection from which it was - received from. Clients SHOULD NOT use a prefix when sending a - message; if they use one, the only valid prefix is the registered - nickname associated with the client. - - The command MUST either be a valid IRC command or a three (3) digit - number represented in ASCII text. - - IRC messages are always lines of characters terminated with a CR-LF - (Carriage Return - Line Feed) pair, and these messages SHALL NOT - exceed 512 characters in length, counting all characters including - the trailing CR-LF. Thus, there are 510 characters maximum allowed - for the command and its parameters. There is no provision for - continuation of message lines. See section 6 for more details about - current implementations. - -2.3.1 Message format in Augmented BNF - - The protocol messages must be extracted from the contiguous stream of - octets. The current solution is to designate two characters, CR and - LF, as message separators. Empty messages are silently ignored, - which permits use of the sequence CR-LF between messages without - extra problems. - - The extracted message is parsed into the components , - and list of parameters (). - - The Augmented BNF representation for this is: - - message = [ ":" prefix SPACE ] command [ params ] crlf - prefix = servername / ( nickname [ [ "!" user ] "@" host ] ) - command = 1*letter / 3digit - params = *14( SPACE middle ) [ SPACE ":" trailing ] - =/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ] - - nospcrlfcl = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF - ; any octet except NUL, CR, LF, " " and ":" - middle = nospcrlfcl *( ":" / nospcrlfcl ) - trailing = *( ":" / " " / nospcrlfcl ) - - SPACE = %x20 ; space character - crlf = %x0D %x0A ; "carriage return" "linefeed" - - - - -Kalt Informational [Page 6] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - NOTES: - 1) After extracting the parameter list, all parameters are equal - whether matched by or . is just a - syntactic trick to allow SPACE within the parameter. - - 2) The NUL (%x00) character is not special in message framing, and - basically could end up inside a parameter, but it would cause - extra complexities in normal C string handling. Therefore, NUL - is not allowed within messages. - - Most protocol messages specify additional semantics and syntax for - the extracted parameter strings dictated by their position in the - list. For example, many server commands will assume that the first - parameter after the command is the list of targets, which can be - described with: - - target = nickname / server - msgtarget = msgto *( "," msgto ) - msgto = channel / ( user [ "%" host ] "@" servername ) - msgto =/ ( user "%" host ) / targetmask - msgto =/ nickname / ( nickname "!" user "@" host ) - channel = ( "#" / "+" / ( "!" channelid ) / "&" ) chanstring - [ ":" chanstring ] - servername = hostname - host = hostname / hostaddr - hostname = shortname *( "." shortname ) - shortname = ( letter / digit ) *( letter / digit / "-" ) - *( letter / digit ) - ; as specified in RFC 1123 [HNAME] - hostaddr = ip4addr / ip6addr - ip4addr = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit - ip6addr = 1*hexdigit 7( ":" 1*hexdigit ) - ip6addr =/ "0:0:0:0:0:" ( "0" / "FFFF" ) ":" ip4addr - nickname = ( letter / special ) *8( letter / digit / special / "-" ) - targetmask = ( "$" / "#" ) mask - ; see details on allowed masks in section 3.3.1 - chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B - chanstring =/ %x2D-39 / %x3B-FF - ; any octet except NUL, BELL, CR, LF, " ", "," and ":" - channelid = 5( %x41-5A / digit ) ; 5( A-Z / 0-9 ) - - - - - - - - - - - -Kalt Informational [Page 7] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Other parameter syntaxes are: - - user = 1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF ) - ; any octet except NUL, CR, LF, " " and "@" - key = 1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F ) - ; any 7-bit US_ASCII character, - ; except NUL, CR, LF, FF, h/v TABs, and " " - letter = %x41-5A / %x61-7A ; A-Z / a-z - digit = %x30-39 ; 0-9 - hexdigit = digit / "A" / "B" / "C" / "D" / "E" / "F" - special = %x5B-60 / %x7B-7D - ; "[", "]", "\", "`", "_", "^", "{", "|", "}" - - NOTES: - 1) The syntax is given here for the sole purpose of - indicating the format to follow for IP addresses. This - reflects the fact that the only available implementations of - this protocol uses TCP/IP as underlying network protocol but is - not meant to prevent other protocols to be used. - - 2) has a maximum length of 63 characters. This is a - limitation of the protocol as internet hostnames (in - particular) can be longer. Such restriction is necessary - because IRC messages are limited to 512 characters in length. - Clients connecting from a host which name is longer than 63 - characters are registered using the host (numeric) address - instead of the host name. - - 3) Some parameters used in the following sections of this - documents are not defined here as there is nothing specific - about them besides the name that is used for convenience. - These parameters follow the general syntax defined for - . - -2.4 Numeric replies - - Most of the messages sent to the server generate a reply of some - sort. The most common reply is the numeric reply, used for both - errors and normal replies. The numeric reply MUST be sent as one - message consisting of the sender prefix, the three-digit numeric, and - the target of the reply. A numeric reply is not allowed to originate - from a client. In all other respects, a numeric reply is just like a - normal message, except that the keyword is made up of 3 numeric - digits rather than a string of letters. A list of different replies - is supplied in section 5 (Replies). - - - - - - -Kalt Informational [Page 8] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - -2.5 Wildcard expressions - - When wildcards are allowed in a string, it is referred as a "mask". - - For string matching purposes, the protocol allows the use of two - special characters: '?' (%x3F) to match one and only one character, - and '*' (%x2A) to match any number of any characters. These two - characters can be escaped using the character '\' (%x5C). - - The Augmented BNF syntax for this is: - - mask = *( nowild / noesc wildone / noesc wildmany ) - wildone = %x3F - wildmany = %x2A - nowild = %x01-29 / %x2B-3E / %x40-FF - ; any octet except NUL, "*", "?" - noesc = %x01-5B / %x5D-FF - ; any octet except NUL and "\" - matchone = %x01-FF - ; matches wildone - matchmany = *matchone - ; matches wildmany - - Examples: - - a?c ; Matches any string of 3 characters in length starting - with "a" and ending with "c" - - a*c ; Matches any string of at least 2 characters in length - starting with "a" and ending with "c" - -3. Message Details - - On the following pages there are descriptions of each message - recognized by the IRC server and client. All commands described in - this section MUST be implemented by any server for this protocol. - - Where the reply ERR_NOSUCHSERVER is returned, it means that the - target of the message could not be found. The server MUST NOT send - any other replies after this error for that command. - - The server to which a client is connected is required to parse the - complete message, and return any appropriate errors. - - If multiple parameters is presented, then each MUST be checked for - validity and appropriate responses MUST be sent back to the client. - In the case of incorrect messages which use parameter lists with - comma as an item separator, a reply MUST be sent for each item. - - - -Kalt Informational [Page 9] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - -3.1 Connection Registration - - The commands described here are used to register a connection with an - IRC server as a user as well as to correctly disconnect. - - A "PASS" command is not required for a client connection to be - registered, but it MUST precede the latter of the NICK/USER - combination (for a user connection) or the SERVICE command (for a - service connection). The RECOMMENDED order for a client to register - is as follows: - - 1. Pass message - 2. Nick message 2. Service message - 3. User message - - Upon success, the client will receive an RPL_WELCOME (for users) or - RPL_YOURESERVICE (for services) message indicating that the - connection is now registered and known the to the entire IRC network. - The reply message MUST contain the full client identifier upon which - it was registered. - -3.1.1 Password message - - Command: PASS - Parameters: - - The PASS command is used to set a 'connection password'. The - optional password can and MUST be set before any attempt to register - the connection is made. Currently this requires that user send a - PASS command before sending the NICK/USER combination. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED - - Example: - - PASS secretpasswordhere - -3.1.2 Nick message - - - Command: NICK - Parameters: - - NICK command is used to give user a nickname or change the existing - one. - - - - -Kalt Informational [Page 10] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Numeric Replies: - - ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME - ERR_NICKNAMEINUSE ERR_NICKCOLLISION - ERR_UNAVAILRESOURCE ERR_RESTRICTED - - Examples: - - NICK Wiz ; Introducing new nick "Wiz" if session is - still unregistered, or user changing his - nickname to "Wiz" - - :WiZ!jto@tolsun.oulu.fi NICK Kilroy - ; Server telling that WiZ changed his - nickname to Kilroy. - -3.1.3 User message - - Command: USER - Parameters: - - The USER command is used at the beginning of connection to specify - the username, hostname and realname of a new user. - - The parameter should be a numeric, and can be used to - automatically set user modes when registering with the server. This - parameter is a bitmask, with only 2 bits having any signification: if - the bit 2 is set, the user mode 'w' will be set and if the bit 3 is - set, the user mode 'i' will be set. (See Section 3.1.5 "User - Modes"). - - The may contain space characters. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED - - Example: - - USER guest 0 * :Ronnie Reagan ; User registering themselves with a - username of "guest" and real name - "Ronnie Reagan". - - USER guest 8 * :Ronnie Reagan ; User registering themselves with a - username of "guest" and real name - "Ronnie Reagan", and asking to be set - invisible. - - - - -Kalt Informational [Page 11] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - -3.1.4 Oper message - - Command: OPER - Parameters: - - A normal user uses the OPER command to obtain operator privileges. - The combination of and are REQUIRED to gain - Operator privileges. Upon success, the user will receive a MODE - message (see section 3.1.5) indicating the new user modes. - - Numeric Replies: - - ERR_NEEDMOREPARAMS RPL_YOUREOPER - ERR_NOOPERHOST ERR_PASSWDMISMATCH - - Example: - - OPER foo bar ; Attempt to register as an operator - using a username of "foo" and "bar" - as the password. - -3.1.5 User mode message - - Command: MODE - Parameters: - *( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) ) - - The user MODE's are typically changes which affect either how the - client is seen by others or what 'extra' messages the client is sent. - - A user MODE command MUST only be accepted if both the sender of the - message and the nickname given as a parameter are both the same. If - no other parameter is given, then the server will return the current - settings for the nick. - - The available modes are as follows: - - a - user is flagged as away; - i - marks a users as invisible; - w - user receives wallops; - r - restricted user connection; - o - operator flag; - O - local operator flag; - s - marks a user for receipt of server notices. - - Additional modes may be available later on. - - - - - -Kalt Informational [Page 12] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - The flag 'a' SHALL NOT be toggled by the user using the MODE command, - instead use of the AWAY command is REQUIRED. - - If a user attempts to make themselves an operator using the "+o" or - "+O" flag, the attempt SHOULD be ignored as users could bypass the - authentication mechanisms of the OPER command. There is no - restriction, however, on anyone `deopping' themselves (using "-o" or - "-O"). - - On the other hand, if a user attempts to make themselves unrestricted - using the "-r" flag, the attempt SHOULD be ignored. There is no - restriction, however, on anyone `deopping' themselves (using "+r"). - This flag is typically set by the server upon connection for - administrative reasons. While the restrictions imposed are left up - to the implementation, it is typical that a restricted user not be - allowed to change nicknames, nor make use of the channel operator - status on channels. - - The flag 's' is obsolete but MAY still be used. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_USERSDONTMATCH - ERR_UMODEUNKNOWNFLAG RPL_UMODEIS - - Examples: - - MODE WiZ -w ; Command by WiZ to turn off - reception of WALLOPS messages. - - MODE Angel +i ; Command from Angel to make herself - invisible. - - MODE WiZ -o ; WiZ 'deopping' (removing operator - status). - -3.1.6 Service message - - Command: SERVICE - Parameters: - - - The SERVICE command to register a new service. Command parameters - specify the service nickname, distribution, type and info of a new - service. - - - - - - -Kalt Informational [Page 13] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - The parameter is used to specify the visibility of a - service. The service may only be known to servers which have a name - matching the distribution. For a matching server to have knowledge - of the service, the network path between that server and the server - on which the service is connected MUST be composed of servers which - names all match the mask. - - The parameter is currently reserved for future usage. - - Numeric Replies: - - ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS - ERR_ERRONEUSNICKNAME - RPL_YOURESERVICE RPL_YOURHOST - RPL_MYINFO - - Example: - - SERVICE dict * *.fr 0 0 :French Dictionary ; Service registering - itself with a name of "dict". This - service will only be available on - servers which name matches "*.fr". - -3.1.7 Quit - - Command: QUIT - Parameters: [ ] - - A client session is terminated with a quit message. The server - acknowledges this by sending an ERROR message to the client. - - Numeric Replies: - - None. - - Example: - - QUIT :Gone to have lunch ; Preferred message format. - - :syrk!kalt@millennium.stealth.net QUIT :Gone to have lunch ; User - syrk has quit IRC to have lunch. - - - - - - - - - - -Kalt Informational [Page 14] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - -3.1.8 Squit - - Command: SQUIT - Parameters: - - The SQUIT command is available only to operators. It is used to - disconnect server links. Also servers can generate SQUIT messages on - error conditions. A SQUIT message may also target a remote server - connection. In this case, the SQUIT message will simply be sent to - the remote server without affecting the servers in between the - operator and the remote server. - - The SHOULD be supplied by all operators who execute a SQUIT - for a remote server. The server ordered to disconnect its peer - generates a WALLOPS message with included, so that other - users may be aware of the reason of this action. - - Numeric replies: - - ERR_NOPRIVILEGES ERR_NOSUCHSERVER - ERR_NEEDMOREPARAMS - - Examples: - - SQUIT tolsun.oulu.fi :Bad Link ? ; Command to uplink of the server - tolson.oulu.fi to terminate its - connection with comment "Bad Link". - - :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; Command - from Trillian from to disconnect - "cm22.eng.umd.edu" from the net with - comment "Server out of control". - -3.2 Channel operations - - This group of messages is concerned with manipulating channels, their - properties (channel modes), and their contents (typically users). - For this reason, these messages SHALL NOT be made available to - services. - - All of these messages are requests which will or will not be granted - by the server. The server MUST send a reply informing the user - whether the request was granted, denied or generated an error. When - the server grants the request, the message is typically sent back - (eventually reformatted) to the user with the prefix set to the user - itself. - - - - - -Kalt Informational [Page 15] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - The rules governing how channels are managed are enforced by the - servers. These rules are beyond the scope of this document. More - details are found in "Internet Relay Chat: Channel Management" [IRC- - CHAN]. - -3.2.1 Join message - - Command: JOIN - Parameters: ( *( "," ) [ *( "," ) ] ) - / "0" - - The JOIN command is used by a user to request to start listening to - the specific channel. Servers MUST be able to parse arguments in the - form of a list of target, but SHOULD NOT use lists when sending JOIN - messages to clients. - - Once a user has joined a channel, he receives information about - all commands his server receives affecting the channel. This - includes JOIN, MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. - This allows channel members to keep track of the other channel - members, as well as channel modes. - - If a JOIN is successful, the user receives a JOIN message as - confirmation and is then sent the channel's topic (using RPL_TOPIC) and - the list of users who are on the channel (using RPL_NAMREPLY), which - MUST include the user joining. - - Note that this message accepts a special argument ("0"), which is - a special request to leave all channels the user is currently a member - of. The server will process this message as if the user had sent - a PART command (See Section 3.2.2) for each channel he is a member - of. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN - ERR_INVITEONLYCHAN ERR_BADCHANNELKEY - ERR_CHANNELISFULL ERR_BADCHANMASK - ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS - ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE - RPL_TOPIC - - Examples: - - JOIN #foobar ; Command to join channel #foobar. - - JOIN &foo fubar ; Command to join channel &foo using - key "fubar". - - - -Kalt Informational [Page 16] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - JOIN #foo,&bar fubar ; Command to join channel #foo using - key "fubar" and &bar using no key. - - JOIN #foo,#bar fubar,foobar ; Command to join channel #foo using - key "fubar", and channel #bar using - key "foobar". - - JOIN #foo,#bar ; Command to join channels #foo and - #bar. - - JOIN 0 ; Leave all currently joined - channels. - - :WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone ; JOIN message from WiZ - on channel #Twilight_zone - -3.2.2 Part message - - Command: PART - Parameters: *( "," ) [ ] - - The PART command causes the user sending the message to be removed - from the list of active members for all given channels listed in the - parameter string. If a "Part Message" is given, this will be sent - instead of the default message, the nickname. This request is always - granted by the server. - - Servers MUST be able to parse arguments in the form of a list of - target, but SHOULD NOT use lists when sending PART messages to - clients. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL - ERR_NOTONCHANNEL - - Examples: - - PART #twilight_zone ; Command to leave channel - "#twilight_zone" - - PART #oz-ops,&group5 ; Command to leave both channels - "&group5" and "#oz-ops". - - :WiZ!jto@tolsun.oulu.fi PART #playzone :I lost - ; User WiZ leaving channel - "#playzone" with the message "I - lost". - - - -Kalt Informational [Page 17] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - -3.2.3 Channel mode message - - Command: MODE - Parameters: *( ( "-" / "+" ) * * ) - - The MODE command is provided so that users may query and change the - characteristics of a channel. For more details on available modes - and their uses, see "Internet Relay Chat: Channel Management" [IRC- - CHAN]. Note that there is a maximum limit of three (3) changes per - command for modes that take a parameter. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_KEYSET - ERR_NOCHANMODES ERR_CHANOPRIVSNEEDED - ERR_USERNOTINCHANNEL ERR_UNKNOWNMODE - RPL_CHANNELMODEIS - RPL_BANLIST RPL_ENDOFBANLIST - RPL_EXCEPTLIST RPL_ENDOFEXCEPTLIST - RPL_INVITELIST RPL_ENDOFINVITELIST - RPL_UNIQOPIS - - The following examples are given to help understanding the syntax of - the MODE command, but refer to modes defined in "Internet Relay Chat: - Channel Management" [IRC-CHAN]. - - Examples: - - MODE #Finnish +imI *!*@*.fi ; Command to make #Finnish channel - moderated and 'invite-only' with user - with a hostname matching *.fi - automatically invited. - - MODE #Finnish +o Kilroy ; Command to give 'chanop' privileges - to Kilroy on channel #Finnish. - - MODE #Finnish +v Wiz ; Command to allow WiZ to speak on - #Finnish. - - MODE #Fins -s ; Command to remove 'secret' flag - from channel #Fins. - - MODE #42 +k oulu ; Command to set the channel key to - "oulu". - - MODE #42 -k oulu ; Command to remove the "oulu" - channel key on channel "#42". - - - - -Kalt Informational [Page 18] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - MODE #eu-opers +l 10 ; Command to set the limit for the - number of users on channel - "#eu-opers" to 10. - - :WiZ!jto@tolsun.oulu.fi MODE #eu-opers -l - ; User "WiZ" removing the limit for - the number of users on channel "#eu- - opers". - - MODE &oulu +b ; Command to list ban masks set for - the channel "&oulu". - - MODE &oulu +b *!*@* ; Command to prevent all users from - joining. - - MODE &oulu +b *!*@*.edu +e *!*@*.bu.edu - ; Command to prevent any user from a - hostname matching *.edu from joining, - except if matching *.bu.edu - - MODE #bu +be *!*@*.edu *!*@*.bu.edu - ; Comment to prevent any user from a - hostname matching *.edu from joining, - except if matching *.bu.edu - - MODE #meditation e ; Command to list exception masks set - for the channel "#meditation". - - MODE #meditation I ; Command to list invitations masks - set for the channel "#meditation". - - MODE !12345ircd O ; Command to ask who the channel - creator for "!12345ircd" is - -3.2.4 Topic message - - Command: TOPIC - Parameters: [ ] - - The TOPIC command is used to change or view the topic of a channel. - The topic for channel is returned if there is no - given. If the parameter is present, the topic for that - channel will be changed, if this action is allowed for the user - requesting it. If the parameter is an empty string, the - topic for that channel will be removed. - - - - - - -Kalt Informational [Page 19] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL - RPL_NOTOPIC RPL_TOPIC - ERR_CHANOPRIVSNEEDED ERR_NOCHANMODES - - Examples: - - :WiZ!jto@tolsun.oulu.fi TOPIC #test :New topic ; User Wiz setting the - topic. - - TOPIC #test :another topic ; Command to set the topic on #test - to "another topic". - - TOPIC #test : ; Command to clear the topic on - #test. - - TOPIC #test ; Command to check the topic for - #test. - -3.2.5 Names message - - Command: NAMES - Parameters: [ *( "," ) [ ] ] - - By using the NAMES command, a user can list all nicknames that are - visible to him. For more details on what is visible and what is not, - see "Internet Relay Chat: Channel Management" [IRC-CHAN]. The - parameter specifies which channel(s) to return information - about. There is no error reply for bad channel names. - - If no parameter is given, a list of all channels and their - occupants is returned. At the end of this list, a list of users who - are visible but either not on any channel or not on a visible channel - are listed as being on `channel' "*". - - If the parameter is specified, the request is forwarded to - that server which will generate the reply. - - Wildcards are allowed in the parameter. - - Numerics: - - ERR_TOOMANYMATCHES ERR_NOSUCHSERVER - RPL_NAMREPLY RPL_ENDOFNAMES - - - - - - -Kalt Informational [Page 20] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Examples: - - NAMES #twilight_zone,#42 ; Command to list visible users on - #twilight_zone and #42 - - NAMES ; Command to list all visible - channels and users - -3.2.6 List message - - Command: LIST - Parameters: [ *( "," ) [ ] ] - - The list command is used to list channels and their topics. If the - parameter is used, only the status of that channel is - displayed. - - If the parameter is specified, the request is forwarded to - that server which will generate the reply. - - Wildcards are allowed in the parameter. - - Numeric Replies: - - ERR_TOOMANYMATCHES ERR_NOSUCHSERVER - RPL_LIST RPL_LISTEND - - Examples: - - LIST ; Command to list all channels. - - LIST #twilight_zone,#42 ; Command to list channels - #twilight_zone and #42 - -3.2.7 Invite message - - Command: INVITE - Parameters: - - The INVITE command is used to invite a user to a channel. The - parameter is the nickname of the person to be invited to - the target channel . There is no requirement that the - channel the target user is being invited to must exist or be a valid - channel. However, if the channel exists, only members of the channel - are allowed to invite other users. When the channel has invite-only - flag set, only channel operators may issue INVITE command. - - - - - -Kalt Informational [Page 21] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Only the user inviting and the user being invited will receive - notification of the invitation. Other channel members are not - notified. (This is unlike the MODE changes, and is occasionally the - source of trouble for users.) - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_NOSUCHNICK - ERR_NOTONCHANNEL ERR_USERONCHANNEL - ERR_CHANOPRIVSNEEDED - RPL_INVITING RPL_AWAY - - Examples: - - :Angel!wings@irc.org INVITE Wiz #Dust - - ; Message to WiZ when he has been - invited by user Angel to channel - #Dust - - INVITE Wiz #Twilight_Zone ; Command to invite WiZ to - #Twilight_zone - -3.2.8 Kick command - - Command: KICK - Parameters: *( "," ) *( "," ) - [] - - The KICK command can be used to request the forced removal of a user - from a channel. It causes the to PART from the by - force. For the message to be syntactically correct, there MUST be - either one channel parameter and multiple user parameter, or as many - channel parameters as there are user parameters. If a "comment" is - given, this will be sent instead of the default message, the nickname - of the user issuing the KICK. - - The server MUST NOT send KICK messages with multiple channels or - users to clients. This is necessarily to maintain backward - compatibility with old client software. - - Numeric Replies: - - ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL - ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED - ERR_USERNOTINCHANNEL ERR_NOTONCHANNEL - - - - - -Kalt Informational [Page 22] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Examples: - - KICK &Melbourne Matthew ; Command to kick Matthew from - &Melbourne - - KICK #Finnish John :Speaking English - ; Command to kick John from #Finnish - using "Speaking English" as the - reason (comment). - - :WiZ!jto@tolsun.oulu.fi KICK #Finnish John - ; KICK message on channel #Finnish - from WiZ to remove John from channel - -3.3 Sending messages - - The main purpose of the IRC protocol is to provide a base for clients - to communicate with each other. PRIVMSG, NOTICE and SQUERY - (described in Section 3.5 on Service Query and Commands) are the only - messages available which actually perform delivery of a text message - from one client to another - the rest just make it possible and try - to ensure it happens in a reliable and structured manner. - -3.3.1 Private messages - - Command: PRIVMSG - Parameters: - - PRIVMSG is used to send private messages between users, as well as to - send messages to channels. is usually the nickname of - the recipient of the message, or a channel name. - - The parameter may also be a host mask (#) or server - mask ($). In both cases the server will only send the PRIVMSG - to those who have a server or host matching the mask. The mask MUST - have at least 1 (one) "." in it and no wildcards following the last - ".". This requirement exists to prevent people sending messages to - "#*" or "$*", which would broadcast to all users. Wildcards are the - '*' and '?' characters. This extension to the PRIVMSG command is - only available to operators. - - Numeric Replies: - - ERR_NORECIPIENT ERR_NOTEXTTOSEND - ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL - ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS - ERR_NOSUCHNICK - RPL_AWAY - - - -Kalt Informational [Page 23] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Examples: - - :Angel!wings@irc.org PRIVMSG Wiz :Are you receiving this message ? - ; Message from Angel to Wiz. - - PRIVMSG Angel :yes I'm receiving it ! - ; Command to send a message to Angel. - - PRIVMSG jto@tolsun.oulu.fi :Hello ! - ; Command to send a message to a user - on server tolsun.oulu.fi with - username of "jto". - - PRIVMSG kalt%millennium.stealth.net@irc.stealth.net :Are you a frog? - ; Message to a user on server - irc.stealth.net with username of - "kalt", and connected from the host - millennium.stealth.net. - - PRIVMSG kalt%millennium.stealth.net :Do you like cheese? - ; Message to a user on the local - server with username of "kalt", and - connected from the host - millennium.stealth.net. - - PRIVMSG Wiz!jto@tolsun.oulu.fi :Hello ! - ; Message to the user with nickname - Wiz who is connected from the host - tolsun.oulu.fi and has the username - "jto". - - PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting. - ; Message to everyone on a server - which has a name matching *.fi. - - PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions - ; Message to all users who come from - a host which has a name matching - *.edu. - -3.3.2 Notice - - Command: NOTICE - Parameters: - - The NOTICE command is used similarly to PRIVMSG. The difference - between NOTICE and PRIVMSG is that automatic replies MUST NEVER be - sent in response to a NOTICE message. This rule applies to servers - - - -Kalt Informational [Page 24] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - too - they MUST NOT send any error reply back to the client on - receipt of a notice. The object of this rule is to avoid loops - between clients automatically sending something in response to - something it received. - - This command is available to services as well as users. - - This is typically used by services, and automatons (clients with - either an AI or other interactive program controlling their actions). - - See PRIVMSG for more details on replies and examples. - -3.4 Server queries and commands - - The server query group of commands has been designed to return - information about any server which is connected to the network. - - In these queries, where a parameter appears as , wildcard - masks are usually valid. For each parameter, however, only one query - and set of replies is to be generated. In most cases, if a nickname - is given, it will mean the server to which the user is connected. - - These messages typically have little value for services, it is - therefore RECOMMENDED to forbid services from using them. - -3.4.1 Motd message - - Command: MOTD - Parameters: [ ] - - The MOTD command is used to get the "Message Of The Day" of the given - server, or current server if is omitted. - - Wildcards are allowed in the parameter. - - Numeric Replies: - RPL_MOTDSTART RPL_MOTD - RPL_ENDOFMOTD ERR_NOMOTD - -3.4.2 Lusers message - - Command: LUSERS - Parameters: [ [ ] ] - - The LUSERS command is used to get statistics about the size of the - IRC network. If no parameter is given, the reply will be about the - whole net. If a is specified, then the reply will only - - - - -Kalt Informational [Page 25] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - concern the part of the network formed by the servers matching the - mask. Finally, if the parameter is specified, the request - is forwarded to that server which will generate the reply. - - Wildcards are allowed in the parameter. - - Numeric Replies: - - RPL_LUSERCLIENT RPL_LUSEROP - RPL_LUSERUNKOWN RPL_LUSERCHANNELS - RPL_LUSERME ERR_NOSUCHSERVER - -3.4.3 Version message - - Command: VERSION - Parameters: [ ] - - The VERSION command is used to query the version of the server - program. An optional parameter is used to query the version - of the server program which a client is not directly connected to. - - Wildcards are allowed in the parameter. - - Numeric Replies: - - ERR_NOSUCHSERVER RPL_VERSION - - Examples: - - VERSION tolsun.oulu.fi ; Command to check the version of - server "tolsun.oulu.fi". - -3.4.4 Stats message - - Command: STATS - Parameters: [ [ ] ] - - The stats command is used to query statistics of certain server. If - parameter is omitted, only the end of stats reply is sent - back. - - A query may be given for any single letter which is only checked by - the destination server and is otherwise passed on by intermediate - servers, ignored and unaltered. - - Wildcards are allowed in the parameter. - - - - - -Kalt Informational [Page 26] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Except for the ones below, the list of valid queries is - implementation dependent. The standard queries below SHOULD be - supported by the server: - - l - returns a list of the server's connections, showing how - long each connection has been established and the - traffic over that connection in Kbytes and messages for - each direction; - m - returns the usage count for each of commands supported - by the server; commands for which the usage count is - zero MAY be omitted; - o - returns a list of configured privileged users, - operators; - u - returns a string showing how long the server has been - up. - - It is also RECOMMENDED that client and server access configuration be - published this way. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_STATSLINKINFO RPL_STATSUPTIME - RPL_STATSCOMMANDS RPL_STATSOLINE - RPL_ENDOFSTATS - - Examples: - - STATS m ; Command to check the command usage - for the server you are connected to - -3.4.5 Links message - - Command: LINKS - Parameters: [ [ ] ] - - With LINKS, a user can list all servernames, which are known by the - server answering the query. The returned list of servers MUST match - the mask, or if no mask is given, the full list is returned. - - If is given in addition to , the LINKS - command is forwarded to the first server found that matches that name - (if any), and that server is then required to answer the query. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_LINKS RPL_ENDOFLINKS - - - -Kalt Informational [Page 27] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Examples: - - LINKS *.au ; Command to list all servers which - have a name that matches *.au; - - LINKS *.edu *.bu.edu ; Command to list servers matching - *.bu.edu as seen by the first server - matching *.edu. - -3.4.6 Time message - - Command: TIME - Parameters: [ ] - - The time command is used to query local time from the specified - server. If the parameter is not given, the server receiving - the command must reply to the query. - - Wildcards are allowed in the parameter. - - Numeric Replies: - - ERR_NOSUCHSERVER RPL_TIME - - Examples: - TIME tolsun.oulu.fi ; check the time on the server - "tolson.oulu.fi" - -3.4.7 Connect message - - Command: CONNECT - Parameters: [ ] - - The CONNECT command can be used to request a server to try to - establish a new connection to another server immediately. CONNECT is - a privileged command and SHOULD be available only to IRC Operators. - If a is given and its mask doesn't match name of the - parsing server, the CONNECT attempt is sent to the first match of - remote server. Otherwise the CONNECT attempt is made by the server - processing the request. - - The server receiving a remote CONNECT command SHOULD generate a - WALLOPS message describing the source and target of the request. - - Numeric Replies: - - ERR_NOSUCHSERVER ERR_NOPRIVILEGES - ERR_NEEDMOREPARAMS - - - -Kalt Informational [Page 28] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Examples: - - CONNECT tolsun.oulu.fi 6667 ; Command to attempt to connect local - server to tolsun.oulu.fi on port 6667 - -3.4.8 Trace message - - Command: TRACE - Parameters: [ ] - - TRACE command is used to find the route to specific server and - information about its peers. Each server that processes this command - MUST report to the sender about it. The replies from pass-through - links form a chain, which shows route to destination. After sending - this reply back, the query MUST be sent to the next server until - given server is reached. - - TRACE command is used to find the route to specific server. Each - server that processes this message MUST tell the sender about it by - sending a reply indicating it is a pass-through link, forming a chain - of replies. After sending this reply back, it MUST then send the - TRACE message to the next server until given server is reached. If - the parameter is omitted, it is RECOMMENDED that TRACE - command sends a message to the sender telling which servers the local - server has direct connection to. - - If the destination given by is an actual server, the - destination server is REQUIRED to report all servers, services and - operators which are connected to it; if the command was issued by an - operator, the server MAY also report all users which are connected to - it. If the destination given by is a nickname, then only a - reply for that nickname is given. If the parameter is - omitted, it is RECOMMENDED that the TRACE command is parsed as - targeted to the processing server. - - Wildcards are allowed in the parameter. - - Numeric Replies: - - ERR_NOSUCHSERVER - - If the TRACE message is destined for another server, all - intermediate servers must return a RPL_TRACELINK reply to indicate - that the TRACE passed through it and where it is going next. - - RPL_TRACELINK - - - - - -Kalt Informational [Page 29] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - A TRACE reply may be composed of any number of the following - numeric replies. - - RPL_TRACECONNECTING RPL_TRACEHANDSHAKE - RPL_TRACEUNKNOWN RPL_TRACEOPERATOR - RPL_TRACEUSER RPL_TRACESERVER - RPL_TRACESERVICE RPL_TRACENEWTYPE - RPL_TRACECLASS RPL_TRACELOG - RPL_TRACEEND - - Examples: - - TRACE *.oulu.fi ; TRACE to a server matching - *.oulu.fi - -3.4.9 Admin command - - Command: ADMIN - Parameters: [ ] - - The admin command is used to find information about the administrator - of the given server, or current server if parameter is - omitted. Each server MUST have the ability to forward ADMIN messages - to other servers. - - Wildcards are allowed in the parameter. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_ADMINME RPL_ADMINLOC1 - RPL_ADMINLOC2 RPL_ADMINEMAIL - - Examples: - - ADMIN tolsun.oulu.fi ; request an ADMIN reply from - tolsun.oulu.fi - - ADMIN syrk ; ADMIN request for the server to - which the user syrk is connected - - - - - - - - - - - -Kalt Informational [Page 30] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - -3.4.10 Info command - - Command: INFO - Parameters: [ ] - - The INFO command is REQUIRED to return information describing the - server: its version, when it was compiled, the patchlevel, when it - was started, and any other miscellaneous information which may be - considered to be relevant. - - Wildcards are allowed in the parameter. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_INFO RPL_ENDOFINFO - - Examples: - - INFO csd.bu.edu ; request an INFO reply from - csd.bu.edu - - INFO Angel ; request info from the server that - Angel is connected to. - -3.5 Service Query and Commands - - The service query group of commands has been designed to return - information about any service which is connected to the network. - -3.5.1 Servlist message - - Command: SERVLIST - Parameters: [ [ ] ] - - The SERVLIST command is used to list services currently connected to - the network and visible to the user issuing the command. The - optional parameters may be used to restrict the result of the query - (to matching services names, and services type). - - Numeric Replies: - - RPL_SERVLIST RPL_SERVLISTEND - - - - - - - - -Kalt Informational [Page 31] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - -3.5.2 Squery - - Command: SQUERY - Parameters: - - The SQUERY command is used similarly to PRIVMSG. The only difference - is that the recipient MUST be a service. This is the only way for a - text message to be delivered to a service. - - See PRIVMSG for more details on replies and example. - - Examples: - - SQUERY irchelp :HELP privmsg - ; Message to the service with - nickname irchelp. - - SQUERY dict@irc.fr :fr2en blaireau - ; Message to the service with name - dict@irc.fr. - -3.6 User based queries - - User queries are a group of commands which are primarily concerned - with finding details on a particular user or group users. When using - wildcards with any of these commands, if they match, they will only - return information on users who are 'visible' to you. The visibility - of a user is determined as a combination of the user's mode and the - common set of channels you are both on. - - Although services SHOULD NOT be using this class of message, they are - allowed to. - -3.6.1 Who query - - Command: WHO - Parameters: [ [ "o" ] ] - - The WHO command is used by a client to generate a query which returns - a list of information which 'matches' the parameter given by - the client. In the absence of the parameter, all visible - (users who aren't invisible (user mode +i) and who don't have a - common channel with the requesting client) are listed. The same - result can be achieved by using a of "0" or any wildcard which - will end up matching every visible user. - - The passed to WHO is matched against users' host, server, real - name and nickname if the channel cannot be found. - - - -Kalt Informational [Page 32] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - If the "o" parameter is passed only operators are returned according - to the supplied. - - Numeric Replies: - - ERR_NOSUCHSERVER - RPL_WHOREPLY RPL_ENDOFWHO - - Examples: - - WHO *.fi ; Command to list all users who match - against "*.fi". - - WHO jto* o ; Command to list all users with a - match against "jto*" if they are an - operator. - -3.6.2 Whois query - - Command: WHOIS - Parameters: [ ] *( "," ) - - This command is used to query information about particular user. - The server will answer this command with several numeric messages - indicating different statuses of each user which matches the mask (if - you are entitled to see them). If no wildcard is present in the - , any information about that nick which you are allowed to see - is presented. - - If the parameter is specified, it sends the query to a - specific server. It is useful if you want to know how long the user - in question has been idle as only local server (i.e., the server the - user is directly connected to) knows that information, while - everything else is globally known. - - Wildcards are allowed in the parameter. - - Numeric Replies: - - ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN - RPL_WHOISUSER RPL_WHOISCHANNELS - RPL_WHOISCHANNELS RPL_WHOISSERVER - RPL_AWAY RPL_WHOISOPERATOR - RPL_WHOISIDLE ERR_NOSUCHNICK - RPL_ENDOFWHOIS - - - - - - -Kalt Informational [Page 33] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Examples: - - WHOIS wiz ; return available user information - about nick WiZ - - WHOIS eff.org trillian ; ask server eff.org for user - information about trillian - -3.6.3 Whowas - - Command: WHOWAS - Parameters: *( "," ) [ [ ] ] - - Whowas asks for information about a nickname which no longer exists. - This may either be due to a nickname change or the user leaving IRC. - In response to this query, the server searches through its nickname - history, looking for any nicks which are lexically the same (no wild - card matching here). The history is searched backward, returning the - most recent entry first. If there are multiple entries, up to - replies will be returned (or all of them if no - parameter is given). If a non-positive number is passed as being - , then a full search is done. - - Wildcards are allowed in the parameter. - - Numeric Replies: - - ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK - RPL_WHOWASUSER RPL_WHOISSERVER - RPL_ENDOFWHOWAS - - Examples: - - WHOWAS Wiz ; return all information in the nick - history about nick "WiZ"; - - WHOWAS Mermaid 9 ; return at most, the 9 most recent - entries in the nick history for - "Mermaid"; - - WHOWAS Trillian 1 *.edu ; return the most recent history for - "Trillian" from the first server - found to match "*.edu". - -3.7 Miscellaneous messages - - Messages in this category do not fit into any of the above categories - but are nonetheless still a part of and REQUIRED by the protocol. - - - -Kalt Informational [Page 34] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - -3.7.1 Kill message - - Command: KILL - Parameters: - - The KILL command is used to cause a client-server connection to be - closed by the server which has the actual connection. Servers - generate KILL messages on nickname collisions. It MAY also be - available available to users who have the operator status. - - Clients which have automatic reconnect algorithms effectively make - this command useless since the disconnection is only brief. It does - however break the flow of data and can be used to stop large amounts - of 'flooding' from abusive users or accidents. Abusive users usually - don't care as they will reconnect promptly and resume their abusive - behaviour. To prevent this command from being abused, any user may - elect to receive KILL messages generated for others to keep an 'eye' - on would be trouble spots. - - In an arena where nicknames are REQUIRED to be globally unique at all - times, KILL messages are sent whenever 'duplicates' are detected - (that is an attempt to register two users with the same nickname) in - the hope that both of them will disappear and only 1 reappear. - - When a client is removed as the result of a KILL message, the server - SHOULD add the nickname to the list of unavailable nicknames in an - attempt to avoid clients to reuse this name immediately which is - usually the pattern of abusive behaviour often leading to useless - "KILL loops". See the "IRC Server Protocol" document [IRC-SERVER] - for more information on this procedure. - - The comment given MUST reflect the actual reason for the KILL. For - server-generated KILLs it usually is made up of details concerning - the origins of the two conflicting nicknames. For users it is left - up to them to provide an adequate reason to satisfy others who see - it. To prevent/discourage fake KILLs from being generated to hide - the identify of the KILLer, the comment also shows a 'kill-path' - which is updated by each server it passes through, each prepending - its name to the path. - - Numeric Replies: - - ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS - ERR_NOSUCHNICK ERR_CANTKILLSERVER - - - - - - - -Kalt Informational [Page 35] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - NOTE: - It is RECOMMENDED that only Operators be allowed to kill other users - with KILL command. This command has been the subject of many - controversies over the years, and along with the above - recommendation, it is also widely recognized that not even operators - should be allowed to kill users on remote servers. - -3.7.2 Ping message - - Command: PING - Parameters: [ ] - - The PING command is used to test the presence of an active client or - server at the other end of the connection. Servers send a PING - message at regular intervals if no other activity detected coming - from a connection. If a connection fails to respond to a PING - message within a set amount of time, that connection is closed. A - PING message MAY be sent even if the connection is active. - - When a PING message is received, the appropriate PONG message MUST be - sent as reply to (server which sent the PING message out) - as soon as possible. If the parameter is specified, it - represents the target of the ping, and the message gets forwarded - there. - - Numeric Replies: - - ERR_NOORIGIN ERR_NOSUCHSERVER - - Examples: - - PING tolsun.oulu.fi ; Command to send a PING message to - server - - PING WiZ tolsun.oulu.fi ; Command from WiZ to send a PING - message to server "tolsun.oulu.fi" - - PING :irc.funet.fi ; Ping message sent by server - "irc.funet.fi" - - - - - - - - - - - - -Kalt Informational [Page 36] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - -3.7.3 Pong message - - Command: PONG - Parameters: [ ] - - PONG message is a reply to ping message. If parameter is - given, this message MUST be forwarded to given target. The - parameter is the name of the entity who has responded to PING message - and generated this message. - - Numeric Replies: - - ERR_NOORIGIN ERR_NOSUCHSERVER - - Example: - - PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to - tolsun.oulu.fi - -3.7.4 Error - - Command: ERROR - Parameters: - - The ERROR command is for use by servers when reporting a serious or - fatal error to its peers. It may also be sent from one server to - another but MUST NOT be accepted from any normal unknown clients. - - Only an ERROR message SHOULD be used for reporting errors which occur - with a server-to-server link. An ERROR message is sent to the server - at the other end (which reports it to appropriate local users and - logs) and to appropriate local users and logs. It is not to be - passed onto any other servers by a server if it is received from a - server. - - The ERROR message is also used before terminating a client - connection. - - When a server sends a received ERROR message to its operators, the - message SHOULD be encapsulated inside a NOTICE message, indicating - that the client was not responsible for the error. - - Numerics: - - None. - - - - - - -Kalt Informational [Page 37] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Examples: - - ERROR :Server *.fi already exists ; ERROR message to the other server - which caused this error. - - NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists - ; Same ERROR message as above but - sent to user WiZ on the other server. - -4. Optional features - - This section describes OPTIONAL messages. They are not required in a - working server implementation of the protocol described herein. In - the absence of the feature, an error reply message MUST be generated - or an unknown command error. If the message is destined for another - server to answer then it MUST be passed on (elementary parsing - REQUIRED) The allocated numerics for this are listed with the - messages below. - - From this section, only the USERHOST and ISON messages are available - to services. - -4.1 Away - - Command: AWAY - Parameters: [ ] - - With the AWAY command, clients can set an automatic reply string for - any PRIVMSG commands directed at them (not to a channel they are on). - The server sends an automatic reply to the client sending the PRIVMSG - command. The only replying server is the one to which the sending - client is connected to. - - The AWAY command is used either with one parameter, to set an AWAY - message, or with no parameters, to remove the AWAY message. - - Because of its high cost (memory and bandwidth wise), the AWAY - message SHOULD only be used for client-server communication. A - server MAY choose to silently ignore AWAY messages received from - other servers. To update the away status of a client across servers, - the user mode 'a' SHOULD be used instead. (See Section 3.1.5) - - Numeric Replies: - - RPL_UNAWAY RPL_NOWAWAY - - - - - - -Kalt Informational [Page 38] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Example: - - AWAY :Gone to lunch. Back in 5 ; Command to set away message to - "Gone to lunch. Back in 5". - -4.2 Rehash message - - Command: REHASH - Parameters: None - - The rehash command is an administrative command which can be used by - an operator to force the server to re-read and process its - configuration file. - - Numeric Replies: - - RPL_REHASHING ERR_NOPRIVILEGES - - - Example: - - REHASH ; message from user with operator - status to server asking it to reread - its configuration file. - -4.3 Die message - - Command: DIE - Parameters: None - - An operator can use the DIE command to shutdown the server. This - message is optional since it may be viewed as a risk to allow - arbitrary people to connect to a server as an operator and execute - this command. - - The DIE command MUST always be fully processed by the server to which - the sending client is connected and MUST NOT be passed onto other - connected servers. - - Numeric Replies: - - ERR_NOPRIVILEGES - - Example: - - DIE ; no parameters required. - - - - - -Kalt Informational [Page 39] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - -4.4 Restart message - - Command: RESTART - Parameters: None - - An operator can use the restart command to force the server to - restart itself. This message is optional since it may be viewed as a - risk to allow arbitrary people to connect to a server as an operator - and execute this command, causing (at least) a disruption to service. - - The RESTART command MUST always be fully processed by the server to - which the sending client is connected and MUST NOT be passed onto - other connected servers. - - Numeric Replies: - - ERR_NOPRIVILEGES - - Example: - - RESTART ; no parameters required. - -4.5 Summon message - - Command: SUMMON - Parameters: [ [ ] ] - - The SUMMON command can be used to give users who are on a host - running an IRC server a message asking them to please join IRC. This - message is only sent if the target server (a) has SUMMON enabled, (b) - the user is logged in and (c) the server process can write to the - user's tty (or similar). - - If no parameter is given it tries to summon from the - server the client is connected to is assumed as the target. - - If summon is not enabled in a server, it MUST return the - ERR_SUMMONDISABLED numeric. - - Numeric Replies: - - ERR_NORECIPIENT ERR_FILEERROR - ERR_NOLOGIN ERR_NOSUCHSERVER - ERR_SUMMONDISABLED RPL_SUMMONING - - - - - - - -Kalt Informational [Page 40] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - Examples: - - SUMMON jto ; summon user jto on the server's - host - - SUMMON jto tolsun.oulu.fi ; summon user jto on the host which a - server named "tolsun.oulu.fi" is - running. - -4.6 Users - - Command: USERS - Parameters: [ ] - - The USERS command returns a list of users logged into the server in a - format similar to the UNIX commands who(1), rusers(1) and finger(1). - If disabled, the correct numeric MUST be returned to indicate this. - - Because of the security implications of such a command, it SHOULD be - disabled by default in server implementations. Enabling it SHOULD - require recompiling the server or some equivalent change rather than - simply toggling an option and restarting the server. The procedure - to enable this command SHOULD also include suitable large comments. - - Numeric Replies: - - ERR_NOSUCHSERVER ERR_FILEERROR - RPL_USERSSTART RPL_USERS - RPL_NOUSERS RPL_ENDOFUSERS - ERR_USERSDISABLED - - Disabled Reply: - - ERR_USERSDISABLED - - Example: - - USERS eff.org ; request a list of users logged in - on server eff.org - -4.7 Operwall message - - Command: WALLOPS - Parameters: - - The WALLOPS command is used to send a message to all currently - connected users who have set the 'w' user mode for themselves. (See - Section 3.1.5 "User modes"). - - - -Kalt Informational [Page 41] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - After implementing WALLOPS as a user command it was found that it was - often and commonly abused as a means of sending a message to a lot of - people. Due to this, it is RECOMMENDED that the implementation of - WALLOPS allows and recognizes only servers as the originators of - WALLOPS. - - Numeric Replies: - - ERR_NEEDMOREPARAMS - - Example: - - :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua ; WALLOPS - message from csd.bu.edu announcing a - CONNECT message it received from - Joshua and acted upon. - -4.8 Userhost message - - Command: USERHOST - Parameters: *( SPACE ) - - The USERHOST command takes a list of up to 5 nicknames, each - separated by a space character and returns a list of information - about each nickname that it found. The returned list has each reply - separated by a space. - - Numeric Replies: - - RPL_USERHOST ERR_NEEDMOREPARAMS - - Example: - - USERHOST Wiz Michael syrk ; USERHOST request for information on - nicks "Wiz", "Michael", and "syrk" - - :ircd.stealth.net 302 yournick :syrk=+syrk@millennium.stealth.net - ; Reply for user syrk - -4.9 Ison message - - Command: ISON - Parameters: *( SPACE ) - - The ISON command was implemented to provide a quick and efficient - means to get a response about whether a given nickname was currently - on IRC. ISON only takes one (1) type of parameter: a space-separated - list of nicks. For each nickname in the list that is present, the - - - -Kalt Informational [Page 42] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - server adds that to its reply string. Thus the reply string may - return empty (none of the given nicks are present), an exact copy of - the parameter string (all of them present) or any other subset of the - set of nicks given in the parameter. The only limit on the number of - nicks that may be checked is that the combined length MUST NOT be too - large as to cause the server to chop it off so it fits in 512 - characters. - - ISON is only processed by the server local to the client sending the - command and thus not passed onto other servers for further - processing. - - Numeric Replies: - - RPL_ISON ERR_NEEDMOREPARAMS - - Example: - - ISON phone trillian WiZ jarlek Avalon Angel Monstah syrk - ; Sample ISON request for 7 nicks. - -5. Replies - - The following is a list of numeric replies which are generated in - response to the commands given above. Each numeric is given with its - number, name and reply string. - -5.1 Command responses - - Numerics in the range from 001 to 099 are used for client-server - connections only and should never travel between servers. Replies - generated in the response to commands are found in the range from 200 - to 399. - - 001 RPL_WELCOME - "Welcome to the Internet Relay Network - !@" - 002 RPL_YOURHOST - "Your host is , running version " - 003 RPL_CREATED - "This server was created " - 004 RPL_MYINFO - " - " - - - The server sends Replies 001 to 004 to a user upon - successful registration. - - - - -Kalt Informational [Page 43] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - 005 RPL_BOUNCE - "Try server , port " - - - Sent by the server to a user to suggest an alternative - server. This is often used when the connection is - refused because the server is already full. - - 302 RPL_USERHOST - ":*1 *( " " )" - - - Reply format used by USERHOST to list replies to - the query list. The reply string is composed as - follows: - - reply = nickname [ "*" ] "=" ( "+" / "-" ) hostname - - The '*' indicates whether the client has registered - as an Operator. The '-' or '+' characters represent - whether the client has set an AWAY message or not - respectively. - - 303 RPL_ISON - ":*1 *( " " )" - - - Reply format used by ISON to list replies to the - query list. - - 301 RPL_AWAY - " :" - 305 RPL_UNAWAY - ":You are no longer marked as being away" - 306 RPL_NOWAWAY - ":You have been marked as being away" - - - These replies are used with the AWAY command (if - allowed). RPL_AWAY is sent to any client sending a - PRIVMSG to a client which is away. RPL_AWAY is only - sent by the server to which the client is connected. - Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the - client removes and sets an AWAY message. - - 311 RPL_WHOISUSER - " * :" - 312 RPL_WHOISSERVER - " :" - 313 RPL_WHOISOPERATOR - " :is an IRC operator" - - - - -Kalt Informational [Page 44] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - 317 RPL_WHOISIDLE - " :seconds idle" - 318 RPL_ENDOFWHOIS - " :End of WHOIS list" - 319 RPL_WHOISCHANNELS - " :*( ( "@" / "+" ) " " )" - - - Replies 311 - 313, 317 - 319 are all replies - generated in response to a WHOIS message. Given that - there are enough parameters present, the answering - server MUST either formulate a reply out of the above - numerics (if the query nick is found) or return an - error reply. The '*' in RPL_WHOISUSER is there as - the literal character and not as a wild card. For - each reply set, only RPL_WHOISCHANNELS may appear - more than once (for long lists of channel names). - The '@' and '+' characters next to the channel name - indicate whether a client is a channel operator or - has been granted permission to speak on a moderated - channel. The RPL_ENDOFWHOIS reply is used to mark - the end of processing a WHOIS message. - - 314 RPL_WHOWASUSER - " * :" - 369 RPL_ENDOFWHOWAS - " :End of WHOWAS" - - - When replying to a WHOWAS message, a server MUST use - the replies RPL_WHOWASUSER, RPL_WHOISSERVER or - ERR_WASNOSUCHNICK for each nickname in the presented - list. At the end of all reply batches, there MUST - be RPL_ENDOFWHOWAS (even if there was only one reply - and it was an error). - - 321 RPL_LISTSTART - Obsolete. Not used. - - 322 RPL_LIST - " <# visible> :" - 323 RPL_LISTEND - ":End of LIST" - - - Replies RPL_LIST, RPL_LISTEND mark the actual replies - with data and end of the server's response to a LIST - command. If there are no channels available to return, - only the end reply MUST be sent. - - - - - -Kalt Informational [Page 45] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - 325 RPL_UNIQOPIS - " " - - 324 RPL_CHANNELMODEIS - " " - - 331 RPL_NOTOPIC - " :No topic is set" - 332 RPL_TOPIC - " :" - - - When sending a TOPIC message to determine the - channel topic, one of two replies is sent. If - the topic is set, RPL_TOPIC is sent back else - RPL_NOTOPIC. - - 341 RPL_INVITING - " " - - - Returned by the server to indicate that the - attempted INVITE message was successful and is - being passed onto the end client. - - 342 RPL_SUMMONING - " :Summoning user to IRC" - - - Returned by a server answering a SUMMON message to - indicate that it is summoning that user. - - 346 RPL_INVITELIST - " " - 347 RPL_ENDOFINVITELIST - " :End of channel invite list" - - - When listing the 'invitations masks' for a given channel, - a server is required to send the list back using the - RPL_INVITELIST and RPL_ENDOFINVITELIST messages. A - separate RPL_INVITELIST is sent for each active mask. - After the masks have been listed (or if none present) a - RPL_ENDOFINVITELIST MUST be sent. - - 348 RPL_EXCEPTLIST - " " - 349 RPL_ENDOFEXCEPTLIST - " :End of channel exception list" - - - - - - -Kalt Informational [Page 46] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - - When listing the 'exception masks' for a given channel, - a server is required to send the list back using the - RPL_EXCEPTLIST and RPL_ENDOFEXCEPTLIST messages. A - separate RPL_EXCEPTLIST is sent for each active mask. - After the masks have been listed (or if none present) - a RPL_ENDOFEXCEPTLIST MUST be sent. - - 351 RPL_VERSION - ". :" - - - Reply by the server showing its version details. - The is the version of the software being - used (including any patchlevel revisions) and the - is used to indicate if the server is - running in "debug mode". - - The "comments" field may contain any comments about - the version or further version details. - - 352 RPL_WHOREPLY - " - ( "H" / "G" > ["*"] [ ( "@" / "+" ) ] - : " - - 315 RPL_ENDOFWHO - " :End of WHO list" - - - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used - to answer a WHO message. The RPL_WHOREPLY is only - sent if there is an appropriate match to the WHO - query. If there is a list of parameters supplied - with a WHO message, a RPL_ENDOFWHO MUST be sent - after processing each list item with being - the item. - - 353 RPL_NAMREPLY - "( "=" / "*" / "@" ) - :[ "@" / "+" ] *( " " [ "@" / "+" ] ) - - "@" is used for secret channels, "*" for private - channels, and "=" for others (public channels). - - 366 RPL_ENDOFNAMES - " :End of NAMES list" - - - To reply to a NAMES message, a reply pair consisting - of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the - server back to the client. If there is no channel - found as in the query, then only RPL_ENDOFNAMES is - - - -Kalt Informational [Page 47] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - returned. The exception to this is when a NAMES - message is sent with no parameters and all visible - channels and contents are sent back in a series of - RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark - the end. - - 364 RPL_LINKS - " : " - 365 RPL_ENDOFLINKS - " :End of LINKS list" - - - In replying to the LINKS message, a server MUST send - replies back using the RPL_LINKS numeric and mark the - end of the list using an RPL_ENDOFLINKS reply. - - 367 RPL_BANLIST - " " - 368 RPL_ENDOFBANLIST - " :End of channel ban list" - - - When listing the active 'bans' for a given channel, - a server is required to send the list back using the - RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate - RPL_BANLIST is sent for each active banmask. After the - banmasks have been listed (or if none present) a - RPL_ENDOFBANLIST MUST be sent. - - 371 RPL_INFO - ":" - 374 RPL_ENDOFINFO - ":End of INFO list" - - - A server responding to an INFO message is required to - send all its 'info' in a series of RPL_INFO messages - with a RPL_ENDOFINFO reply to indicate the end of the - replies. - - 375 RPL_MOTDSTART - ":- Message of the day - " - 372 RPL_MOTD - ":- " - 376 RPL_ENDOFMOTD - ":End of MOTD command" - - - When responding to the MOTD message and the MOTD file - is found, the file is displayed line by line, with - each line no longer than 80 characters, using - - - - -Kalt Informational [Page 48] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - RPL_MOTD format replies. These MUST be surrounded - by a RPL_MOTDSTART (before the RPL_MOTDs) and an - RPL_ENDOFMOTD (after). - - 381 RPL_YOUREOPER - ":You are now an IRC operator" - - - RPL_YOUREOPER is sent back to a client which has - just successfully issued an OPER message and gained - operator status. - - 382 RPL_REHASHING - " :Rehashing" - - - If the REHASH option is used and an operator sends - a REHASH message, an RPL_REHASHING is sent back to - the operator. - - 383 RPL_YOURESERVICE - "You are service " - - - Sent by the server to a service upon successful - registration. - - 391 RPL_TIME - " :" - - - When replying to the TIME message, a server MUST send - the reply using the RPL_TIME format above. The string - showing the time need only contain the correct day and - time there. There is no further requirement for the - time string. - - 392 RPL_USERSSTART - ":UserID Terminal Host" - 393 RPL_USERS - ": " - 394 RPL_ENDOFUSERS - ":End of users" - 395 RPL_NOUSERS - ":Nobody logged in" - - - If the USERS message is handled by a server, the - replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and - RPL_NOUSERS are used. RPL_USERSSTART MUST be sent - first, following by either a sequence of RPL_USERS - or a single RPL_NOUSER. Following this is - RPL_ENDOFUSERS. - - - -Kalt Informational [Page 49] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - 200 RPL_TRACELINK - "Link - V - - " - 201 RPL_TRACECONNECTING - "Try. " - 202 RPL_TRACEHANDSHAKE - "H.S. " - 203 RPL_TRACEUNKNOWN - "???? []" - 204 RPL_TRACEOPERATOR - "Oper " - 205 RPL_TRACEUSER - "User " - 206 RPL_TRACESERVER - "Serv S C - @ V" - 207 RPL_TRACESERVICE - "Service " - 208 RPL_TRACENEWTYPE - " 0 " - 209 RPL_TRACECLASS - "Class " - 210 RPL_TRACERECONNECT - Unused. - 261 RPL_TRACELOG - "File " - 262 RPL_TRACEEND - " :End of TRACE" - - - The RPL_TRACE* are all returned by the server in - response to the TRACE message. How many are - returned is dependent on the TRACE message and - whether it was sent by an operator or not. There - is no predefined order for which occurs first. - Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and - RPL_TRACEHANDSHAKE are all used for connections - which have not been fully established and are either - unknown, still attempting to connect or in the - process of completing the 'server handshake'. - RPL_TRACELINK is sent by any server which handles - a TRACE message and has to pass it on to another - server. The list of RPL_TRACELINKs sent in - response to a TRACE command traversing the IRC - network should reflect the actual connectivity of - the servers themselves along that path. - - - - -Kalt Informational [Page 50] - -RFC 2812 Internet Relay Chat: Client Protocol April 2000 - - - RPL_TRACENEWTYPE is to be used for any connection - which does not fit in the other categories but is - being displayed anyway. - RPL_TRACEEND is sent to indicate the end of the list. - - 211 RPL_STATSLINKINFO - " - -