summaryrefslogtreecommitdiff
path: root/doc/technical
diff options
context:
space:
mode:
authormichael <michael@82007160-df01-0410-b94d-b575c5fd34c7>2012-10-27 21:02:32 +0000
committermichael <michael@82007160-df01-0410-b94d-b575c5fd34c7>2012-10-27 21:02:32 +0000
commit70f1558a2eca8295e30bb1e381d948056333634d (patch)
tree3051cb6afbc7d5ebae4381e54c70d9cbe54005a4 /doc/technical
parent4f1edcf052857117fd51e878c362f878961c4dc9 (diff)
- Second time's the charm? Moving svnroot/ircd-hybrid-8 to
svnroot/ircd-hybrid/trunk git-svn-id: svn://svn.ircd-hybrid.org/svnroot/ircd-hybrid/trunk@1592 82007160-df01-0410-b94d-b575c5fd34c7
Diffstat (limited to 'doc/technical')
-rw-r--r--doc/technical/draft-mitchell-irc-capabilities-01.txt1298
-rw-r--r--doc/technical/event.txt82
-rw-r--r--doc/technical/fd-management.txt47
-rw-r--r--doc/technical/hostmask.txt136
-rw-r--r--doc/technical/index.txt16
-rw-r--r--doc/technical/network.txt99
-rw-r--r--doc/technical/rfc1459.txt3110
-rw-r--r--doc/technical/rfc2812.txt2916
-rw-r--r--doc/technical/rfc2813.txt1173
-rw-r--r--doc/technical/send.txt262
-rw-r--r--doc/technical/ts3.txt321
-rw-r--r--doc/technical/ts5.txt147
-rw-r--r--doc/technical/ts6.txt267
13 files changed, 9874 insertions, 0 deletions
diff --git a/doc/technical/draft-mitchell-irc-capabilities-01.txt b/doc/technical/draft-mitchell-irc-capabilities-01.txt
new file mode 100644
index 0000000..f0c6736
--- /dev/null
+++ b/doc/technical/draft-mitchell-irc-capabilities-01.txt
@@ -0,0 +1,1298 @@
+
+Network Working Group K. Mitchell
+Internet-Draft P. Lorier
+Expires: September 5, 2005 Undernet IRC Network
+ L. Hardy
+ ircd-ratbox
+ P. Kucharski
+ IRCnet
+ March 7, 2005
+
+ IRC Client Capabilities Extension
+ draft-mitchell-irc-capabilities-01
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on September 5, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ IRC (Internet Relay Chat) is a long-standing protocol for real-time
+ chatting. The basic client-server protocol is a very simple
+ text-based protocol with no explicit mechanism for introducing or
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 1]
+Internet-Draft IRC CAP March 2005
+
+ negotiating backwards-incompatible extensions. This memo presents a
+ mechanism for negotiation of such extensions.
+
+Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in RFC
+ 2119 [1].
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+
+ 2. Problems to be Solved . . . . . . . . . . . . . . . . . . . . 4
+
+ 3. The CAP Command . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1 CAP LS . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.2 CAP LIST . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.3 CAP REQ . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.4 CAP ACK . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.5 CAP NAK . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.6 CAP CLEAR . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.7 CAP END . . . . . . . . . . . . . . . . . . . . . . . . . 8
+
+ 4. Capability Negotiation . . . . . . . . . . . . . . . . . . . . 10
+
+ 5. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.1 Capability Modifiers . . . . . . . . . . . . . . . . . . . 11
+
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
+
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
+
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
+
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
+
+ A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+
+ B. ABNF Description of Capabilities . . . . . . . . . . . . . . . 19
+
+ C. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+
+ Intellectual Property and Copyright Statements . . . . . . . . 28
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 2]
+Internet-Draft IRC CAP March 2005
+
+1. Introduction
+
+ The IRC protocol, as originally documented by RFC 1459 [2] and
+ updated by RFC 2812 [3], is a simple, text-based conferencing
+ protocol, involving a number of users spread across a number of
+ interconnected servers. These users may chat with other individual
+ users, or may chat with groups of users on "channels"--what other
+ chat systems refer to as "rooms" or "chat rooms".
+
+ Over the years, various extensions to the basic IRC protocol have
+ been made by IRC server programmers. Often, these extensions are
+ intended to conserve bandwidth, close loopholes left by the original
+ protocol specification, or add features for users or for the server
+ administrators. Most of these changes are backwards-compatible with
+ the original protocol specification: A command may be added, a reply
+ may be extended to contain more parameters, etc. Recently, however,
+ there has been a desire to introduce changes that would not be
+ backwards-compatible with existing IRC clients. Ideally, these
+ protocol changes would only be used with clients and servers that can
+ understand the revised protocol. Unfortunately, the IRC protocol
+ does not provide any form of extension or protocol negotiation,
+ making it impossible to determine support for such extensions.
+
+ This memo introduces a standardized mechanism for negotiation of
+ protocol extensions, known as *capabilities*, that will be
+ backwards-compatible with all existing IRC clients and servers. Any
+ server not implementing this extension will still interoperate with
+ clients that do implement it; similarly, clients that do not
+ implement the capabilities extension may successfully communicate
+ with a server that does implement the extension.
+
+
+
+
+
+
+
+
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 3]
+Internet-Draft IRC CAP March 2005
+
+2. Problems to be Solved
+
+ The IRC protocol is not a lockstep protocol. This means that a
+ client may issue additional commands before the server has finished
+ responding to the first one. Additionally, unlike other protocols,
+ the server does not necessarily issue a banner response upon initial
+ connection. This, combined with the fact that some servers do not
+ complain about unknown commands prior to completion of the client
+ registration phase, means that a client cannot know for certain
+ whether a server implements the extension. If a client had to wait
+ for a banner message, it would fail to interoperate with a server not
+ implementing the capabilities extension. If the client must issue a
+ command and then wait for a response, a similar problem results. As
+ some potential protocol extensions must be set up prior to completion
+ of the client registration phase, there is no reliable way a server
+ may indicate implementation of the capabilities extension to a
+ client.
+
+ The solution to these problems turns out to be to extend the client
+ registration procedure. The client sends a request to begin
+ capability negotiation, as well as the other information necessary
+ for client registration (user name, nick name, optional password,
+ etc.). If the server understands the capabilities extension, it will
+ suspend completion of the registration phase until the negotiation is
+ complete; negotiation may then proceed in a lockstep fashion. If the
+ server does not understand capabilities, then the registration will
+ complete immediately, and the client will receive the 001 numeric.
+ This will signal to the client that the server does not implement the
+ capabilities extension.
+
+
+
+
+
+
+
+
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 4]
+Internet-Draft IRC CAP March 2005
+
+3. The CAP Command
+
+ The capabilities extension is implemented by addition of one command
+ with several subcommands. The command added is *CAP*. CAP takes a
+ single, required subcommand, optionally followed by a single
+ parameter consisting of a space-separated list of capabilities. Each
+ capability within the list MAY be preceded by a capability modifier.
+ (Section 5.1)
+
+ The subcommands defined for CAP are:
+
+ 1. LS (Section 3.1)
+ 2. LIST (Section 3.2)
+ 3. REQ (Section 3.3)
+ 4. ACK (Section 3.4)
+ 5. NAK (Section 3.5)
+ 6. CLEAR (Section 3.6)
+ 7. END (Section 3.7)
+
+ The LS (Section 3.1), LIST (Section 3.2), REQ (Section 3.3), ACK
+ (Section 3.4), and NAK (Section 3.5) subcommands may be followed by a
+ single parameter consisting of a space-separated list of capability
+ names. If more than one capability is named, this argument MUST be
+ preceded by the IRC protocol colon (':') sentinel to signal that the
+ remainder of the line is a single argument.
+
+ If a client sends a subcommand not listed above or issues an invalid
+ command, the server SHOULD reply with the ERR_INVALIDCAPCMD numeric
+ response, 410. The first parameter after the client nickname SHALL
+ be the subcommand the client sent; the second parameter SHOULD be a
+ textual description of the error.
+
+ In ABNF [4] notation:
+
+ capcmd = [ ":" servername SP ] "CAP" SP subcmd
+
+ subcmd = lscmd / listcmd / reqcmd / ackcmd /
+ nakcmd / clearcmd / endcmd
+
+ capcmderr = ":" servername SP "410" SP nick SP badcmd
+ SP ":Invalid CAP subcommand"
+ ; badcmd is the unrecognized subcommand
+
+ caplist = [ ":" ] *( capmod ) capab
+ caplist =/ ":" *( capmod ) capab 1*( SP *( capmod ) capab )
+
+ where SP is as designated in Appendix A of RFC 2234 [4], and
+ servername and nick are as designated in section 2.3.1 of RFC 1459
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 5]
+Internet-Draft IRC CAP March 2005
+
+ [2].
+
+ The discussion in the following sections applies only to clients and
+ servers implementing the capabilities extension. Servers (and
+ clients) not implementing the capabilities extension are exempted
+ from the requirements of this section.
+
+3.1 CAP LS
+
+ The LS subcommand is used to list the capabilities supported by the
+ server. The client SHALL send an LS subcommand with no arguments to
+ solicit a list of supported capabilities from the server. Servers
+ MUST respond to such LS subcommands with one or more LS subcommands
+ containing the list of recognized capabilities. All but the last
+ subcommand MUST have a parameter containing only an asterisk ('*')
+ preceding the capability list.
+
+ If a client issues an LS subcommand during the client registration
+ phase, client registration MUST be suspended until an END (Section
+ 3.7) subcommand is received.
+
+ ABNF [4] description of the LS subcommand:
+
+ lscmd = "LS"
+ lscmd =/ "LS" SP [ "*" SP ] caplist
+
+3.2 CAP LIST
+
+ The LIST subcommand is provided to permit the client to request a
+ list of the capabilities currently active for the connection. It is
+ similar to the LS (Section 3.1) subcommand--if a client issues a LIST
+ subcommand with no arguments, the server MUST respond with a sequence
+ of LIST subcommands, all but the last of which MUST have a single
+ parameter consisting solely of an asterisk ('*') preceding the list
+ of capabilities. If no capabilities have been enabled, the server
+ MUST send a LIST command with an empty capability list; the parameter
+ MUST NOT be omitted. The active capabilities MAY be listed in any
+ order.
+
+ ABNF [4] description of the LIST subcommand:
+
+ listcmd = "LIST"
+ listcmd =/ "LIST" SP ":"
+ listcmd =/ "LIST" SP [ "*" SP ] caplist
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 6]
+Internet-Draft IRC CAP March 2005
+
+3.3 CAP REQ
+
+ The REQ subcommand is sent by the client to request that a capability
+ or set of capabilities be enabled or disabled. Its sole parameter
+ MUST be a space-separated list of capabilities. Each capability name
+ MAY be preceded by a dash ('-') to indicate that the capability
+ should be disabled. Additionally, receipt of this subcommand during
+ the client registration MUST suspend client registration until an END
+ (Section 3.7) subcommand is received.
+
+ Servers MUST respond to a REQ command with either the ACK (Section
+ 3.4) or NAK (Section 3.5) subcommands to indicate acceptance or
+ rejection of the capability set requested by the client. A server
+ MUST accept the entire capability set or reject it whole; servers
+ MUST NOT accept some capabilities in the set while rejecting others.
+ If a client requests that a "sticky" capability be disabled, the
+ server MUST reject the capability set.
+
+ ABNF [4] description of the REQ subcommand:
+
+ reqcmd = "REQ" SP caplist
+
+3.4 CAP ACK
+
+ The ACK subcommand has three uses. It is used by the server to
+ acknowledge a REQ (Section 3.3) subcommand; by the server to
+ acknowledge a CLEAR (Section 3.6) subcommand and list the removed
+ capabilities; and by the client to acknowledge certain capabilities
+ designated as requiring acknowledgment. If more than one ACK is
+ required due to the IRC line length limitation of 512 characters, all
+ but the last SHALL contain a parameter consisting of a single
+ asterisk ('*') immediately preceding the list of capabilities, as for
+ LS (Section 3.1) and LIST (Section 3.2).
+
+ If an ACK reply originating from the server is spread across multiple
+ lines, a client MUST NOT change capabilities until the last ACK of
+ the set is received. Equally, a server MUST NOT change the
+ capabilities of the client until the last ACK of the set has been
+ sent.
+
+ In the first usage, acknowledging a REQ (Section 3.3) subcommand, the
+ ACK subcommand has a single parameter consisting of a space separated
+ list of capability names, which may optionally be preceded with one
+ or more modifiers (Section 5.1).
+
+ The second usage, acknowledging a CLEAR (Section 3.6) subcommand, is
+ similar to the first usage. When a CLEAR (Section 3.6) subcommand is
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 7]
+Internet-Draft IRC CAP March 2005
+
+ issued, all non-"sticky" capabilities are disabled, and a set of ACK
+ subcommands will be generated by the server with the disable modifier
+ preceding each capability.
+
+ The third usage is when, in the preceding two cases, some capability
+ names have been preceded with the ack modifier. ACK in this case is
+ used to fully enable or disable the capability. Clients MUST NOT
+ issue an ACK subcommand for any capability not marked with the ack
+ modifier in a server-generated ACK subcommand.
+
+ ABNF [4] description of the ACK subcommand:
+
+ ackcmd = "ACK" SP [ "*" SP ] caplist
+
+3.5 CAP NAK
+
+ The NAK subcommand MUST be sent by the server in response to a REQ
+ (Section 3.3) subcommand when any capability change requested cannot
+ be performed for any reason. The server MUST NOT make any change to
+ the set of capabilities for the client if it responds with a NAK
+ subcommand. The argument of the NAK subcommand MUST consist of at
+ least the first one hundred characters of the capability list in the
+ REQ (Section 3.3) subcommand which triggered the NAK.
+
+ ABNF [4] description of the NAK subcommand:
+
+ nakcmd = "NAK" SP ":" acklist
+ ; acklist is at least 100 characters of the
+ ; capability list from the REQ
+
+3.6 CAP CLEAR
+
+ The CLEAR subcommand requests that the server clear the capability
+ set for the client. The server MUST respond with a set of ACK
+ (Section 3.4) subcommands indicating the capabilities being
+ deactivated.
+
+ ABNF [4] description of the CLEAR subcommand:
+
+ clearcmd = "CLEAR"
+
+3.7 CAP END
+
+ The END subcommand signals to the server that capability negotiation
+ is complete and requests that the server continue with client
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 8]
+Internet-Draft IRC CAP March 2005
+
+ registration. If the client is already registered, this command MUST
+ be ignored by the server.
+
+ Clients that support capabilities but do not wish to enter
+ negotiation SHOULD send CAP END upon connection to the server.
+
+ ABNF [4] description of the END subcommand:
+
+ endcmd = "END"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 9]
+Internet-Draft IRC CAP March 2005
+
+4. Capability Negotiation
+
+ Clients implementing this extension SHOULD take one of the following
+ three actions upon initial connection to a server:
+
+ o Issue an LS (Section 3.1) subcommand (with an empty capability
+ list) to solicit a list of supported capabilities from the server;
+
+ o Issue the REQ (Section 3.3) subcommand to request a particular set
+ of capabilities without knowing what capabilities the server
+ supports or if it supports the capabilities extension; or
+
+ o Issue the END (Section 3.7) subcommand to signal implementation of
+ the capabilities extension without entering into capability
+ negotiation.
+
+ Although a client is permitted to not issue any CAP commands upon
+ connection, this is NOT RECOMMENDED. Servers MAY assume a client
+ does not implement the capabilities extension if it does not issue
+ any CAP commands upon initial connection.
+
+ Clients SHOULD follow CAP commands issued upon connection with the
+ standard IRC client registration commands without waiting for any
+ responses from the server. See RFC 1459 [2] for more details about
+ the client registration procedure.
+
+ If a client issues the LS (Section 3.1) or REQ (Section 3.3)
+ subcommands during the client registration procedure, a server
+ implementing the capabilities extension MUST NOT complete the client
+ registration until the client issues the END (Section 3.7)
+ subcommand. A client that sees a RPL_WELCOME (001) numeric response
+ before it sends CAP END (Section 3.7) SHOULD assume that the server
+ does not support the capabilities extension.
+
+ Once the client is registered, CAP commands SHALL have no effect on
+ other connection operations, except that a client MAY change the
+ capabilities it has set. In particular, CAP commands and their
+ responses MAY be interspersed with other protocol messages. The END
+ (Section 3.7) subcommand SHALL have no effect once client
+ registration has been completed.
+
+
+
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 10]
+Internet-Draft IRC CAP March 2005
+
+5. Capabilities
+
+ Capabilities are designated by a name composed of one or more
+ elements. Name elements are not case-sensitive. They must begin
+ with a letter and may contain any number of letters, numbers, and the
+ dash character ('-'). Names containing more than one name element
+ MUST also contain a period character ('.') in the first name element.
+ Name elements are separated from each other via the slash character
+ ('/').
+
+ There are two capability name spaces:
+
+ Network Specific: Names whose first element contains a period
+ character ('.') designate a delegated capability name space. The
+ first element MUST be a valid, existing DNS domain name. These
+ names MUST contain at least two elements.
+
+ Standardized: All other names MUST correspond to capabilities
+ documented by an RFC. Further, these names MUST contain only one
+ element.
+
+ These rules are summarized by the following ABNF [4] representation:
+
+ elem = ALPHA *( ALPHA / DIGIT / "-" )
+
+ netname = elem 1*( "." elem )
+
+ netDeleg = netname 1*( "/" elem )
+
+ standardized = elem
+
+ capab = netDeleg / standardized
+
+ where ALPHA and DIGIT are as designated in Appendix A of RFC 2234
+ [4].
+
+5.1 Capability Modifiers
+
+ There are various capability modifiers available. If a capability
+ modifier is to be used, it MUST directly precede the capability name.
+ The following are the modifiers defined for capabilities. Certain
+ modifiers MAY be combined.
+
+ The disable modifier is used by both the server and the client to
+ indicate that a capability should be disabled. The disable modifier
+ is defined as the dash character ('-'). A client MUST only use the
+ disable modifier in the REQ (Section 3.3) and ACK (Section 3.4)
+ subcommands. A server MUST use the disable modifier in the ACK
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 11]
+Internet-Draft IRC CAP March 2005
+
+ (Section 3.4) subcommand when disabling a capability, or in
+ conjunction with a ack modifier in the LIST (Section 3.2) subcommand.
+ The server MUST NOT use the disable modifier in any other command
+ response.
+
+ The sticky modifier is used by the server to indicate a capability
+ that, once enabled, cannot be disabled. The sticky modifier is
+ defined as the equals character ('='). A client MUST NOT use the
+ sticky modifier. A server MUST only use the sticky modifier in the
+ ACK (Section 3.4), LIST (Section 3.2) and LS (Section 3.1)
+ subcommands and MUST use the modifier for all such capabilities.
+
+ The ack modifier is used by the server to indicate that the client
+ must issue an ACK (Section 3.4) subcommand to fully enable or disable
+ the capability. The ack modifier is defined as the tilde character
+ ('~'). The ack modifier indicates that traffic originating from the
+ server SHALL make use of the capability, but the server SHALL NOT
+ expect traffic originating from the client to make use of the
+ capability. When combined with the disable modifier, it indicates
+ traffic originating from the server SHALL NOT make use of the
+ capability, but the server expects traffic originating from the
+ client SHALL make use of the capability. The ack modifier MAY be
+ combined with the sticky modifier.
+
+ A server MUST use the ack modifier in the ACK (Section 3.4) and LIST
+ (Section 3.2) subcommands to indicate capabilities that require an
+ ACK (Section 3.4) subcommand from the client to be fully enabled or
+ disabled. Servers MUST also use the ack modifier in the response to
+ an LS (Section 3.1) subcommand to indicate capabilities which will
+ require ACK (Section 3.4) subcommands from the client. Clients MUST
+ NOT use the ack modifier, but SHOULD issue the ACK (Section 3.4)
+ subcommand as soon as possible after receiving an ACK (Section 3.4)
+ or REQ (Section 3.3) subcommand from the server that contains a
+ capability marked with the ack modifier.
+
+ In ABNF [4] notation:
+
+ dismod = "-"
+ stickymod = "="
+ ackmod = "~"
+
+ capmod = dismod / stickymod / ackmod
+
+
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 12]
+Internet-Draft IRC CAP March 2005
+
+6. IANA Considerations
+
+ The standardized capability name space shall be managed by IANA in
+ accordance with the description of capability names in Section 5. In
+ particular, any name not containing the period character ('.') must
+ be specified by an RFC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 13]
+Internet-Draft IRC CAP March 2005
+
+7. Security Considerations
+
+ Capabilities are an extension to a preexisting, insecure chat
+ protocol. This extension does not add and does not purport to add
+ any security to the IRC protocol. Capability negotiation occurs
+ after client registration has already begun. Moreover, no mechanism
+ is defined that allows parameters to be passed for specific
+ capabilities. Although such a mechanism could be added,
+ cryptographic security systems frequently require several exchanges
+ to establish a secure context, particularly if authentication must
+ also be negotiated. Thus, the capabilities extension is unsuited to
+ the implementation of those protocols, and other mechanisms, such as
+ SSL-encapsulated IRC, should be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 14]
+Internet-Draft IRC CAP March 2005
+
+8. Acknowledgments
+
+ The authors wish to gratefully acknowledge the participation of Aaron
+ Wiebe and the members of the proto-desc@dal.net email list in the
+ design of this protocol extension.
+
+9 References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC
+ 1459, May 1993.
+
+ [3] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812,
+ April 2000.
+
+ [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [5] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
+ February 2004.
+
+Authors' Addresses
+
+ Kevin L. Mitchell
+ Undernet IRC Network
+ 38 Eighth St., Apt. 7
+ Cambridge, Massachusetts 02141
+ US
+
+ Phone: +1-617-230-1021
+ EMail: klmitch@mit.edu
+ URI: http://www.mit.edu/~klmitch/
+
+ Perry Lorier
+ Undernet IRC Network
+ 3 Liston Cres
+ Hamilton, Waikato 2001
+ NZ
+
+ Phone: +64-7-859-1109
+ EMail: isomer@undernet.org
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 15]
+Internet-Draft IRC CAP March 2005
+
+ Lee Hardy
+ ircd-ratbox Development Team
+
+ EMail: lee@leeh.co.uk
+ URI: http://www.leeh.co.uk
+
+ Piotr Kucharski
+ IRCnet
+
+ EMail: Beeth@irc.pl
+ URI: http://42.pl/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 16]
+Internet-Draft IRC CAP March 2005
+
+Appendix A. Examples
+
+ In the following examples, lines preceded by "CLIENT:" indicate
+ protocol messages sent by the client, and lines preceded by "SERVER:"
+ indicate protocol messages sent by the server. For clarity, the
+ origin field for server-originated protocol messages has been
+ omitted. This field would consist of a colon (':') followed by the
+ full server name, and would be the first field in the command.
+
+ A client communicating with a server not supporting CAP.
+
+ CLIENT: CAP LS
+ CLIENT: NICK nickname
+ CLIENT: USER username ignored ignored :real name
+ SERVER: 001 [...]
+
+ A client which does not wish to enter capability negotiation.
+
+ CLIENT: CAP END
+ CLIENT: NICK nickname
+ CLIENT: USER username ignored ignored :real name
+ SERVER: 001 [...]
+
+ A client entering into capability negotiation during registration,
+ and requesting a set of capabilities that the server does not
+ support.
+
+ CLIENT: CAP LS
+ CLIENT: NICK nickname
+ CLIENT: USER username ignored ignored :real name
+ SERVER: CAP LS * :A B C D E F G H
+ SERVER: CAP LS :I J
+ CLIENT: CAP REQ :A B C D E F
+ SERVER: CAP NAK :A B C D E F
+ CLIENT: CAP REQ :A C E F
+ SERVER: CAP ACK :A C E F
+ CLIENT: CAP REQ :B
+ SERVER: CAP ACK :B
+ CLIENT: CAP REQ :D
+ SERVER: CAP NAK :D
+ CLIENT: CAP END
+ SERVER: 001 [...]
+
+
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 17]
+Internet-Draft IRC CAP March 2005
+
+ A client requesting a capability that requires an ACK (Section 3.4)
+ subcommand from the client to be enabled.
+
+ CLIENT: CAP LS
+ SERVER: CAP LS :~I ~J K
+ CLIENT: CAP REQ :I J K
+ SERVER: CAP ACK :~I ~J K
+ CLIENT: CAP ACK :I J
+
+ A client requesting a capability that requires an ACK (Section 3.4)
+ subcommand from the client to be enabled and disabled, using the LIST
+ (Section 3.2) subcommand in between.
+
+ CLIENT: CAP LS
+ SERVER: CAP LS :~A ~B
+ CLIENT: CAP REQ :A B
+ SERVER: CAP ACK :~A ~B
+ CLIENT: CAP LIST
+ SERVER: CAP LIST :~A ~B
+ CLIENT: CAP ACK :A B
+ CLIENT: CAP LIST
+ SERVER: CAP LIST :A B
+ CLIENT: CAP REQ :-B
+ SERVER: CAP ACK :-~B
+ CLIENT: CAP LIST
+ SERVER: CAP LIST :A -~B
+ CLIENT: CAP ACK :-B
+ CLIENT: CAP LIST
+ SERVER: CAP LIST :A
+
+ A client requesting a capability that is sticky.
+
+ CLIENT: CAP LS
+ SERVER: CAP LS :=I J
+ CLIENT: CAP REQ :I J
+ SERVER: CAP ACK :=I J
+
+ A client requesting a capability be disabled.
+
+ CLIENT: CAP LIST
+ SERVER: CAP LIST :=A B C D
+ CLIENT: CAP REQ :-B -C
+ SERVER: CAP ACK :-B -C
+
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 18]
+Internet-Draft IRC CAP March 2005
+
+Appendix B. ABNF Description of Capabilities
+
+ This section summarizes the ABNF [4] description of the capabilities
+ extension.
+
+ capcmd = [ ":" servername SP ] "CAP" SP subcmd
+
+ subcmd = lscmd / listcmd / reqcmd / ackcmd /
+ nakcmd / clearcmd / endcmd
+
+ capcmderr = ":" servername SP "410" SP nick SP badcmd
+ SP ":Invalid CAP subcommand"
+ ; badcmd is the unrecognized subcommand
+
+ caplist = [ ":" ] *( capmod ) capab
+ caplist =/ ":" *( capmod ) capab 1*( SP *( capmod ) capab )
+
+ lscmd = "LS"
+ lscmd =/ "LS" SP [ "*" SP ] caplist
+
+ listcmd = "LIST"
+ listcmd =/ "LIST" SP ":"
+ listcmd =/ "LIST" SP [ "*" SP ] caplist
+
+ reqcmd = "REQ" SP caplist
+
+ ackcmd = "ACK" SP [ "*" SP ] caplist
+
+ nakcmd = "NAK" SP ":" acklist
+ ; acklist is at least 100 characters of the
+ ; capability list from the REQ
+
+ clearcmd = "CLEAR"
+
+ endcmd = "END"
+
+ elem = ALPHA *( ALPHA / DIGIT / "-" )
+
+ netname = elem 1*( "." elem )
+
+ netDeleg = netname 1*( "/" elem )
+
+ standardized = elem
+
+ capab = netDeleg / standardized
+
+ dismod = "-"
+ stickymod = "="
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 19]
+Internet-Draft IRC CAP March 2005
+
+ ackmod = "~"
+
+ capmod = dismod / stickymod / ackmod
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 20]
+Internet-Draft IRC CAP March 2005
+
+Appendix C. ChangeLog
+
+ Note to RFC Editor: This section may be removed on publication as an
+ RFC.
+
+ Here is a log of changes to this document:
+
+ 2004-12-15 KLM Initial draft written.
+
+ 2004-12-16 KLM
+
+ * Added description of the argument to some CAP commands in
+ Section 3.
+
+ * Clarified that requirements of Section 3 only apply to clients
+ and servers implementing capabilities.
+
+ * Substitution of "performed" for "done" in Section 3.5
+
+ * Added LIST (Section 3.2) subcommand to provide a mechanism to
+ query active capabilities.
+
+ * Added reference to RFC 2812 [3].
+
+ * Moved Examples (Appendix A) section into the back matter.
+
+ * Corrected Perry Lorier's email address.
+
+ * Added this ChangeLog section.
+
+ * Corrected typo in Section 3.7: "sent" for "send".
+
+ * Added <vspace> elements to enhance readability.
+
+ * Changed to non-compact form.
+
+ * Changed anchor for Section 5 to "capabilities" from "caps" to
+ reduce possible confusion.
+
+ * Revise last sentence of first paragraph of Section 2 to remove
+ redundancy.
+
+ * Revise last sentence of second paragraph of Section 2
+
+ * Added email addresses for Lee H and Beeth; updated contact
+ information for Isomer.
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 21]
+Internet-Draft IRC CAP March 2005
+
+ 2004-12-17 KLM
+
+ * Augmented description of CAP command and subcommands with ABNF
+ description.
+
+ * Revised Section 5 to remove "net." name space and replace it
+ with a delegated name space beginning with a DNS domain name
+ (suggested by Isomer).
+
+ * Augmented ABNF description of capability names.
+
+ * Revised Section 6 to reflect change in capability name space.
+
+ * Added Appendix B to bring together the entire ABNF description
+ of capabilities.
+
+ 2004-12-18 KLM
+
+ * Added explanation of what should happen if an unrecognized
+ subcommand is given.
+
+ * Clarified what to do if a client sends a subcommand that
+ shouldn't come from a client.
+
+ * Add references to LIST (Section 3.2) to LSL and Section 3.1.
+
+ * Section 3.3 omitted the caplist argument for the REQ command;
+ corrected.
+
+ * Relax the prohibition against a client acknowledging a
+ capability that doesn't modify the protocol stream in Section
+ 3.4
+
+ * Relax the requirement for a client that understands
+ capabilities to send CAP END in Section 3.7
+
+ 2004-12-19 KLM
+
+ * Converted a number of common xrefs into internal entities to
+ simplify the text.
+
+ * Inserted some white space to make the <front> section a bit
+ more readable.
+
+ * Added the keyword "Protocol".
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 22]
+Internet-Draft IRC CAP March 2005
+
+ * Added the term "NOT RECOMMENDED" to the note on "Requirements
+ Language".
+
+ * Moved LIST (Section 3.2) up in the list of CAP subcommands.
+
+ * Minor formatting change to the ABNF representation of subcmd.
+
+ * Capitalized "MAY" in "empty" subcommand.
+
+ * Added text about capability list order and what to do if no
+ capabilities are implemented to "empty" subcommand.
+
+ * Mention LIST (Section 3.2) also in LSL when talking about
+ sending more than one LSL subcommand.
+
+ * Clarify language in Section 3.1 a little bit.
+
+ * Substitute "set of capabilities" for "list of capabilities" in
+ Section 3.3.
+
+ * Fix minor typo in preamble to ABNF description of NAK (Section
+ 3.5) subcommand: substitution of "ACK" for "NAK".
+
+ * Add note about servers ignoring END (Section 3.7) after client
+ registration.
+
+ * Fix minor typo in preamble to ABNF description of LIST (Section
+ 3.2) subcommand: substitution of "END" for "LIST".
+
+ * Added Section 4 discussing capability negotiation.
+
+ * Add ".xml" extension to include files in references section.
+
+ * Simplification of preamble of first example (Appendix A).
+
+ * Add 'type="ABNF"' to <artwork> sections so that they can be
+ extracted and used to create the abnf.xml now included in
+ Appendix B.
+
+ * It's now RFC 3667 [5], not RFC 2026...
+
+ 2004-12-27 KLM
+
+ * Minor wording changes to second paragraph of Section 1
+
+ * Minor wording change to first paragraph of Section 2
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 23]
+Internet-Draft IRC CAP March 2005
+
+ * Minor wording changes to first paragraph of Section 3; remove
+ redundant note about the IRC colon sentinel.
+
+ * Change a "must" to a "MUST" in Section 3.4; note that
+ capability list may be truncated if it would otherwise exceed
+ the 512 character limit.
+
+ * In Section 3.5, note that capability list may be truncated if
+ it would otherwise exceed the 512 character limit.
+
+ * Remove redundant line about ignoring END (Section 3.7) commands
+ after registration.
+
+ * Correct spelling of "acknowledgments".
+
+ * Empty <organization> elements for Lee H and Beeth; put Beeth's
+ real name, Piotr Kucharski, in the right place.
+
+ * Switch to using a new preprocessor that consolidates all the
+ ABNF artwork and inserts it with the processing instruction
+ <?art type="foo"?>.
+
+ * Remove deliberate page break after <abstract> section.
+
+ * Reorder authors section to consolidate <organization> elements
+ for everyone.
+
+ * Drop abbreviation for Undernet.
+
+ * Expand Section 7 a bit to try to explain why capabilities are
+ not suited to securing IRC.
+
+ 2005-01-04 KLM
+
+ * Add Lee Hardy's information to the list of authors.
+
+ 2005-01-05 KLM
+
+ * Replace UNKNOWNCAPCMD with INVALIDCAPCMD.
+
+ * Begin rewriting LS (Section 3.1) documentation
+
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 24]
+Internet-Draft IRC CAP March 2005
+
+ 2005-01-19 KLM
+
+ * Redesign the protocol substantially to simplify it.
+
+ 2005-01-20 KLM
+
+ * Update Piotr's contact information.
+
+ * Drop the "x-" namespace...
+
+ 2005-01-20 LH
+
+ * Some servers do issue banner responses, now.
+
+ * The CAP subcommand is now a requirement.
+
+ * Minor grammatical fix-up in documentation of REQ (Section 3.3)
+ ("acceptance of or rejection of"--strike first "of").
+
+ * Clarify that sticky capabilities cause a REQ (Section 3.3) to
+ be NAK (Section 3.5)ed.
+
+ * Mark the third case of an ACK (Section 3.4) with an explicit
+ indicator that it's the third case...
+
+ * Strike redundant mention of not suspending client registration
+ in documentation for END (Section 3.7).
+
+ 2005-01-21 LH
+
+ * Move all references on capability modifiers to its own section
+
+ * Clarify instructions on the ack ('~') modifier, indicating it
+ can be used with sticky capabilities.
+
+ * Add a note into CAP section about capability modifiers
+
+ 2005-01-21 KLM
+
+ * Subcommands are not optional anymore; updated the description
+ of CAP and the ABNF to reflect this.
+
+ * More than one modifier may precede a capability name.
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 25]
+Internet-Draft IRC CAP March 2005
+
+ * Move ABNF for capmod into the "Capability Modifiers" section.
+
+ * Fix a few minor grammatical errors (I think).
+
+ * Note that capability names may be preceded by modifiers in the
+ first form of ACK.
+
+ * Remove an unnecessary "MAY" in documentation for the third
+ usage of ACK.
+
+ * Explicitly note in the ABNF for NAK that the parameter is an
+ opaque repeat of at least the first 100 characters of the
+ argument to REQ.
+
+ * CLEAR may result in more than one ACK.
+
+ * Clarify the language of what composes a capability name.
+
+ * Add missing </figure>.
+
+ * ACK subcommand should be sent in response to ACK with ack
+ modifier as soon as possible...
+
+ * Allow disable modifier in LIST, but only in conjunction with an
+ ack modifier.
+
+ * The ack modifier may also show up in an LS response; rewrote
+ the final paragraph to indicate that and clarify the language.
+
+ * Add "Client" to the title in the appropriate place...
+
+ * The "capability" rule in the ABNF got changed to "capab" for
+ brevity.
+
+ * Update "date" to be current.
+
+ 2005-01-22 LH
+
+ * Clarify a client must not act upon an ACK spread across
+ multiple lines until it receives the final ACK of the set.
+
+ 2005-01-23 KLM
+
+ * Bump version number in preparation for any suggested edits...
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 26]
+Internet-Draft IRC CAP March 2005
+
+ 2005-01-26 LH
+
+ * Clarify a server also must not change capabilities until its
+ finished sending its ACKs.
+
+ 2005-01-27 KLM
+
+ * Acknowledge Aaron Wiebe as participating.
+
+ 2005-03-01 LH
+
+ * Add examples on sticky modifiers, the removal modifier and the
+ sticky modifier.
+
+ 2005-03-07 KLM
+
+ * Submit second draft...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 27]
+Internet-Draft IRC CAP March 2005
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM 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.
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+Mitchell, et al. Expires September 5, 2005 [Page 28]
diff --git a/doc/technical/event.txt b/doc/technical/event.txt
new file mode 100644
index 0000000..b09b0b7
--- /dev/null
+++ b/doc/technical/event.txt
@@ -0,0 +1,82 @@
+Overview of the event subsystem
+Adrian Chadd <adrian@creative.net.au>
+
+$Id$
+
+One of the things that immediately struck me whilst first looking at the
+code was that the ircd periodically scheduled things in io_loop() but
+it did them manually. This is very wasteful and very tedious.
+
+Therefore, an event system was added to hybrid. src/event.c contains an
+event system ported from the squid web cache. It is pretty self contained,
+and only a few things (debugging, time resolution) needed changing.
+
+An event is scheduled through eventAdd() or eventAddIsh() :
+
+eventAdd(const char *name, EVH * func, void *arg, time_t when, int weight)
+eventAddIsh(const char *name, EVH * func, void *arg, time_t delta_ish,
+ int weight)
+
+after 'when' (or delta_ish) seconds has elapsed from the time the above
+functions are called, the 'func' is called with the given data 'arg'. The
+event is then deleted.
+
+To delete an event, use eventDelete() :
+
+eventDelete(EVH * func, void *arg)
+
+An event is identified by its callback function and data pair.
+
+Events are run through eventRun(). This is designed to be called *BEFORE*
+your IO handlers, to let events scheduled immediately (ie a time of 0)
+to initiate IO before the IO handlers are called.
+
+(Believe me, its useful.)
+
+
+
+Example:
+
+Say you have something which must be called every 15 seconds.
+
+* You would first define the callback in your module:
+
+static EVH foo_periodic_event;
+static int initialised = 0;
+
+* You would then add the event in your initialization function:
+
+void foo_init(void)
+{
+ if (!initialised) {
+ eventAdd("foo_periodic_event", foo_periodic_event, NULL, 0, 0);
+ initialised = 1;
+ }
+}
+
+ This will force the event to be called the next time eventRun() is called,
+ rather than waiting 15 seconds.
+
+* You then define your event callback:
+
+static void
+foo_periodic_event(void *data)
+{
+ /* We'd do our work here */
+
+ /* Then we'd finish */
+ eventAdd("foo_periodic_event", foo_periodic_event, NULL, 15, 0);
+}
+
+
+Notes:
+
+* I really should change the timeout value to be in milliseconds. Squid used
+ a double, but Dianora had something against floating point code in the main
+ loop (which is understandable). If someone wants a fun task .. :-)
+
+* Note that the 'name' parameter to eventAdd() / eventAddIsh() is a const
+ char *, and is *not copied* but *referenced*. Therefore, it is in your
+ best interest to use string constants.
+
+* /stats E for an oper shows pending events. Thanks Diane!
diff --git a/doc/technical/fd-management.txt b/doc/technical/fd-management.txt
new file mode 100644
index 0000000..cb98e3f
--- /dev/null
+++ b/doc/technical/fd-management.txt
@@ -0,0 +1,47 @@
+Overview of the filedescriptor subsystem
+Adrian Chadd <adrian@creative.net.au>
+
+$Id$
+
+
+Filedescriptor lists
+--------------------
+
+The filedescriptor list is managed through the routines in fdlist.c .
+These include:
+
+fd_open() - tag an FD as "open" and active
+fd_close() - tag an FD as "closed" and close() the filedescriptor
+fd_note() - update the filedescriptor tag
+
+You can get the current list of open filedescriptors through /stats F as
+an oper.
+
+
+
+FD lists
+--------
+
+The FD list support is very alpha. There are a few lists defined:
+
+typedef enum fdlist_t {
+ FDLIST_NONE,
+ FDLIST_SERVICE,
+ FDLIST_SERVER,
+ FDLIST_IDLECLIENT,
+ FDLIST_BUSYCLIENT,
+ FDLIST_MAX
+} fdlist_t;
+
+FDLIST_NONE Not on any list (ie close()d)
+FDLIST_SERVICE A service - listen() sockets, resolver, etc
+FDLIST_SERVER Server connections
+FDLIST_IDLECLIENT An idle client
+FDLIST_BUSYCLIENT A busy client
+FDLIST_MAX Used for bounds checking
+
+The idea is that the SERVICE sockets need polling frequently, the SERVER
+sockets also need polling frequently, BUSYCLIENT is for busy clients
+which need frequent polling (eg we're trying to write to them), and
+IDLECLIENT is for clients which we don't need to poll frequently.
+THIS hasn't been decided upon yet.
diff --git a/doc/technical/hostmask.txt b/doc/technical/hostmask.txt
new file mode 100644
index 0000000..892bc93
--- /dev/null
+++ b/doc/technical/hostmask.txt
@@ -0,0 +1,136 @@
+The Hostmask and Netmask System
+Copyright(c) 2001 by Andrew Miller(A1kmm)<a1kmm@mware.virtualave.net>
+
+$Id$
+------------------------------------------------------------------------
+
+Contents ::
+============
+* Section 1: Motivation
+* Section 2: Underlying Mechanism
+ - 2.1: General Overview
+ - 2.2: IPv4 Netmasks
+ - 2.3: IPv6 Netmasks
+ - 2.4: Hostmasks
+* Section 3: Exposed Abstraction Layer
+ - 3.1: Parsing Masks
+ - 3.2: Adding Configuration Items
+ - 3.3: Initialising or Rehashing
+ - 3.4: Finding IP/Hostname Confs
+ - 3.5: Deleting Entries
+ - 3.6: Reporting Entries
+
+Section 1: Motivation
+=====================
+
+Looking up configuration hostnames and IP addresses (such as for I-Lines
+and K-Lines) needs to be implemented efficiently. It turns out a hash
+based algorithm like that employed here performs very will on the average
+case, which is what we should be the most concerned about. A profiling
+comparison with the mtre code using data from a real network confirmed
+that this algorithm performs much better.
+
+
+Section 2: Underlying Mechanism
+===============================
+
+2.1: General Overview
+---------------------
+
+In short, a hash-table with linked lists for buckets is used to locate
+the correct hostname/netmask entries. In order to support CIDR IPs and
+wildcard masks, the entire key cannot be hashed, and there is a need to
+rehash. The means for deciding how much to hash differs between the
+hostmasks and IPv4/6 netmasks.
+
+2.2: IPv4 Netmasks
+------------------
+
+In order to hash IPv4 netmasks for addition to the hash, the mask is first
+processed into a 32-bit address and a number of bits is used. All unused
+bits are set to 0. The mask could be in these forms:
+
+1.2.3.4 => 1.2.3.4 : 32
+1.2.3.* => 1.2.3.0 : 24
+1.2.*.* => 1.2.0.0 : 16
+1.2.3.64/26 => 1.2.3.64 : 26
+
+The number of whole bytes is then calculated, and only those bytes are
+hashed (e.g. 1.2.3.64/26 and 1.2.3.0/24 hash the same). When a complete
+IPv4 address is given so that an IPv4 match can be found the entire IP
+address is first hashed, and then looked up in the table. Then the most
+significant three bytes are hashed, followed by the most significant two,
+the most significant one, and finally the "identity hash" bucket is
+searched (to match masks like 192/7).
+
+2.3: IPv6 Netmasks
+------------------
+
+As per the IPv4 netmasks, except that instead of rehashing with one byte
+granularity, a 16-bit (two byte) granularity is used, as 16 rehashes is
+considered too great a fixed offset to be justified for a (possible)
+slight reduction in hash collisions.
+
+2.4: Hostmasks
+--------------
+
+On adding a hostmask to the hash, all of the hostmask right of the next
+dot after the last wildcard character in the string is hashed, or in the
+case that there are no wildcards in the hostmask, the entire string is
+hashed.
+
+On searching for a hostmask match, the entire hostname is hashed, followed
+by the entire hostmask after the first dot, followed by the entire hostmask
+after the second dot, and so on. Finally the "identity hash" bucket is checked
+to catch hostnames like *test*.
+
+Section 3: Exposed Abstraction Layer
+====================================
+
+Section 3.1: Parsing Masks
+--------------------------
+
+Call "parse_netmask()" with the netmask and a pointer to an irc_inaddr
+structure to be filled in, as well as a pointer to an integer where the
+number of bits will be placed.
+
+Always check the return value, if it returns HM_MOST, it means that the
+mask is probably a hostmask. If it returns HM_IPV4, it means it was an
+IPv4 address. If it returns HM_IPV6, it means it was an IPv6 address.
+If parse_netmask() returns HM_MOST however, no change is made to the
+irc_inaddr structure or the number of bits.
+
+Section 3.2: Adding Configuration Items
+---------------------------------------
+
+Call "add_conf_by_address()" with the hostname or IP mask, the username,
+and the ConfItem* to associate with this mask.
+
+Section 3.3: Initialising and Rehashing
+---------------------------------------
+
+To initialise, call "init_host_hash()". This only needs to be done once
+on start-up. On rehash, to wipe out the old unwanted configuration, and
+free them if there are no references to them, call
+"clear_out_address_conf()".
+
+Section 3.4: Finding IP/Hostname Confs
+---------------------------------------
+
+Call "find_address_conf()" with the hostname, the username, the address,
+the address family and the client-supplied password. To find a D-Line,
+call "find_dline()" with the address and address family.
+
+Section 3.5: Deleted Entries
+----------------------------
+
+Call "delete_one_address_conf()" with the hostname and the ConfItem*.
+
+Section 3.6: Reporting Entries
+------------------------------
+
+Call "report_dlines()", "report_exemptlines()", "report_Klines()", or
+"report_Ilines()" with the client pointer to report to. Note these walk
+the hash, which is inefficient, but these are not called often enough
+to justify the memory and maintenance clockcycles to for more efficient
+data structuring.
diff --git a/doc/technical/index.txt b/doc/technical/index.txt
new file mode 100644
index 0000000..32577e9
--- /dev/null
+++ b/doc/technical/index.txt
@@ -0,0 +1,16 @@
+$Id$
+-----------------------------------------------
+
+Technical Documentation for ircd-hybrid-8
+
+event.txt - Outline of the event system
+fd-management.txt - Outline of the file descriptor management system
+hostmask.txt - Outline of hostmask handling
+network.txt - Outline of the network traffic subsystem
+rfc1459.txt - The IRC RFC
+rfc2812.txt - The IRC Client RFC
+rfc2813.txt - The IRC Server RFC
+send.txt - Document on all of the send_to functions
+ts3.txt - TSora Version 3 Protocol
+ts5.txt - TSora Version 5 Protocol
+ts6.txt - TSora Version 6 Protocol
diff --git a/doc/technical/network.txt b/doc/technical/network.txt
new file mode 100644
index 0000000..520adc0
--- /dev/null
+++ b/doc/technical/network.txt
@@ -0,0 +1,99 @@
+Overview of the network subsystem
+Adrian Chadd <adrian@creative.net.au>
+
+$Id$
+
+This document is an overview of the new and hopefully improved network
+subsystem.
+
+The code is based loosely upon the network core found in the Squid web cache
+server, with some optimizations for ircd-specific IO patterns.
+
+Filedescriptor IO
+-----------------
+
+Filedescriptor IO is initiated using comm_setselect(). comm_setselect()
+registers interest in reading from or writing to a file descriptor.
+When a filedescriptor is ready for the required IO a callback is called
+from the IO loop.
+
+The comm_setselect() usage is:
+
+void
+comm_setselect(int fd, fdlist_t list, int type, PF *callback, void *cbdata,
+ int timeout)
+
+where:
+ fd filedescriptor
+ list Which list the FD should be put on
+ type IO type. Can currently include:
+ COMM_SELECT_READ - register for read
+ COMM_SELECT_WRITE - register for write
+ callback Function to call when the FD is ready
+ cbdata Data to be passed to above function
+ timeout Update the timeout value. 0 is "don't update".
+
+
+A typical use is:
+
+..
+
+/* Register interest in the FD for a read event */
+comm_setselect(fd, FDLIST_SERVICE, COMM_SELECT_READ, read_callback, read_data,
+ 0);
+
+..
+
+(FD becomes ready for read in the IO loop)
+
+void
+read_callback(int fd, void *data)
+{
+ /* called when the FD becomes ready for read */
+ retval = read(fd, buf, len);
+
+ ..
+ /* Ok, we need to read some more when its ready */
+ comm_setselect(fd, FDLIST_SERVICE, COMM_SELECT_READ, read_callback, data,
+ 0);
+}
+
+Socket timeouts
+---------------
+
+A "socket timeout" is a callback registered to be called when a certain
+amount of time has elapsed. Think of it as an event, but against a FD.
+
+A good example of socket timeouts is in the comm_connect_tcp() code.
+When the connect() begins, comm_settimeout() is called to call
+comm_connect_timeout() if the timeout occurs. Once the connect() completes,
+comm_settimeout() is called with a timeout of 0 and callback of NULL
+to deregister the timeout. If the timeout occurs, comm_connect_timeout()
+is called and the connection attempt is aborted.
+
+
+
+
+Functions
+---------
+
+comm_open() - a socket() wrapper, enforcing fd limitations and tagging the
+ file descriptor with a note
+
+comm_accept() - an accept() wrapper, enforcing fd limitations and tagging
+ the file descriptor with a note
+
+comm_connect_tcp() - attempt an async connect(). Handles DNS lookups if
+ required, and will call the given callback at completion or error
+
+comm_settimeout() - set a callback to be called after a given time period.
+ This is good to implement things like PING checks and connect() timeouts.
+
+Notes:
+
+* All socket creation should go through comm_open() / comm_accept().
+* All socket closing should go through fd_close(). comm_close() isn't
+ implemented yet.
+* comm_connect_tcp() is your best friend. :-)
+* *ALL* network sockets should be non-blocking. If your OS doesn't support
+ non-blocking sockets, you shouldn't be here.
diff --git a/doc/technical/rfc1459.txt b/doc/technical/rfc1459.txt
new file mode 100644
index 0000000..768e176
--- /dev/null
+++ b/doc/technical/rfc1459.txt
@@ -0,0 +1,3110 @@
+$Id$
+
+Network Working Group J. Oikarinen
+Request for Comments: 1459 D. Reed
+ May 1993
+
+ Internet Relay Chat Protocol
+
+Status of This Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. Discussion and suggestions for improvement are requested.
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" for the standardization state and status of this protocol.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ The IRC protocol was developed over the last 4 years since it was
+ first implemented as a means for users on a BBS to chat amongst
+ themselves. Now it supports a world-wide network of servers and
+ clients, and is stringing to cope with growth. Over the past 2 years,
+ the average number of users connected to the main IRC network has
+ grown by a factor of 10.
+
+ The IRC protocol is a text-based protocol, with the simplest client
+ being any socket program capable of connecting to the server.
+
+Table of Contents
+
+ 1. INTRODUCTION ............................................... 4
+ 1.1 Servers ................................................ 4
+ 1.2 Clients ................................................ 5
+ 1.2.1 Operators .......................................... 5
+ 1.3 Channels ................................................ 5
+ 1.3.1 Channel Operators .................................... 6
+ 2. THE IRC SPECIFICATION ....................................... 7
+ 2.1 Overview ................................................ 7
+ 2.2 Character codes ......................................... 7
+ 2.3 Messages ................................................ 7
+ 2.3.1 Message format in 'pseudo' BNF .................... 8
+ 2.4 Numeric replies ......................................... 10
+ 3. IRC Concepts ................................................ 10
+ 3.1 One-to-one communication ................................ 10
+ 3.2 One-to-many ............................................. 11
+ 3.2.1 To a list .......................................... 11
+ 3.2.2 To a group (channel) ............................... 11
+ 3.2.3 To a host/server mask .............................. 12
+ 3.3 One to all .............................................. 12
+
+ 3.3.1 Client to Client ................................... 12
+ 3.3.2 Clients to Server .................................. 12
+ 3.3.3 Server to Server ................................... 12
+ 4. MESSAGE DETAILS ............................................. 13
+ 4.1 Connection Registration ................................. 13
+ 4.1.1 Password message ................................... 14
+ 4.1.2 Nickname message ................................... 14
+ 4.1.3 User message ....................................... 15
+ 4.1.4 Server message ..................................... 16
+ 4.1.5 Operator message ................................... 17
+ 4.1.6 Quit message ....................................... 17
+ 4.1.7 Server Quit message ................................ 18
+ 4.2 Channel operations ...................................... 19
+ 4.2.1 Join message ....................................... 19
+ 4.2.2 Part message ....................................... 20
+ 4.2.3 Mode message ....................................... 21
+ 4.2.3.1 Channel modes ................................. 21
+ 4.2.3.2 User modes .................................... 22
+ 4.2.4 Topic message ...................................... 23
+ 4.2.5 Names message ...................................... 24
+ 4.2.6 List message ....................................... 24
+ 4.2.7 Invite message ..................................... 25
+ 4.2.8 Kick message ....................................... 25
+ 4.3 Server queries and commands ............................. 26
+ 4.3.1 Version message .................................... 26
+ 4.3.2 Stats message ...................................... 27
+ 4.3.3 Links message ...................................... 28
+ 4.3.4 Time message ....................................... 29
+ 4.3.5 Connect message .................................... 29
+ 4.3.6 Trace message ...................................... 30
+ 4.3.7 Admin message ...................................... 31
+ 4.3.8 Info message ....................................... 31
+ 4.4 Sending messages ........................................ 32
+ 4.4.1 Private messages ................................... 32
+ 4.4.2 Notice messages .................................... 33
+ 4.5 User-based queries ...................................... 33
+ 4.5.1 Who query .......................................... 33
+ 4.5.2 Whois query ........................................ 34
+ 4.5.3 Whowas message ..................................... 35
+ 4.6 Miscellaneous messages .................................. 35
+ 4.6.1 Kill message ....................................... 36
+ 4.6.2 Ping message ....................................... 37
+ 4.6.3 Pong message ....................................... 37
+ 4.6.4 Error message ...................................... 38
+ 5. OPTIONAL MESSAGES ........................................... 38
+ 5.1 Away message ............................................ 38
+ 5.2 Rehash command .......................................... 39
+ 5.3 Restart command ......................................... 39
+
+ 5.4 Summon message .......................................... 40
+ 5.5 Users message ........................................... 40
+ 5.6 Operwall command ........................................ 41
+ 5.7 Userhost message ........................................ 42
+ 5.8 Ison message ............................................ 42
+ 6. REPLIES ..................................................... 43
+ 6.1 Error Replies ........................................... 43
+ 6.2 Command responses ....................................... 48
+ 6.3 Reserved numerics ....................................... 56
+ 7. Client and server authentication ............................ 56
+ 8. Current Implementations Details ............................. 56
+ 8.1 Network protocol: TCP ................................... 57
+ 8.1.1 Support of Unix sockets ............................ 57
+ 8.2 Command Parsing ......................................... 57
+ 8.3 Message delivery ........................................ 57
+ 8.4 Connection 'Liveness' ................................... 58
+ 8.5 Establishing a server-client connection ................. 58
+ 8.6 Establishing a server-server connection ................. 58
+ 8.6.1 State information exchange when connecting ......... 59
+ 8.7 Terminating server-client connections ................... 59
+ 8.8 Terminating server-server connections ................... 59
+ 8.9 Tracking nickname changes ............................... 60
+ 8.10 Flood control of clients ............................... 60
+ 8.11 Non-blocking lookups ................................... 61
+ 8.11.1 Hostname (DNS) lookups ............................ 61
+ 8.11.2 Username (Ident) lookups .......................... 61
+ 8.12 Configuration file ..................................... 61
+ 8.12.1 Allowing clients to connect ....................... 62
+ 8.12.2 Operators ......................................... 62
+ 8.12.3 Allowing servers to connect ....................... 62
+ 8.12.4 Administrivia ..................................... 63
+ 8.13 Channel membership ..................................... 63
+ 9. Current problems ............................................ 63
+ 9.1 Scalability ............................................. 63
+ 9.2 Labels .................................................. 63
+ 9.2.1 Nicknames .......................................... 63
+ 9.2.2 Channels ........................................... 64
+ 9.2.3 Servers ............................................ 64
+ 9.3 Algorithms .............................................. 64
+ 10. Support and availability ................................... 64
+ 11. Security Considerations .................................... 65
+ 12. Authors' Addresses ......................................... 65
+
+1. INTRODUCTION
+
+ The IRC (Internet Relay Chat) protocol has been designed over a
+ number of years for use with text based conferencing. This document
+ describes the current IRC protocol.
+
+ The IRC protocol has been developed on systems using the TCP/IP
+ network protocol, although there is no requirement that this remain
+ the only sphere in which it operates.
+
+ IRC itself is a teleconferencing system, which (through the use of
+ the client-server model) is well-suited to running on many machines
+ in a distributed fashion. A typical setup involves a single process
+ (the server) forming a central point for clients (or other servers)
+ to connect to, performing the required message delivery/multiplexing
+ and other functions.
+
+1.1 Servers
+
+ The server forms the backbone of IRC, providing a point to which
+ clients may connect to to talk to each other, and a point for other
+ servers to connect to, forming an IRC network. The only network
+ configuration allowed for IRC servers is that of a spanning tree [see
+ Fig. 1] where each server acts as a central node for the rest of the
+ net it sees.
+
+ [ Server 15 ] [ Server 13 ] [ Server 14]
+ / \ /
+ / \ /
+ [ Server 11 ] ------ [ Server 1 ] [ Server 12]
+ / \ /
+ / \ /
+ [ Server 2 ] [ Server 3 ]
+ / \ \
+ / \ \
+ [ Server 4 ] [ Server 5 ] [ Server 6 ]
+ / | \ /
+ / | \ /
+ / | \____ /
+ / | \ /
+ [ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ]
+
+ :
+ [ etc. ]
+ :
+
+ [ Fig. 1. Format of IRC server network ]
+
+1.2 Clients
+
+ A client is anything connecting to a server that is not another
+ server. Each client is distinguished from other clients by a unique
+ nickname having a maximum length of nine (9) characters. See the
+ protocol grammar rules for what may and may not be used in a
+ nickname. In addition to the nickname, all servers must have the
+ following information about all clients: the real name of the host
+ that the client is running on, the username of the client on that
+ host, and the server to which the client is connected.
+
+1.2.1 Operators
+
+ To allow a reasonable amount of order to be kept within the IRC
+ network, a special class of clients (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 required. Operators should be able to perform basic
+ network tasks such as disconnecting and reconnecting servers as
+ needed to prevent long-term use of bad network routing. In
+ recognition of this need, the protocol discussed herein provides for
+ operators only to be able to perform such functions. See sections
+ 4.1.7 (SQUIT) and 4.3.5 (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 delicate since its abuse is both
+ destructive and annoying. For further details on this type of
+ action, see section 4.6.1 (KILL).
+
+1.3 Channels
+
+ A channel is a named group of one or more clients which will all
+ receive messages addressed to that channel. The channel is created
+ implicitly when the first client joins it, and the channel ceases to
+ exist when the last client leaves it. While channel exists, any
+ client can reference the channel using the name of the channel.
+
+ Channels names are strings (beginning with a '&' or '#' character) of
+ length up to 200 characters. Apart from the the requirement that the
+ first character being either '&' or '#'; the only restriction on a
+ channel name is that it may not contain any spaces (' '), a control G
+ (^G or ASCII 7), or a comma (',' which is used as a list item
+ separator by the protocol).
+
+ There are two types of channels allowed by this protocol. One is a
+ distributed channel which is known to all the servers that are
+
+ connected to the network. These channels are marked by the first
+ character being a only clients on the server where it exists may join
+ it. These are distinguished by a leading '&' character. On top of
+ these two types, there are the various channel modes available to
+ alter the characteristics of individual channels. See section 4.2.3
+ (MODE command) for more details on this.
+
+ To create a new channel or become part of an existing channel, a user
+ is required to JOIN the channel. If the channel doesn't exist prior
+ to joining, the channel is created and the creating user becomes a
+ channel operator. If the channel already exists, whether or not your
+ request to JOIN that channel is honoured depends on the current modes
+ of the channel. For example, if the channel is invite-only, (+i),
+ then you may only join if invited. As part of the protocol, a user
+ may be a part of several channels at once, but a limit of ten (10)
+ channels is recommended as being ample for both experienced and
+ novice users. See section 8.13 for more information on this.
+
+ If the IRC network becomes disjoint because of a split between two
+ servers, the channel on each side is only composed of those clients
+ which are connected to servers on the respective sides of the split,
+ possibly ceasing to exist on one side of the split. When the split
+ is healed, the connecting servers announce to each other who they
+ think is in each channel and the mode of that channel. If the
+ channel exists on both sides, the JOINs and MODEs are interpreted in
+ an inclusive manner so that both sides of the new connection will
+ agree about which clients are in the channel and what modes the
+ channel has.
+
+1.3.1 Channel Operators
+
+ The channel operator (also referred to as a "chop" or "chanop") on a
+ given channel is considered to 'own' that channel. In recognition of
+ this status, channel operators are endowed with certain powers which
+ enable them to keep control and some sort of sanity in their channel.
+ As an owner of a channel, a channel operator is not required to have
+ reasons for their actions, although if their actions are generally
+ antisocial or otherwise abusive, it might be reasonable to ask an IRC
+ operator to intervene, or for the usersjust leave and go elsewhere
+ and form their own channel.
+
+ The commands which may only be used by channel operators are:
+
+ KICK - Eject a client from the channel
+ MODE - Change the channel's mode
+ INVITE - Invite a client to an invite-only channel (mode +i)
+ TOPIC - Change the channel topic in a mode +t channel
+
+ A channel operator is identified by the '@' symbol next to their
+ nickname whenever it is associated with a channel (ie replies to the
+ NAMES, WHO and WHOIS commands).
+
+2. The IRC Specification
+
+2.1 Overview
+
+ The protocol as described herein is for use both with server to
+ server and client to server connections. There are, however, more
+ restrictions on client connections (which are considered to be
+ untrustworthy) than on server connections.
+
+2.2 Character codes
+
+ No specific character set is specified. The protocol is based on a 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 USASCII terminal and a
+ telnet connection.
+
+ Because of IRC's scandanavian 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.
+
+2.3 Messages
+
+ Servers and clients send eachother 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 in nature.
+
+ Each IRC message may consist of up to three main parts: the prefix
+ (optional), the command, and the command parameters (of which there
+ may be up to 15). The prefix, command, and all parameters are
+ separated by one (or more) ASCII space character(s) (0x20).
+
+ 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. Clients should not use prefix when sending a message from
+ themselves; if they use a prefix, the only valid prefix is the
+ registered nickname associated with the client. If the source
+ identified by the prefix cannot be found from the server's internal
+ database, or if the source is registered from a different link than
+ from which the message arrived, the server must ignore the message
+ silently.
+
+ 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 message lines. See section 7 for more details about
+ current implementations.
+
+2.3.1 Message format in 'pseudo' 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 <prefix>,
+ <command> and list of parameters matched either by <middle> or
+ <trailing> components.
+
+ The BNF representation for this is:
+
+<message> ::= [':' <prefix> <SPACE> ] <command> <params> <crlf>
+<prefix> ::= <servername> | <nick> [ '!' <user> ] [ '@' <host> ]
+<command> ::= <letter> { <letter> } | <number> <number> <number>
+<SPACE> ::= ' ' { ' ' }
+<params> ::= <SPACE> [ ':' <trailing> | <middle> <params> ]
+
+<middle> ::= <Any *non-empty* sequence of octets not including SPACE
+ or NUL or CR or LF, the first of which may not be ':'>
+<trailing> ::= <Any, possibly *empty*, sequence of octets not including
+ NUL or CR or LF>
+
+<crlf> ::= CR LF
+
+NOTES:
+
+ 1) <SPACE> is consists only of SPACE character(s) (0x20).
+ Specially notice that TABULATION, and all other control
+ characters are considered NON-WHITE-SPACE.
+
+ 2) After extracting the parameter list, all parameters are equal,
+ whether matched by <middle> or <trailing>. <Trailing> is just
+ a syntactic trick to allow SPACE within parameter.
+
+ 3) The fact that CR and LF cannot appear in parameter strings is
+ just artifact of the message framing. This might change later.
+
+ 4) The NUL character is not special in message framing, and
+ basically could end up inside a parameter, but as it would
+ cause extra complexities in normal C string handling. Therefore
+ NUL is not allowed within messages.
+
+ 5) The last parameter may be an empty string.
+
+ 6) Use of the extended prefix (['!' <user> ] ['@' <host> ]) must
+ not be used in server to server communications and is only
+ intended for server to client messages in order to provide
+ clients with more useful information about who a message is
+ from without the need for additional queries.
+
+ 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> ::= <to> [ "," <target> ]
+ <to> ::= <channel> | <user> '@' <servername> | <nick> | <mask>
+ <channel> ::= ('#' | '&') <chstring>
+ <servername> ::= <host>
+ <host> ::= see RFC 952 [DNS:4] for details on allowed hostnames
+ <nick> ::= <letter> { <letter> | <number> | <special> }
+ <mask> ::= ('#' | '$') <chstring>
+ <chstring> ::= <any 8bit code except SPACE, BELL, NUL, CR, LF and
+ comma (',')>
+
+ Other parameter syntaxes are:
+
+ <user> ::= <nonwhite> { <nonwhite> }
+ <letter> ::= 'a' ... 'z' | 'A' ... 'Z'
+ <number> ::= '0' ... '9'
+ <special> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'
+
+ <nonwhite> ::= <any 8bit code except SPACE (0x20), NUL (0x0), CR
+ (0xd), and LF (0xa)>
+
+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; any such messages received by a server are silently
+ dropped. 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 6.
+
+3. IRC Concepts.
+
+ This section is devoted to describing the actual concepts behind the
+ organization of the IRC protocol and how the current
+ implementations deliver different classes of messages.
+
+ 1--\
+ A D---4
+ 2--/ \ /
+ B----C
+ / \
+ 3 E
+
+ Servers: A, B, C, D, E Clients: 1, 2, 3, 4
+
+ [ Fig. 2. Sample small IRC network ]
+
+3.1 One-to-one communication
+
+ Communication on a one-to-one basis is usually only performed by
+ clients, since most server-server traffic is not a result of servers
+ talking only to each other. To provide a secure means for clients to
+ talk to each other, it is required that all servers be able to send a
+ message in exactly one direction along the spanning tree in order to
+ reach any client. The path of a message being delivered is the
+ shortest path between any two points on the spanning tree.
+
+ The following examples all refer to Figure 2 above.
+
+Example 1:
+ A message between clients 1 and 2 is only seen by server A, which
+ sends it straight to client 2.
+
+Example 2:
+ A message between clients 1 and 3 is seen by servers A & B, and
+ client 3. No other clients or servers are allowed see the message.
+
+Example 3:
+ A message between clients 2 and 4 is seen by servers A, B, C & D
+ and client 4 only.
+
+3.2 One-to-many
+
+ The main goal of IRC is to provide a forum which allows easy and
+ efficient conferencing (one to many conversations). IRC offers
+ several means to achieve this, each serving its own purpose.
+
+3.2.1 To a list
+
+ The least efficient style of one-to-many conversation is through
+ clients talking to a 'list' of users. How this is done is almost
+ self explanatory: the client gives a list of destinations to which
+ the message is to be delivered and the server breaks it up and
+ dispatches a separate copy of the message to each given destination.
+ This isn't as efficient as using a group since the destination list
+ is broken up and the dispatch sent without checking to make sure
+ duplicates aren't sent down each path.
+
+3.2.2 To a group (channel)
+
+ In IRC the channel has a role equivalent to that of the multicast
+ group; their existence is dynamic (coming and going as people join
+ and leave channels) and the actual conversation carried out on a
+ channel is only sent to servers which are supporting users on a given
+ channel. If there are multiple users on a server in the same
+ channel, the message text is sent only once to that server and then
+ sent to each client on the channel. This action is then repeated for
+ each client-server combination until the original message has fanned
+ out and reached each member of the channel.
+
+ The following examples all refer to Figure 2.
+
+Example 4:
+ Any channel with 1 client in it. Messages to the channel go to the
+ server and then nowhere else.
+
+Example 5:
+ 2 clients in a channel. All messages traverse a path as if they
+ were private messages between the two clients outside a channel.
+
+Example 6:
+ Clients 1, 2 and 3 in a channel. All messages to the channel are
+ sent to all clients and only those servers which must be traversed
+ by the message if it were a private message to a single client. If
+ client 1 sends a message, it goes back to client 2 and then via
+ server B to client 3.
+
+3.2.3 To a host/server mask
+
+ To provide IRC operators with some mechanism to send messages to a
+ large body of related users, host and server mask messages are
+ provided. These messages are sent to users whose host or server
+ information match that of the mask. The messages are only sent to
+ locations where users are, in a fashion similar to that of channels.
+
+3.3 One-to-all
+
+ The one-to-all type of message is better described as a broadcast
+ message, sent to all clients or servers or both. On a large network
+ of users and servers, a single message can result in a lot of traffic
+ being sent over the network in an effort to reach all of the desired
+ destinations.
+
+ For some messages, there is no option but to broadcast it to all
+ servers so that the state information held by each server is
+ reasonably consistent between servers.
+
+3.3.1 Client-to-Client
+
+ There is no class of message which, from a single message, results in
+ a message being sent to every other client.
+
+3.3.2 Client-to-Server
+
+ Most of the commands which result in a change of state information
+ (such as channel membership, channel mode, user status, etc) must be
+ sent to all servers by default, and this distribution may not be
+ changed by the client.
+
+3.3.3 Server-to-Server.
+
+ While most messages between servers are distributed to all 'other'
+ servers, this is only required for any message that affects either a
+ user, channel or server. Since these are the basic items found in
+
+ IRC, nearly all messages originating from a server are broadcast to
+ all other connected servers.
+
+4. Message details
+
+ On the following pages 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 listed, it means that the
+ <server> parameter could not be found. The server must not send any
+ other replies after this for that command.
+
+ The server to which a client is connected is required to parse the
+ complete message, returning any appropriate errors. If the server
+ encounters a fatal error while parsing a message, an error must be
+ sent back to the client and the parsing terminated. A fatal error
+ may be considered to be incorrect command, a destination which is
+ otherwise unknown to the server (server, nick or channel names fit
+ this category), not enough parameters or incorrect privileges.
+
+ If a full set of parameters is presented, then each must be checked
+ for validity and appropriate responses sent back to the client. In
+ the case of messages which use parameter lists using the comma as an
+ item separator, a reply must be sent for each item.
+
+ In the examples below, some messages appear using the full format:
+
+ :Name COMMAND parameter list
+
+ Such examples represent a message from "Name" in transit between
+ servers, where it is essential to include the name of the original
+ sender of the message so remote servers may send back a reply along
+ the correct path.
+
+4.1 Connection Registration
+
+ The commands described here are used to register a connection with an
+ IRC server as either a user or a server as well as correctly
+ disconnect.
+
+ A "PASS" command is not required for either client or server
+ connection to be registered, but it must precede the server message
+ or the latter of the NICK/USER combination. It is strongly
+ recommended that all server connections have a password in order to
+ give some level of security to the actual connections. The
+ recommended order for a client to register is as follows:
+
+ 1. Pass message
+ 2. Nick message
+ 3. User message
+
+4.1.1 Password message
+
+ Command: PASS
+ Parameters: <password>
+
+ The PASS command is used to set a 'connection password'. The
+ password can and must be set before any attempt to register the
+ connection is made. Currently this requires that clients send a PASS
+ command before sending the NICK/USER combination and servers *must*
+ send a PASS command before any SERVER command. The password supplied
+ must match the one contained in the C/N lines (for servers) or I
+ lines (for clients). It is possible to send multiple PASS commands
+ before registering but only the last one sent is used for
+ verification and it may not be changed once registered. Numeric
+ Replies:
+
+ ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
+
+ Example:
+
+ PASS secretpasswordhere
+
+4.1.2 Nick message
+
+ Command: NICK
+ Parameters: <nickname> [ <hopcount> ]
+
+ NICK message is used to give user a nickname or change the previous
+ one. The <hopcount> parameter is only used by servers to indicate
+ how far away a nick is from its home server. A local connection has
+ a hopcount of 0. If supplied by a client, it must be ignored.
+
+ If a NICK message arrives at a server which already knows about an
+ identical nickname for another client, a nickname collision occurs.
+ As a result of a nickname collision, all instances of the nickname
+ are removed from the server's database, and a KILL command is issued
+ to remove the nickname from all other server's database. If the NICK
+ message causing the collision was a nickname change, then the
+ original (old) nick must be removed as well.
+
+ If the server recieves an identical NICK from a client which is
+ directly connected, it may issue an ERR_NICKCOLLISION to the local
+ client, drop the NICK command, and not generate any kills.
+
+ Numeric Replies:
+
+ ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
+ ERR_NICKNAMEINUSE ERR_NICKCOLLISION
+
+ Example:
+
+ NICK Wiz ; Introducing new nick "Wiz".
+
+ :WiZ NICK Kilroy ; WiZ changed his nickname to Kilroy.
+
+4.1.3 User message
+
+ Command: USER
+ Parameters: <username> <hostname> <servername> <realname>
+
+ The USER message is used at the beginning of connection to specify
+ the username, hostname, servername and realname of s new user. It is
+ also used in communication between servers to indicate new user
+ arriving on IRC, since only after both USER and NICK have been
+ received from a client does a user become registered.
+
+ Between servers USER must to be prefixed with client's NICKname.
+ Note that hostname and servername are normally ignored by the IRC
+ server when the USER command comes from a directly connected client
+ (for security reasons), but they are used in server to server
+ communication. This means that a NICK must always be sent to a
+ remote server when a new user is being introduced to the rest of the
+ network before the accompanying USER is sent.
+
+ It must be noted that realname parameter must be the last parameter,
+ because it may contain space characters and must be prefixed with a
+ colon (':') to make sure this is recognised as such.
+
+ Since it is easy for a client to lie about its username by relying
+ solely on the USER message, the use of an "Identity Server" is
+ recommended. If the host which a user connects from has such a
+ server enabled the username is set to that as in the reply from the
+ "Identity Server".
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
+
+ Examples:
+
+ USER guest tolmoon tolsun :Ronnie Reagan
+
+ ; User registering themselves with a
+ username of "guest" and real name
+ "Ronnie Reagan".
+
+ :testnick USER guest tolmoon tolsun :Ronnie Reagan
+ ; message between servers with the
+ nickname for which the USER command
+ belongs to
+
+4.1.4 Server message
+
+ Command: SERVER
+ Parameters: <servername> <hopcount> <info>
+
+ The server message is used to tell a server that the other end of a
+ new connection is a server. This message is also used to pass server
+ data over whole net. When a new server is connected to net,
+ information about it be broadcast to the whole network. <hopcount>
+ is used to give all servers some internal information on how far away
+ all servers are. With a full server list, it would be possible to
+ construct a map of the entire server tree, but hostmasks prevent this
+ from being done.
+
+ The SERVER message must only be accepted from either (a) a connection
+ which is yet to be registered and is attempting to register as a
+ server, or (b) an existing connection to another server, in which
+ case the SERVER message is introducing a new server behind that
+ server.
+
+ Most errors that occur with the receipt of a SERVER command result in
+ the connection being terminated by the destination host (target
+ SERVER). Error replies are usually sent using the "ERROR" command
+ rather than the numeric since the ERROR command has several useful
+ properties which make it useful here.
+
+ If a SERVER message is parsed and attempts to introduce a server
+ which is already known to the receiving server, the connection from
+ which that message must be closed (following the correct procedures),
+ since a duplicate route to a server has formed and the acyclic nature
+ of the IRC tree broken.
+
+ Numeric Replies:
+
+ ERR_ALREADYREGISTRED
+
+ Example:
+
+SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server
+ ; New server test.oulu.fi introducing
+ itself and attempting to register. The
+ name in []'s is the hostname for the
+ host running test.oulu.fi.
+
+:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
+ ; Server tolsun.oulu.fi is our uplink
+ for csd.bu.edu which is 5 hops away.
+
+4.1.5 Oper
+
+ Command: OPER
+ Parameters: <user> <password>
+
+ OPER message is used by a normal user to obtain operator privileges.
+ The combination of <user> and <password> are required to gain
+ Operator privileges.
+
+ If the client sending the OPER command supplies the correct password
+ for the given user, the server then informs the rest of the network
+ of the new operator by issuing a "MODE +o" for the clients nickname.
+
+ The OPER message is client-server only.
+
+ 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.
+
+4.1.6 Quit
+
+ Command: QUIT
+ Parameters: [<Quit message>]
+
+ A client session is ended with a quit message. The server must close
+ the connection to a client which sends a QUIT message. If a "Quit
+ Message" is given, this will be sent instead of the default message,
+ the nickname.
+
+ When netsplits (disconnecting of two servers) occur, the quit message
+
+ is composed of the names of two servers involved, separated by a
+ space. The first name is that of the server which is still connected
+ and the second name is that of the server that has become
+ disconnected.
+
+ If, for some other reason, a client connection is closed without the
+ client issuing a QUIT command (e.g. client dies and EOF occurs
+ on socket), the server is required to fill in the quit message with
+ some sort of message reflecting the nature of the event which
+ caused it to happen.
+
+ Numeric Replies:
+
+ None.
+
+ Examples:
+
+ QUIT :Gone to have lunch ; Preferred message format.
+
+4.1.7 Server quit message
+
+ Command: SQUIT
+ Parameters: <server> <comment>
+
+ The SQUIT message is needed to tell about quitting or dead servers.
+ If a server wishes to break the connection to another server it must
+ send a SQUIT message to the other server, using the the name of the
+ other server as the server parameter, which then closes its
+ connection to the quitting server.
+
+ This command is also available operators to help keep a network of
+ IRC servers connected in an orderly fashion. Operators may also
+ issue an SQUIT message for a remote server connection. In this case,
+ the SQUIT must be parsed by each server inbetween the operator and
+ the remote server, updating the view of the network held by each
+ server as explained below.
+
+ The <comment> should be supplied by all operators who execute a SQUIT
+ for a remote server (that is not connected to the server they are
+ currently on) so that other operators are aware for the reason of
+ this action. The <comment> is also filled in by servers which may
+ place an error or similar message here.
+
+ Both of the servers which are on either side of the connection being
+ closed are required to to send out a SQUIT message (to all its other
+ server connections) for all other servers which are considered to be
+ behind that link.
+
+ Similarly, a QUIT message must be sent to the other connected servers
+ rest of the network on behalf of all clients behind that link. In
+ addition to this, all channel members of a channel which lost a
+ member due to the split must be sent a QUIT message.
+
+ If a server connection is terminated prematurely (e.g. the server on
+ the other end of the link died), the server which detects
+ this disconnection is required to inform the rest of the network
+ that the connection has closed and fill in the comment field
+ with something appropriate.
+
+ Numeric replies:
+
+ ERR_NOPRIVILEGES ERR_NOSUCHSERVER
+
+ Example:
+
+ SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has
+ been terminated because of "Bad Link".
+
+ :Trillian SQUIT cm22.eng.umd.edu :Server out of control
+ ; message from Trillian to disconnect
+ "cm22.eng.umd.edu" from the net
+ because "Server out of control".
+
+4.2 Channel operations
+
+ This group of messages is concerned with manipulating channels, their
+ properties (channel modes), and their contents (typically clients).
+ In implementing these, a number of race conditions are inevitable
+ when clients at opposing ends of a network send commands which will
+ ultimately clash. It is also required that servers keep a nickname
+ history to ensure that wherever a <nick> parameter is given, the
+ server check its history in case it has recently been changed.
+
+4.2.1 Join message
+
+ Command: JOIN
+ Parameters: <channel>{,<channel>} [<key>{,<key>}]
+
+ The JOIN command is used by client to start listening a specific
+ channel. Whether or not a client is allowed to join a channel is
+ checked only by the server the client is connected to; all other
+ servers automatically add the user to the channel when it is received
+ from other servers. The conditions which affect this are as follows:
+
+ 1. the user must be invited if the channel is invite-only;
+
+ 2. the user's nick/username/hostname must not match any
+ active bans;
+
+ 3. the correct key (password) must be given if it is set.
+
+ These are discussed in more detail under the MODE command (see
+ section 4.2.3 for more details).
+
+ Once a user has joined a channel, they receive notice about all
+ commands their server receives which affect the channel. This
+ includes MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. The
+ JOIN command needs to be broadcast to all servers so that each server
+ knows where to find the users who are on the channel. This allows
+ optimal delivery of PRIVMSG/NOTICE messages to the channel.
+
+ If a JOIN is successful, the user 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.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
+ ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
+ ERR_CHANNELISFULL ERR_BADCHANMASK
+ ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
+ RPL_TOPIC
+
+ Examples:
+
+ JOIN #foobar ; join channel #foobar.
+
+ JOIN &foo fubar ; join channel &foo using key "fubar".
+
+ JOIN #foo,&bar fubar ; join channel #foo using key "fubar"
+ and &bar using no key.
+
+ JOIN #foo,#bar fubar,foobar ; join channel #foo using key "fubar".
+ and channel #bar using key "foobar".
+
+ JOIN #foo,#bar ; join channels #foo and #bar.
+
+ :WiZ JOIN #Twilight_zone ; JOIN message from WiZ
+
+4.2.2 Part message
+
+ Command: PART
+ Parameters: <channel>{,<channel>}
+
+ The PART message causes the client sending the message to be removed
+ from the list of active users for all given channels listed in the
+ parameter string.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
+ ERR_NOTONCHANNEL
+
+ Examples:
+
+ PART #twilight_zone ; leave channel "#twilight_zone"
+
+ PART #oz-ops,&group5 ; leave both channels "&group5" and
+ "#oz-ops".
+
+4.2.3 Mode message
+
+ Command: MODE
+
+ The MODE command is a dual-purpose command in IRC. It allows both
+ usernames and channels to have their mode changed. The rationale for
+ this choice is that one day nicknames will be obsolete and the
+ equivalent property will be the channel.
+
+ When parsing MODE messages, it is recommended that the entire message
+ be parsed first and then the changes which resulted then passed on.
+
+4.2.3.1 Channel modes
+
+ Parameters: <channel> {[+|-]|o|p|s|i|t|n|b|v} [<limit>] [<user>]
+ [<ban mask>]
+
+ The MODE command is provided so that channel operators may change the
+ characteristics of `their' channel. It is also required that servers
+ be able to change channel modes so that channel operators may be
+ created.
+
+ The various modes available for channels are as follows:
+
+ o - give/take channel operator privileges;
+ p - private channel flag;
+ s - secret channel flag;
+ i - invite-only channel flag;
+ t - topic settable by channel operator only flag;
+ n - no messages to channel from clients on the outside;
+ m - moderated channel;
+ l - set the user limit to channel;
+
+ b - set a ban mask to keep users out;
+ v - give/take the ability to speak on a moderated channel;
+ k - set a channel key (password).
+
+ When using the 'o' and 'b' options, a restriction on a total of three
+ per mode command has been imposed. That is, any combination of 'o'
+ and
+
+4.2.3.2 User modes
+
+ Parameters: <nickname> {[+|-]|i|w|s|o}
+
+ The user MODEs 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 may only be accepted if both the sender of the
+ message and the nickname given as a parameter are both the same.
+
+ The available modes are as follows:
+
+ i - marks a users as invisible;
+ s - marks a user for receipt of server notices;
+ w - user receives wallops;
+ o - operator flag.
+
+ Additional modes may be available later on.
+
+ If a user attempts to make themselves an operator using the "+o"
+ flag, the attempt should be ignored. There is no restriction,
+ however, on anyone `deopping' themselves (using "-o"). Numeric
+ Replies:
+
+ ERR_NEEDMOREPARAMS RPL_CHANNELMODEIS
+ ERR_CHANOPRIVSNEEDED ERR_NOSUCHNICK
+ ERR_NOTONCHANNEL ERR_KEYSET
+ RPL_BANLIST RPL_ENDOFBANLIST
+ ERR_UNKNOWNMODE ERR_NOSUCHCHANNEL
+
+ ERR_USERSDONTMATCH RPL_UMODEIS
+ ERR_UMODEUNKNOWNFLAG
+
+ Examples:
+
+ Use of Channel Modes:
+
+MODE #Finnish +im ; Makes #Finnish channel moderated and
+ 'invite-only'.
+
+MODE #Finnish +o Kilroy ; Gives 'chanop' privileges to Kilroy on
+
+ channel #Finnish.
+
+MODE #Finnish +v Wiz ; Allow WiZ to speak on #Finnish.
+
+MODE #Fins -s ; Removes 'secret' flag from channel
+ #Fins.
+
+MODE #42 +k oulu ; Set the channel key to "oulu".
+
+MODE #eu-opers +l 10 ; Set the limit for the number of users
+ on channel to 10.
+
+MODE &oulu +b ; list ban masks set for channel.
+
+MODE &oulu +b *!*@* ; prevent all users from joining.
+
+MODE &oulu +b *!*@*.edu ; prevent any user from a hostname
+ matching *.edu from joining.
+
+ Use of user Modes:
+
+:MODE WiZ -w ; turns reception of WALLOPS messages
+ off for WiZ.
+
+:Angel MODE Angel +i ; Message from Angel to make themselves
+ invisible.
+
+MODE WiZ -o ; WiZ 'deopping' (removing operator
+ status). The plain reverse of this
+ command ("MODE WiZ +o") must not be
+ allowed from users since would bypass
+ the OPER command.
+
+4.2.4 Topic message
+
+ Command: TOPIC
+ Parameters: <channel> [<topic>]
+
+ The TOPIC message is used to change or view the topic of a channel.
+ The topic for channel <channel> is returned if there is no <topic>
+ given. If the <topic> parameter is present, the topic for that
+ channel will be changed, if the channel modes permit this action.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
+ RPL_NOTOPIC RPL_TOPIC
+ ERR_CHANOPRIVSNEEDED
+
+ Examples:
+
+ :Wiz TOPIC #test :New topic ;User Wiz setting the topic.
+
+ TOPIC #test :another topic ;set the topic on #test to "another
+ topic".
+
+ TOPIC #test ; check the topic for #test.
+
+4.2.5 Names message
+
+ Command: NAMES
+ Parameters: [<channel>{,<channel>}]
+
+ By using the NAMES command, a user can list all nicknames that are
+ visible to them on any channel that they can see. Channel names
+ which they can see are those which aren't private (+p) or secret (+s)
+ or those which they are actually on. The <channel> parameter
+ specifies which channel(s) to return information about if valid.
+ There is no error reply for bad channel names.
+
+ If no <channel> 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' "*".
+
+ Numerics:
+
+ RPL_NAMREPLY RPL_ENDOFNAMES
+
+ Examples:
+
+ NAMES #twilight_zone,#42 ; list visible users on #twilight_zone
+ and #42 if the channels are visible to
+ you.
+
+ NAMES ; list all visible channels and users
+
+4.2.6 List message
+
+ Command: LIST
+ Parameters: [<channel>{,<channel>} [<server>]]
+
+ The list message is used to list channels and their topics. If the
+ <channel> parameter is used, only the status of that channel
+ is displayed. Private channels are listed (without their
+ topics) as channel "Prv" unless the client generating the query is
+ actually on that channel. Likewise, secret channels are not listed
+
+ at all unless the client is a member of the channel in question.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER RPL_LISTSTART
+ RPL_LIST RPL_LISTEND
+
+ Examples:
+
+ LIST ; List all channels.
+
+ LIST #twilight_zone,#42 ; List channels #twilight_zone and #42
+
+4.2.7 Invite message
+
+ Command: INVITE
+ Parameters: <nickname> <channel>
+
+ The INVITE message is used to invite users to a channel. The
+ parameter <nickname> is the nickname of the person to be invited to
+ the target channel <channel>. There is no requirement that the
+ channel the target user is being invited to must exist or be a valid
+ channel. To invite a user to a channel which is invite only (MODE
+ +i), the client sending the invite must be recognised as being a
+ channel operator on the given channel.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
+ ERR_NOTONCHANNEL ERR_USERONCHANNEL
+ ERR_CHANOPRIVSNEEDED
+ RPL_INVITING RPL_AWAY
+
+ Examples:
+
+ :Angel INVITE Wiz #Dust ; User Angel inviting WiZ to channel
+ #Dust
+
+ INVITE Wiz #Twilight_Zone ; Command to invite WiZ to
+ #Twilight_zone
+
+4.2.8 Kick command
+
+ Command: KICK
+ Parameters: <channel> <user> [<comment>]
+
+ The KICK command can be used to forcibly remove a user from a
+ channel. It 'kicks them out' of the channel (forced PART).
+
+ Only a channel operator may kick another user out of a channel.
+ Each server that receives a KICK message checks that it is valid
+ (ie the sender is actually a channel operator) before removing
+ the victim from the channel.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
+ ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
+ ERR_NOTONCHANNEL
+
+ Examples:
+
+KICK &Melbourne Matthew ; Kick Matthew from &Melbourne
+
+KICK #Finnish John :Speaking English
+ ; Kick John from #Finnish using
+ "Speaking English" as the reason
+ (comment).
+
+:WiZ KICK #Finnish John ; KICK message from WiZ to remove John
+ from channel #Finnish
+
+NOTE:
+ It is possible to extend the KICK command parameters to the
+following:
+
+<channel>{,<channel>} <user>{,<user>} [<comment>]
+
+4.3 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. All
+ servers connected must respond to these queries and respond
+ correctly. Any invalid response (or lack thereof) must be considered
+ a sign of a broken server and it must be disconnected/disabled as
+ soon as possible until the situation is remedied.
+
+ In these queries, where a parameter appears as "<server>", it will
+ usually mean it can be a nickname or a server or a wildcard name of
+ some sort. For each parameter, however, only one query and set of
+ replies is to be generated.
+
+4.3.1 Version message
+
+ Command: VERSION
+ Parameters: [<server>]
+
+ The VERSION message is used to query the version of the server
+ program. An optional parameter <server> is used to query the version
+ of the server program which a client is not directly connected to.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER RPL_VERSION
+
+ Examples:
+
+ :Wiz VERSION *.se ; message from Wiz to check the version
+ of a server matching "*.se"
+
+ VERSION tolsun.oulu.fi ; check the version of server
+ "tolsun.oulu.fi".
+
+4.3.2 Stats message
+
+ Command: STATS
+ Parameters: [<query> [<server>]]
+
+ The stats message is used to query statistics of certain server. If
+ <server> parameter is omitted, only the end of stats reply is sent
+ back. The implementation of this command is highly dependent on the
+ server which replies, although the server must be able to supply
+ information as described by the queries below (or similar).
+
+ A query may be given by any single letter which is only checked by
+ the destination server (if given as the <server> parameter) and is
+ otherwise passed on by intermediate servers, ignored and unaltered.
+ The following queries are those found in the current IRC
+ implementation and provide a large portion of the setup information
+ for that server. Although these may not be supported in the same way
+ by other versions, all servers should be able to supply a valid reply
+ to a STATS query which is consistent with the reply formats currently
+ used and the purpose of the query.
+
+ The currently supported queries are:
+
+ c - returns a list of servers which the server may connect
+ to or allow connections from;
+ h - returns a list of servers which are either forced to be
+ treated as leaves or allowed to act as hubs;
+ i - returns a list of hosts which the server allows a client
+ to connect from;
+ k - returns a list of banned username/hostname combinations
+ for that 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 bytes and messages for each
+ direction;
+ m - returns a list of commands supported by the server and
+ the usage count for each if the usage count is non zero;
+ o - returns a list of hosts from which normal clients may
+ become operators;
+ y - show Y (Class) lines from server's configuration file;
+ u - returns a string showing how long the server has been up.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER
+ RPL_STATSCLINE RPL_STATSNLINE
+ RPL_STATSILINE RPL_STATSKLINE
+ RPL_STATSQLINE RPL_STATSLLINE
+ RPL_STATSLINKINFO RPL_STATSUPTIME
+ RPL_STATSCOMMANDS RPL_STATSOLINE
+ RPL_STATSHLINE RPL_ENDOFSTATS
+
+ Examples:
+
+STATS m ; check the command usage for the server
+ you are connected to
+
+:Wiz STATS c eff.org ; request by WiZ for C/N line
+ information from server eff.org
+
+4.3.3 Links message
+
+ Command: LINKS
+ Parameters: [[<remote server>] <server mask>]
+
+ With LINKS, a user can list all servers 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 <remote server> is given in addition to <server mask>, 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
+
+ Examples:
+
+LINKS *.au ; list all servers which have a name
+ that matches *.au;
+
+:WiZ LINKS *.bu.edu *.edu ; LINKS message from WiZ to the first
+ server matching *.edu for a list of
+ servers matching *.bu.edu.
+
+4.3.4 Time message
+
+ Command: TIME
+ Parameters: [<server>]
+
+ The time message is used to query local time from the specified
+ server. If the server parameter is not given, the server handling the
+ command must reply to the query.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER RPL_TIME
+
+ Examples:
+
+ TIME tolsun.oulu.fi ; check the time on the server
+ "tolson.oulu.fi"
+
+ Angel TIME *.au ; user angel checking the time on a
+ server matching "*.au"
+
+4.3.5 Connect message
+
+ Command: CONNECT
+ Parameters: <target server> [<port> [<remote server>]]
+
+ The CONNECT command can be used to force a server to try to establish
+ a new connection to another server immediately. CONNECT is a
+ privileged command and is to be available only to IRC Operators. If
+ a remote server is given then the CONNECT attempt is made by that
+ server to <target server> and <port>.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER ERR_NOPRIVILEGES
+ ERR_NEEDMOREPARAMS
+
+ Examples:
+
+CONNECT tolsun.oulu.fi ; Attempt to connect a server to
+ tolsun.oulu.fi
+
+:WiZ CONNECT eff.org 6667 csd.bu.edu
+ ; CONNECT attempt by WiZ to get servers
+ eff.org and csd.bu.edu connected on port
+ 6667.
+
+4.3.6 Trace message
+
+ Command: TRACE
+ Parameters: [<server>]
+
+ 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 similar to that gained from using "traceroute". After
+ sending this reply back, it must then send the TRACE message to the
+ next server until given server is reached. If the <server> parameter
+ is omitted, it is recommended that TRACE command send a message to
+ the sender telling which servers the current server has direct
+ connection to.
+
+ If the destination given by "<server>" is an actual server, then the
+ destination server is required to report all servers and users which
+ are connected to it, although only operators are permitted to see
+ users present. If the destination given by <server> is a nickname,
+ they only a reply for that nickname is given.
+
+ 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 its going next.
+
+ RPL_TRACELINK
+ 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
+
+ Examples:
+
+TRACE *.oulu.fi ; TRACE to a server matching *.oulu.fi
+
+:WiZ TRACE AngelDust ; TRACE issued by WiZ to nick AngelDust
+
+4.3.7 Admin command
+
+ Command: ADMIN
+ Parameters: [<server>]
+
+ The admin message is used to find the name of the administrator of
+ the given server, or current server if <server> parameter is omitted.
+ Each server must have the ability to forward ADMIN messages to other
+ servers.
+
+ 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
+
+ :WiZ ADMIN *.edu ; ADMIN request from WiZ for first
+ server found to match *.edu.
+
+4.3.8 Info command
+
+ Command: INFO
+ Parameters: [<server>]
+
+ The INFO command is required to return information which describes
+ 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.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER
+ RPL_INFO RPL_ENDOFINFO
+
+ Examples:
+
+ INFO csd.bu.edu ; request an INFO reply from
+ csd.bu.edu
+
+ :Avalon INFO *.fi ; INFO request from Avalon for first
+ server found to match *.fi.
+
+ INFO Angel ; request info from the server that
+ Angel is connected to.
+
+4.4 Sending messages
+
+ The main purpose of the IRC protocol is to provide a base for clients
+ to communicate with each other. PRIVMSG and NOTICE 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.
+
+4.4.1 Private messages
+
+ Command: PRIVMSG
+ Parameters: <receiver>{,<receiver>} <text to be sent>
+
+ PRIVMSG is used to send private messages between users. <receiver>
+ is the nickname of the receiver of the message. <receiver> can also
+ be a list of names or channels separated with commas.
+
+ The <receiver> parameter may also me a host mask (#mask) or server
+ mask ($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; from
+ experience, this is abused more than used responsibly and properly.
+ 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
+
+ Examples:
+
+:Angel PRIVMSG Wiz :Hello are you receiving this message ?
+ ; Message from Angel to Wiz.
+
+PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ;
+ Message to Angel.
+
+PRIVMSG jto@tolsun.oulu.fi :Hello !
+ ; Message to a client on server
+
+ tolsun.oulu.fi with username of "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.
+
+4.4.2 Notice
+
+ Command: NOTICE
+ Parameters: <nickname> <text>
+
+ The NOTICE message 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
+ 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 a client automatically sending something in response to
+ something it received. This is typically used by automatons (clients
+ with either an AI or other interactive program controlling their
+ actions) which are always seen to be replying lest they end up in a
+ loop with another automaton.
+
+ See PRIVMSG for more details on replies and examples.
+
+4.5 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.
+
+4.5.1 Who query
+
+ Command: WHO
+ Parameters: [<name> [<o>]]
+
+ The WHO message is used by a client to generate a query which returns
+ a list of information which 'matches' the <name> parameter given by
+ the client. In the absence of the <name> 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 <name> of "0" or any wildcard which
+
+ will end up matching every entry possible.
+
+ The <name> passed to WHO is matched against users' host, server, real
+ name and nickname if the channel <name> cannot be found.
+
+ If the "o" parameter is passed only operators are returned according
+ to the name mask supplied.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER
+ RPL_WHOREPLY RPL_ENDOFWHO
+
+ Examples:
+
+ WHO *.fi ; List all users who match against
+ "*.fi".
+
+ WHO jto* o ; List all users with a match against
+ "jto*" if they are an operator.
+
+4.5.2 Whois query
+
+ Command: WHOIS
+ Parameters: [<server>] <nickmask>[,<nickmask>[,...]]
+
+ This message is used to query information about particular user. The
+ server will answer this message with several numeric messages
+ indicating different statuses of each user which matches the nickmask
+ (if you are entitled to see them). If no wildcard is present in the
+ <nickmask>, any information about that nick which you are allowed to
+ see is presented. A comma (',') separated list of nicknames may be
+ given.
+
+ The latter version 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 (ie. the server the user is directly
+ connected to) knows that information, while everything else is
+ globally known.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
+ RPL_WHOISUSER RPL_WHOISCHANNELS
+ RPL_WHOISCHANNELS RPL_WHOISSERVER
+ RPL_AWAY RPL_WHOISOPERATOR
+ RPL_WHOISIDLE ERR_NOSUCHNICK
+ RPL_ENDOFWHOIS
+
+ Examples:
+
+ WHOIS wiz ; return available user information
+ about nick WiZ
+
+ WHOIS eff.org trillian ; ask server eff.org for user
+ information about trillian
+
+4.5.3 Whowas
+
+ Command: WHOWAS
+ Parameters: <nickname> [<count> [<server>]]
+
+ 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
+ <count> replies will be returned (or all of them if no <count>
+ parameter is given). If a non-positive number is passed as being
+ <count>, then a full search is done.
+
+ 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".
+
+4.6 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.
+
+4.6.1 Kill message
+
+ Command: KILL
+ Parameters: <nickname> <comment>
+
+ The KILL message is used to cause a client-server connection to be
+ closed by the server which has the actual connection. KILL is used
+ by servers when they encounter a duplicate entry in the list of valid
+ nicknames and is used to remove both entries. It is also available
+ to operators.
+
+ 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 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.
+
+ 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
+
+ KILL David (csd.bu.edu <- tolsun.oulu.fi)
+ ; Nickname collision between csd.bu.edu
+ and tolson.oulu.fi
+
+ NOTE:
+ It is recommended that only Operators be allowed to kill other users
+ with KILL message. In an ideal world not even operators would need
+ to do this and it would be left to servers to deal with.
+
+4.6.2 Ping message
+
+ Command: PING
+ Parameters: <server1> [<server2>]
+
+ The PING message is used to test the presence of an active client at
+ the other end of the connection. A PING message is sent at regular
+ intervals if no other activity detected coming from a connection. If
+ a connection fails to respond to a PING command within a set amount
+ of time, that connection is closed.
+
+ Any client which receives a PING message must respond to <server1>
+ (server which sent the PING message out) as quickly as possible with
+ an appropriate PONG message to indicate it is still there and alive.
+ Servers should not respond to PING commands but rely on PINGs from
+ the other end of the connection to indicate the connection is alive.
+ If the <server2> parameter is specified, the PING message gets
+ forwarded there.
+
+ Numeric Replies:
+
+ ERR_NOORIGIN ERR_NOSUCHSERVER
+
+ Examples:
+
+ PING tolsun.oulu.fi ; server sending a PING message to
+ another server to indicate it is still
+ alive.
+
+ PING WiZ ; PING message being sent to nick WiZ
+
+4.6.3 Pong message
+
+ Command: PONG
+ Parameters: <daemon> [<daemon2>]
+
+ PONG message is a reply to ping message. If parameter <daemon2> is
+ given this message must be forwarded to given daemon. The <daemon>
+ parameter is the name of the daemon who has responded to PING message
+ and generated this message.
+
+ Numeric Replies:
+
+ ERR_NOORIGIN ERR_NOSUCHSERVER
+
+ Examples:
+
+ PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to
+
+ tolsun.oulu.fi
+
+4.6.4 Error
+
+ Command: ERROR
+ Parameters: <error message>
+
+ The ERROR command is for use by servers when reporting a serious or
+ fatal error to its operators. It may also be sent from one server to
+ another but must not be accepted from any normal unknown clients.
+
+ An ERROR message is for use for reporting errors which occur with a
+ server-to-server link only. An ERROR message is sent to the server
+ at the other end (which sends it to all of its connected operators)
+ and to all operators currently connected. It is not to be passed
+ onto any other servers by a server if it is received from a server.
+
+ 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.
+
+ 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.
+
+5. OPTIONALS
+
+ This section describes OPTIONAL messages. They are not required in a
+ working server implementation of the protocol described herein. In
+ the absence of the option, 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.
+
+5.1 Away
+
+ Command: AWAY
+ Parameters: [message]
+
+ With the AWAY message, clients can set an automatic reply string for
+ any PRIVMSG commands directed at them (not to a channel they are on).
+ The automatic reply is sent by the server to client sending the
+ PRIVMSG command. The only replying server is the one to which the
+ sending client is connected to.
+
+ The AWAY message is used either with one parameter (to set an AWAY
+ message) or with no parameters (to remove the AWAY message).
+
+ Numeric Replies:
+
+ RPL_UNAWAY RPL_NOWAWAY
+
+ Examples:
+
+ AWAY :Gone to lunch. Back in 5 ; set away message to "Gone to lunch.
+ Back in 5".
+
+ :WiZ AWAY ; unmark WiZ as being away.
+
+5.2 Rehash message
+
+ Command: REHASH
+ Parameters: None
+
+ The rehash message can be used by the operator to force the server to
+ re-read and process its configuration file.
+
+ Numeric Replies:
+
+ RPL_REHASHING ERR_NOPRIVILEGES
+
+Examples:
+
+REHASH ; message from client with operator
+ status to server asking it to reread its
+ configuration file.
+
+5.3 Restart message
+
+ Command: RESTART
+ Parameters: None
+
+ The restart message can only be used by an operator to force a server
+ 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 not be passed onto other
+ connected servers.
+
+ Numeric Replies:
+
+ ERR_NOPRIVILEGES
+
+ Examples:
+
+ RESTART ; no parameters required.
+
+5.4 Summon message
+
+ Command: SUMMON
+ Parameters: <user> [<server>]
+
+ 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 <server> parameter is given it tries to summon <user> 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 and pass the summon message onwards.
+
+ Numeric Replies:
+
+ ERR_NORECIPIENT ERR_FILEERROR
+ ERR_NOLOGIN ERR_NOSUCHSERVER
+ RPL_SUMMONING
+
+ 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.
+
+5.5 Users
+
+ Command: USERS
+ Parameters: [<server>]
+
+ The USERS command returns a list of users logged into the server in a
+ similar format to who(1), rusers(1) and finger(1). Some people
+ may disable this command on their server for security related
+ reasons. If disabled, the correct numeric must be returned to
+ indicate this.
+
+ Numeric Replies:
+
+ ERR_NOSUCHSERVER ERR_FILEERROR
+ RPL_USERSSTART RPL_USERS
+ RPL_NOUSERS RPL_ENDOFUSERS
+ ERR_USERSDISABLED
+
+ Disabled Reply:
+
+ ERR_USERSDISABLED
+
+ Examples:
+
+USERS eff.org ; request a list of users logged in on
+ server eff.org
+
+:John USERS tolsun.oulu.fi ; request from John for a list of users
+ logged in on server tolsun.oulu.fi
+
+5.6 Operwall message
+
+ Command: WALLOPS
+ Parameters: Text to be sent to all operators currently online
+
+ Sends a message to all operators currently online. 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 (much similar to WALL). Due to this it is recommended
+ that the current implementation of WALLOPS be used as an
+ example by allowing and recognising only servers as the senders of
+ WALLOPS.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS
+
+ Examples:
+
+ :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua; WALLOPS
+ message from csd.bu.edu announcing a
+ CONNECT message it received and acted
+ upon from Joshua.
+
+5.7 Userhost message
+
+ Command: USERHOST
+ Parameters: <nickname>{<space><nickname>}
+
+ 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
+
+ Examples:
+
+ USERHOST Wiz Michael Marty p ;USERHOST request for information on
+ nicks "Wiz", "Michael", "Marty" and "p"
+
+5.8 Ison message
+
+ Command: ISON
+ Parameters: <nickname>{<space><nickname>}
+
+ 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) parameter: a space-separated list of
+ nicks. For each nickname in the list that is present, the 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 as 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 be 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
+
+ Examples:
+
+ ISON phone trillian WiZ jarlek Avalon Angel Monstah
+ ; Sample ISON request for 7 nicks.
+
+6. 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.
+
+6.1 Error Replies.
+
+ 401 ERR_NOSUCHNICK
+ "<nickname> :No such nick/channel"
+
+ - Used to indicate the nickname parameter supplied to a
+ command is currently unused.
+
+ 402 ERR_NOSUCHSERVER
+ "<server name> :No such server"
+
+ - Used to indicate the server name given currently
+ doesn't exist.
+
+ 403 ERR_NOSUCHCHANNEL
+ "<channel name> :No such channel"
+
+ - Used to indicate the given channel name is invalid.
+
+ 404 ERR_CANNOTSENDTOCHAN
+ "<channel name> :Cannot send to channel"
+
+ - Sent to a user who is either (a) not on a channel
+ which is mode +n or (b) not a chanop (or mode +v) on
+ a channel which has mode +m set and is trying to send
+ a PRIVMSG message to that channel.
+
+ 405 ERR_TOOMANYCHANNELS
+ "<channel name> :You have joined too many \
+ channels"
+ - Sent to a user when they have joined the maximum
+ number of allowed channels and they try to join
+ another channel.
+
+ 406 ERR_WASNOSUCHNICK
+ "<nickname> :There was no such nickname"
+
+ - Returned by WHOWAS to indicate there is no history
+ information for that nickname.
+
+ 407 ERR_TOOMANYTARGETS
+ "<target> :Duplicate recipients. No message \
+
+ delivered"
+
+ - Returned to a client which is attempting to send a
+ PRIVMSG/NOTICE using the user@host destination format
+ and for a user@host which has several occurrences.
+
+ 409 ERR_NOORIGIN
+ ":No origin specified"
+
+ - PING or PONG message missing the originator parameter
+ which is required since these commands must work
+ without valid prefixes.
+
+ 411 ERR_NORECIPIENT
+ ":No recipient given (<command>)"
+ 412 ERR_NOTEXTTOSEND
+ ":No text to send"
+ 413 ERR_NOTOPLEVEL
+ "<mask> :No toplevel domain specified"
+ 414 ERR_WILDTOPLEVEL
+ "<mask> :Wildcard in toplevel domain"
+
+ - 412 - 414 are returned by PRIVMSG to indicate that
+ the message wasn't delivered for some reason.
+ ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
+ are returned when an invalid use of
+ "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
+
+ 421 ERR_UNKNOWNCOMMAND
+ "<command> :Unknown command"
+
+ - Returned to a registered client to indicate that the
+ command sent is unknown by the server.
+
+ 422 ERR_NOMOTD
+ ":MOTD File is missing"
+
+ - Server's MOTD file could not be opened by the server.
+
+ 423 ERR_NOADMININFO
+ "<server> :No administrative info available"
+
+ - Returned by a server in response to an ADMIN message
+ when there is an error in finding the appropriate
+ information.
+
+ 424 ERR_FILEERROR
+ ":File error doing <file op> on <file>"
+
+ - Generic error message used to report a failed file
+ operation during the processing of a message.
+
+ 431 ERR_NONICKNAMEGIVEN
+ ":No nickname given"
+
+ - Returned when a nickname parameter expected for a
+ command and isn't found.
+
+ 432 ERR_ERRONEUSNICKNAME
+ "<nick> :Erroneus nickname"
+
+ - Returned after receiving a NICK message which contains
+ characters which do not fall in the defined set. See
+ section x.x.x for details on valid nicknames.
+
+ 433 ERR_NICKNAMEINUSE
+ "<nick> :Nickname is already in use"
+
+ - Returned when a NICK message is processed that results
+ in an attempt to change to a currently existing
+ nickname.
+
+ 436 ERR_NICKCOLLISION
+ "<nick> :Nickname collision KILL"
+
+ - Returned by a server to a client when it detects a
+ nickname collision (registered of a NICK that
+ already exists by another server).
+
+ 441 ERR_USERNOTINCHANNEL
+ "<nick> <channel> :They aren't on that channel"
+
+ - Returned by the server to indicate that the target
+ user of the command is not on the given channel.
+
+ 442 ERR_NOTONCHANNEL
+ "<channel> :You're not on that channel"
+
+ - Returned by the server whenever a client tries to
+ perform a channel effecting command for which the
+ client isn't a member.
+
+ 443 ERR_USERONCHANNEL
+ "<user> <channel> :is already on channel"
+
+ - Returned when a client tries to invite a user to a
+ channel they are already on.
+
+ 444 ERR_NOLOGIN
+ "<user> :User not logged in"
+
+ - Returned by the summon after a SUMMON command for a
+ user was unable to be performed since they were not
+ logged in.
+
+ 445 ERR_SUMMONDISABLED
+ ":SUMMON has been disabled"
+
+ - Returned as a response to the SUMMON command. Must be
+ returned by any server which does not implement it.
+
+ 446 ERR_USERSDISABLED
+ ":USERS has been disabled"
+
+ - Returned as a response to the USERS command. Must be
+ returned by any server which does not implement it.
+
+ 451 ERR_NOTREGISTERED
+ ":You have not registered"
+
+ - Returned by the server to indicate that the client
+ must be registered before the server will allow it
+ to be parsed in detail.
+
+ 461 ERR_NEEDMOREPARAMS
+ "<command> :Not enough parameters"
+
+ - Returned by the server by numerous commands to
+ indicate to the client that it didn't supply enough
+ parameters.
+
+ 462 ERR_ALREADYREGISTRED
+ ":You may not reregister"
+
+ - Returned by the server to any link which tries to
+ change part of the registered details (such as
+ password or user details from second USER message).
+
+ 463 ERR_NOPERMFORHOST
+ ":Your host isn't among the privileged"
+
+ - Returned to a client which attempts to register with
+ a server which does not been setup to allow
+ connections from the host the attempted connection
+ is tried.
+
+ 464 ERR_PASSWDMISMATCH
+ ":Password incorrect"
+
+ - Returned to indicate a failed attempt at registering
+ a connection for which a password was required and
+ was either not given or incorrect.
+
+ 465 ERR_YOUREBANNEDCREEP
+ ":You are banned from this server"
+
+ - Returned after an attempt to connect and register
+ yourself with a server which has been setup to
+ explicitly deny connections to you.
+
+ 467 ERR_KEYSET
+ "<channel> :Channel key already set"
+ 471 ERR_CHANNELISFULL
+ "<channel> :Cannot join channel (+l)"
+ 472 ERR_UNKNOWNMODE
+ "<char> :is unknown mode char to me"
+ 473 ERR_INVITEONLYCHAN
+ "<channel> :Cannot join channel (+i)"
+ 474 ERR_BANNEDFROMCHAN
+ "<channel> :Cannot join channel (+b)"
+ 475 ERR_BADCHANNELKEY
+ "<channel> :Cannot join channel (+k)"
+ 481 ERR_NOPRIVILEGES
+ ":Permission Denied- You're not an IRC operator"
+
+ - Any command requiring operator privileges to operate
+ must return this error to indicate the attempt was
+ unsuccessful.
+
+ 482 ERR_CHANOPRIVSNEEDED
+ "<channel> :You're not channel operator"
+
+ - Any command requiring 'chanop' privileges (such as
+ MODE messages) must return this error if the client
+ making the attempt is not a chanop on the specified
+ channel.
+
+ 483 ERR_CANTKILLSERVER
+ ":You cant kill a server!"
+
+ - Any attempts to use the KILL command on a server
+ are to be refused and this error returned directly
+ to the client.
+
+ 491 ERR_NOOPERHOST
+ ":No O-lines for your host"
+
+ - If a client sends an OPER message and the server has
+ not been configured to allow connections from the
+ client's host as an operator, this error must be
+ returned.
+
+ 501 ERR_UMODEUNKNOWNFLAG
+ ":Unknown MODE flag"
+
+ - Returned by the server to indicate that a MODE
+ message was sent with a nickname parameter and that
+ the a mode flag sent was not recognized.
+
+ 502 ERR_USERSDONTMATCH
+ ":Cant change mode for other users"
+
+ - Error sent to any user trying to view or change the
+ user mode for a user other than themselves.
+
+6.2 Command responses.
+
+ 300 RPL_NONE
+ Dummy reply number. Not used.
+
+ 302 RPL_USERHOST
+ ":[<reply>{<space><reply>}]"
+
+ - Reply format used by USERHOST to list replies to
+ the query list. The reply string is composed as
+ follows:
+
+ <reply> ::= <nick>['*'] '=' <'+'|'-'><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
+ ":[<nick> {<space><nick>}]"
+
+ - Reply format used by ISON to list replies to the
+ query list.
+
+ 301 RPL_AWAY
+ "<nick> :<away message>"
+
+ 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
+ "<nick> <user> <host> * :<real name>"
+ 312 RPL_WHOISSERVER
+ "<nick> <server> :<server info>"
+ 313 RPL_WHOISOPERATOR
+ "<nick> :is an IRC operator"
+ 317 RPL_WHOISIDLE
+ "<nick> <integer> :seconds idle"
+ 318 RPL_ENDOFWHOIS
+ "<nick> :End of /WHOIS list"
+ 319 RPL_WHOISCHANNELS
+ "<nick> :{[@|+]<channel><space>}"
+
+ - 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
+ "<nick> <user> <host> * :<real name>"
+ 369 RPL_ENDOFWHOWAS
+ "<nick> :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
+ "Channel :Users Name"
+ 322 RPL_LIST
+ "<channel> <# visible> :<topic>"
+ 323 RPL_LISTEND
+ ":End of /LIST"
+
+ - Replies RPL_LISTSTART, RPL_LIST, RPL_LISTEND mark
+ the start, 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 start
+ and end reply must be sent.
+
+ 324 RPL_CHANNELMODEIS
+ "<channel> <mode> <mode params>"
+
+ 331 RPL_NOTOPIC
+ "<channel> :No topic is set"
+ 332 RPL_TOPIC
+ "<channel> :<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
+ "<channel> <nick>"
+
+ - Returned by the server to indicate that the
+ attempted INVITE message was successful and is
+ being passed onto the end client.
+
+ 342 RPL_SUMMONING
+ "<user> :Summoning user to IRC"
+
+ - Returned by a server answering a SUMMON message to
+ indicate that it is summoning that user.
+
+ 351 RPL_VERSION
+ "<version>.<debuglevel> <server> :<comments>"
+
+ - Reply by the server showing its version details.
+ The <version> is the version of the software being
+
+ used (including any patchlevel revisions) and the
+ <debuglevel> 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
+ "<channel> <user> <host> <server> <nick> \
+ <H|G>[*][@|+] :<hopcount> <real name>"
+ 315 RPL_ENDOFWHO
+ "<name> :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 <name> being
+ the item.
+
+ 353 RPL_NAMREPLY
+ "<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]"
+ 366 RPL_ENDOFNAMES
+ "<channel> :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
+ 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
+ "<mask> <server> :<hopcount> <server info>"
+ 365 RPL_ENDOFLINKS
+ "<mask> :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
+ "<channel> <banid>"
+ 368 RPL_ENDOFBANLIST
+
+ "<channel> :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 banid. After the
+ banids have been listed (or if none present) a
+ RPL_ENDOFBANLIST must be sent.
+
+ 371 RPL_INFO
+ ":<string>"
+ 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
+ ":- <server> Message of the day - "
+ 372 RPL_MOTD
+ ":- <text>"
+ 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
+ RPL_MOTD format replies. These should 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
+ "<config file> :Rehashing"
+
+ - If the REHASH option is used and an operator sends
+ a REHASH message, an RPL_REHASHING is sent back to
+ the operator.
+
+ 391 RPL_TIME
+
+ "<server> :<string showing server's local 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
+ ":%-8s %-9s %-8s"
+ 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.
+
+ 200 RPL_TRACELINK
+ "Link <version & debug level> <destination> \
+ <next server>"
+ 201 RPL_TRACECONNECTING
+ "Try. <class> <server>"
+ 202 RPL_TRACEHANDSHAKE
+ "H.S. <class> <server>"
+ 203 RPL_TRACEUNKNOWN
+ "???? <class> [<client IP address in dot form>]"
+ 204 RPL_TRACEOPERATOR
+ "Oper <class> <nick>"
+ 205 RPL_TRACEUSER
+ "User <class> <nick>"
+ 206 RPL_TRACESERVER
+ "Serv <class> <int>S <int>C <server> \
+ <nick!user|*!*>@<host|server>"
+ 208 RPL_TRACENEWTYPE
+ "<newtype> 0 <client name>"
+ 261 RPL_TRACELOG
+ "File <logfile> <debug level>"
+
+ - The RPL_TRACE* are all returned by the server in
+ response to the TRACE message. How many are
+ returned is dependent on the 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.
+ RPL_TRACENEWTYPE is to be used for any connection
+ which does not fit in the other categories but is
+ being displayed anyway.
+
+ 211 RPL_STATSLINKINFO
+ "<linkname> <sendq> <sent messages> \
+ <sent bytes> <received messages> \
+ <received bytes> <time open>"
+ 212 RPL_STATSCOMMANDS
+ "<command> <count>"
+ 213 RPL_STATSCLINE
+ "C <host> * <name> <port> <class>"
+ 214 RPL_STATSNLINE
+ "N <host> * <name> <port> <class>"
+ 215 RPL_STATSILINE
+ "I <host> * <host> <port> <class>"
+ 216 RPL_STATSKLINE
+ "K <host> * <username> <port> <class>"
+ 218 RPL_STATSYLINE
+ "Y <class> <ping frequency> <connect \
+ frequency> <max sendq>"
+ 219 RPL_ENDOFSTATS
+ "<stats letter> :End of /STATS report"
+ 241 RPL_STATSLLINE
+ "L <hostmask> * <servername> <maxdepth>"
+ 242 RPL_STATSUPTIME
+ ":Server Up %d days %d:%02d:%02d"
+ 243 RPL_STATSOLINE
+ "O <hostmask> * <name>"
+ 244 RPL_STATSHLINE
+ "H <hostmask> * <servername>"
+
+ 221 RPL_UMODEIS
+ "<user mode string>"
+
+ - To answer a query about a client's own mode,
+ RPL_UMODEIS is sent back.
+
+ 251 RPL_LUSERCLIENT
+ ":There are <integer> users and <integer> \
+ invisible on <integer> servers"
+ 252 RPL_LUSEROP
+ "<integer> :operator(s) online"
+ 253 RPL_LUSERUNKNOWN
+ "<integer> :unknown connection(s)"
+ 254 RPL_LUSERCHANNELS
+ "<integer> :channels formed"
+ 255 RPL_LUSERME
+ ":I have <integer> clients and <integer> \
+ servers"
+
+ - In processing an LUSERS message, the server
+ sends a set of replies from RPL_LUSERCLIENT,
+ RPL_LUSEROP, RPL_USERUNKNOWN,
+ RPL_LUSERCHANNELS and RPL_LUSERME. When
+ replying, a server must send back
+ RPL_LUSERCLIENT and RPL_LUSERME. The other
+ replies are only sent back if a non-zero count
+ is found for them.
+
+ 256 RPL_ADMINME
+ "<server> :Administrative info"
+ 257 RPL_ADMINLOC1
+ ":<admin info>"
+ 258 RPL_ADMINLOC2
+ ":<admin info>"
+ 259 RPL_ADMINEMAIL
+ ":<admin info>"
+
+ - When replying to an ADMIN message, a server
+ is expected to use replies RLP_ADMINME
+ through to RPL_ADMINEMAIL and provide a text
+ message with each. For RPL_ADMINLOC1 a
+ description of what city, state and country
+ the server is in is expected, followed by
+ details of the university and department
+ (RPL_ADMINLOC2) and finally the administrative
+ contact for the server (an email address here
+ is required) in RPL_ADMINEMAIL.
+
+6.3 Reserved numerics.
+
+ These numerics are not described above since they fall into one of
+ the following categories:
+
+ 1. no longer in use;
+
+ 2. reserved for future planned use;
+
+ 3. in current use but are part of a non-generic 'feature' of
+ the current IRC server.
+
+ 209 RPL_TRACECLASS 217 RPL_STATSQLINE
+ 231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES
+ 233 RPL_SERVICE 234 RPL_SERVLIST
+ 235 RPL_SERVLISTEND
+ 316 RPL_WHOISCHANOP 361 RPL_KILLDONE
+ 362 RPL_CLOSING 363 RPL_CLOSEEND
+ 373 RPL_INFOSTART 384 RPL_MYPORTIS
+ 466 ERR_YOUWILLBEBANNED 476 ERR_BADCHANMASK
+ 492 ERR_NOSERVICEHOST
+
+7. Client and server authentication
+
+ Clients and servers are both subject to the same level of
+ authentication. For both, an IP number to hostname lookup (and
+ reverse check on this) is performed for all connections made to the
+ server. Both connections are then subject to a password check (if
+ there is a password set for that connection). These checks are
+ possible on all connections although the password check is only
+ commonly used with servers.
+
+ An additional check that is becoming of more and more common is that
+ of the username responsible for making the connection. Finding the
+ username of the other end of the connection typically involves
+ connecting to an authentication server such as IDENT as described in
+ RFC 1413.
+
+ Given that without passwords it is not easy to reliably determine who
+ is on the other end of a network connection, use of passwords is
+ strongly recommended on inter-server connections in addition to any
+ other measures such as using an ident server.
+
+8. Current implementations
+
+ The only current implementation of this protocol is the IRC server,
+ version 2.8. Earlier versions may implement some or all of the
+ commands described by this document with NOTICE messages replacing
+
+ many of the numeric replies. Unfortunately, due to backward
+ compatibility requirements, the implementation of some parts of this
+ document varies with what is laid out. On notable difference is:
+
+ * recognition that any LF or CR anywhere in a message marks the
+ end of that message (instead of requiring CR-LF);
+
+ The rest of this section deals with issues that are mostly of
+ importance to those who wish to implement a server but some parts
+ also apply directly to clients as well.
+
+8.1 Network protocol: TCP - why it is best used here.
+
+ IRC has been implemented on top of TCP since TCP supplies a reliable
+ network protocol which is well suited to this scale of conferencing.
+ The use of multicast IP is an alternative, but it is not widely
+ available or supported at the present time.
+
+8.1.1 Support of Unix sockets
+
+ Given that Unix domain sockets allow listen/connect operations, the
+ current implementation can be configured to listen and accept both
+ client and server connections on a Unix domain socket. These are
+ recognized as sockets where the hostname starts with a '/'.
+
+ When providing any information about the connections on a Unix domain
+ socket, the server is required to supplant the actual hostname in
+ place of the pathname unless the actual socket name is being asked
+ for.
+
+8.2 Command Parsing
+
+ To provide useful 'non-buffered' network IO for clients and servers,
+ each connection is given its own private 'input buffer' in which the
+ results of the most recent read and parsing are kept. A buffer size
+ of 512 bytes is used so as to hold 1 full message, although, this
+ will usually hold several commands. The private buffer is parsed
+ after every read operation for valid messages. When dealing with
+ multiple messages from one client in the buffer, care should be taken
+ in case one happens to cause the client to be 'removed'.
+
+8.3 Message delivery
+
+ It is common to find network links saturated or hosts to which you
+ are sending data unable to send data. Although Unix typically
+ handles this through the TCP window and internal buffers, the server
+ often has large amounts of data to send (especially when a new
+ server-server link forms) and the small buffers provided in the
+
+ kernel are not enough for the outgoing queue. To alleviate this
+ problem, a "send queue" is used as a FIFO queue for data to be sent.
+ A typical "send queue" may grow to 200 Kbytes on a large IRC network
+ with a slow network connection when a new server connects.
+
+ When polling its connections, a server will first read and parse all
+ incoming data, queuing any data to be sent out. When all available
+ input is processed, the queued data is sent. This reduces the number
+ of write() system calls and helps TCP make bigger packets.
+
+8.4 Connection 'Liveness'
+
+ To detect when a connection has died or become unresponsive, the
+ server must ping each of its connections that it doesn't get a
+ response from in a given amount of time.
+
+ If a connection doesn't respond in time, its connection is closed
+ using the appropriate procedures. A connection is also dropped if
+ its sendq grows beyond the maximum allowed, because it is better to
+ close a slow connection than have a server process block.
+
+8.5 Establishing a server to client connection
+
+ Upon connecting to an IRC server, a client is sent the MOTD (if
+ present) as well as the current user/server count (as per the LUSER
+ command). The server is also required to give an unambiguous message
+ to the client which states its name and version as well as any other
+ introductory messages which may be deemed appropriate.
+
+ After dealing with this, the server must then send out the new user's
+ nickname and other information as supplied by itself (USER command)
+ and as the server could discover (from DNS/authentication servers).
+ The server must send this information out with NICK first followed by
+ USER.
+
+8.6 Establishing a server-server connection.
+
+ The process of establishing of a server-to-server connection is
+ fraught with danger since there are many possible areas where
+ problems can occur - the least of which are race conditions.
+
+ After a server has received a connection following by a PASS/SERVER
+ pair which were recognised as being valid, the server should then
+ reply with its own PASS/SERVER information for that connection as
+ well as all of the other state information it knows about as
+ described below.
+
+ When the initiating server receives a PASS/SERVER pair, it too then
+
+ checks that the server responding is authenticated properly before
+ accepting the connection to be that server.
+
+8.6.1 Server exchange of state information when connecting
+
+ The order of state information being exchanged between servers is
+ essential. The required order is as follows:
+
+ * all known other servers;
+
+ * all known user information;
+
+ * all known channel information.
+
+ Information regarding servers is sent via extra SERVER messages, user
+ information with NICK/USER/MODE/JOIN messages and channels with MODE
+ messages.
+
+ NOTE: channel topics are *NOT* exchanged here because the TOPIC
+ command overwrites any old topic information, so at best, the two
+ sides of the connection would exchange topics.
+
+ By passing the state information about servers first, any collisions
+ with servers that already exist occur before nickname collisions due
+ to a second server introducing a particular nickname. Due to the IRC
+ network only being able to exist as an acyclic graph, it may be
+ possible that the network has already reconnected in another
+ location, the place where the collision occurs indicating where the
+ net needs to split.
+
+8.7 Terminating server-client connections
+
+ When a client connection closes, a QUIT message is generated on
+ behalf of the client by the server to which the client connected. No
+ other message is to be generated or used.
+
+8.8 Terminating server-server connections
+
+ If a server-server connection is closed, either via a remotely
+ generated SQUIT or 'natural' causes, the rest of the connected IRC
+ network must have its information updated with by the server which
+ detected the closure. The server then sends a list of SQUITs (one
+ for each server behind that connection) and a list of QUITs (again,
+ one for each client behind that connection).
+
+8.9 Tracking nickname changes
+
+ All IRC servers are required to keep a history of recent nickname
+ changes. This is required to allow the server to have a chance of
+ keeping in touch of things when nick-change race conditions occur
+ with commands which manipulate them. Commands which must trace nick
+ changes are:
+
+ * KILL (the nick being killed)
+
+ * MODE (+/- o,v)
+
+ * KICK (the nick being kicked)
+
+ No other commands are to have nick changes checked for.
+
+ In the above cases, the server is required to first check for the
+ existence of the nickname, then check its history to see who that
+ nick currently belongs to (if anyone!). This reduces the chances of
+ race conditions but they can still occur with the server ending up
+ affecting the wrong client. When performing a change trace for an
+ above command it is recommended that a time range be given and
+ entries which are too old ignored.
+
+ For a reasonable history, a server should be able to keep previous
+ nickname for every client it knows about if they all decided to
+ change. This size is limited by other factors (such as memory, etc).
+
+8.10 Flood control of clients
+
+ With a large network of interconnected IRC servers, it is quite easy
+ for any single client attached to the network to supply a continuous
+ stream of messages that result in not only flooding the network, but
+ also degrading the level of service provided to others. Rather than
+ require every 'victim' to be provide their own protection, flood
+ protection was written into the server and is applied to all clients
+ except services. The current algorithm is as follows:
+
+ * check to see if client's `message timer' is less than
+ current time (set to be equal if it is);
+
+ * read any data present from the client;
+
+ * while the timer is less than ten seconds ahead of the current
+ time, parse any present messages and penalize the client by
+ 2 seconds for each message;
+
+ which in essence means that the client may send 1 message every 2
+
+ seconds without being adversely affected.
+
+8.11 Non-blocking lookups
+
+ In a real-time environment, it is essential that a server process do
+ as little waiting as possible so that all the clients are serviced
+ fairly. Obviously this requires non-blocking IO on all network
+ read/write operations. For normal server connections, this was not
+ difficult, but there are other support operations that may cause the
+ server to block (such as disk reads). Where possible, such activity
+ should be performed with a short timeout.
+
+8.11.1 Hostname (DNS) lookups
+
+ Using the standard resolver libraries from Berkeley and others has
+ meant large delays in some cases where replies have timed out. To
+ avoid this, a separate set of DNS routines were written which were
+ setup for non-blocking IO operations and then polled from within the
+ main server IO loop.
+
+8.11.2 Username (Ident) lookups
+
+ Although there are numerous ident libraries for use and inclusion
+ into other programs, these caused problems since they operated in a
+ synchronous manner and resulted in frequent delays. Again the
+ solution was to write a set of routines which would cooperate with
+ the rest of the server and work using non-blocking IO.
+
+8.12 Configuration File
+
+ To provide a flexible way of setting up and running the server, it is
+ recommended that a configuration file be used which contains
+ instructions to the server on the following:
+
+ * which hosts to accept client connections from;
+
+ * which hosts to allow to connect as servers;
+
+ * which hosts to connect to (both actively and
+ passively);
+
+ * information about where the server is (university,
+ city/state, company are examples of this);
+
+ * who is responsible for the server and an email address
+ at which they can be contacted;
+
+ * hostnames and passwords for clients which wish to be given
+
+ access to restricted operator commands.
+
+ In specifying hostnames, both domain names and use of the 'dot'
+ notation (127.0.0.1) should both be accepted. It must be possible to
+ specify the password to be used/accepted for all outgoing and
+ incoming connections (although the only outgoing connections are
+ those to other servers).
+
+ The above list is the minimum requirement for any server which wishes
+ to make a connection with another server. Other items which may be
+ of use are:
+
+ * specifying which servers other server may introduce;
+
+ * how deep a server branch is allowed to become;
+
+ * hours during which clients may connect.
+
+8.12.1 Allowing clients to connect
+
+ A server should use some sort of 'access control list' (either in the
+ configuration file or elsewhere) that is read at startup and used to
+ decide what hosts clients may use to connect to it.
+
+ Both 'deny' and 'allow' should be implemented to provide the required
+ flexibility for host access control.
+
+8.12.2 Operators
+
+ The granting of operator privileges to a disruptive person can have
+ dire consequences for the well-being of the IRC net in general due to
+ the powers given to them. Thus, the acquisition of such powers
+ should not be very easy. The current setup requires two 'passwords'
+ to be used although one of them is usually easy guessed. Storage of
+ oper passwords in configuration files is preferable to hard coding
+ them in and should be stored in a crypted format (ie using crypt(3)
+ from Unix) to prevent easy theft.
+
+8.12.3 Allowing servers to connect
+
+ The interconnection of server is not a trivial matter: a bad
+ connection can have a large impact on the usefulness of IRC. Thus,
+ each server should have a list of servers to which it may connect and
+ which servers may connect to it. Under no circumstances should a
+ server allow an arbitrary host to connect as a server. In addition
+ to which servers may and may not connect, the configuration file
+ should also store the password and other characteristics of that
+ link.
+
+8.12.4 Administrivia
+
+ To provide accurate and valid replies to the ADMIN command (see
+ section 4.3.7), the server should find the relevant details in the
+ configuration.
+
+8.13 Channel membership
+
+ The current server allows any registered local user to join upto 10
+ different channels. There is no limit imposed on non-local users so
+ that the server remains (reasonably) consistant with all others on a
+ channel membership basis
+
+9. Current problems
+
+ There are a number of recognized problems with this protocol, all of
+ which hope to be solved sometime in the near future during its
+ rewrite. Currently, work is underway to find working solutions to
+ these problems.
+
+9.1 Scalability
+
+ It is widely recognized that this protocol does not scale
+ sufficiently well when used in a large arena. The main problem comes
+ from the requirement that all servers know about all other servers
+ and users and that information regarding them be updated as soon as
+ it changes. It is also desirable to keep the number of servers low
+ so that the path length between any two points is kept minimal and
+ the spanning tree as strongly branched as possible.
+
+9.2 Labels
+
+ The current IRC protocol has 3 types of labels: the nickname, the
+ channel name and the server name. Each of the three types has its
+ own domain and no duplicates are allowed inside that domain.
+ Currently, it is possible for users to pick the label for any of the
+ three, resulting in collisions. It is widely recognized that this
+ needs reworking, with a plan for unique names for channels and nicks
+ that don't collide being desirable as well as a solution allowing a
+ cyclic tree.
+
+9.2.1 Nicknames
+
+ The idea of the nickname on IRC is very convenient for users to use
+ when talking to each other outside of a channel, but there is only a
+ finite nickname space and being what they are, its not uncommon for
+ several people to want to use the same nick. If a nickname is chosen
+ by two people using this protocol, either one will not succeed or
+
+ both will removed by use of KILL (4.6.1).
+
+9.2.2 Channels
+
+ The current channel layout requires that all servers know about all
+ channels, their inhabitants and properties. Besides not scaling
+ well, the issue of privacy is also a concern. A collision of
+ channels is treated as an inclusive event (both people who create the
+ new channel are considered to be members of it) rather than an
+ exclusive one such as used to solve nickname collisions.
+
+9.2.3 Servers
+
+ Although the number of servers is usually small relative to the
+ number of users and channels, they two currently required to be known
+ globally, either each one separately or hidden behind a mask.
+
+9.3 Algorithms
+
+ In some places within the server code, it has not been possible to
+ avoid N^2 algorithms such as checking the channel list of a set
+ of clients.
+
+ In current server versions, there are no database consistency checks,
+ each server assumes that a neighbouring server is correct. This
+ opens the door to large problems if a connecting server is buggy or
+ otherwise tries to introduce contradictions to the existing net.
+
+ Currently, because of the lack of unique internal and global labels,
+ there are a multitude of race conditions that exist. These race
+ conditions generally arise from the problem of it taking time for
+ messages to traverse and effect the IRC network. Even by changing to
+ unique labels, there are problems with channel-related commands being
+ disrupted.
+
+10. Current support and availability
+
+ Mailing lists for IRC related discussion:
+ Future protocol: ircd-three-request@eff.org
+ General discussion: operlist-request@eff.org
+
+ Software implemenations
+ cs.bu.edu:/irc
+ nic.funet.fi:/pub/irc
+ coombs.anu.edu.au:/pub/irc
+
+ Newsgroup: alt.irc
+
+Security Considerations
+
+ Security issues are discussed in sections 4.1, 4.1.1, 4.1.3, 5.5, and
+ 7.
+
+12. Authors' Addresses
+
+ Jarkko Oikarinen
+ Tuirantie 17 as 9
+ 90500 OULU
+ FINLAND
+
+ Email: jto@tolsun.oulu.fi
+
+ Darren Reed
+ 4 Pateman Street
+ Watsonia, Victoria 3087
+ Australia
+
+ Email: avalon@coombs.anu.edu.au
diff --git a/doc/technical/rfc2812.txt b/doc/technical/rfc2812.txt
new file mode 100644
index 0000000..3a77c66
--- /dev/null
+++ b/doc/technical/rfc2812.txt
@@ -0,0 +1,2916 @@
+$Id$
+
+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
+
+ 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
+
+ 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.
+
+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.
+
+ 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.
+
+ 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 <prefix>,
+ <command> and list of parameters (<params>).
+
+ 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"
+
+ NOTES:
+ 1) After extracting the parameter list, all parameters are equal
+ whether matched by <middle> or <trailing>. <trailing> 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 )
+
+ 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 <hostaddr> 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) <hostname> 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
+ <params>.
+
+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).
+
+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.
+
+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: <password>
+
+ 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: <nickname>
+
+ NICK command is used to give user a nickname or change the existing
+ one.
+
+ 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: <user> <mode> <unused> <realname>
+
+ The USER command is used at the beginning of connection to specify
+ the username, hostname and realname of a new user.
+
+ The <mode> 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 <realname> 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.
+
+3.1.4 Oper message
+
+ Command: OPER
+ Parameters: <name> <password>
+
+ A normal user uses the OPER command to obtain operator privileges.
+ The combination of <name> and <password> 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: <nickname>
+ *( ( "+" / "-" ) *( "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.
+
+ 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: <nickname> <reserved> <distribution> <type>
+ <reserved> <info>
+
+ The SERVICE command to register a new service. Command parameters
+ specify the service nickname, distribution, type and info of a new
+ service.
+
+ The <distribution> 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 <type> 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: [ <Quit Message> ]
+
+ 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.
+
+3.1.8 Squit
+
+ Command: SQUIT
+ Parameters: <server> <comment>
+
+ 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 <comment> 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 <comment> 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.
+
+ 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: ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] )
+ / "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".
+
+ 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: <channel> *( "," <channel> ) [ <Part Message> ]
+
+ 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".
+
+3.2.3 Channel mode message
+
+ Command: MODE
+ Parameters: <channel> *( ( "-" / "+" ) *<modes> *<modeparams> )
+
+ 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".
+
+ 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: <channel> [ <topic> ]
+
+ The TOPIC command is used to change or view the topic of a channel.
+ The topic for channel <channel> is returned if there is no <topic>
+ given. If the <topic> parameter is present, the topic for that
+ channel will be changed, if this action is allowed for the user
+ requesting it. If the <topic> parameter is an empty string, the
+ topic for that channel will be removed.
+
+ 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: [ <channel> *( "," <channel> ) [ <target> ] ]
+
+ 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
+ <channel> parameter specifies which channel(s) to return information
+ about. There is no error reply for bad channel names.
+
+ If no <channel> 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 <target> parameter is specified, the request is forwarded to
+ that server which will generate the reply.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numerics:
+
+ ERR_TOOMANYMATCHES ERR_NOSUCHSERVER
+ RPL_NAMREPLY RPL_ENDOFNAMES
+
+ 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: [ <channel> *( "," <channel> ) [ <target> ] ]
+
+ The list command is used to list channels and their topics. If the
+ <channel> parameter is used, only the status of that channel is
+ displayed.
+
+ If the <target> parameter is specified, the request is forwarded to
+ that server which will generate the reply.
+
+ Wildcards are allowed in the <target> 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: <nickname> <channel>
+
+ The INVITE command is used to invite a user to a channel. The
+ parameter <nickname> is the nickname of the person to be invited to
+ the target channel <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.
+
+ 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: <channel> *( "," <channel> ) <user> *( "," <user> )
+ [<comment>]
+
+ The KICK command can be used to request the forced removal of a user
+ from a channel. It causes the <user> to PART from the <channel> 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
+
+ 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: <msgtarget> <text to be sent>
+
+ PRIVMSG is used to send private messages between users, as well as to
+ send messages to channels. <msgtarget> is usually the nickname of
+ the recipient of the message, or a channel name.
+
+ The <msgtarget> parameter may also be a host mask (#<mask>) or server
+ mask ($<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
+
+ 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: <msgtarget> <text>
+
+ 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
+
+ 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 <target>, 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: [ <target> ]
+
+ The MOTD command is used to get the "Message Of The Day" of the given
+ server, or current server if <target> is omitted.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numeric Replies:
+ RPL_MOTDSTART RPL_MOTD
+ RPL_ENDOFMOTD ERR_NOMOTD
+
+3.4.2 Lusers message
+
+ Command: LUSERS
+ Parameters: [ <mask> [ <target> ] ]
+
+ 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 <mask> is specified, then the reply will only
+
+ concern the part of the network formed by the servers matching the
+ mask. Finally, if the <target> parameter is specified, the request
+ is forwarded to that server which will generate the reply.
+
+ Wildcards are allowed in the <target> parameter.
+
+ Numeric Replies:
+
+ RPL_LUSERCLIENT RPL_LUSEROP
+ RPL_LUSERUNKOWN RPL_LUSERCHANNELS
+ RPL_LUSERME ERR_NOSUCHSERVER
+
+3.4.3 Version message
+
+ Command: VERSION
+ Parameters: [ <target> ]
+
+ The VERSION command is used to query the version of the server
+ program. An optional parameter <target> is used to query the version
+ of the server program which a client is not directly connected to.
+
+ Wildcards are allowed in the <target> 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: [ <query> [ <target> ] ]
+
+ The stats command is used to query statistics of certain server. If
+ <query> 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 <target> parameter.
+
+ 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: [ [ <remote server> ] <server mask> ]
+
+ 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 <remote server> is given in addition to <server mask>, 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
+
+ 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: [ <target> ]
+
+ The time command is used to query local time from the specified
+ server. If the <target> parameter is not given, the server receiving
+ the command must reply to the query.
+
+ Wildcards are allowed in the <target> 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: <target server> <port> [ <remote server> ]
+
+ 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 <remote server> 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
+
+ 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: [ <target> ]
+
+ 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 <target> 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 <target> 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 <target> 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 <target> is a nickname, then only a
+ reply for that nickname is given. If the <target> parameter is
+ omitted, it is RECOMMENDED that the TRACE command is parsed as
+ targeted to the processing server.
+
+ Wildcards are allowed in the <target> 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
+
+ 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: [ <target> ]
+
+ The admin command is used to find information about the administrator
+ of the given server, or current server if <target> parameter is
+ omitted. Each server MUST have the ability to forward ADMIN messages
+ to other servers.
+
+ Wildcards are allowed in the <target> 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
+
+3.4.10 Info command
+
+ Command: INFO
+ Parameters: [ <target> ]
+
+ 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 <target> 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: [ <mask> [ <type> ] ]
+
+ 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
+
+3.5.2 Squery
+
+ Command: SQUERY
+ Parameters: <servicename> <text>
+
+ 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: [ <mask> [ "o" ] ]
+
+ The WHO command is used by a client to generate a query which returns
+ a list of information which 'matches' the <mask> parameter given by
+ the client. In the absence of the <mask> 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 <mask> of "0" or any wildcard which
+ will end up matching every visible user.
+
+ The <mask> passed to WHO is matched against users' host, server, real
+ name and nickname if the channel <mask> cannot be found.
+
+ If the "o" parameter is passed only operators are returned according
+ to the <mask> 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: [ <target> ] <mask> *( "," <mask> )
+
+ 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
+ <mask>, any information about that nick which you are allowed to see
+ is presented.
+
+ If the <target> 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 <target> 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
+
+ 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: <nickname> *( "," <nickname> ) [ <count> [ <target> ] ]
+
+ 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
+ <count> replies will be returned (or all of them if no <count>
+ parameter is given). If a non-positive number is passed as being
+ <count>, then a full search is done.
+
+ Wildcards are allowed in the <target> 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.
+
+3.7.1 Kill message
+
+ Command: KILL
+ Parameters: <nickname> <comment>
+
+ 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
+
+ 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: <server1> [ <server2> ]
+
+ 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 <server1> (server which sent the PING message out)
+ as soon as possible. If the <server2> 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"
+
+3.7.3 Pong message
+
+ Command: PONG
+ Parameters: <server> [ <server2> ]
+
+ PONG message is a reply to ping message. If parameter <server2> is
+ given, this message MUST be forwarded to given target. The <server>
+ 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: <error message>
+
+ 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.
+
+ 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: [ <text> ]
+
+ 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
+
+ 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.
+
+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: <user> [ <target> [ <channel> ] ]
+
+ 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 <server> parameter is given it tries to summon <user> 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
+
+ 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: [ <target> ]
+
+ 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: <Text to be sent>
+
+ 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").
+
+ 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: <nickname> *( SPACE <nickname> )
+
+ 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: <nickname> *( SPACE <nickname> )
+
+ 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
+
+ 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
+ <nick>!<user>@<host>"
+ 002 RPL_YOURHOST
+ "Your host is <servername>, running version <ver>"
+ 003 RPL_CREATED
+ "This server was created <date>"
+ 004 RPL_MYINFO
+ "<servername> <version> <available user modes>
+ <available channel modes>"
+
+ - The server sends Replies 001 to 004 to a user upon
+ successful registration.
+
+ 005 RPL_BOUNCE
+ "Try server <server name>, port <port number>"
+
+ - 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> *( " " <reply> )"
+
+ - 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<nick> *( " " <nick> )"
+
+ - Reply format used by ISON to list replies to the
+ query list.
+
+ 301 RPL_AWAY
+ "<nick> :<away message>"
+ 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
+ "<nick> <user> <host> * :<real name>"
+ 312 RPL_WHOISSERVER
+ "<nick> <server> :<server info>"
+ 313 RPL_WHOISOPERATOR
+ "<nick> :is an IRC operator"
+
+ 317 RPL_WHOISIDLE
+ "<nick> <integer> :seconds idle"
+ 318 RPL_ENDOFWHOIS
+ "<nick> :End of WHOIS list"
+ 319 RPL_WHOISCHANNELS
+ "<nick> :*( ( "@" / "+" ) <channel> " " )"
+
+ - 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
+ "<nick> <user> <host> * :<real name>"
+ 369 RPL_ENDOFWHOWAS
+ "<nick> :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
+ "<channel> <# visible> :<topic>"
+ 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.
+
+ 325 RPL_UNIQOPIS
+ "<channel> <nickname>"
+
+ 324 RPL_CHANNELMODEIS
+ "<channel> <mode> <mode params>"
+
+ 331 RPL_NOTOPIC
+ "<channel> :No topic is set"
+ 332 RPL_TOPIC
+ "<channel> :<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
+ "<channel> <nick>"
+
+ - Returned by the server to indicate that the
+ attempted INVITE message was successful and is
+ being passed onto the end client.
+
+ 342 RPL_SUMMONING
+ "<user> :Summoning user to IRC"
+
+ - Returned by a server answering a SUMMON message to
+ indicate that it is summoning that user.
+
+ 346 RPL_INVITELIST
+ "<channel> <invitemask>"
+ 347 RPL_ENDOFINVITELIST
+ "<channel> :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
+ "<channel> <exceptionmask>"
+ 349 RPL_ENDOFEXCEPTLIST
+ "<channel> :End of channel exception list"
+
+ - 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
+ "<version>.<debuglevel> <server> :<comments>"
+
+ - Reply by the server showing its version details.
+ The <version> is the version of the software being
+ used (including any patchlevel revisions) and the
+ <debuglevel> 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
+ "<channel> <user> <host> <server> <nick>
+ ( "H" / "G" > ["*"] [ ( "@" / "+" ) ]
+ :<hopcount> <real name>"
+
+ 315 RPL_ENDOFWHO
+ "<name> :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 <name> being
+ the item.
+
+ 353 RPL_NAMREPLY
+ "( "=" / "*" / "@" ) <channel>
+ :[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )
+ - "@" is used for secret channels, "*" for private
+ channels, and "=" for others (public channels).
+
+ 366 RPL_ENDOFNAMES
+ "<channel> :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
+
+ 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
+ "<mask> <server> :<hopcount> <server info>"
+ 365 RPL_ENDOFLINKS
+ "<mask> :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
+ "<channel> <banmask>"
+ 368 RPL_ENDOFBANLIST
+ "<channel> :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
+ ":<string>"
+ 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
+ ":- <server> Message of the day - "
+ 372 RPL_MOTD
+ ":- <text>"
+ 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
+
+ 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
+ "<config file> :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 <servicename>"
+
+ - Sent by the server to a service upon successful
+ registration.
+
+ 391 RPL_TIME
+ "<server> :<string showing server's local 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
+ ":<username> <ttyline> <hostname>"
+ 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.
+
+ 200 RPL_TRACELINK
+ "Link <version & debug level> <destination>
+ <next server> V<protocol version>
+ <link uptime in seconds> <backstream sendq>
+ <upstream sendq>"
+ 201 RPL_TRACECONNECTING
+ "Try. <class> <server>"
+ 202 RPL_TRACEHANDSHAKE
+ "H.S. <class> <server>"
+ 203 RPL_TRACEUNKNOWN
+ "???? <class> [<client IP address in dot form>]"
+ 204 RPL_TRACEOPERATOR
+ "Oper <class> <nick>"
+ 205 RPL_TRACEUSER
+ "User <class> <nick>"
+ 206 RPL_TRACESERVER
+ "Serv <class> <int>S <int>C <server>
+ <nick!user|*!*>@<host|server> V<protocol version>"
+ 207 RPL_TRACESERVICE
+ "Service <class> <name> <type> <active type>"
+ 208 RPL_TRACENEWTYPE
+ "<newtype> 0 <client name>"
+ 209 RPL_TRACECLASS
+ "Class <class> <count>"
+ 210 RPL_TRACERECONNECT
+ Unused.
+ 261 RPL_TRACELOG
+ "File <logfile> <debug level>"
+ 262 RPL_TRACEEND
+ "<server name> <version & debug level> :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.
+
+ 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
+ "<linkname> <sendq> <sent messages>
+ <sent Kbytes> <received messages>
+ <received Kbytes> <time open>"
+
+ - reports statistics on a connection. <linkname>
+ identifies the particular connection, <sendq> is
+ the amount of data that is queued and waiting to be
+ sent <sent messages> the number of messages sent,
+ and <sent Kbytes> the amount of data sent, in
+ Kbytes. <received messages> and <received Kbytes>
+ are the equivalent of <sent messages> and <sent
+ Kbytes> for received data, respectively. <time
+ open> indicates how long ago the connection was
+ opened, in seconds.
+
+ 212 RPL_STATSCOMMANDS
+ "<command> <count> <byte count> <remote count>"
+
+ - reports statistics on commands usage.
+
+ 219 RPL_ENDOFSTATS
+ "<stats letter> :End of STATS report"
+
+ 242 RPL_STATSUPTIME
+ ":Server Up %d days %d:%02d:%02d"
+
+ - reports the server uptime.
+
+ 243 RPL_STATSOLINE
+ "O <hostmask> * <name>"
+
+ - reports the allowed hosts from where user may become IRC
+ operators.
+
+ 221 RPL_UMODEIS
+ "<user mode string>"
+
+ - To answer a query about a client's own mode,
+ RPL_UMODEIS is sent back.
+
+ 234 RPL_SERVLIST
+ "<name> <server> <mask> <type> <hopcount> <info>"
+
+ 235 RPL_SERVLISTEND
+ "<mask> <type> :End of service listing"
+
+ - When listing services in reply to a SERVLIST message,
+ a server is required to send the list back using the
+ RPL_SERVLIST and RPL_SERVLISTEND messages. A separate
+ RPL_SERVLIST is sent for each service. After the
+ services have been listed (or if none present) a
+ RPL_SERVLISTEND MUST be sent.
+
+ 251 RPL_LUSERCLIENT
+ ":There are <integer> users and <integer>
+ services on <integer> servers"
+ 252 RPL_LUSEROP
+ "<integer> :operator(s) online"
+ 253 RPL_LUSERUNKNOWN
+ "<integer> :unknown connection(s)"
+ 254 RPL_LUSERCHANNELS
+ "<integer> :channels formed"
+ 255 RPL_LUSERME
+ ":I have <integer> clients and <integer>
+ servers"
+
+ - In processing an LUSERS message, the server
+ sends a set of replies from RPL_LUSERCLIENT,
+ RPL_LUSEROP, RPL_USERUNKNOWN,
+ RPL_LUSERCHANNELS and RPL_LUSERME. When
+ replying, a server MUST send back
+ RPL_LUSERCLIENT and RPL_LUSERME. The other
+ replies are only sent back if a non-zero count
+ is found for them.
+
+ 256 RPL_ADMINME
+ "<server> :Administrative info"
+ 257 RPL_ADMINLOC1
+ ":<admin info>"
+ 258 RPL_ADMINLOC2
+ ":<admin info>"
+ 259 RPL_ADMINEMAIL
+ ":<admin info>"
+
+ - When replying to an ADMIN message, a server
+ is expected to use replies RPL_ADMINME
+ through to RPL_ADMINEMAIL and provide a text
+ message with each. For RPL_ADMINLOC1 a
+ description of what city, state and country
+ the server is in is expected, followed by
+ details of the institution (RPL_ADMINLOC2)
+
+ and finally the administrative contact for the
+ server (an email address here is REQUIRED)
+ in RPL_ADMINEMAIL.
+
+ 263 RPL_TRYAGAIN
+ "<command> :Please wait a while and try again."
+
+ - When a server drops a command without processing it,
+ it MUST use the reply RPL_TRYAGAIN to inform the
+ originating client.
+
+5.2 Error Replies
+
+ Error replies are found in the range from 400 to 599.
+
+ 401 ERR_NOSUCHNICK
+ "<nickname> :No such nick/channel"
+
+ - Used to indicate the nickname parameter supplied to a
+ command is currently unused.
+
+ 402 ERR_NOSUCHSERVER
+ "<server name> :No such server"
+
+ - Used to indicate the server name given currently
+ does not exist.
+
+ 403 ERR_NOSUCHCHANNEL
+ "<channel name> :No such channel"
+
+ - Used to indicate the given channel name is invalid.
+
+ 404 ERR_CANNOTSENDTOCHAN
+ "<channel name> :Cannot send to channel"
+
+ - Sent to a user who is either (a) not on a channel
+ which is mode +n or (b) not a chanop (or mode +v) on
+ a channel which has mode +m set or where the user is
+ banned and is trying to send a PRIVMSG message to
+ that channel.
+
+ 405 ERR_TOOMANYCHANNELS
+ "<channel name> :You have joined too many channels"
+
+ - Sent to a user when they have joined the maximum
+ number of allowed channels and they try to join
+ another channel.
+
+ 406 ERR_WASNOSUCHNICK
+ "<nickname> :There was no such nickname"
+
+ - Returned by WHOWAS to indicate there is no history
+ information for that nickname.
+
+ 407 ERR_TOOMANYTARGETS
+ "<target> :<error code> recipients. <abort message>"
+
+ - Returned to a client which is attempting to send a
+ PRIVMSG/NOTICE using the user@host destination format
+ and for a user@host which has several occurrences.
+
+ - Returned to a client which trying to send a
+ PRIVMSG/NOTICE to too many recipients.
+
+ - Returned to a client which is attempting to JOIN a safe
+ channel using the shortname when there are more than one
+ such channel.
+
+ 408 ERR_NOSUCHSERVICE
+ "<service name> :No such service"
+
+ - Returned to a client which is attempting to send a SQUERY
+ to a service which does not exist.
+
+ 409 ERR_NOORIGIN
+ ":No origin specified"
+
+ - PING or PONG message missing the originator parameter.
+
+ 411 ERR_NORECIPIENT
+ ":No recipient given (<command>)"
+ 412 ERR_NOTEXTTOSEND
+ ":No text to send"
+ 413 ERR_NOTOPLEVEL
+ "<mask> :No toplevel domain specified"
+ 414 ERR_WILDTOPLEVEL
+ "<mask> :Wildcard in toplevel domain"
+ 415 ERR_BADMASK
+ "<mask> :Bad Server/host mask"
+
+ - 412 - 415 are returned by PRIVMSG to indicate that
+ the message wasn't delivered for some reason.
+ ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
+ are returned when an invalid use of
+ "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
+
+ 421 ERR_UNKNOWNCOMMAND
+ "<command> :Unknown command"
+
+ - Returned to a registered client to indicate that the
+ command sent is unknown by the server.
+
+ 422 ERR_NOMOTD
+ ":MOTD File is missing"
+
+ - Server's MOTD file could not be opened by the server.
+
+ 423 ERR_NOADMININFO
+ "<server> :No administrative info available"
+
+ - Returned by a server in response to an ADMIN message
+ when there is an error in finding the appropriate
+ information.
+
+ 424 ERR_FILEERROR
+ ":File error doing <file op> on <file>"
+
+ - Generic error message used to report a failed file
+ operation during the processing of a message.
+
+ 431 ERR_NONICKNAMEGIVEN
+ ":No nickname given"
+
+ - Returned when a nickname parameter expected for a
+ command and isn't found.
+
+ 432 ERR_ERRONEUSNICKNAME
+ "<nick> :Erroneous nickname"
+
+ - Returned after receiving a NICK message which contains
+ characters which do not fall in the defined set. See
+ section 2.3.1 for details on valid nicknames.
+
+ 433 ERR_NICKNAMEINUSE
+ "<nick> :Nickname is already in use"
+
+ - Returned when a NICK message is processed that results
+ in an attempt to change to a currently existing
+ nickname.
+
+ 436 ERR_NICKCOLLISION
+ "<nick> :Nickname collision KILL from <user>@<host>"
+
+ - Returned by a server to a client when it detects a
+ nickname collision (registered of a NICK that
+ already exists by another server).
+
+ 437 ERR_UNAVAILRESOURCE
+ "<nick/channel> :Nick/channel is temporarily unavailable"
+
+ - Returned by a server to a user trying to join a channel
+ currently blocked by the channel delay mechanism.
+
+ - Returned by a server to a user trying to change nickname
+ when the desired nickname is blocked by the nick delay
+ mechanism.
+
+ 441 ERR_USERNOTINCHANNEL
+ "<nick> <channel> :They aren't on that channel"
+
+ - Returned by the server to indicate that the target
+ user of the command is not on the given channel.
+
+ 442 ERR_NOTONCHANNEL
+ "<channel> :You're not on that channel"
+
+ - Returned by the server whenever a client tries to
+ perform a channel affecting command for which the
+ client isn't a member.
+
+ 443 ERR_USERONCHANNEL
+ "<user> <channel> :is already on channel"
+
+ - Returned when a client tries to invite a user to a
+ channel they are already on.
+
+ 444 ERR_NOLOGIN
+ "<user> :User not logged in"
+
+ - Returned by the summon after a SUMMON command for a
+ user was unable to be performed since they were not
+ logged in.
+
+ 445 ERR_SUMMONDISABLED
+ ":SUMMON has been disabled"
+
+ - Returned as a response to the SUMMON command. MUST be
+ returned by any server which doesn't implement it.
+
+ 446 ERR_USERSDISABLED
+ ":USERS has been disabled"
+
+ - Returned as a response to the USERS command. MUST be
+ returned by any server which does not implement it.
+
+ 451 ERR_NOTREGISTERED
+ ":You have not registered"
+
+ - Returned by the server to indicate that the client
+ MUST be registered before the server will allow it
+ to be parsed in detail.
+
+ 461 ERR_NEEDMOREPARAMS
+ "<command> :Not enough parameters"
+
+ - Returned by the server by numerous commands to
+ indicate to the client that it didn't supply enough
+ parameters.
+
+ 462 ERR_ALREADYREGISTRED
+ ":Unauthorized command (already registered)"
+
+ - Returned by the server to any link which tries to
+ change part of the registered details (such as
+ password or user details from second USER message).
+
+ 463 ERR_NOPERMFORHOST
+ ":Your host isn't among the privileged"
+
+ - Returned to a client which attempts to register with
+ a server which does not been setup to allow
+ connections from the host the attempted connection
+ is tried.
+
+ 464 ERR_PASSWDMISMATCH
+ ":Password incorrect"
+
+ - Returned to indicate a failed attempt at registering
+ a connection for which a password was required and
+ was either not given or incorrect.
+
+ 465 ERR_YOUREBANNEDCREEP
+ ":You are banned from this server"
+
+ - Returned after an attempt to connect and register
+ yourself with a server which has been setup to
+ explicitly deny connections to you.
+
+ 466 ERR_YOUWILLBEBANNED
+
+ - Sent by a server to a user to inform that access to the
+ server will soon be denied.
+
+ 467 ERR_KEYSET
+ "<channel> :Channel key already set"
+ 471 ERR_CHANNELISFULL
+ "<channel> :Cannot join channel (+l)"
+ 472 ERR_UNKNOWNMODE
+ "<char> :is unknown mode char to me for <channel>"
+ 473 ERR_INVITEONLYCHAN
+ "<channel> :Cannot join channel (+i)"
+ 474 ERR_BANNEDFROMCHAN
+ "<channel> :Cannot join channel (+b)"
+ 475 ERR_BADCHANNELKEY
+ "<channel> :Cannot join channel (+k)"
+ 476 ERR_BADCHANMASK
+ "<channel> :Bad Channel Mask"
+ 477 ERR_NOCHANMODES
+ "<channel> :Channel doesn't support modes"
+ 478 ERR_BANLISTFULL
+ "<channel> <char> :Channel list is full"
+
+ 481 ERR_NOPRIVILEGES
+ ":Permission Denied- You're not an IRC operator"
+
+ - Any command requiring operator privileges to operate
+ MUST return this error to indicate the attempt was
+ unsuccessful.
+
+ 482 ERR_CHANOPRIVSNEEDED
+ "<channel> :You're not channel operator"
+
+ - Any command requiring 'chanop' privileges (such as
+ MODE messages) MUST return this error if the client
+ making the attempt is not a chanop on the specified
+ channel.
+
+ 483 ERR_CANTKILLSERVER
+ ":You can't kill a server!"
+
+ - Any attempts to use the KILL command on a server
+ are to be refused and this error returned directly
+ to the client.
+
+ 484 ERR_RESTRICTED
+ ":Your connection is restricted!"
+
+ - Sent by the server to a user upon connection to indicate
+ the restricted nature of the connection (user mode "+r").
+
+ 485 ERR_UNIQOPPRIVSNEEDED
+ ":You're not the original channel operator"
+
+ - Any MODE requiring "channel creator" privileges MUST
+ return this error if the client making the attempt is not
+ a chanop on the specified channel.
+
+ 491 ERR_NOOPERHOST
+ ":No O-lines for your host"
+
+ - If a client sends an OPER message and the server has
+ not been configured to allow connections from the
+ client's host as an operator, this error MUST be
+ returned.
+
+ 501 ERR_UMODEUNKNOWNFLAG
+ ":Unknown MODE flag"
+
+ - Returned by the server to indicate that a MODE
+ message was sent with a nickname parameter and that
+ the a mode flag sent was not recognized.
+
+ 502 ERR_USERSDONTMATCH
+ ":Cannot change mode for other users"
+
+ - Error sent to any user trying to view or change the
+ user mode for a user other than themselves.
+
+5.3 Reserved numerics
+
+ These numerics are not described above since they fall into one of
+ the following categories:
+
+ 1. no longer in use;
+
+ 2. reserved for future planned use;
+
+ 3. in current use but are part of a non-generic 'feature' of
+ the current IRC server.
+
+ 231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES
+ 233 RPL_SERVICE
+ 300 RPL_NONE 316 RPL_WHOISCHANOP
+ 361 RPL_KILLDONE 362 RPL_CLOSING
+ 363 RPL_CLOSEEND 373 RPL_INFOSTART
+ 384 RPL_MYPORTIS
+
+ 213 RPL_STATSCLINE 214 RPL_STATSNLINE
+ 215 RPL_STATSILINE 216 RPL_STATSKLINE
+ 217 RPL_STATSQLINE 218 RPL_STATSYLINE
+ 240 RPL_STATSVLINE 241 RPL_STATSLLINE
+ 244 RPL_STATSHLINE 244 RPL_STATSSLINE
+ 246 RPL_STATSPING 247 RPL_STATSBLINE
+ 250 RPL_STATSDLINE
+
+ 492 ERR_NOSERVICEHOST
+
+6. Current implementations
+
+ The IRC software, version 2.10 is the only complete implementation of
+ the IRC protocol (client and server). Because of the small amount of
+ changes in the client protocol since the publication of RFC 1459
+ [IRC], implementations that follow it are likely to be compliant with
+ this protocol or to require a small amount of changes to reach
+ compliance.
+
+7. Current problems
+
+ There are a number of recognized problems with the IRC Client
+ Protocol, and more generally with the IRC Server Protocol. In order
+ to preserve backward compatibility with old clients, this protocol
+ has almost not evolved since the publication of RFC 1459 [IRC].
+
+7.1 Nicknames
+
+ The idea of the nickname on IRC is very convenient for users to use
+ when talking to each other outside of a channel, but there is only a
+ finite nickname space and being what they are, it's not uncommon for
+ several people to want to use the same nick. If a nickname is chosen
+ by two people using this protocol, either one will not succeed or
+ both will removed by use of a server KILL (See Section 3.7.1).
+
+7.2 Limitation of wildcards
+
+ There is no way to escape the escape character "\" (%x5C). While
+ this isn't usually a problem, it makes it impossible to form a mask
+ with a backslash character ("\") preceding a wildcard.
+
+7.3 Security considerations
+
+ Security issues related to this protocol are discussed in the "IRC
+ Server Protocol" [IRC-SERVER] as they are mostly an issue for the
+ server side of the connection.
+
+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://ftp.irc.org/irc/clients
+
+ 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.
+
+10. References
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [HNAME] Braden, R., "Requirements for Internet Hosts --
+ Application and Support", STD 3, RFC 1123, October 1989.
+
+ [IRC] Oikarinen, J. & D. Reed, "Internet Relay Chat Protocol",
+ RFC 1459, May 1993.
+
+ [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+ April 2000.
+
+ [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
+ 2811, 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
+
+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.
diff --git a/doc/technical/rfc2813.txt b/doc/technical/rfc2813.txt
new file mode 100644
index 0000000..175de1d
--- /dev/null
+++ b/doc/technical/rfc2813.txt
@@ -0,0 +1,1173 @@
+$Id$
+
+Network Working Group C. Kalt
+Request for Comments: 2813 April 2000
+Updates: 1459
+Category: Informational
+
+ Internet Relay Chat: Server 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.
+
+Abstract
+
+ While based on the client-server model, the IRC (Internet Relay Chat)
+ protocol allows servers to connect to each other effectively forming
+ a network.
+
+ This document defines the protocol used by servers to talk to each
+ other. It was originally a superset of the client protocol but has
+ evolved differently.
+
+ First formally documented in May 1993 as part of RFC 1459 [IRC], most
+ of the changes brought since then can be found in this document as
+ development was focused on making the protocol scale better. Better
+ scalability has allowed existing world-wide networks to keep growing
+ and reach sizes which defy the old specification.
+
+Table of Contents
+
+ 1. Introduction ............................................... 3
+ 2. Global database ............................................ 3
+ 2.1 Servers ................................................ 3
+ 2.2 Clients ................................................ 4
+ 2.2.1 Users ............................................. 4
+ 2.2.2 Services .......................................... 4
+ 2.3 Channels ............................................... 4
+ 3. The IRC Server Specification ............................... 5
+ 3.1 Overview ............................................... 5
+ 3.2 Character codes ........................................ 5
+ 3.3 Messages ............................................... 5
+ 3.3.1 Message format in Augmented BNF ................... 6
+ 3.4 Numeric replies ........................................ 7
+ 4. Message Details ............................................ 7
+ 4.1 Connection Registration ................................ 8
+ 4.1.1 Password message .................................. 8
+ 4.1.2 Server message .................................... 9
+ 4.1.3 Nick .............................................. 10
+ 4.1.4 Service message ................................... 11
+ 4.1.5 Quit .............................................. 12
+ 4.1.6 Server quit message ............................... 13
+ 4.2 Channel operations ..................................... 14
+ 4.2.1 Join message ...................................... 14
+ 4.2.2 Njoin message ..................................... 15
+ 4.2.3 Mode message ...................................... 16
+ 5. Implementation details .................................... 16
+ 5.1 Connection 'Liveness' .................................. 16
+ 5.2 Accepting a client to server connection ................ 16
+ 5.2.1 Users ............................................. 16
+ 5.2.2 Services .......................................... 17
+ 5.3 Establishing a server-server connection. ............... 17
+ 5.3.1 Link options ...................................... 17
+ 5.3.1.1 Compressed server to server links ............ 18
+ 5.3.1.2 Anti abuse protections ....................... 18
+ 5.3.2 State information exchange when connecting ........ 18
+ 5.4 Terminating server-client connections .................. 19
+ 5.5 Terminating server-server connections .................. 19
+ 5.6 Tracking nickname changes .............................. 19
+ 5.7 Tracking recently used nicknames ....................... 20
+ 5.8 Flood control of clients ............................... 20
+ 5.9 Non-blocking lookups ................................... 21
+ 5.9.1 Hostname (DNS) lookups ............................ 21
+ 5.9.2 Username (Ident) lookups .......................... 21
+ 6. Current problems ........................................... 21
+ 6.1 Scalability ............................................ 21
+ 6.2 Labels ................................................. 22
+
+ 6.2.1 Nicknames ......................................... 22
+ 6.2.2 Channels .......................................... 22
+ 6.2.3 Servers ........................................... 22
+ 6.3 Algorithms ............................................. 22
+ 7. Security Considerations .................................... 23
+ 7.1 Authentication ......................................... 23
+ 7.2 Integrity .............................................. 23
+ 8. Current support and availability ........................... 24
+ 9. Acknowledgements ........................................... 24
+ 10. References ................................................ 24
+ 11. Author's Address .......................................... 25
+ 12. Full Copyright Statement ................................... 26
+
+1. Introduction
+
+ This document is intended for people working on implementing an IRC
+ server but will also be useful to anyone implementing an IRC service.
+
+ Servers provide the three basic services required for realtime
+ conferencing defined by the "Internet Relay Chat: Architecture"
+ [IRC-ARCH]: client locator (via the client protocol [IRC-CLIENT]),
+ message relaying (via the server protocol defined in this document)
+ and channel hosting and management (following specific rules [IRC-
+ CHAN]).
+
+2. Global database
+
+ Although the IRC Protocol defines a fairly distributed model, each
+ server maintains a "global state database" about the whole IRC
+ network. This database is, in theory, identical on all servers.
+
+2.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 3.3.1) for what may and may not be used in a server
+ name.
+
+ Each server is typically known by all other servers, however it is
+ possible to define a "hostmask" to group servers together according
+ to their name. Inside the hostmasked area, all the servers have a
+ name which matches the hostmask, and any other server with a name
+ matching the hostmask SHALL NOT be connected to the IRC network
+ outside the hostmasked area. Servers which are outside the area have
+ no knowledge of the individual servers present inside the area,
+ instead they are presented with a virtual server which has the
+ hostmask for name.
+
+2.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 to which the client is connected.
+
+2.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 3.3.1) for what may and may not be used in a
+ nickname. In addition to the nickname, all servers MUST have the
+ following information about all users: the name of the host that the
+ user is running on, the username of the user on that host, and the
+ server to which the client is connected.
+
+2.2.2 Services
+
+ Each service is distinguished from other services by a service name
+ composed of a nickname and a server name. The nickname has a maximum
+ length of nine (9) characters. See the protocol grammar rules
+ (section 3.3.1) for what may and may not be used in a nickname. The
+ server name used to compose the service name is the name of the
+ server to which the service is connected. In addition to this
+ service name all servers MUST know the service type.
+
+ Services differ from users by the format of their identifier, but
+ more importantly services and users don't have the same type of
+ access to the server: services can request part or all of the global
+ state information that a server maintains, but have a more restricted
+ set of commands available to them (See "IRC Client Protocol" [IRC-
+ CLIENT] for details on which) and are not allowed to join channels.
+ Finally services are not usually subject to the "Flood control"
+ mechanism described in section 5.8.
+
+2.3 Channels
+
+ Alike services, channels have a scope [IRC-CHAN] and are not
+ necessarily known to all servers. When a channel existence is known
+ to a server, the server MUST keep track of the channel members, as
+ well as the channel modes.
+
+3. The IRC Server Specification
+
+3.1 Overview
+
+ The protocol as described herein is for use with server to server
+ connections. For client to server connections, see the IRC Client
+ Protocol specification.
+
+ There are, however, more restrictions on client connections (which
+ are considered to be untrustworthy) than on server connections.
+
+3.2 Character codes
+
+ No specific character set is specified. The protocol is based on a 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.
+
+3.3 Messages
+
+ Servers and clients send each other messages which may or may not
+ generate a reply. Most communication between servers do not generate
+ any reply, as servers mostly perform routing tasks for the clients.
+
+ 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.
+
+ 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. Clients SHOULD not use a prefix when sending a message
+ from themselves; if they use one, the only valid prefix is the
+ registered nickname associated with the client.
+
+ When a server receives a message, it MUST identify its source using
+ the (eventually assumed) prefix. If the prefix cannot be found in
+ the server's internal database, it MUST be discarded, and if the
+ prefix indicates the message comes from an (unknown) server, the link
+ from which the message was received MUST be dropped. Dropping a link
+ in such circumstances is a little excessive but necessary to maintain
+ the integrity of the network and to prevent future problems. Another
+ common error condition is that the prefix found in the server's
+ internal database identifies a different source (typically a source
+ registered from a different link than from which the message
+ arrived). If the message was received from a server link and the
+ prefix identifies a client, a KILL message MUST be issued for the
+ client and sent to all servers. In other cases, the link from which
+ the message arrived SHOULD be dropped for clients, and MUST be
+ dropped for servers. In all cases, the message MUST be discarded.
+
+ 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 message lines. See section 5 for more details about
+ current implementations.
+
+3.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 <prefix>,
+ <command> and list of parameters (<params>).
+
+ The Augmented BNF representation for this is found in "IRC Client
+ Protocol" [IRC-CLIENT].
+
+ The extended prefix (["!" user "@" host ]) MUST NOT be used in server
+ to server communications and is only intended for server to client
+ messages in order to provide clients with more useful information
+ about who a message is from without the need for additional queries.
+
+3.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; any such messages received by a server are silently
+ dropped. 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 "IRC Client Protocol" [IRC-CLIENT].
+
+4. Message Details
+
+ All the messages recognized by the IRC server and client are
+ described in the IRC Client Protocol specification.
+
+ 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, returning any appropriate errors. If the server
+ encounters a fatal error while parsing a message, an error MUST be
+ sent back to the client and the parsing terminated. A fatal error
+ may follow from incorrect command, a destination which is otherwise
+ unknown to the server (server, client or channel names fit this
+ category), not enough parameters or incorrect privileges.
+
+ If a full set of parameters is presented, then each MUST be checked
+ for validity and appropriate responses sent back to the client. In
+ the case of messages which use parameter lists using the comma as an
+ item separator, a reply MUST be sent for each item.
+
+ In the examples below, some messages appear using the full format:
+
+ :Name COMMAND parameter list
+
+ Such examples represent a message from "Name" in transit between
+ servers, where it is essential to include the name of the original
+ sender of the message so remote servers may send back a reply along
+ the correct path.
+
+ The message details for client to server communication are described
+ in the "IRC Client Protocol" [IRC-CLIENT]. Some sections in the
+ following pages apply to some of these messages, they are additions
+ to the message specifications which are only relevant to server to
+
+ server communication, or to the server implementation. The messages
+ which are introduced here are only used for server to server
+ communication.
+
+4.1 Connection Registration
+
+ The commands described here are used to register a connection with
+ another IRC server.
+
+4.1.1 Password message
+
+ Command: PASS
+ Parameters: <password> <version> <flags> [<options>]
+
+ The PASS command is used to set a 'connection password'. The
+ password MUST be set before any attempt to register the connection is
+ made. Currently this means that servers MUST send a PASS command
+ before any SERVER command. Only one (1) PASS command SHALL be
+ accepted from a connection.
+
+ The last three (3) parameters MUST be ignored if received from a
+ client (e.g. a user or a service). They are only relevant when
+ received from a server.
+
+ The <version> parameter is a string of at least four (4) characters,
+ and up to fourteen (14) characters. The first four (4) characters
+ MUST be digits and indicate the protocol version known by the server
+ issuing the message. The protocol described by this document is
+ version 2.10 which is encoded as "0210". The remaining OPTIONAL
+ characters are implementation dependent and should describe the
+ software version number.
+
+ The <flags> parameter is a string of up to one hundred (100)
+ characters. It is composed of two substrings separated by the
+ character "|" (%x7C). If present, the first substring MUST be the
+ name of the implementation. The reference implementation (See
+ Section 8, "Current support and availability") uses the string "IRC".
+ If a different implementation is written, which needs an identifier,
+ then that identifier should be registered through publication of an
+ RFC. The second substring is implementation dependent. Both
+ substrings are OPTIONAL, but the character "|" is REQUIRED. The
+ character "|" MUST NOT appear in either substring.
+
+ Finally, the last parameter, <options>, is used for link options.
+ The only options defined by the protocol are link compression (using
+ the character "Z"), and an abuse protection flag (using the character
+
+ "P"). See sections 5.3.1.1 (Compressed server to server links) and
+ 5.3.1.2 (Anti abuse protections) respectively for more information on
+ these options.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
+
+ Example:
+
+ PASS moresecretpassword 0210010000 IRC|aBgH$ Z
+
+4.1.2 Server message
+
+ Command: SERVER
+ Parameters: <servername> <hopcount> <token> <info>
+
+ The SERVER command is used to register a new server. A new connection
+ introduces itself as a server to its peer. This message is also used
+ to pass server data over whole net. When a new server is connected
+ to net, information about it MUST be broadcasted to the whole
+ network.
+
+ The <info> parameter may contain space characters.
+
+ <hopcount> is used to give all servers some internal information on
+ how far away each server is. Local peers have a value of 0, and each
+ passed server increments the value. With a full server list, it
+ would be possible to construct a map of the entire server tree, but
+ hostmasks prevent this from being done.
+
+ The <token> parameter is an unsigned number used by servers as an
+ identifier. This identifier is subsequently used to reference a
+ server in the NICK and SERVICE messages sent between servers. Server
+ tokens only have a meaning for the point-to-point peering they are
+ used and MUST be unique for that connection. They are not global.
+
+ The SERVER message MUST only be accepted from either (a) a connection
+ which is yet to be registered and is attempting to register as a
+ server, or (b) an existing connection to another server, in which
+ case the SERVER message is introducing a new server behind that
+ server.
+
+ Most errors that occur with the receipt of a SERVER command result in
+ the connection being terminated by the destination host (target
+ SERVER). Because of the severity of such event, error replies are
+ usually sent using the "ERROR" command rather than a numeric.
+
+ If a SERVER message is parsed and it attempts to introduce a server
+ which is already known to the receiving server, the connection, from
+ which that message arrived, MUST be closed (following the correct
+ procedures), since a duplicate route to a server has been formed and
+ the acyclic nature of the IRC tree breaks. In some conditions, the
+ connection from which the already known server has registered MAY be
+ closed instead. It should be noted that this kind of error can also
+ be the result of a second running server, problem which cannot be
+ fixed within the protocol and typically requires human intervention.
+ This type of problem is particularly insidious, as it can quite
+ easily result in part of the IRC network to be isolated, with one of
+ the two servers connected to each partition therefore making it
+ impossible for the two parts to unite.
+
+ Numeric Replies:
+
+ ERR_ALREADYREGISTRED
+
+ Example:
+
+ SERVER test.oulu.fi 1 1 :Experimental server ; New server
+ test.oulu.fi introducing itself and
+ attempting to register.
+
+ :tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server
+ tolsun.oulu.fi is our uplink for
+ csd.bu.edu which is 5 hops away. The
+ token "34" will be used by
+ tolsun.oulu.fi when introducing new
+ users or services connected to
+ csd.bu.edu.
+
+4.1.3 Nick
+
+ Command: NICK
+ Parameters: <nickname> <hopcount> <username> <host> <servertoken>
+ <umode> <realname>
+
+ This form of the NICK message MUST NOT be allowed from user
+ connections. However, it MUST be used instead of the NICK/USER pair
+ to notify other servers of new users joining the IRC network.
+
+ This message is really the combination of three distinct messages:
+ NICK, USER and MODE [IRC-CLIENT].
+
+ The <hopcount> parameter is used by servers to indicate how far away
+ a user is from its home server. A local connection has a hopcount of
+ 0. The hopcount value is incremented by each passed server.
+
+ The <servertoken> parameter replaces the <servername> parameter of
+ the USER (See section 4.1.2 for more information on server tokens).
+
+ Examples:
+
+ NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New
+ user with nickname "syrk", username
+ "kalt", connected from host
+ "millennium.stealth.net" to server
+ "34" ("csd.bu.edu" according to the
+ previous example).
+
+ :krys NICK syrk ; The other form of the NICK message,
+ as defined in "IRC Client Protocol"
+ [IRC-CLIENT] and used between
+ servers: krys changed his nickname to
+ syrk
+
+4.1.4 Service message
+
+ Command: SERVICE
+ Parameters: <servicename> <servertoken> <distribution> <type>
+ <hopcount> <info>
+
+ The SERVICE command is used to introduce a new service. This form of
+ the SERVICE message SHOULD NOT be allowed from client (unregistered,
+ or registered) connections. However, it MUST be used between servers
+ to notify other servers of new services joining the IRC network.
+
+ The <servertoken> is used to identify the server to which the service
+ is connected. (See section 4.1.2 for more information on server
+ tokens).
+
+ The <hopcount> parameter is used by servers to indicate how far away
+ a service is from its home server. A local connection has a hopcount
+ of 0. The hopcount value is incremented by each passed server.
+
+ The <distribution> 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
+ to which the service is connected MUST be composed of servers whose
+ names all match the mask. Plain "*" is used when no restriction is
+ wished.
+
+ The <type> parameter is currently reserved for future usage.
+
+ Numeric Replies:
+
+ ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
+ ERR_ERRONEUSNICKNAME
+ RPL_YOURESERVICE RPL_YOURHOST
+ RPL_MYINFO
+
+ Example:
+
+SERVICE dict@irc.fr 9 *.fr 0 1 :French Dictionary r" registered on
+ server "9" is being announced to
+ another server. This service will
+ only be available on servers whose
+ name matches "*.fr".
+
+4.1.5 Quit
+
+ Command: QUIT
+ Parameters: [<Quit Message>]
+
+ A client session ends with a quit message. The server MUST close the
+ connection to a client which sends a QUIT message. If a "Quit
+ Message" is given, this will be sent instead of the default message,
+ the nickname or service name.
+
+ When "netsplit" (See Section 4.1.6) occur, the "Quit Message" is
+ composed of the names of two servers involved, separated by a space.
+ The first name is that of the server which is still connected and the
+ second name is either that of the server which has become
+ disconnected or that of the server to which the leaving client was
+ connected:
+
+ <Quit Message> = ":" servername SPACE servername
+
+ Because the "Quit Message" has a special meaning for "netsplits",
+ servers SHOULD NOT allow a client to use a <Quit Message> in the
+ format described above.
+
+ If, for some other reason, a client connection is closed without the
+ client issuing a QUIT command (e.g. client dies and EOF occurs on
+ socket), the server is REQUIRED to fill in the quit message with some
+ sort of message reflecting the nature of the event which caused it to
+ happen. Typically, this is done by reporting a system specific
+ error.
+
+ Numeric Replies:
+
+ None.
+
+ Examples:
+
+ :WiZ QUIT :Gone to have lunch ; Preferred message format.
+
+4.1.6 Server quit message
+
+ Command: SQUIT
+ Parameters: <server> <comment>
+
+ The SQUIT message has two distinct uses.
+
+ The first one (described in "Internet Relay Chat: Client Protocol"
+ [IRC-CLIENT]) allows operators to break a local or remote server
+ link. This form of the message is also eventually used by servers to
+ break a remote server link.
+
+ The second use of this message is needed to inform other servers when
+ a "network split" (also known as "netsplit") occurs, in other words
+ to inform other servers about quitting or dead servers. If a server
+ wishes to break the connection to another server it MUST send a SQUIT
+ message to the other server, using the name of the other server as
+ the server parameter, which then closes its connection to the
+ quitting server.
+
+ The <comment> is filled in by servers which SHOULD place an error or
+ similar message here.
+
+ Both of the servers which are on either side of the connection being
+ closed are REQUIRED to send out a SQUIT message (to all its other
+ server connections) for all other servers which are considered to be
+ behind that link.
+
+ Similarly, a QUIT message MAY be sent to the other still connected
+ servers on behalf of all clients behind that quitting link. In
+ addition to this, all channel members of a channel which lost a
+ member due to the "split" MUST be sent a QUIT message. Messages to
+ channel members are generated by each client's local server.
+
+ If a server connection is terminated prematurely (e.g., the server on
+ the other end of the link died), the server which detects this
+ disconnection is REQUIRED to inform the rest of the network that the
+ connection has closed and fill in the comment field with something
+ appropriate.
+
+ When a client is removed as the result of a SQUIT message, the server
+ SHOULD add the nickname to the list of temporarily unavailable
+ nicknames in an attempt to prevent future nickname collisions. See
+
+ section 5.7 (Tracking recently used nicknames) for more information
+ on this procedure.
+
+ Numeric replies:
+
+ ERR_NOPRIVILEGES ERR_NOSUCHSERVER
+ ERR_NEEDMOREPARAMS
+
+ Example:
+
+ SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi
+ has been terminated because of "Bad
+ Link".
+
+ :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; message
+ from Trillian to disconnect
+ "cm22.eng.umd.edu" from the net
+ because "Server out of control".
+
+4.2 Channel operations
+
+ This group of messages is concerned with manipulating channels, their
+ properties (channel modes), and their contents (typically users). In
+ implementing these, a number of race conditions are inevitable when
+ users at opposing ends of a network send commands which will
+ ultimately clash. It is also REQUIRED that servers keep a nickname
+ history to ensure that wherever a <nick> parameter is given, the
+ server check its history in case it has recently been changed.
+
+4.2.1 Join message
+
+ Command: JOIN
+ Parameters: <channel>[ %x7 <modes> ]
+ *( "," <channel>[ %x7 <modes> ] )
+
+ The JOIN command is used by client to start listening a specific
+ channel. Whether or not a client is allowed to join a channel is
+ checked only by the local server the client is connected to; all
+ other servers automatically add the user to the channel when the
+ command is received from other servers.
+
+ Optionally, the user status (channel modes 'O', 'o', and 'v') on the
+ channel may be appended to the channel name using a control G (^G or
+ ASCII 7) as separator. Such data MUST be ignored if the message
+ wasn't received from a server. This format MUST NOT be sent to
+ clients, it can only be used between servers and SHOULD be avoided.
+
+ The JOIN command MUST be broadcast to all servers so that each server
+ knows where to find the users who are on the channel. This allows
+ optimal delivery of PRIVMSG and NOTICE messages to the channel.
+
+ 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:
+
+ :WiZ JOIN #Twilight_zone ; JOIN message from WiZ
+
+4.2.2 Njoin message
+
+ Command: NJOIN
+ Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
+ *( "," [ "@@" / "@" ] [ "+" ] <nickname> )
+
+ The NJOIN message is used between servers only. If such a message is
+ received from a client, it MUST be ignored. It is used when two
+ servers connect to each other to exchange the list of channel members
+ for each channel.
+
+ Even though the same function can be performed by using a succession
+ of JOIN, this message SHOULD be used instead as it is more efficient.
+ The prefix "@@" indicates that the user is the "channel creator", the
+ character "@" alone indicates a "channel operator", and the character
+ '+' indicates that the user has the voice privilege.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
+ ERR_ALREADYREGISTRED
+
+ Examples:
+
+ :ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN
+ message from ircd.stealth.net
+ announcing users joining the
+ #Twilight_zone channel: WiZ with
+ channel operator status, syrk with
+ voice privilege and avalon with no
+ privilege.
+
+4.2.3 Mode message
+
+ The MODE message is a dual-purpose command in IRC. It allows both
+ usernames and channels to have their mode changed.
+
+ When parsing MODE messages, it is RECOMMENDED that the entire message
+ be parsed first, and then the changes which resulted passed on.
+
+ It is REQUIRED that servers are able to change channel modes so that
+ "channel creator" and "channel operators" may be created.
+
+5. Implementation details
+
+ A the time of writing, the only current implementation of this
+ protocol is the IRC server, version 2.10. Earlier versions may
+ implement some or all of the commands described by this document with
+ NOTICE messages replacing many of the numeric replies. Unfortunately,
+ due to backward compatibility requirements, the implementation of
+ some parts of this document varies with what is laid out. One
+ notable difference is:
+
+ * recognition that any LF or CR anywhere in a message marks
+ the end of that message (instead of requiring CR-LF);
+
+ The rest of this section deals with issues that are mostly of
+ importance to those who wish to implement a server but some parts
+ also apply directly to clients as well.
+
+5.1 Connection 'Liveness'
+
+ To detect when a connection has died or become unresponsive, the
+ server MUST poll each of its connections. The PING command (See "IRC
+ Client Protocol" [IRC-CLIENT]) is used if the server doesn't get a
+ response from its peer in a given amount of time.
+
+ If a connection doesn't respond in time, its connection is closed
+ using the appropriate procedures.
+
+5.2 Accepting a client to server connection
+
+5.2.1 Users
+
+ When a server successfully registers a new user connection, it is
+ REQUIRED to send to the user unambiguous messages stating: the user
+ identifiers upon which it was registered (RPL_WELCOME), the server
+ name and version (RPL_YOURHOST), the server birth information
+ (RPL_CREATED), available user and channel modes (RPL_MYINFO), and it
+ MAY send any introductory messages which may be deemed appropriate.
+
+ In particular the server SHALL send the current user/service/server
+ count (as per the LUSER reply) and finally the MOTD (if any, as per
+ the MOTD reply).
+
+ After dealing with registration, the server MUST then send out to
+ other servers the new user's nickname (NICK message), other
+ information as supplied by itself (USER message) and as the server
+ could discover (from DNS servers). The server MUST NOT send this
+ information out with a pair of NICK and USER messages as defined in
+ "IRC Client Protocol" [IRC-CLIENT], but MUST instead take advantage
+ of the extended NICK message defined in section 4.1.3.
+
+5.2.2 Services
+
+ Upon successfully registering a new service connection, the server is
+ subject to the same kind of REQUIREMENTS as for a user. Services
+ being somewhat different, only the following replies are sent:
+ RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO.
+
+ After dealing with this, the server MUST then send out to other
+ servers (SERVICE message) the new service's nickname and other
+ information as supplied by the service (SERVICE message) and as the
+ server could discover (from DNS servers).
+
+5.3 Establishing a server-server connection.
+
+ The process of establishing a server-to-server connection is fraught
+ with danger since there are many possible areas where problems can
+ occur - the least of which are race conditions.
+
+ After a server has received a connection following by a PASS/SERVER
+ pair which were recognized as being valid, the server SHOULD then
+ reply with its own PASS/SERVER information for that connection as
+ well as all of the other state information it knows about as
+ described below.
+
+ When the initiating server receives a PASS/SERVER pair, it too then
+ checks that the server responding is authenticated properly before
+ accepting the connection to be that server.
+
+5.3.1 Link options
+
+ Server links are based on a common protocol (defined by this
+ document) but a particular link MAY set specific options using the
+ PASS message (See Section 4.1.1).
+
+5.3.1.1 Compressed server to server links
+
+ If a server wishes to establish a compressed link with its peer, it
+ MUST set the 'Z' flag in the options parameter to the PASS message.
+ If both servers request compression and both servers are able to
+ initialize the two compressed streams, then the remainder of the
+ communication is to be compressed. If any server fails to initialize
+ the stream, it will send an uncompressed ERROR message to its peer
+ and close the connection.
+
+ The data format used for the compression is described by RFC 1950
+ [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].
+
+5.3.1.2 Anti abuse protections
+
+ Most servers implement various kinds of protections against possible
+ abusive behaviours from non trusted parties (typically users). On
+ some networks, such protections are indispensable, on others they are
+ superfluous. To require that all servers implement and enable such
+ features on a particular network, the 'P' flag is used when two
+ servers connect. If this flag is present, it means that the server
+ protections are enabled, and that the server REQUIRES all its server
+ links to enable them as well.
+
+ Commonly found protections are described in sections 5.7 (Tracking
+ recently used nicknames) and 5.8 (Flood control of clients).
+
+5.3.2 State information exchange when connecting
+
+ The order of state information being exchanged between servers is
+ essential. The REQUIRED order is as follows:
+
+ * all known servers;
+
+ * all known client information;
+
+ * all known channel information.
+
+ Information regarding servers is sent via extra SERVER messages,
+ client information with NICK and SERVICE messages and channels with
+ NJOIN/MODE messages.
+
+ NOTE: channel topics SHOULD NOT be exchanged here because the TOPIC
+ command overwrites any old topic information, so at best, the two
+ sides of the connection would exchange topics.
+
+ By passing the state information about servers first, any collisions
+ with servers that already exist occur before nickname collisions
+ caused by a second server introducing a particular nickname. Due to
+ the IRC network only being able to exist as an acyclic graph, it may
+ be possible that the network has already reconnected in another
+ location. In this event, the place where the server collision occurs
+ indicates where the net needs to split.
+
+5.4 Terminating server-client connections
+
+ When a client connection unexpectedly closes, a QUIT message is
+ generated on behalf of the client by the server to which the client
+ was connected. No other message is to be generated or used.
+
+5.5 Terminating server-server connections
+
+ If a server-server connection is closed, either via a SQUIT command
+ or "natural" causes, the rest of the connected IRC network MUST have
+ its information updated by the server which detected the closure.
+ The terminating server then sends a list of SQUITs (one for each
+ server behind that connection). (See Section 4.1.6 (SQUIT)).
+
+5.6 Tracking nickname changes
+
+ All IRC servers are REQUIRED to keep a history of recent nickname
+ changes. This is important to allow the server to have a chance of
+ keeping in touch of things when nick-change race conditions occur
+ with commands manipulating them. Messages which MUST trace nick
+ changes are:
+
+ * KILL (the nick being disconnected)
+
+ * MODE (+/- o,v on channels)
+
+ * KICK (the nick being removed from channel)
+
+ No other commands need to check nick changes.
+
+ In the above cases, the server is required to first check for the
+ existence of the nickname, then check its history to see who that
+ nick now belongs to (if anyone!). This reduces the chances of race
+ conditions but they can still occur with the server ending up
+ affecting the wrong client. When performing a change trace for an
+ above command it is RECOMMENDED that a time range be given and
+ entries which are too old ignored.
+
+ For a reasonable history, a server SHOULD be able to keep previous
+ nickname for every client it knows about if they all decided to
+ change. This size is limited by other factors (such as memory, etc).
+
+5.7 Tracking recently used nicknames
+
+ This mechanism is commonly known as "Nickname Delay", it has been
+ proven to significantly reduce the number of nickname collisions
+ resulting from "network splits"/reconnections as well as abuse.
+
+ In addition of keeping track of nickname changes, servers SHOULD keep
+ track of nicknames which were recently used and were released as the
+ result of a "network split" or a KILL message. These nicknames are
+ then unavailable to the server local clients and cannot be re-used
+ (even though they are not currently in use) for a certain period of
+ time.
+
+ The duration for which a nickname remains unavailable 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.8 Flood control of clients
+
+ With a large network of interconnected IRC servers, it is quite easy
+ for any single client attached to the network to supply a continuous
+ stream of messages that result in not only flooding the network, but
+ also degrading the level of service provided to others. Rather than
+ require every 'victim' to provide their own protection, flood
+ protection was written into the server and is applied to all clients
+ except services. The current algorithm is as follows:
+
+ * check to see if client's `message timer' is less than current time
+ (set to be equal if it is);
+
+ * read any data present from the client;
+
+ * while the timer is less than ten (10) seconds ahead of the current
+ time, parse any present messages and penalize the client by two (2)
+ seconds for each message;
+
+ * additional penalties MAY be used for specific commands which
+ generate a lot of traffic across the network.
+
+ This in essence means that the client may send one (1) message every
+ two (2) seconds without being adversely affected. Services MAY also
+ be subject to this mechanism.
+
+5.9 Non-blocking lookups
+
+ In a real-time environment, it is essential that a server process
+ does as little waiting as possible so that all the clients are
+ serviced fairly. Obviously this requires non-blocking IO on all
+ network read/write operations. For normal server connections, this
+ was not difficult, but there are other support operations that may
+ cause the server to block (such as disk reads). Where possible, such
+ activity SHOULD be performed with a short timeout.
+
+5.9.1 Hostname (DNS) lookups
+
+ Using the standard resolver libraries from Berkeley and others has
+ meant large delays in some cases where replies have timed out. To
+ avoid this, a separate set of DNS routines were written for the
+ current implementation. Routines were setup for non-blocking IO
+ operations with local cache, and then polled from within the main
+ server IO loop.
+
+5.9.2 Username (Ident) lookups
+
+ Although there are numerous ident libraries (implementing the
+ "Identification Protocol" [IDENT]) for use and inclusion into other
+ programs, these caused problems since they operated in a synchronous
+ manner and resulted in frequent delays. Again the solution was to
+ write a set of routines which would cooperate with the rest of the
+ server and work using non-blocking IO.
+
+6. Current problems
+
+ There are a number of recognized problems with this protocol, all of
+ which are hoped to be solved sometime in the near future during its
+ rewrite. Currently, work is underway to find working solutions to
+ these problems.
+
+6.1 Scalability
+
+ It is widely recognized that this protocol does not scale
+ sufficiently well when used in a large arena. The main problem comes
+ from the requirement that all servers know about all other servers
+ and clients and that information regarding them be updated as soon as
+ it changes. It is also desirable to keep the number of servers low
+ so that the path length between any two points is kept minimal and
+ the spanning tree as strongly branched as possible.
+
+6.2 Labels
+
+ The current IRC protocol has 4 types of labels: the nickname, the
+ channel name, the server name and the service name. Each of the four
+ types has its own domain and no duplicates are allowed inside that
+ domain. Currently, it is possible for users to pick the label for
+ any of the first three, resulting in collisions. It is widely
+ recognized that this needs reworking, with a plan for unique names
+ for nicks that don't collide being desirable as well as a solution
+ allowing a cyclic tree.
+
+6.2.1 Nicknames
+
+ The idea of the nickname on IRC is very convenient for users to use
+ when talking to each other outside of a channel, but there is only a
+ finite nickname space and being what they are, it's not uncommon for
+ several people to want to use the same nick. If a nickname is chosen
+ by two people using this protocol, either one will not succeed or
+ both will be removed by use of KILL (See Section 3.7.1 of "IRC Client
+ Protocol" [IRC-CLIENT]).
+
+6.2.2 Channels
+
+ The current channel layout requires that all servers know about all
+ channels, their inhabitants and properties. Besides not scaling
+ well, the issue of privacy is also a concern. A collision of
+ channels is treated as an inclusive event (people from both nets on
+ channel with common name are considered to be members of it) rather
+ than an exclusive one such as used to solve nickname collisions.
+
+ This protocol defines "Safe Channels" which are very unlikely to be
+ the subject of a channel collision. Other channel types are kept for
+ backward compatibility.
+
+6.2.3 Servers
+
+ Although the number of servers is usually small relative to the
+ number of users and channels, they too are currently REQUIRED to be
+ known globally, either each one separately or hidden behind a mask.
+
+6.3 Algorithms
+
+ In some places within the server code, it has not been possible to
+ avoid N^2 algorithms such as checking the channel list of a set of
+ clients.
+
+ In current server versions, there are only few database consistency
+ checks, most of the time each server assumes that a neighbouring
+ server is correct. This opens the door to large problems if a
+ connecting server is buggy or otherwise tries to introduce
+ contradictions to the existing net.
+
+ Currently, because of the lack of unique internal and global labels,
+ there are a multitude of race conditions that exist. These race
+ conditions generally arise from the problem of it taking time for
+ messages to traverse and effect the IRC network. Even by changing to
+ unique labels, there are problems with channel-related commands being
+ disrupted.
+
+7. Security Considerations
+
+7.1 Authentication
+
+ Servers only have two means of authenticating incoming connections:
+ plain text password, and DNS lookups. While these methods are weak
+ and widely recognized as unsafe, their combination has proven to be
+ sufficient in the past:
+
+ * public networks typically allow user connections with only few
+ restrictions, without requiring accurate authentication.
+
+ * private networks which operate in a controlled environment often
+ use home-grown authentication mechanisms not available on the
+ internet: reliable ident servers [IDENT], or other proprietary
+ mechanisms.
+
+ The same comments apply to the authentication of IRC Operators.
+
+ It should also be noted that while there has been no real demand over
+ the years for stronger authentication, and no real effort to provide
+ better means to safely authenticate users, the current protocol
+ offers enough to be able to easily plug-in external authentication
+ methods based on the information that a client can submit to the
+ server upon connection: nickname, username, password.
+
+7.2 Integrity
+
+ Since the PASS and OPER messages of the IRC protocol are sent in
+ clear text, a stream layer encryption mechanism (like "The TLS
+ Protocol" [TLS]) could be used to protect these transactions.
+
+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.
+
+10. References
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 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-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
+ 2811, April 2000.
+
+ [ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
+ Format Specification version 3.3", RFC 1950, May 1996.
+
+ [DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format
+ Specification version 1.3", RFC 1951, May 1996.
+
+ [GZIP] Deutsch, P., "GZIP file format specification version
+ 4.3", RFC 1952, May 1996.
+
+ [IDENT] St. Johns, M., "The Identification Protocol", RFC 1413,
+ February 1993.
+
+ [TLS] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
+ January 1999.
+
+11. Author's Address
+
+ Christophe Kalt
+ 99 Teaneck Rd, Apt #117
+ Ridgefield Park, NJ 07660
+ USA
+
+ EMail: kalt@stealth.net
+
+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.
diff --git a/doc/technical/send.txt b/doc/technical/send.txt
new file mode 100644
index 0000000..38fd916
--- /dev/null
+++ b/doc/technical/send.txt
@@ -0,0 +1,262 @@
+PREFIXES
+========
+
+ Server prefixes are the ":%s" strings at the beginning of messages.
+They are used by servers to route the message properly and by servers to
+local clients to update their idea of who is whom.
+
+":nick!user@host" is a prefix ":name" where name is either a nick
+or name of a server is another valid prefix.
+
+Typical prefix for a local client to a channel:
+
+":Dianora!db@irc.db.net"
+
+for a prefix to a remote server:
+":Dianora"
+
+e.g. as seen locally on a channel:
+
+":Dianora!db@irc.db.net PRIVMSG #us-opers :ON TOP OF ...\r\n"
+
+e.g. as seen sent to a remote server:
+":Dianora PRIVMSG #us-opers :ON TOP OF ...\r\n"
+
+ It has been argued that full prefixes sent locally are a waste of bandwidth
+(Isomer from Undernet has argued this). i.e. instead of sending:
+":nick!user@host" for a local prefix, one could just send ":nick"..
+Unfortunately, this breaks many clients badly. Personally I feel that
+until clients are updated to understand that a full prefix isn't always
+going to be sent, that this should be held off on.
+
+ As much as possible, prefix generation is now moved "upstairs" as
+much as possible. i.e. if its known its a local client only, then the
+onus of the prefix generation, is the users, not hidden in send.c
+This allows somewhat faster code to be written, as the prefix doesn't
+have to be regenerated over and over again.
+
+ Prefixes aren't sent in all cases, such as a new user using NICK
+A prefix is needed when it must be routed.
+
+i.e.
+
+NICK newnick
+
+ There is obviously no prefix needed from a locally connected client.
+
+
+
+FUNCTIONS
+=========
+
+sendto_one() - Should be used for _local_ clients only
+ it expects the prefix to be pre-built by user.
+
+ usage - sendto_one(struct Client *to, char *pattern, ...);
+
+ typical use:
+
+ sendto_one(acptr,":%s NOTICE %s :I'm tired", me.name);
+ Note: This was from a server "me" hence only one
+ name in prefix.
+
+ This would be an example of a client sptr, noticing
+ acptr IF acptr is known to be a local client:
+
+ sendto_one(acptr,":%s!%s@%s NOTICE %s :You there?",
+ sptr->name,
+ sptr->username,
+ sptr->host,
+ acptr->name);
+
+sendto_channel_butone()
+ - This function sends a var args message to a channel globally,
+ except to the client specified as "one", the prefix
+ is built by this function on the fly as it has to
+ be sent both to local clients on this server and to
+ remote servers. +D clients are omitted, as this is used
+ only for PRIVMSG/NOTICE.
+
+ usage - sendto_channel_butone(struct Client *one,
+ struct Client *from,
+ struct Channel *chptr,
+ const char *pattern, ... );
+
+ sendto_channel_butone(cptr, sptr, chptr
+ "PRIVMSG %s :HI!",
+ chptr->chname);
+
+ e.g. if channel message is coming from "cptr"
+ it must not be sent back to cptr.
+
+
+sendto_ll_serv_butone(struct Client *one, struct Client *sptr, int add,
+ const char *pattern, ...)
+
+ - This function is almost identical to sendto_channel_butone
+ however, it will also not send on a nick as given by sptr,
+ if target server does not "know" about it.
+ As the name implies, it is used for "lazylinks"
+
+sendto_server()
+ - This function sends specified var args message
+ to all connected servers except the client "one"
+ - chptr can be NULL, in which case it goes to server
+ - caps is a set of CAPS to send =to=
+ - nocaps is a set of CAPS to not send =to=
+
+ usage - sendto_server(struct Client *one,
+ struct Channel *chptr,
+ unsigned long caps,
+ unsigned long nocaps,
+ unsigned long llflags,
+ const char *pattern, ... );
+
+
+sendto_common_channels_local()
+ - This function is used only by m_nick and exit_one_client
+ its used to propagate nick changes to all channels user
+ is in, and QUIT messages to all channels user is in.
+ As it only sends to local clients, prefix generation
+ is left to the user. It also sends the message to the
+ user if the user isn't on any channels.
+
+ usage - sendto_common_channels_local(struct Client *user,
+ const char *pattern,
+ ...);
+
+sendto_channel_local()
+ - This function is used only to send locally, never
+ to remote servers. This is useful when removing
+ local chanops, or adding a local chanop. MODE/SJOIN
+ sent to remote server allows that server to propagate
+ mode changes to its clients locally. If nodeaf is YES,
+ +D clients are omitted (used for delivering WALLCHOPS).
+
+ usage - sendto_channel_local(type, nodeaf,
+ struct Channel *chptr,
+ const char *pattern, ... );
+
+
+ prefix must be pre-built. type is a flag
+ denoting ONE of
+ ALL_MEMBERS - all members locally are sent to
+ NON_CHANOPS - only non-chanops see this
+ ONLY_CHANOPS_VOICED - both chanops and voiced see this
+ ONLY_CHANOPS - only chanops see this
+
+
+sendto_match_butone()
+match_it() - both only used for the old style oper masking
+ i.e. /msg #hostmask which in hyb7 is /msg $#hostmask
+ or /msg $servermask in hyb7 /msg $$servermask
+
+ usage - match_it(struct Client *one,
+ const char *mask,
+ int what);
+
+ one is the client to match on either hostmask or servermask
+ mask is the actual mask
+ what is either MATCH_HOST or MATCH_SERVER
+
+ usage - sendto_match_butone(struct Client *one,
+ struct Client *from,
+ char *mark,
+ int what,
+ const char *pattern, ... );
+
+sendto_channel_remote()
+ - Is only used to send a message to a remote server
+
+
+sendto_match_cap_servs()
+ - Is used only to send MODE lists to remote server
+ who are capable of it. i.e. MODE #channel +e nick!user@host
+
+sendto_match_noncap_servs()
+ - Is used only to send MODE lists to remote servers that
+ are not capable of it. i.e. MODE #channel +o nick
+ - This allows you to send a MODE #channel +h nick via
+ sendto_match_cap_servs and MODE #channel +o nick to
+ servers which don't support it.
+
+sendto_anywhere()
+ - Allows the sending of a message to any client on the net
+ without knowing whether its local or remote. The penalty
+ is the calculation of a run-time prefix.
+ It is less efficient then sendto_one()
+
+ usage - sendto_anywhere(struct Client *to,
+ struct Client *from,
+ const char *pattern, ...);
+
+ e.g.
+ sendto_anywhere(acptr, sptr,
+ "PRIVMSG Larz :Hi, Where ever you are");
+
+sendto_realops_flags()
+ - combines old sendto_realops and sendto_realops_flags
+ sends specified message to opers locally only
+ depending on two flags, UMODE i.e. +y +d or UMODE_SERVNOTICE
+ or special case, UMODE_ALL (see client.h UMODE flags )
+ to send to any oper. The second flag gives the level
+ of whom to send the messages to, OPERS, ADMINS only or both.
+ (See send.h for those flags)
+
+ usage - sendto_realops_flags(int umode, int level,
+ const char *pattern, ... );
+
+ e.g.
+ sendto_realops_flags(UMODE_ALL, L_ALL,
+ "Don't eat the yellow snow");
+
+sendto_wallops_flags()
+ - sends specified message to opers locally,
+ depending on flags. used for messages that need
+ to be in wallops form
+
+ usage - sendto_wall_flags(int flags,
+ struct Client *, const char *patterm ...);
+
+ e.g.
+ sendto_wallops_flags(UMODE_WALLOP,
+ sptr, "Message");
+
+ts_warn() - Only used to send warning messages to all opers
+ without flooding them with warnings.
+ It limits the number of warnings to no more than 5
+ every 5 seconds. It probably can go away now.
+
+ usage - ts_warn(const char *pattern, ... );
+
+*** LOCAL HELPER FUNCTIONS (static) ***
+
+send_format() - Used to format a varargs buffer into given buffer
+ returns length of buffer built, enforces RFC1459 length
+ limits and appends \r\n as per rfc.
+
+ usage - send_format(char *sendbuf,
+ const char *pattern, ... );
+
+send_message()
+ - This local function does the actual send of message
+
+ usage: send_message(struct Client *to, char *msg, int len);
+
+ The message has to be pre-formatted and the length
+ must be pre-calculated.
+
+send_message_remote()
+ - This local function does the actual send of message to
+ remote clients
+
+ usage: send_message_remote(struct Client *to,
+ struct Client *from, char *msg, int len);
+
+ The message has to be pre-formatted and the length
+ must be pre-calculated.
+
+
+-- Diane Bruce
+
+$Id$
diff --git a/doc/technical/ts3.txt b/doc/technical/ts3.txt
new file mode 100644
index 0000000..e2f4927
--- /dev/null
+++ b/doc/technical/ts3.txt
@@ -0,0 +1,321 @@
+$Id$
+ Protocol changes for +TSora
+ ---------------------------
+
+Note:
+
+The protocols described here implement TimeStamps on IRC channels and
+nicks. The idea of IRC TimeStamps was started on Undernet, and first
+implemented by Run <carlo@runaway.xs4all.nl>. The protocols used here
+are not exactly the same as the ones used on Undernet; the nick-kill
+handling is very similar and must be credited to Run, while the
+"TimeStamped channel description" protocol is quite different.
+
+TSora servers keep track of which version of the TS protocol (if any)
+their neighboring servers are using, and take it into account when
+sending messages to them. This allows for seamless integration of TS
+servers into a non-TS net, and for upgrades of the protocol.
+
+Each server knows which is the lowest and the highest version of the
+TS protocol it can interact with; currently both of these are set to 1:
+
+#define TS_CURRENT 1 /* the highest TS ver we can do */
+#define TS_MIN 1 /* the lowest TS ver we can do */
+
+Timings and TS versions:
+========================
+
+. Keep a 'delta' value to be added to the result of all calls to time(),
+ initially 0.
+
+. Send a second argument to the PASS command, ending in the 'TS' string.
+
+. Send a
+
+ SVINFO <TS_CURRENT> <TS_MIN> <STANDALONE> :<UTC-TIME>
+
+ just after "SERVER", where <STANDALONE> is 1 if we're connected to
+ more TSora servers, and 0 if not, and <UTC-TIME> is our idea of the
+ current UTC time, fixed with the delta.
+
+. When we receive a "SVINFO <x> <y> <z> :<t>" line from a connecting
+ server, we ignore it if TS_CURRENT<y or x<TS_MIN, otherwise we
+ set a flag remembering that that server is TS-aware, remember the TS
+ version to use with it (min(TS_CURRENT, x)). Additionally, if this is
+ our first connected TS server, we set our delta to t-<OUR_UTC> if
+ z==0, and to (t-<OUR_UTC>)/2 if z!=0. The SVINFO data is kept around
+ until the server has effectively registered with SERVER, and used
+ *after* sending our own SVINFO to that server.
+
+Explanations:
+
+ Servers will always know which of their directly-linked servers can do
+ TS, and will use the TS protocol only with servers that do understand
+ it. This makes it possible to switch to full TS in just one
+ code-replacement step, without incompatibilities.
+
+ As long as not all servers are TS-aware, the net will be divided into
+ "zones" of linked TS-aware servers. Channel modes will be kept
+ synchronized at least within the zone in which the channel was
+ created, and nick collisions between servers in the same zone will
+ result in only one client being killed.
+
+ Time synchronization ensures that servers have the same idea of the
+ current time, and achieves this purpose as long as TS servers are
+ introduced one by one within the same 'zone'. The merging of two zones
+ cannot synchronize them completely, but it is to be expected that
+ within each zone the effective time will be very close to the real
+ time.
+
+ By sending TSINFO after SERVER rather than before, we avoid the extra
+ lag created by the identd check on the server. To be able to send
+ immediately a connect burst of either type (TS or not), we need to
+ know before that if the server does TS or not, so we send that
+ information with PASS as an extra argument. And to avoid being
+ incompatible with 2.9 servers, which check that this second argument
+ begins with "2.9", we check that it *ends* with "TS".
+
+ The current time is only used when setting a TS on a new channel or
+ nick, and once such a TS is set, it is never modified because of
+ synchronization, as it is much more important that the TS for a
+ channel or nick stays the same across all servers than that it is
+ accurate to the second.
+
+ Note that Undernet's 2.8.x servers have no time synchronization at
+ all, and have had no problems because of it - all of this is more to
+ catch the occasional server with a way-off clock than anything.
+
+NICK handling patches (anti-nick-collide + shorter connect burst):
+==================================================================
+
+. For each nick, store a TS value = the TS value received if any, or our
+ UTC+delta at the time we first heard of the nick. TS's are propagated
+ to TS-aware servers whenever sending a NICK command.
+
+. Nick changes reset the TS to the current time.
+
+. When sending a connect burst to another TS server, replace the
+ NICK/USER pair with only one NICK command containing the nick, the
+ hopcount, the TS, the umode, and all the USER information.
+
+ The format for a full NICK line is:
+ NICK <nick> <hops> <TS> <umode> <user> <host> <server> :<ircname>
+
+ The umode is a + followed by any applying usermodes.
+
+ The format for a nick-change NICK line is:
+ :<oldnick> NICK <newnick> :<TS>
+
+. When a NICK is received from a TS server, that conflicts with an
+ existing nick:
+ + if the userhosts differ or one is not known:
+ * if the timestamps are equal, kill ours and the old one if it
+ was a nick change
+ * if the incoming timestamp is older than ours, kill ours and
+ propagate the new one
+ * if the incoming timestamp is younger, ignore the line, but kill
+ the old nick if it was a nick change
+ + if the userhosts are the same:
+ * if the timestamps are equal, kill ours and the old one if it
+ was a nick change
+ * if the incoming timestamp is younger, kill ours and propagate
+ the new one
+ * if the incoming timestamp is older, ignore the line but kill
+ the old nick if it was a nick change
+
+. When a NICK is received from a non-TS server that conflicts with
+ an existing nick, kill both.
+
+. Do not send "Fake Prefix" kills in response to lines coming from TS
+ servers; the sanitization works anyway, and this allows the "newer
+ nick overruled" case to work.
+
+Explanations:
+
+ The modified nick-introduction syntax allows for a slightly shorter
+ connect-burst, and most importantly lets the server compare
+ user@host's when determining which nick to kill: if the user@host
+ is the same, then the older nick must be killed rather than the
+ newer.
+
+ When talking to a non-TS server, we need to behave exactly like one
+ because it expects us to. When talkign to a TS server, we don't kill
+ the nicks it's introducing, as we know it'll be smart enough to do it
+ itself when seeing our own introduced nick.
+
+ When we see a nick arriving from a non-TS server, it won't have a TS,
+ but it's safe enough to give it the current time rather than keeping
+ it 0; such TS's won't be the same all across the network (as long as
+ there is more than one TS zone), and when there's a collision, the TS
+ used will be the one in the zone the collision occurs in.
+
+ Also, it is important to note that by the time a server sees (and
+ chooses to ignore) a nick introduction, the introducing server has
+ also had the time to put umode changes for that nick on its queue, so
+ we must ignore them too... so we need to ignore fake-prefix lines
+ rather than sending kills for them. This is safe enough, as the rest
+ of the protocol ensures that they'll get killed anyway (and the
+ Undernet does it too, so it's been more than enough tested). Just for
+ an extra bit of compatibility, we still kill fake prefixes coming from
+ non-TS servers.
+
+ This part of the TS protocol is almost exactly the same as the
+ Undernet's .anc (anti-nick-collide) patches, except that Undernet
+ servers don't add usermodes to the NICK line.
+
+TimeStamped channel descriptions (avoiding hacked ops and desynchs):
+====================================================================
+
+. For each channel, keep a timestamp, set to the current time when the
+ channel is created by a client on the local server, or to the received
+ value if the channel has been propagated from a TS server, or to 0
+ otherwise. This value will have the semantics of "the time of creation
+ of the current ops on the channel", and 0 will mean that the channel
+ is in non-TS mode.
+
+ A new server protocol command is introduced, SJOIN, which introduces
+ a full channel description: a timestamp, all the modes (except bans),
+ and the list of channel members with their ops and voices. This
+ command will be used instead of JOIN and of (most) MODEs both in
+ connect bursts and when propagating channel creations among TS
+ servers. SJOIN will never be accepted from or sent to users.
+
+ The syntax for the command is:
+
+ SJOIN <TS> #<channel> <modes> :[@][+]<nick_1> ... [@][+]<nick_n>
+
+ The fields have the following meanings:
+
+ * <TS> is the timestamp for the channel
+
+ * <modes> is the list of global channel modes, starting with a +
+ and a letter for each of the active modes (spmntkil), followed
+ by an argument for +l if there is a limit, and an argument for
+ +k if there's a key (in the same order they were mentioned in
+ the string of letters).
+
+ A channel with no modes will have a "+" in that field.
+
+ A special value of "0" means that the server does not specify the
+ modes, and will be used when more than one SJOIN line is needed
+ to completely describe a channel, or when propagating a SJOIN
+ the modes of which were rejected.
+
+ * Each nick is preceded by a "@" if the user has ops, and a "+" if
+ the user has a voice. For mode +ov, both flags are used.
+
+ SJOINs will be propagated (when appropriate) to neighboring TS
+ servers, and converted to JOINs and MODEs for neighboring non-TS
+ servers.
+
+ To propagate channels for which not all users fit in one
+ SJOIN line, several SJOINs will be sent consecutively, only the first
+ one including actual information in the <mode> field.
+
+ An extra ad-hoc restriction is imposed on SJOIN messages, to simplify
+ processing: if a channel has ops, then the first <nick> of the first
+ SJOIN sent to propagate that channel must be one of the ops.
+
+ Servers will never attempt to reconstruct a SJOIN from JOIN/MODE
+ information being received at the moment from other servers.
+
+. For each user on a channel, keep an extra flag (like ops and voice)
+ that is set when the user has received channel ops from another
+ server (in a SJOIN channel description), which we rejected (ignored).
+ Mode changes (but NOT kicks) coming from a TS server and from someone
+ with this flag set will be ignored. The flag will be reset when the
+ user gets ops from another user or server.
+
+. On deops done by non-local users, coming from TS servers, on channels
+ with a non-zero TS, do not check that the user has ops but check that
+ their 'deopped' flag is not set. For kicks coming from a TS server, do
+ not check either. This will avoid desynchs, and 'bad' modechanges are
+ avoided anyway. Other mode changes will still only be taken into
+ account and propagated when done by users that are seen as having ops.
+
+. When a MODE change that ops someone is received from a server for a
+ channel, that channel's TS is set to 0, and the mode change is
+ propagated.
+
+. When a SJOIN is received for a channel, deal with it in this way:
+ * received-TS = 0:
+ + if we have ops or the SJOIN doesn't op anyone, SJOIN propagated
+ with our own TS.
+ + otherwise, TS set to 0 and SJOIN propagated with 0.
+ * received-TS > 0, own-TS = 0:
+ + if the SJOIN ops someone or we don't have ops, set our TS to the
+ received TS and propagate.
+ + otherwise, propagate with TS = 0.
+ * received-TS = own-TS: propagate.
+ * received-TS < own-TS:
+ + if the SJOIN ops someone, remove *all* modes (except bans) from
+ the channel and propagate these mode changes to all neighboring
+ non-TS servers, and copy the received TS and propagate the SJOIN.
+ + if the SJOIN does not op anyone and we have ops, propagate
+ with our own TS.
+ + otherwise, copy the received TS and propagate the SJOIN.
+ * received-TS > own-TS:
+ + if the SJOIN does not introduce any ops, process and propagate
+ with our own TS.
+ + if we have ops: for each person the mode change would op, set the
+ 'deopped' flag; process all the JOINs ignoring the '@' and '+'
+ flags; propagate without the flags and with our TS.
+ + if we don't have ops: set our TS to the received one, propagate
+ with the flags.
+
+Explanations:
+
+ This part of the protocol is the one that is most different (and
+ incompatible) with the Undernet's: we never timestamp MODE changes,
+ but instead we introduce the concept of time-stamped channel
+ descriptions. This way each server can determine, based on its state
+ and the received description, what the correct modes for a channel
+ are, and deop its own users if necessary. With this protocol, there is
+ *never* the need to reverse and bounce back a mode change. This is
+ both faster and more bandwith-effective.
+
+ The end goal is to have a protocol will eventually protect channels
+ against hacked ops, while minimizing the impact on a mixed-server net.
+ In order to do this, whenever there is a conflict between a TS server
+ and a non-TS one, the non-TS one's idea of the whole situation
+ prevails. This means that channels will only have a TS when they have
+ been created on a TS-aware server, and will lose it whenever a server
+ op comes from a non-TS server. Also, at most one 'zone' will have a TS
+ for any given channel at any given time, ensuring that there won't be
+ any deops when zones are merged. However, when TS zones are merged, if
+ the side that has a TS also has ops, then the TS is kept across the
+ whole new zone. Effective protection will only be ensured once all
+ servers run TS patches and channels have been re-created, as there is
+ no way servers can assign a TS to a channel they are not creating
+ (like they do with nicks) without having unwanted deops later.
+
+ The visible effects of this timestamped channel-description protocol
+ are that when a split rejoins, and one side has hacked ops, the other
+ side doesn't see any server mode changes (just like with Undernet's
+ TS), but the side that has hacked ops sees:
+
+ * first the first server on the other side deopping and devoicing
+ everyone, and fixing the +spmntkli modes
+ * then other users joining, and getting server ops and voices
+
+ The less obvious part of this protocol is its behavior in the case
+ that the younger side of a rejoin has servers that are lagged with
+ each other. In such a situation, a SJOIN that clears all modes and
+ sets the legitimate ones is being propagated from one server, and
+ lagged illegitimate mode changes and kicks are being propagated in the
+ opposite direction. In this case, a kick done by someone who is being
+ deopped by the SJOIN must be taken into account to keep the name list
+ in sync (and since it can only be kicking someone who also was on the
+ younger side), while a deop does not matter (and will be ignored by
+ the first server on the other side), and an opping *needs* to be
+ discareded to avoid hacked ops.
+
+ The main property of timestamped channel descriptions that makes them
+ a very stable protocol even with lag and splits, is that they leave a
+ server in the same final state, independently of the order in which
+ channel descriptions coming from different servers are received. Even
+ when SJOINs and MODEs for the same channel are being propagated in
+ different direction because of several splits rejoining, the final
+ state will be the same, independently of the exact order in which each
+ server received the SJOINs, and will be the same across all the
+ servers in the same zone.
diff --git a/doc/technical/ts5.txt b/doc/technical/ts5.txt
new file mode 100644
index 0000000..de10506
--- /dev/null
+++ b/doc/technical/ts5.txt
@@ -0,0 +1,147 @@
+ Overview of the TS5 system
+ Lee H <lee@leeh.co.uk>
+
+$Id$
+
+For the purposes of this document, ircd versions:
+ hybrid6.0
+ ircd-comstud-1.12
+ CSr31pl4
+
+and prior, are TS3.
+
+ircd-hybrid-6.2 and later support TS5.
+
+Whats TS5?
+----------
+
+The difference between TS5 and TS3 is what happened on opless channels. TS
+works by establishing which server has the oldest version of the channel,
+the version that is oldest, keeps its modes and ops, the version that is
+youngest, removes their modes and ops, and accepts the older version.
+
+There was an exception to this rule with opless channels, if a channel was
+opless, TS3 would allow anybody to keep their ops and modes on the channel.
+TS5 aims to stop this, by removing this exception.
+
+Example1:
+
+An irc network, with server A (every server is ts3)
+
+UserA is on ServerA, in channel #broken. This channel is opless, and has a
+TS of 800000000. ServerA splits, and whilst it is split, UserA cycles
+channel #broken, recreates the channel and is given ops. On ServerA #broken
+now has a TS of 900000000 and has ops. ServerA rejoins with the network,
+via HubB. HubB realises #broken is opless, so allows UserA to retain ops.
+The TS is moved forward to 900000000.
+
+The network now sees #broken as having a TS of 900000000, with UserA being
+opped.
+
+Example2:
+
+An irc network, with server C (every server is ts5)
+
+Same scenario as above. ServerC splits and UserC cycles channel #broken,
+recreating it with a TS of 900000000. ServerC rejoins with the network via
+HubD. HubD realises #broken has a TS of 800000000 locally, and ServerC is
+showing a TS of 900000000, it ignores ServerC's modes and ops. The channel
+remains opless. ServerC receives HubD's modes, and it notices HubD has a
+lower TS of channel #broken. It removes UserC's ops, removes the channel
+modes on #broken, and accepts HubD's status.
+
+The network version of #broken hasnt changed. It is still opless, with a TS
+of 800000000.
+
+
+As you can see, TS5 makes splitting a server to regain ops useless, as it
+cannot be abused to give ops after a netsplit.
+
+The problem with TS5 however, is what happens on a mixed TS5/TS3 network.
+Channels where the older TS has ops will behave the same way on TS5 and TS3,
+however an opless channel will behave differently, as you can see above.
+
+The result of TS5/TS3 mixed can be a desync:
+
+Example1:
+
+As per Example1 above, except the rest of the network is TS5, ServerA is
+TS3. ServerA would keep its modes and ops, whilst the rest of the network
+would remove them. This means only ServerA would see UserA as opped. The
+desync can be abused, as UserA can send modes. Hybrid6.0 servers will
+accept these modes from the unopped client, so if UserA ops UserB, who then
+ops UserA, the channel will be the same across all Hybrid6.0 and Hybrid6.1
+servers.
+
+Example2:
+
+As per Example2 above, except the rest of the network is TS3. ServerC is
+TS5. ServerC would remove its modes and ops, therefore UserC would not be
+opped on ServerC, therefore it could not send any mode changes to the
+channel. Although it is opped elsewhere, it isnt opped locally, so the
+desync cannot be abused.
+
+As you can see, the desync's that can occur can either be resynced, or are
+useless to the user, so a mixed TS5/TS3 network is not a huge problem,
+although a desync is NOT a good thing to have.
+
+
+Why TS5?
+--------
+
+We have jumped to TS5 from TS3, because there was a version of ircd that was
+TS4, so it was thought better to avoid a clash with an existing version.
+
+
+Advantages
+----------
+
+It's a realistic event that a server will be attacked so it splits off a
+network, then used to regain ops in a channel. TS5 makes this pointless,
+the server will never give ops on a netsplit. TS5 is network wide, so it
+leaves individual servers free to choose options like NO_JOIN_ON_SPLIT,
+whilst keeping splits useless to users.
+
+
+Disadvantages
+-------------
+
+It's virtually impossible for a user to actively regain ops themselves (some
+regard this as an advantage..) because on a large sized channel, its
+impossible to get people to leave so it can be recreated, therefore if a
+network did not have some form of services, it could possibly end up
+requiring oper intervention, as you cant get everybody to leave, and you
+cant use splits to regain ops, therefore if the channel is open (an
+invite-only channel would gradually destroy itself as noone new can join) it
+could be impossible for a user to regain ops.
+
+On a network that has some form of services, The effect of TS5 would be
+minimal, however the services must be of sufficient quality to fix opless
+channels, as TS5 renders netsplits for ops worthless.
+
+
+Recommendations
+---------------
+
+If your network has good stable services, we recommend TS5 is enabled, as
+people have no reason to abuse netsplits anyway.
+
+If your network has no services at all, then TS5 may cause problems with
+users being left with a permanently opless channel.
+
+If your network occupies the middle ground, then its a choice between users
+needing to be able to use splits to regain ops, or making netsplits that are
+caused to regain ops worthless.
+
+If TS5 is chosen, the FULL network must upgrade and this should be done in a
+relatively short space of time to minimise the possible desync effects.
+
+
+Alternatives
+------------
+
+There is also NO_JOIN_ON_SPLIT and NO_OP_ON_SPLIT, however these use the
+configuration of minimum servers and users, and sometimes a split that is
+above these limits is enough to be abused to regain ops, whereas if the
+limits are too high, clients will never be able to join anything or be opped
+when they create a channel.
diff --git a/doc/technical/ts6.txt b/doc/technical/ts6.txt
new file mode 100644
index 0000000..d1e29e8
--- /dev/null
+++ b/doc/technical/ts6.txt
@@ -0,0 +1,267 @@
+$Id$
+
+TS6 Proposal (v7)
+Written by Lee H <lee@leeh.co.uk>
+
+Introduction
+------------
+
+This document aims to fix some of the flaws that are still present in the
+current TS system.
+
+Whilst only one person may use a nickname at any one time, they are not
+a reliable method of directing commands between servers. Clients can change
+their nicknames, which can create desyncs. A reliable method of directing
+messages between servers is required so that a message will always reach the
+intended destination, even if the client changes nicks in between.
+
+UID solves this problem by ensuring that a client has a unique ID for the
+duration of his connection.
+
+This document also aims to solve the lack of TS rules to channel 'bans' on
+a netburst. Bans from both sides of a TS war (losing/winning) are kept.
+Bursting the bans with a TS solves this problem.
+
+There is also a race condition in the current TS system, where a user can
+issue a mode during a netburst and the mode will be set on the server
+we are bursting to.
+
+
+Definitions
+-----------
+
+Throughout this document, the following terms are used:
+
+SID - A servers unique ID. This is three characters long and must be in
+ the form [0-9][A-Z0-9][A-Z0-9]
+ID - A clients unique ID. This is six characters long and must be in
+ the form [A-Z][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9]. The
+ numbers [0-9] at the beginning of an ID are legal characters, but
+ reserved for future use.
+UID - An ID concateneted to a SID. This forms the clients UID.
+TS6 - The TS version 6.
+
+
+Support
+-------
+
+Support for this document is given by the TS version 6.
+
+Wherever a destination parameter or source parameter is used, it must use
+the SID or UID if the server/client has one. A TS6 capable server must
+translate any SIDs/UIDs back into the server/clients name when communicating
+with a server that does not support TS6.
+
+A TS6 server must also support the QS (quitstorm) system, and the encap
+specification found here:
+http://www.leeh.co.uk/ircd/encap.txt
+
+The TS6 protocol does not supports masked entities.
+
+
+Nick TS rules
+-------------
+
+A server receiving a command that requires nick TS rules must check for a
+collision between an existing user, and the nick in the received message.
+(the "new user"). The collisions must obey the rules specified in Nick TS
+collisions.
+
+If the TS received is lower than the TS of the existing user the server will
+collide the existing user if the clients user@host are different, if the
+clients user@hosts are identical it will collide the new user.
+
+If the TS received is equal to the TS of the existing user both clients are
+collided.
+
+If the TS received is higher than the TS of the existing user, the server
+will collide the existing user if the user@hosts are identical, if the
+clients user@host are different it will collide the new user and drop the
+message.
+
+
+Nick TS collisions
+------------------
+
+If both users are to be collided, we must issue a KILL for the existing
+user to all servers. If the new user has a UID then we must also issue a
+KILL for that UID back to the server sending us data causing the collision.
+
+If only the existing user is being collided, we must issue a KILL for the
+existing user to all servers except the server sending us data. If the
+existing user has a UID and the server sending us data supports TS6 then
+we must also issue a KILL for the existing users UID to the server sending
+us data.
+
+If only the new user is being collided, we must issue a KILL for the new user
+back to the server sending us data if the new user has a UID.
+
+
+Channel TS rules
+----------------
+
+A server receiving a command that requires normal channel TS rules must
+apply the following rules to the command.
+
+If the TS received is lower than our TS of the channel a TS6 server must
+remove status modes (+ov etc) and channel modes (+nt etc). If the
+originating server is TS6 capable (ie, it has a SID), the server must
+also remove any ban modes (+b etc). The new modes and statuses are then
+accepted.
+
+If any bans are removed, the server must send to non-TS6, directly connected
+servers mode changes removing the bans after the command is propagated.
+This prevents desync with banlists, and has to be sent after as clients are
+still able to send mode changes before the triggering command arrives.
+
+If the TS received is equal to our TS of the channel the server should keep
+its current modes and accept the received modes and statuses.
+
+If the TS received is higher than our TS of the channel the server should keep
+its current modes and ignore the received modes and statuses. Any statuses
+given in the received message will be removed. A server must mark clients
+losing their op (+o) status who do not have a UID as 'deopped'. A server must
+ignore any "MODE" commands from a user marked as 'deopped'.
+
+
+Simple channel TS rules
+-----------------------
+
+A server receiving a command that requires simple channel TS rules must
+apply the following rules to the command.
+
+If the TS received is lower, or equal to our TS of the channel the modes are
+accepted. If the TS received is higher than our TS of the channel the modes
+are ignored and dropped.
+
+Simple channel TS rules do not affect current modes in the channel except
+for the modes we are accepting.
+
+
+The following commands are defined here as the TS6 protocol
+-----------------------------------------------------------
+
+PASS:
+PASS <PASSWORD> TS <TS_CURRENT> :<SID>
+
+This command is used for password verification with the server we are
+connecting to.
+
+Due to the burst being sent on verification of the "SERVER" command, and
+"SVINFO" being sent after "SERVER", we need to be aware of the TS version
+earlier to decide whether to send a TS6 burst or not.
+
+The <PASSWORD> field is the password we have stored for this server,
+<TS_CURRENT> is our current TS version. If this field is not present then
+the server does not support TS6. <SID> is the SID of the server.
+
+UID:
+:<SID> UID <NICK> <HOPS> <TS> +<UMODE> <USERNAME> <HOSTNAME> <IP> <UID> :<GECOS>
+
+This command is used for introducing clients to the network.
+
+The <SID> field is the SID of the server the client is connected to.
+The <NICK> field is the nick of the client being introduced. The <HOPS>
+field is the amount of server hops between the server being burst to and
+the server the client is on. The <TS> field is the TS of the client, either
+the time they connected or the time they last changed nick. The <UMODE>
+field contains the clients usermodes that need to be transmitted between
+servers. The <USERNAME> field contains the clients username/ident. The
+<HOSTNAME> field contains the clients host.
+
+The <IP> field contains the clients IP. If the IP is not to be sent
+(due to a spoof etc), the field must be sent as "0". The <UID> field is the
+clients UID. The <GECOS> field is the clients gecos.
+
+A server receiving a UID command must apply nick TS rules to the nick.
+
+SID:
+:<SID> SID <SERVERNAME> <HOPS> <SID> :<GECOS>
+
+This command is used for introducing servers to the network.
+
+The first <SID> field is the SID of the new servers uplink. The
+<SERVERNAME> field is the new servers name. The <HOPS> field is the hops
+between the server being introduced nd the server being burst to.
+
+The second <SID> field is the SID of the new server. The <GECOS> field i
+is the new servers gecos.
+
+Upon receiving the SID command servers must check for a SID collision.
+Two servers must not be allowed to link to the network with the same SID.
+If a server detects a SID collision it must drop the link to the directly
+connected server through which the command was received.
+
+Client and servers which do not have a UID/SID must be introduced by old
+methods.
+
+SJOIN:
+:<SID> SJOIN <TS> <CHANNAME> +<CHANMODES> :<UIDS>
+
+This command is used for introducing users to channels.
+
+The <SID> field is the SID of the server introducing users to the channel.
+The <TS> field is the channels current TS, <CHANNAME> is the channels
+current name, <CHANMODES> are the channels current modes. <UIDS> is a
+space delimited list of clients UIDs to join to the channel. Each clients
+UID is prefixed with their status on the channel, ie "@UID" for an opped
+user. Multiple prefixes are allowed, "peons" (clients without a status) are
+not prefixed.
+
+A server receiving an SJOIN must apply normal channel TS rules to the SJOIN.
+
+A TS6 server must not use the SJOIN command outside of a netburst
+to introduce a single user to an existing channel. It must instead
+use the "JOIN" command defined in this specification. A TS6 server must
+still use SJOIN for creating channels.
+
+JOIN:
+:<UID> JOIN <TS> <CHANNAME> +<CHANMODES>
+
+This command is used for introducing one user unopped to an existing channel.
+
+The <UID> field is the UID of the client joining the channel. The
+<TS> field is the channels current TS, <CHANNAME> is the channels
+current name, <CHANMODES> are the channels current modes.
+
+A server receiving a JOIN must apply normal channel TS rules to the JOIN.
+
+It should be noted that whilst JOIN would not normally create a
+channel, during specific race conditions it can. This can create
+a ban desync that this specification does not rectify.
+
+BMASK:
+:<SID> BMASK <TS> <CHANNAME> <TYPE> :<MASKS>
+
+This command is used for bursting channel bans to a network.
+
+The <SID> field is the SID of the server bursting the bans. The
+<TS> field is the channels current TS, <CHANNAME> is the channels
+name. <TYPE> is a single character identifying the mode type (ie,
+for a ban 'b'). <MASKS> is a space delimited list of masks of the
+given mode,limited only in length to the size of the buffer as defined
+by RFC1459.
+
+A server receiving a BMASK must apply simple channel TS rules to the BMASK.
+
+A TS6 server must translate BMASKs into raw modes for non-TS6
+capable servers. This command must be used only after SJOIN has
+been sent for the given channel.
+
+It should be noted however, that a BMASK with a lower TS should
+not be possible without a desync, due to it being sent after
+SJOIN.
+
+TMODE:
+:<UID> TMODE <TS> <CHANNAME> <MODESTRING>
+
+This command is used for clients issuing modes on a channel.
+
+<UID> is the UID of the client setting the mode. <TS> is the
+current TS of the channel, <CHANNAME> is the channels name.
+<MODESTRING> is the raw mode the client is setting.
+
+A server receiving a TMODE must apply simple channel TS rules to the TMODE.
+
+A TS6 server must translate MODEs issued by a local client into TMODE
+to send to other TS6 capable servers.
generated by cgit (git 2.34.1) at 2025-05-11 19:16:50 +0000