Mercurial > pidgin.yaz
changeset 2285:8573faeb9298
[gaim-migrate @ 2295]
it's easier to do things with them in the right directories
committer: Tailor Script <tailor@pidgin.im>
| author | Eric Warmenhoven <eric@warmenhoven.org> |
|---|---|
| date | Sat, 15 Sep 2001 21:15:36 +0000 |
| parents | 83c7123e5a7e |
| children | f00bf9537bb7 |
| files | doc/MSN-PROTOCOL doc/PROTOCOL doc/rfc1459.txt src/protocols/irc/rfc1459.txt src/protocols/msn/PROTOCOL src/protocols/toc/PROTOCOL |
| diffstat | 6 files changed, 5322 insertions(+), 5322 deletions(-) [+] |
line wrap: on
line diff
--- a/doc/MSN-PROTOCOL Sat Sep 15 19:32:51 2001 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,1180 +0,0 @@ -Some other notes not contained in this spec. -REA TrID UserHandle FriendlyName - will change your friendly name - ---- -Instant Messaging and Presence Protocol R. Movva -Internet Draft Microsoft -Category: Informational August, 1999 -Document: draft-movva-msn-messenger-protocol-00.txt -Document Expires: 2/00 W. Lai - Microsoft - August, 1999 - - - - MSN Messenger Service 1.0 Protocol - - - -Status of this Memo - - This document is an Internet-Draft and is NOT offered in accordance - with Section 10 of RFC2026, and the author does not provide the IETF - with any rights other than to publish as an Internet-Draft. - - 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 document and related documents are discussed on the impp - mailing list. To join the list, send mail to impp- - request@iastate.edu. To contribute to the discussion, send mail to - impp@iastate.edu. The archives are at http://lists.fsck.com/cgi- - bin/wilma/pip. The IMPP working group charter, including the current - list of group documents, can be found at - http://www.ietf.org/html.charters/impp-charter.html. - - - -1. Abstract - - Microsoft released a commercial Instant Messaging product in July of - 1999 called MSN Messenger Service. This document describes the - protocol used by that product for core instant messaging and - presence functionality. While this protocol does not meet many of - the requirements of the IMPP working group, it is provided as - background information on existing Instant Messaging - implementations. This protocol is provided 'as is' without warranty - of any kind. - - -Movva and Lai Category - Informational 1 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - -2. Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in - this document are to be interpreted as described in RFC-2119. - - Protocol messages sent from client to server are preceded by "C:". - - Protocol messages sent from server to client are preceded by "S:". - - - -3. Introduction - - MSN Messenger Service enables a user to learn about the presence of - other people on the Internet, and to communicate with them in real- - time. This functionality is commonly referred to as "Instant - Messaging" (IM). - - This document describes the syntax and semantics of the MSN - Messenger Protocol, the communication protocol running between MSN - Messenger Service 1.0 clients and servers. Among the core services - that the MSN Messenger Servers provide to clients are: - - - Authenticated user logon. - - Adding and deleting members of the user's contact list. - - Changing the user's on-line state. - - Receipt of asynchronous, real-time, on-line state change - notifications from members of the user's contact list. - - Delivering lightweight, real-time messages to other users. - - Receipt of asynchronous, real-time messages from other users. - - Configuring the user's access permissions, to restrict the ability - of other users to view the user's on-line state or send messages - to the user. - - Additional background: - - 1. Some features extraneous to core instant messaging functionality - contained within the MSN Messenger Service 1.0 protocol are beyond - the scope of this document. Examples include client version - management and directory functionality. - - 2. The purpose of this document is to provide the members of the - IMPP working group with a reference implementation of a "monolithic" - IM system. That is, a system designed for massive scale, but not yet - capable of communication with servers other than those associated - with this specific service. Since any standard in this area will of - necessity be a "distributed" design that explicitly enables server- - to-server and service-to-service communication, this document will - serve primarily as a reference and example of one implementer's - choices when providing IM functionality at scale. - - -Movva and Lai Category - Informational 2 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - 3. This document reflects the protocol used in the 1.0 release of - MSN Messenger clients and servers, deployed on the Internet in July - of 1999. However, the service is in production and rapidly growing, - which almost certainly will necessitate changes to the protocol as - Microsoft gains operational experience with the service and expands - its feature set. This Internet Draft may not be updated with such - changes, and the changes may be made with little or no notice. - - - -4. MSN Messenger Server Component Overview - - MSN Messenger Service clients make connections to several different - kinds of servers. They are separate components to facilitate running - at scale - each component can be duplicated an arbitrary number of - times, independently of each other, to enable large numbers of - users. - -4.1 Dispatch Server (DS) - - The Dispatch Server is the initial point of connection between - client and server. Its primary functions are protocol version - negotiation, determination of which Notification Server (NS) is - associated with the client making a connection (via an algorithm of - the server's choosing), and referring the client to the proper NS. - -4.2 Notification Server (NS) - - The Notification Server is the primary server component. The client - and the Notification Server authenticate, synchronize user - properties, and exchange asynchronous event notifications. The - client's connection to the Notification Server occurs after the - referral from the Dispatch Server is completed, and persists without - interruption during the user's MSN Messenger Service session. - - Some of the events transmitted between a client and a Notification - Server are: State changes (e.g. client is on-line, client is - offline, client is idle), Switchboard Server invitation requests - (see below), and application-specific notifications that are beyond - the scope of this document. (E.g. new e-mail has arrived) - -4.3 Switchboard Server (SS) - - The Switchboard Server is the component through which clients can - establish lightweight communication sessions without requiring a - direct network connection between clients. The common usage of the - Switchboard Server is to provide instant messaging sessions. - When a client wishes to communicate with another client, it sends a - message to its Notification Server, which then refers the client to - a Switchboard Server. Once the SS connection is established, the - "destination" client receives a notification from its NS to connect - to the same SS. - - -Movva and Lai Category - Informational 3 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - -5. Protocol Conventions - -5.1 Connection Type - - The MSN Messenger Protocol currently works over TCP/IP. The MSN - Messenger server components support connections over port numbers - 1863, which is the registered port number assigned by the IANA - (http://www.isi.edu/in-notes/iana/assignments/port-numbers). - -5.2 Command Syntax - - MSN Messenger Protocol command syntax is ASCII and single line- - based. Commands begin with a case-sensitive, three-letter command - type, followed by zero or more parameters, and terminated by CRLF. - Parameters are separated by one or more whitespace characters and - cannot contain whitespace characters. Parameters that contain spaces - or extended (non 7-bit ASCII) characters should be encoded using - URL-style encoding (e.g. "%20" for space). Some commands accept un- - encoded binary data. In these cases, the length of the data is - transmitted as part of the command, and the data is transmitted - immediately following a CRLF of the command. - -5.3 Asynchronous Requests - - Commands issued from the client to the server that result in a reply - are known as requests. Requests are entirely asynchronous. The - client can submit several requests in sequence without waiting for - the server response after submitting each request. The server is - required to deliver a response or an error for each request - received, but it is not required to deliver the responses in the - same order as the requests were received. The client can determine - the request associated with a particular response by examining the - Transaction ID parameter (described below). - -5.4 User Handles - - MSN Messenger Protocol uses User Handles for identifying users. A - user handle (also known as "account name" and "logon name") is a - text representation of the user's identity that is both unique and - persistent. The user handle is syntactically equivalent to an e-mail - address, and as such is subject to the same restrictions for - character set, as described in RFC-822. Most notable among these - restrictions are the limitation to Latin alphanumeric characters and - a few symbols. The maximum acceptable length of the user handle is - 129 bytes. - - Implementation note: In the initial release of the client and - server, user handles are Hotmail account names. All user handles - must contain the "@hotmail.com" domain name, and user handles that - do not contain a domain name are not valid. - -5.5 Custom User Names - - -Movva and Lai Category - Informational 4 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - A custom user name (also known as "custom name" and "friendly name") - is a user's representation of the "friendly" textual name associated - with a user handle. (E.g. "Auntie Em" instead of em123@hotmail.com). - Custom user names are neither unique nor persistent, and can contain - any valid Unicode characters. Custom user names are represented in - UTF-8 as described in RFC-2044 and URL-encoded as described in RFC- - 1738 when transmitted between the client and server. The maximum - acceptable length of the encoded custom user name is 387 in the - current implementation. - -5.6 Transaction Identifiers - - The Transaction Identifier (a.k.a. Transaction ID) is a numeric - string representing a number between 0 and (2^32 - 1). It is a value - that a client includes with any command that it issues to the - server. In the current version of the protocol, the transaction - identifier is used to associate server responses with client-issued - commands. The server treats the transaction ID as an opaque number - and does not assume any relationship between successive Transaction - - IDs or any particular starting Transaction ID. It is the client's - responsibility to guarantee the uniqueness of the Transaction IDs - for the purpose of disambiguating the commands and/or responses. (A - future version of the protocol could enable the client to track the - status or cancel a particular transaction using the transaction ID.) - - When the server sends the response to a command to the client, it - must include in the response the transaction ID that the client sent - to the server when the client originally issued the command. In - cases where a server sends a command to a client that requires a - transaction ID but is not in response to a specific client command, - it will use 0 as the transaction ID. In cases where a server sends - multiple responses to a single client request, the server will use - the same transaction ID in each response. - -5.7 User List Types - - Some of the protocol commands are used to the manipulate lists of - users. The following types of user lists are supported by the - protocol: - - Forward List (FL) - The list of users for whom a given user wants to - receive state change notifications. The Forward List is what is most - commonly referred to as the user's "contact list." - - Reverse List (RL) - The list of users who have registered an - interest in seeing this user's state change notifications. - - Allow List (AL) - The list of users who the user has explicitly - allowed to see state change notifications and establish client-to- - client sessions via a Switchboard Server. - - - -Movva and Lai Category - Informational 5 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - Block List (BL) - The list of users who the user has explicitly - prevented from seeing state change notifications and establishing - client-to-client sessions via a Switchboard Server. - - - -6. Command Summary Table - - Command From To Description - ================================================================== - ACK Switchboard Client Sends a positive message - delivery acknowledgement. - ------------------------------------------------------------------- - ADD Client Notification Adds to the user's FL, AL, - Notification Client and BL. Notifies the client - of asynchronous additions - to a user's list. - ------------------------------------------------------------------- - ANS Client Switchboard Accepts a request for a - switchboard server session. - ------------------------------------------------------------------- - BLP Client Notification Changes the user's message - Notification Client privacy setting, which - determines how to treat - messages from users not - already in the BL or AL. - ------------------------------------------------------------------- - BYE Switchboard Client Notifies a client that a - user is no longer in the - session. - ------------------------------------------------------------------- - CAL Client Switchboard Initiates a switchboard - server session. - ------------------------------------------------------------------- - CHG Client Notification Sends a client state change - Notification Client to the server. - Echoes the success of - client's state change - request. - ------------------------------------------------------------------- - FLN Notification Client Notifies the client when - users in the FL go off- - line. - ------------------------------------------------------------------- - GTC Client Notification Changes the user's prompt - Notification Client setting, which determines - how the client reacts to - certain RL changes. - ------------------------------------------------------------------- - INF Client Dispatch, Requests set of support - Notification authentication protocol - Dispatch, Client from the server. - Notification Provides the set of - -Movva and Lai Category - Informational 6 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - supported authentication - protocols to the client. - ------------------------------------------------------------------- - ILN Notification Client Notifies the client of the - initial online state of a - user in the FL, while - either logging on or adding - a user to the FL. - ------------------------------------------------------------------- - IRO Switchboard Client Provides the initial roster - information for new users - joining the session. - ------------------------------------------------------------------- - JOI Switchboard Client Notifies a client that a - user is now in the session. - ------------------------------------------------------------------- - LST Client Notification Retrieves the server's - Notification Client version of the user's FL, - RL, AL, or BL. - ------------------------------------------------------------------- - MSG Client Switchboard Sends a message to the - members of the current - session. - ------------------------------------------------------------------- - MSG Notification, Client Delivers a message from - Switchboard another client or from a - server-side component. - ------------------------------------------------------------------- - NAK Switchboard Client Sends a negative message - delivery acknowledgement. - ------------------------------------------------------------------- - NLN Notification Client Notifies the client when - users in the FL go on-line - or when their on-line state - changes. - ------------------------------------------------------------------- - OUT All All Ends a client-server - Session. - ------------------------------------------------------------------- - REM Client Notification Removes from the user's FL, - Notification Client AL, and BL. - Notifies the client of - asynchronous removals from - a user's list. - ------------------------------------------------------------------- - RNG Notification Client Notifies the client of a - request by another client - to establish a session via - a switchboard server. - ------------------------------------------------------------------- - SYN Client Notification Initiates client-server - Notification Client property synchronization. - ------------------------------------------------------------------- - -Movva and Lai Category - Informational 7 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - USR All All Authenticates client with - server, possibly in - multiple passes. - ------------------------------------------------------------------ - VER Client Dispatch Negotiates common protocol - Dispatch Client dialect between client and - Server. - ------------------------------------------------------------------ - XFR Client Notification Requests a Switchboard - Notification Client server for use in - establishing a session. - ------------------------------------------------------------------- - XFR Dispatch Client Notification of login-NS to - Notification Client the client or notification - to move to a different NS. -======================================================================= - - - -7. Presence and State Protocol Details - - This is a detailed list of protocol commands associated with - presence functionality. They are defined in the order used by - clients. Commands associated with instant messages are discussed in - section 8 below. - -7.1 Protocol Versioning - - After the client connects to a dispatch server by opening a TCP - socket to port 1863, the client and server agree on a particular - protocol version before they proceed. The Client-Server protocol - version handshake involves the following command exchange: - - C: VER TrID dialect-name{ dialect-name...} - S: VER TrID dialect-name - - The client can provide multiple dialect names in preferred order. - The dialect-name parameter returned by the server is the version - server is designating for this connection - - The current protocol dialect-name supported by Messenger servers is - "MSNP2". The dialect names are not case-sensitive. - - The string "0" is a reserved dialect name and is used to indicate a - failure response. E.g.: - - S: VER TrID 0{ dialect-name ... } - -7.2 Server Policy Information - - The client next queries the server for variable "policy" - information. In this version of the protocol, the only policy - - -Movva and Lai Category - Informational 8 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - information returned by the server is the authentication package in - use. - - C: INF TrID - S: INF TrID SP{,SP...} - - SP identifies a security package - the name of the SASL mechanism to - use for authentication. "MD5" is used by the Notification Server, - "CKI" by the Switchboard Server. - -7.3 Authentication - - The client needs to authenticate itself after protocol version - handshake and identifying the security packages supported on the - server. The following are the client server interactions involved. - - C: USR TrID SP I{ AuthInitiateInfo} - S: USR TrID SP S{ AuthChallengeInfo} - C: USR TrID SP S{ AuthResponseInfo } - S: USR TrID OK UserHandle FriendlyName - - The SP parameter is the name of the security package("MD5"). The - next parameter is a sequence value, which must be I to (I)nitiate - the authentication process and S for all (S)ubsequent messages. If - authentication fails on the server, the client can start the - authentication process again. - - For the MD5 security package: - - The AuthInitiateInfo parameter provided by the client must be the - User handle. - - The AuthChallengeInfo parameter returned by the server contains a - challenge string. - - The AuthResponseInfo contains the binary response as a hexadecimal - string, which the MD5 hash of the challenge and the User password - strings concatenated together. - - The final response from the server contains, in addition to the user - handle, the current "Friendly Name" associated with the user handle. - This is a "Custom User Name" as described above. - -7.4 Referral - - There are three cases in which clients are referred from one server - to another: - - 1. The initial "Dispatch Server" refers the client to the - Notification Server to which it is assigned. - 2. Asynchronous referral by the Notification Server to reassign the - client to a different Notification Server if that server is - overloaded or undergoing maintenance. - 3. During Switchboard Session establishment, the assigned - Notification Server refers the client to a particular - switchboard server for use. This is discussed below. - -Movva and Lai Category - Informational 9 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - - In the current implementation the Dispatch Server uses the user - handle provided in the initial USR command above to assign the user - in question to a Notification Server. Alternate implementations - might not require referral at this stage. - - If received, referral is of the form: - - S: XFR TrID ReferralType Address[:PortNo] - - ReferralType is either "NS" or "SB" and defines the type of referral - to a Notification Server or Switchboard Server. - Address is a valid DNS name or IP address to a referred server, with - optional port# suffixed as ":PortNo". - - If this command is received from the server, the client should - attempt to log in to the server provided. - - In the case of "NS" referrals during logon, the Server automatically - closes the client connection after sending this XFR response so that - the client can connect to the new IP Address. - - If sent asynchronously, the client is responsible for closing the - connection. - - After a "NS" referral, the client will not receive any more messages - from the "old" NS, and also must not send any commands to the "old" - NS after receiving an XFR. - -7.5 Client User Property Synchronization - - Several of the user properties used by the Messenger application are - stored on the server. This is done for two reasons: - - 1) So that users can "roam", i.e. log in from different locations - and still have the appropriate data, such as their contact lists and - privacy settings. - 2) If changes occur to a user's Reverse List while that user was - offline (the user was added to another user's list), the client can - be updated with this information. - - For performance reasons it is useful to cache these properties on - the client, so that bandwidth usage is minimized in the typical case - where the user is not roaming and there were no Reverse List - changes. - - These requirements are met by the SYN command - synchronization. - - Once a client logs in successfully, it uses the SYN command to - ensure it has the latest version of the server-stored properties. - These properties include: Forward List, Reverse List, Block List, - Allow List, GTC setting (privacy setting when someone adds this user - to their Forward List), and BLP setting (the user's privacy mode). - -Movva and Lai Category - Informational 10 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - - The SYN command is: - - C: SYN TrID Ser# - S: SYN TrID Ser# - - The Ser# parameter sent by the client is the version of the - properties currently cached on the client. The server responds with - the current server version of the properties. If the server has a - newer version, the server will immediately follow the SYN reply by - updating the client with the latest version of the user properties. - These updates are done as described below, and are done without the - client explicitly initiating a LST, GTC or BLP command. Note that - the server will update all server-stored properties to the client, - regardless of how many entries have been changed. - - The following "List Retrieval and Property Management" section - describes the format of the user properties sent by the server. - After the SYN reply from the server, the user property updates will - be sent from the server in this sequence: GTC, BLP, LST FL, LST AL, - LST BL, LST RL. - - All the user property updates will share the same TrID as the SYN - command and reply. - -7.6 List Retrieval And Property Management - - Synchronizing can result in a batch of user properties and lists - getting sent by the server to the client. However, the client - application can also initiate a request to retrieve the server- - stored lists and properties. The following are the privacy property - and list retrieval commands. The response formats are the same - whether it is a client-initiated request, or whether it is a - response to the SYN process as described above. - - - List Command - - By issuing the LST command, the client can explicitly request that a - list be sent. The server will respond with a series of LST - responses, one LST response for each item in the requested list. - - C: LST TrID LIST - S: LST TrID LIST Ser# Item# TtlItems UserHandle CustomUserName - - - LIST is FL/RL/AL/BL for Forward List, Reverse List, Allow List, - and Block List, respectively. - - The Item# parameter contains the index of the item described in - this command message. (E.g. item 1 of N, 2 of N, etc.) - - The TtlItems parameter contains the total number of items in this - list. - - UserHandle is the user handle for this list item. - - CustomUserName is the friendly name for this list item. - - -Movva and Lai Category - Informational 11 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - If the list is empty, the response will be: - - S: LST TrID LIST Ser# 0 0 - - Reverse List Prompting - - The client can change its persistent setting for when to prompt the - user in reaction to an Reverse List change. This is accomplished via - the GTC command: - - C: GTC TrID [A | N] - S: GTC TrID Ser# [A | N] - - The value of the A/N parameter determines how the client should - behave when it discovers that a user is in its RL, but is not in its - AL or BL. (Note that this occurs when a user has been added to - another user's list, but has not been explicitly allowed or - blocked): - - A - Prompt the user as to whether the new user in the RL should be - added to the AL or the BL - N - Automatically add the new user in the RL to the AL - - The A/N parameter is not interpreted by the server, merely stored. - - The server will respond with the current setting if the change was - successful. Otherwise, it will return an error with the matching - TrID. If the client tries to change the setting to the same value as - the current setting, the server will respond with an error message. - - The default setting is A when a new user connects to the server for - the first time. - - Privacy Mode - - The client can change how the server handles instant messages from - users via the BLP command: - - C: BLP TrID [AL | BL] - S: BLP TrID Ser# [AL | BL] - - The AL/BL parameter determines how the server should treat messages - (MSG and RNG) from users. If the current setting is AL, messages - from users who are not in BL will be delivered. If the current - setting is BL, only messages from people who are in the AL will be - delivered. - - The server will respond with the current setting if the change was - successful. Otherwise, it will return an error with the matching - TrID. If the client tries to change the setting to the same value as - the current setting, the server will respond with an error message. - - - -Movva and Lai Category - Informational 12 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - The default setting is AL when a new user connects to the server for - the first time. - - -7.7 Client States - - After the client is authenticated and synchronized, the client - establishes its initial state with the server with the CHG command. - The syntax of the command is: - - C: CHG TrID State - S: CHG TrID State - - When the state is changed, the server will echo the settings back to - client. The state shall not be considered changed until the response - is received from the server. - - Note that the server can send a state change message to the client - at any time. If the server changes the state without a request from - the client, the TrID parameter will be 0. - - States are denoted by a string of three characters. The predefined - states that the server recognizes are: - - NLN - Make the client Online (after logging in) and send and receive - notifications about buddies. - FLN - Make the client Offline. If the client is already online, - offline notifications will be sent to users on the RL. No message - activity is allowed. In this state, the client can only synchronize - the lists as described above. - HDN - Make the client Hidden/Invisible. If the client is already - online, offline notifications will be sent to users on the RL. The - client will appear as Offline to others but can receive - online/offline notifications from other users, and can also - synchronize the lists. Clients cannot receive any instant messages - in this state. - - All other States are treated as sub-states of NLN (online). The - other States currently supported are: - BSY - Busy. - IDL - Idle. - BRB - Be Right Back. - AWY - Away From Computer. - PHN - On The Phone. - LUN - Out To Lunch. - -7.8 List Modifications - - The protocol supports generic commands to add and remove users from - various lists. This is used by clients to enable "Adding" contacts - to the list of folks being watched, or for the "Block" and "Allow" - features that define how users chooses to interact with one another. - - -Movva and Lai Category - Informational 13 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - However, these generic commands have different semantics based on - the list being modified. For example, only the server can add or - remove entries from the Reverse List - since it is an indirect - consequence of the user having been added to another user's Forward - List. - - The add and remove commands: - - C: ADD TrID LIST UserHandle CustomUserName - S: ADD TrID LIST ser# UserHandle CustomUserName - - C: REM TrID LIST UserHandle - S: REM TrID LIST ser# UserHandle - - Valid values for LIST in Client initiated adds and removes are - FL/AL/BL. - - All client initiated adds and removes will be echoed by the server - with a new serial number that should be persisted by the client - along with the list modification. If not successful, an error will - result. - - The protocol also supports the concept of an ADD or REM that the - client did not initiate. Server generated ADDs and REMs can have - LIST values of FL/AL/BL/RL. This is common with RL changes, which - are never initiated by the client, but is an indirect consequence of - this user having been added to someone's Forward List. If the RL - change happens while the user is online, it will trigger an - asynchronous ADD or REM command from the server. - - Asynchronous ADDs and REMs to the FL, AL, and BL can happen when the - server allows an authenticated user to make list changes from - another environment, such as a web site. In all of these cases, the - server will send the ADD or REM command with the TrID parameter - equal to 0. - -7.9 Notification Messages - - The client receives asynchronous notifications whenever a contact on - the user's Forward List changes its state. The notifications are of - the form: - - S: NLN Substate UserHandle FriendlyName - S: ILN TrID Substate UserHandle FriendlyName - S: FLN UserHandle - - NLN indicates that a user has come online. - - Substate can be any three-letter code (see "Client States" above). - - UserHandle and FriendlyName are the handle and names associated - with the user coming online. - - ILN is similar to the NLN message, and is received from the server - in response to an CHG or ADD command from the client: - -Movva and Lai Category - Informational 14 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - - 1. Immediately after the client logon and sends its first CHG - command to the NS. In this case several ILNs may be received - - one for each Forward List contact that is currently online. - 2. After the client sends an "ADD TrID FL UserHandle - CustomUserName" to the NS. (e.g. ILN for the new contact if that - contact is currently online) - - In both cases, TrID in the ILN is the same as the one sent by the - client in the CHG or ADD command. - - FLN means that the specified user is now offline. - -7.10 Connection Close - - The client issues the following command to logoff from the NS: - - C: OUT - S: OUT {StatusCode} - - The server will reply with an OUT to the client before it initiates - a disconnect, with an optional StatusCode. - - The StatusCode can be "OTH", which indicates that a client with the - same user handle and password has logged on to the server from - another location, or "SSD" meaning the server is being shut down for - maintenance. - - The server will drop the connection after sending the OUT. - -7.11 Error Information - - Error messages from the server are of the format: - - S: eee {TrID} {(error-info) {param...}} - - eee is a 3 digit decimal number indicating the error code. Error- - info contains the description of the error in a text string - localized to the server's locale. The optional parameters provide - indication of the client command causing the error. TrID is the - Transaction ID of the client command that caused this error. Any - server generated errors will not have Transaction IDs. - - - ERR_SYNTAX_ERROR 200 - ERR_INVALID_PARAMETER 201 - ERR_INVALID_USER 205 - ERR_FQDN_MISSING 206 - ERR_ALREADY_LOGIN 207 - ERR_INVALID_USERNAME 208 - ERR_INVALID_FRIENDLY_NAME 209 - ERR_LIST_FULL 210 - ERR_ALREADY_THERE 215 - -Movva and Lai Category - Informational 15 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - ERR_NOT_ON_LIST 216 - ERR_ALREADY_IN_THE_MODE 218 - ERR_ALREADY_IN_OPPOSITE_LIST 219 - ERR_SWITCHBOARD_FAILED 280 - ERR_NOTIFY_XFR_FAILED 281 - - ERR_REQUIRED_FIELDS_MISSING 300 - ERR_NOT_LOGGED_IN 302 - ERR_INTERNAL_SERVER 500 - ERR_DB_SERVER 501 - ERR_FILE_OPERATION 510 - ERR_MEMORY_ALLOC 520 - ERR_SERVER_BUSY 600 - ERR_SERVER_UNAVAILABLE 601 - ERR_PEER_NS_DOWN 602 - ERR_DB_CONNECT 603 - ERR_SERVER_GOING_DOWN 604 - ERR_CREATE_CONNECTION 707 - ERR_BLOCKING_WRITE 711 - ERR_SESSION_OVERLOAD 712 - ERR_USER_TOO_ACTIVE 713 - ERR_TOO_MANY_SESSIONS 714 - ERR_NOT_EXPECTED 715 - ERR_BAD_FRIEND_FILE 717 - ERR_AUTHENTICATION_FAILED 911 - ERR_NOT_ALLOWED_WHEN_OFFLINE 913 - ERR_NOT_ACCEPTING_NEW_USERS 920 - - - -8. Session based Instant Messaging Protocol Details - - MSN Messenger Service utilizes a lightweight, session-based - messaging scheme. In order for two clients to exchange instant - messages, they must first establish a common session via a - Switchboard Server. They can invite additional clients to join the - established session. - -8.1 Referral to Switchboard - - This process begins with a "calling" client requesting a referral - from its Notification Server to a Switchboard Server: - - C: XFR TrID SB - S: XFR TrID SB Address SP AuthChallengeInfo - - - SB is the type of referral being requested or granted. - - Address is the DNS name or IP address of a Switchboard Server that - has been assigned, and that the client should connect to. - - SP is the Security Package being used. In this version of the - protocol it is "CKI" only. - - AuthChallengeInfo is a cookie that the client needs to present to - the Switchboard server for authentication. - - -Movva and Lai Category - Informational 16 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - -8.2 Switchboard Connections and Authentication - - After the XFR reply is received, the client makes a TCP/IP - connection to the Switchboard server using port 1863. Note that a - lack of version negotiation in the switchboard connection is a - limitation of the current implementation. - - The client first needs to authenticates with the Switchboard Server: - - C: USR TrID UserHandle AuthResponseInfo - S: USR TrID OK UserHandle FriendlyName - - - AuthResponseInfo is the cookie for CKI security package returned - by the Notification Server in the XFR. - - UserHandle and FriendlyName are the Switchboard's echoes of the - user handle and friendly name of the user. - -8.3 Inviting Users to a Switchboard Session - - Any user in a Switchboard session can invite other users to join the - session. The CAL command is sent to the Switchboard server for this - purpose: - - C: CAL TrID UserHandle - S: CAL TrID Status SessionID - - The Messenger servers verify that the calling user has permissions - to contact the called user, with consideration given to the called - user's privacy settings and its online state. If instant messaging - with this user is not allowed, the server responds to the calling - user with an error. If it is allowed, the Switchboard server causes - a RNG command to be sent to the called client (see below), and - returns a CAL echo to the calling client. The CAL echo has these - parameters: - - - Status is a predefined status code - in this implementation it - must be "RINGING". - - SessionID is the ASCII representation of a decimal number that - uniquely identifies this session on the Switchboard Server. - -8.4 Getting Invited to a Switchboard Session - - The other side of the session establishment is the behavior of the - called client. The called client receives a RNG from its - Notification Server and is expected to connect to the Switchboard - Server and respond with an ANS. - - The client receives a RNG from the Notification Server as follows: - - S: RNG SessionID SwitchboardServerAddress SP AuthChallengeInfo - CallingUserHandle CallingUserFriendlyName - - - SessionID is a numeric ASCII session ID. - -Movva and Lai Category - Informational 17 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - - SwitchboardServerAddress is a DNS name or IP Address - - SP is the security package in use. In this implementation only - "CKI" is supported. - - AuthChallengeInfo is the cookie to be passed back to the - switchboard to gain entrance to the session. - - CallingUserHandle is the user handle of the caller. - - CallingUserFriendlyName is the custom user name of the caller. - - To join the session, the called client connects to the Switchboard - Server and carries out the following exchange to join the session: - - C: ANS TrID LocalUserHandle AuthResponseInfo SessionID - S: IRO TrID Participant# TotalParticipants UserHandle - FriendlyName - S: ANS TrID OK - - The IRO commands relay to the newly joined client roster information - about the current session. Each IRO command message from the - Switchboard contains one participant in the session. - - Participant# contains the index of the participant described in - this IRO command (e.g. 1 of N, 2 of N). - - TotalParticipants contains the total number of participants - currently in the session. - - The entire session roster will be sent to the new client joining the - session before any JOI or BYE commands described below. - - If no one is in the session when the user joins (an unexpected error - condition), the server skips directly to "ANS TrID OK" command. All - the responses from the server related to the issued ANS command will - contain the same TrID as the original client ANS request. - -8.5 Session Participant Changes - - When a new user joins a Switchboard session, the server sends the - following command to all participating clients, including the client - joining the session: - - S: JOI CalleeUserHandle CalleeUserFriendlyName - - - CalleeUserHandle is the user handle of the new participant. - - CalleeUserFriendlyName is the Custom User Name of the new - participant. - - If a client's connection with the Switchboard Server is dropped for - any reason, the server sends the following command to the remaining - clients in the session: - - S: BYE CalleeUserHandle - - - CalleeUserHandle is the user handle of the participant that left - the session. - - -Movva and Lai Category - Informational 18 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - Privacy Note: - If the client moved a contact to the BL while Switchboard sessions - are active, it is the client's responsibility to leave any session - that should now be blocked. The servers only enforce privacy - permissions when inviting users to a session. Further, the servers - only enforce privacy permission with respect to the calling user, - and not the other participants in a Switchboard session. Therefore, - in a multipoint session, it is possible for a user to participate in - a session with someone whom he has blocked, if a third party is - performing the invitation. - -8.6 Leaving a Switchboard Session - - When a client wishes to disconnect from the session, it sends the - following command and waits for the Switchboard to close the - connection: - - C: OUT - -8.7 Instant Messages - - Sending an Instant Message - - Once a client-to-client session has been established via the - Switchboard Server, sending an Instant Message to the participants - of the session is done as follows: - - C: MSG TrID [U | N | A] Length\r\nMessage - S: NAK TrID - S: ACK TrID - - U, N, and A correspond to the three delivery acknowledgement modes: - Unacknowledged, Negative-Acknowledgement-Only, and Acknowledgement. - Depending on the value of this parameter, either nothing, NAK, or - ACK will be sent back by the Switchboard Server to the client. - - For Unacknowledged mode, the Switchboard Server does not respond to - the sending client with the success or failure of message delivery. - - For Negative-Acknowledgement-Only mode, the Switchboard Server - responds to the send client only if the message could not be - delivered to the recipient client. - - Acknowledgement mode is not currently implemented. - - Length is the length of the Message parameter in bytes, whereas - Message is the actual message as described below. - -8.8 Receiving an Instant Message - - A client can receive a system-generated message from the - Notification Server, or it can receive an instant message from - - -Movva and Lai Category - Informational 19 - - MSN Messenger Service 1.0 Protocol Aug - 99 - - - another client via a Switchboard Server. The message is received in - the following format: - - S: MSG UserHandle FriendlyName Length\r\nMessage - - The UserHandle and FriendlyName are those of the sending user. - Length is the length of the message in bytes. - - Message is a MIME encoded stream, using a standard MIME header as - defined by RFC-1521 and RFC-822. - - Message is constructed as: - - MIME-Header\r\nMIME-Header\r\n\r\nMessageData - - MIME-Header is constructed as: - - string": "string - (E.g. "Content-Type: text/plain") - - The Content-Type MIME headers that the current client will use and - recognize are: - - "text/plain;charset=UTF-8" - "text/plain" - - If "charset=UTF-8" appears at the end of the Content-Type, the - Message Data is UTF-8 encoded. - - Note: The Switchboard Server does not interpret the contents of the - Message. - - - -9. Author's Addresses - - Ramu Movva - Microsoft Corporation - One Microsoft Way - Redmond WA 98052 - ramum@microsoft.com - - William Lai - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - wlai@microsoft.com - - - -Movva and Lai Category - Informational 20
--- a/doc/PROTOCOL Sat Sep 15 19:32:51 2001 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,499 +0,0 @@ -# Copyright (c) 1998-9 America Online, Inc. All Rights Reserved. -# -# This program is free software; you can redistribute it and/or -# modify it under the terms of the GNU General Public License -# as published by the Free Software Foundation; either version 2 -# of the License, or (at your option) any later version. -# -# This program is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. - -# Note from Jim Duchek, gaim maintainer -- this may not be the latest -# version of this document, I provide it as a service. Download a copy -# of TiK (http://www.aim.aol.com/tik/) for the latest version of this -# doc. - -# Note from Eric Warmenhoven, random guy -- this appears to be the last -# published version of the protocol, and AOL has stopped hosting the TiK -# program. TiK is still being maintained and is hosted on sourceforge.net; -# this appears to be the same version of the protocol they're using. - -Version: TOC1.0 - -This document describes the protocol between TOC and TOC clients. -The protocol is built on TCP. Framing is done by SFLAP, -described at the bottom of this document. Inside each -SFLAP frame is a TOC command. - -The TOC protocol is ASCII based, and special attention -must be placed argument separation. The separator and -the rules of separation are different for messages inbound -to TOC and outbound to the client. The rules of separation -are described in sections below. - -The TOC server is built mainly to service the TIC and TiK clients. Since -the TIC client is a Java applet, and downloadable, TOC will NOT support -multiple TOC protocol versions at the same time. Therefore, TiK -users will be forced to upgrade if the protocol version changes. -TOC sends down the protocol version it expects the client -to speak and understand. Note, the protocol version is a string. - -Important Notes -=============== -* TOC will drop the connection if a command exceeds the maximum - length, which is currently 2048 bytes. So the client needs to - spend special attention to im, chat, and config message lengths. - There is an 8k length maximum from TOC to the client. - -* No commands should be sent to TOC (besides toc_signon) before - a SIGN_ON is received. If you do send a command before SIGN_ON - the command will be ignored, and in some case the connection - will be dropped. - -* Initial permit/deny items should be sent after receiving SIGN_ON - but before sending toc_init_done, otherwise the user will flash - on peoples buddylist who the user has denied. You will probably - want to send the toc_add_buddies at this time also. - -* After TOC sends the PAUSE message to a client, all messages sent - to TOC will be ignored, and in some cases the connection will - be dropped. Another SIGN_ON message will be sent to the client - when it is online again. The buddy list and permit/deny items must - be sent again, followed by the toc_init_done. In most cases the - SIGN_ON message will be sent between 1-2 seconds after the - PAUSE message. Therefore a client could choose to ignore the - PAUSE message and hope nothing bad happens. - - -Client -> TOC -============== -The commands and the arguments are usually separated by whitespaces. Arguments -with whitespace characters should be enclosed in quotes. Dollar signs, -curly brackets, square brackets, parentheses, quotes, and backslashes -must all be backslashed whether in quotes or not. It is usually -a good idea just to use quotes no matter what. All user names from clients -to TOC should be normalized (spaces removed and lowercased), and therefore -are the one exception to the always use quotes rule. - -When sending commands to the server you will not get a response -back confirming that the command format was correct or not! However -in some cases if the command format was incorrect the connection -will be dropped. - - -RoastingString="Tic/Toc" - -toc_signon <authorizer host> <authorizer port> <User Name> <Password> - <language> <version> - The password needs to be roasted with the Roasting String if - coming over a FLAP connection, CP connections don't use - roasted passwords. The language specified will be used - when generating web pages, such as the get info pages. - Currently the only supported language is "english". - If the language sent isn't found, the default "english" - language will be used. The version string will be used - for the client identity, and must be less then 50 - characters. - - Passwords are roasted when sent to the host. This is done so they - aren't sent in "clear text" over the wire, although they are still - trivial to decode. Roasting is performed by first xoring each byte - in the password with the equivalent modulo byte in the roasting - string. The result is then converted to ascii hex, and prepended - with "0x". So for example the password "password" roasts to - "0x2408105c23001130" - -toc_init_done - Tells TOC that we are ready to go online. TOC clients should first - send TOC the buddy list and any permit/deny lists. However toc_init_done - must be called within 30 seconds after toc_signon, or the connection - will be dropped. Remember, it can't be called until after the SIGN_ON - message is received. Calling this before or multiple times after a - SIGN_ON will cause the connection to be dropped. - -toc_send_im <Destination User> <Message> [auto] - Send a message to a remote user. Remember to quote and encode the - message. If the optional string "auto" is the last argument, then the - auto response flag will be turned on for the im. - -toc_add_buddy <Buddy User 1> [<Buddy User2> [<Buddy User 3> [...]]] - Add buddies to your buddy list. This does not change your - saved config. - -toc_remove_buddy <Buddy User 1> [<Buddy User2> [<Buddy User 3> [...]]] - Remove buddies from your buddy list. This does not change your - saved config. - -toc_set_config <Config Info> - Set the config information for this user. The config information - is line oriented with the first character being the item type, - followed by a space, with the rest of the line being the item - value. Only letters, numbers, and spaces should be used. Remember - you will have to enclose the entire config in quotes. - - Item Types: - g - Buddy Group (All Buddies until the next g or the end of config - are in this group.) - b - A Buddy - p - Person on permit list - d - Person on deny list - m - Permit/Deny Mode. Possible values are - 1 - Permit All - 2 - Deny All - 3 - Permit Some - 4 - Deny Some - -toc_evil <User> <norm|anon> - Evil/Warn someone else. The 2nd argument is either the string - "norm" for a normal warning, or "anon" for an anonymous - warning. You can only evil people who have recently sent you - ims. The higher someones evil level, the slower they can - send message. - -toc_add_permit [ <User 1> [<User 2> [...]]] - ADD the following people to your permit mode. If - you are in deny mode it will switch you to permit - mode first. With no arguments and in deny mode - this will switch you to permit none. If already - in permit mode, no arguments does nothing - and your permit list remains the same. - -toc_add_deny [ <User 1> [<User 2> [...]]] - ADD the following people to your deny mode. If - you are in permit mode it will switch you to - deny mode first. With no arguments and in permit - mode, this will switch you to deny none. If - already in deny mode, no arguments does nothing - and your deny list remains unchanged. - -toc_chat_join <Exchange> <Chat Room Name> - Join a chat room in the given exchange. Exchange is - an integer that represents a group of chat rooms. - Different exchanges have different properties. For - example some exchanges might have room replication (ie - a room never fills up, there are just multiple - instances.) and some exchanges might have navigational - information, and some exchanges might have ... Currently - exchange should always be 4, however this may - change in the future. You will either - receive an ERROR if the room couldn't be joined - or a CHAT_JOIN message. The Chat Room Name - is case insensitive and consecutive spaces - are removed. - -toc_chat_send <Chat Room ID> <Message> - Send a message in a chat room using the chat room - id from CHAT_JOIN. Since reflection is always on in - TOC, you do not need to add the message to your chat UI, - since you will get a CHAT_IN with the message. - Remember to quote and encode the message. - -toc_chat_whisper <Chat Room ID> <dst_user> <Message> - Send a message in a chat room using the chat room - id from CHAT_JOIN. This message is directed at - only one person. (Currently you DO need to add this to - your UI.) Remember to quote and encode the message. - Chat whispering is different from IMs since it is linked - to a chat room, and should usually be displayed in the chat - room UI. - -toc_chat_evil <Chat Room ID> <User> <norm|anon> - Evil/Warn someone else inside a chat room. The 3rd argument is either - the string "norm" for a normal warning, or "anon" for an anonymous - warning. Currently chat evil is not turned on in the chat complex. - -toc_chat_invite <Chat Room ID> <Invite Msg> <buddy1> [<buddy2> [<buddy3> [...]]] - Once you are inside a chat room you can invite other people into - that room. Remember to quote and encode the invite message. - -toc_chat_leave <Chat Room ID> - Leave the chat room. - -toc_chat_accept <Chat Room ID> - Accept a CHAT_INVITE message from TOC. The server will send a - CHAT_JOIN in response. - -toc_get_info <username> - Gets a user's info a GOTO_URL or ERROR message will be sent back to the - client. - -toc_set_info <info information> - Set the LOCATE user information. This is basic HTML. - Remember to encode the info. - -toc_set_away [<away message>] - if the away message is present, then the unavailable - status flag is set for the user. If the away message - is not present, then the unavailable status flag is - unset. The away message is basic HTML, remember to - encode the information. - -toc_get_dir <username> - Gets a user's dir info a GOTO_URL or ERROR message will be sent back to the - client. - -toc_set_dir <info information> - Set the DIR user information. This is a colon separated fields as in: - "first name":"middle name":"last name":"maiden name":"city":"state":"country":"email":"allow web searches" - Should return a DIR_STATUS msg. Having anything in the "allow web searches" - field allows people to use web-searches to find your directory info. - Otherwise, they'd have to use the client. - -toc_dir_search <info information> - Perform a search of the Oscar Directory, using colon separated fields as in: - "first name":"middle name":"last name":"maiden name":"city":"state":"country":"email" - Returns either a GOTO_URL or ERROR msg. - -toc_set_idle <idle secs> - Set idle information. If <idle secs> is 0 then the user isn't idle at all. - If <idle secs> is greater then 0 then the user has already been idle - for <idle secs> number of seconds. The server will automatically - keep incrementing this number, so do not repeatedly call with new - idle times. - -toc_set_caps [ <Capability 1> [<Capability 2> [...]]] - Set my capabilities. All capabilities that we support need to - be sent at the same time. Capabilities are represented by - UUIDs. - -toc_rvous_propose - Not Implemented Yet - -toc_rvous_accept <nick> <cookie> <service> <tlvlist> - Accept a rendezvous proposal from the user <nick>. - <cookie> is the cookie from the RVOUS_PROPOSE - message. <service> is the UUID the proposal was - for. <tlvlist> contains a list of tlv tags followed by - base64 encoded values. - -toc_rvous_cancel <nick> <cookie> <service> <tlvlist> - Cancel a rendezvous proposal from the user <nick>. - <cookie> is the cookie from the RVOUS_PROPOSE - message. <service> is the UUID the proposal was - for. <tlvlist> contains a list of tlv tags followed by - base64 encoded values. - -toc_format_nickname <new_format> - Reformat a user's nickname. An ADMIN_NICK_STATUS or ERROR message will - be sent back to the client. - -toc_change_passwd <existing_passwd new_passwd> - Change a user's password. An ADMIN_PASSWD_STATUS or ERROR message will - be sent back to the client. - - -TOC -> Client -============== -All user names from TOC to client are NOT normalized, and are -sent as they should be displayed. String are NOT encoded, instead -we use colons as separators. So that you can have colons inside -of messages, everything after the colon before :<Message> should -be considered part of the message (ie don't just "split" on colons, -instead split with a max number of results.) - - -SIGN_ON:<Client Version Supported> - This is sent after a successful toc_signon command is sent to TOC. - If the command was unsuccessful either the FLAP connection will - be dropped or you will receive a ERROR message. - -CONFIG:<config> - A user's config. Config can be empty in which case the host was not able to - retrieve it, or a config didn't exist for the user. See toc_set_config - above for the format. - -NICK:<Nickname> - Tells you your correct nickname (ie how it should be capitalized and - spacing) - -IM_IN:<Source User>:<Auto Response T/F?>:<Message> - Receive an IM from some one. Everything after the third colon is - the incoming message, including other colons. - -UPDATE_BUDDY:<Buddy User>:<Online? T/F>:<Evil Amount>:<Signon Time>:<IdleTime>:<UC> - This one command handles arrival/depart/updates. Evil Amount is - a percentage, Signon Time is UNIX epoc, idle time is in minutes, UC (User Class) - is a two/three character string. - uc[0]: - ' ' - Ignore - 'A' - On AOL - uc[1] - ' ' - Ignore - 'A' - Oscar Admin - 'U' - Oscar Unconfirmed - 'O' - Oscar Normal - uc[2] - '\0' - Ignore - ' ' - Ignore - 'U' - The user has set their unavailable flag. - - - -ERROR:<Error Code>:Var args - * General Errors * - 901 - $1 not currently available - 902 - Warning of $1 not currently available - 903 - A message has been dropped, you are exceeding - the server speed limit - - * Admin Errors * - 911 - Error validating input - 912 - Invalid account - 913 - Error encountered while processing request - 914 - Service unavailable - - * Chat Errors * - 950 - Chat in $1 is unavailable. - - * IM & Info Errors * - 960 - You are sending message too fast to $1 - 961 - You missed an im from $1 because it was too big. - 962 - You missed an im from $1 because it was sent too fast. - - * Dir Errors * - 970 - Failure - 971 - Too many matches - 972 - Need more qualifiers - 973 - Dir service temporarily unavailable - 974 - Email lookup restricted - 975 - Keyword Ignored - 976 - No Keywords - 977 - Language not supported - 978 - Country not supported - 979 - Failure unknown $1 - - * Auth errors * - 980 - Incorrect nickname or password. - 981 - The service is temporarily unavailable. - 982 - Your warning level is currently too high to sign on. - 983 - You have been connecting and - disconnecting too frequently. Wait 10 minutes and try again. - If you continue to try, you will need to wait even longer. - 989 - An unknown signon error has occurred $1 - - -EVILED:<new evil>:<name of eviler, blank if anonymous> - The user was just eviled. - -CHAT_JOIN:<Chat Room Id>:<Chat Room Name> - We were able to join this chat room. The Chat Room Id is - internal to TOC. - -CHAT_IN:<Chat Room Id>:<Source User>:<Whisper? T/F>:<Message> - A chat message was sent in a chat room. - -CHAT_UPDATE_BUDDY:<Chat Room Id>:<Inside? T/F>:<User 1>:<User 2>... - This one command handles arrival/departs from a chat room. The - very first message of this type for each chat room contains the - users already in the room. - -CHAT_INVITE:<Chat Room Name>:<Chat Room Id>:<Invite Sender>:<Message> - We are being invited to a chat room. - -CHAT_LEFT:<Chat Room Id> - Tells tic connection to chat room has been dropped - -GOTO_URL:<Window Name>:<Url> - Goto a URL. Window Name is the suggested internal name of the window - to use. (Java supports this.) - -DIR_STATUS:<Return Code>:<Optional args> - <Return Code> is always 0 for success status. - -ADMIN_NICK_STATUS:<Return Code>:<Optional args> - <Return Code> is always 0 for success status. - -ADMIN_PASSWD_STATUS:<Return Code>:<Optional args> - <Return Code> is always 0 for success status. - - -PAUSE - Tells TIC to pause so we can do migration - -RVOUS_PROPOSE:<user>:<uuid>:<cookie>:<seq>:<rip>:<pip>:<vip>:<port> - [:tlv tag1:tlv value1[:tlv tag2:tlv value2[:...]]] - Another user has proposed that we rendezvous with them to - perform the service specified by <uuid>. They want us - to connect to them, we have their rendezvous ip, their - proposer_ip, and their verified_ip. The tlv values are - base64 encoded. - -Typical Signon Process -====================== -Except for the section marked optional this is an sequential -process. Each line MUST occur before the following line. - -* Client connects to TOC -* Client sends "FLAPON\r\n\r\n" -* TOC sends Client FLAP SIGNON -* Client sends TOC FLAP SIGNON -* Client sends TOC "toc_signon" message -* if login fails TOC drops client's connection - else TOC sends client SIGN_ON reply -* if Client doesn't support version it drops the connection - -[BEGIN OPTIONAL] - * TOC sends Client CONFIG - * Client sends TOC permit/deny stuff - * Client sends TOC toc_add_buddy message -[END OPTIONAL] - -* Client sends TOC toc_init_done message - - -SFLAP Documentation -=================== -SFLAP is pretty much a FLAP connection except the DATA frame payload is a null -terminated string when traveling from client to host, it is NOT null -terminated when traveling from host to client. The FLAP Header is binary -data, and is in network byte order. The data portion is at offset 6, after the -header. The sequence number is sequential in each direction. So -packets from the server to client have one sequence number, while -the packets from the client to server have an independent -increasing number. - -FLAP Header (6 bytes) ------------ -Offset Size Type -0 1 ASTERISK (literal ASCII '*') -1 1 Frame Type -2 2 Sequence Number -4 2 Data Length - - -Valid Frame Type Values ------------------------ -1 SIGNON -2 DATA -3 ERROR (Not used by TOC) -4 SIGNOFF (Not used by TOC) -5 KEEP_ALIVE - - -TOC SIGNON FRAME TYPE ---------------------- -Sequence Number contains the initial sequence number used in each direction. -Data Length contains the payload length, with the payload described -below. The payload area is NOT null terminated. - -Host To Client: - 4 byte FLAP version (1) - -Client To Host: - 4 byte FLAP version (1) - 2 byte TLV Tag (1) - 2 byte Normalized User Name Length - N byte Normalized User Name (NOT null terminated) - - -TOC DATA FRAME TYPE -------------------- -Sequence Number contains the next sequence number. -Data Length is the length of the payload, including the null termination -from client to host. -
--- a/doc/rfc1459.txt Sat Sep 15 19:32:51 2001 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,3643 +0,0 @@ - - - - - - -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 - - - -Oikarinen & Reed [Page 1] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 2] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - - - - - - - -Oikarinen & Reed [Page 3] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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 ] - - - -Oikarinen & Reed [Page 4] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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 - - - -Oikarinen & Reed [Page 5] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - - -Oikarinen & Reed [Page 6] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 7] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 8] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}' - - - -Oikarinen & Reed [Page 9] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - <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. - - - - - -Oikarinen & Reed [Page 10] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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. - - - - - -Oikarinen & Reed [Page 11] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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 - - - -Oikarinen & Reed [Page 12] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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: - - - - -Oikarinen & Reed [Page 13] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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. - - - -Oikarinen & Reed [Page 14] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 15] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - ; 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: - - - - -Oikarinen & Reed [Page 16] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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 - - - -Oikarinen & Reed [Page 17] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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. - - - - -Oikarinen & Reed [Page 18] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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; - - - - -Oikarinen & Reed [Page 19] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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>} - - - - -Oikarinen & Reed [Page 20] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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; - - - -Oikarinen & Reed [Page 21] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 22] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 23] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 24] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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). - - - -Oikarinen & Reed [Page 25] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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>] - - - - -Oikarinen & Reed [Page 26] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 27] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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: - - - - -Oikarinen & Reed [Page 28] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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 - - - -Oikarinen & Reed [Page 29] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -: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 - - - - -Oikarinen & Reed [Page 30] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -: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. - - - -Oikarinen & Reed [Page 31] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 32] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 33] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 34] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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. - - - - - -Oikarinen & Reed [Page 35] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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. - - - - - -Oikarinen & Reed [Page 36] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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 - - - -Oikarinen & Reed [Page 37] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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] - - - -Oikarinen & Reed [Page 38] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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. - - - -Oikarinen & Reed [Page 39] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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>] - - - -Oikarinen & Reed [Page 40] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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. - - - -Oikarinen & Reed [Page 41] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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. - - - -Oikarinen & Reed [Page 42] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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 \ - - - -Oikarinen & Reed [Page 43] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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>" - - - -Oikarinen & Reed [Page 44] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - - 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. - - - -Oikarinen & Reed [Page 45] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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. - - - -Oikarinen & Reed [Page 46] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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. - - - - -Oikarinen & Reed [Page 47] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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>" - - - -Oikarinen & Reed [Page 48] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 49] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 50] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 51] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - "<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 - - - -Oikarinen & Reed [Page 52] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - "<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 - - - -Oikarinen & Reed [Page 53] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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>" - - - - -Oikarinen & Reed [Page 54] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - - 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. - - - - - - - -Oikarinen & Reed [Page 55] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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 - - - -Oikarinen & Reed [Page 56] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 57] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 58] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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). - - - - - - - -Oikarinen & Reed [Page 59] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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 - - - -Oikarinen & Reed [Page 60] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - -Oikarinen & Reed [Page 61] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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. - - - -Oikarinen & Reed [Page 62] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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 - - - -Oikarinen & Reed [Page 63] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - - 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 - - - - -Oikarinen & Reed [Page 64] - -RFC 1459 Internet Relay Chat Protocol May 1993 - - -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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Oikarinen & Reed [Page 65] - \ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/protocols/irc/rfc1459.txt Sat Sep 15 21:15:36 2001 +0000 @@ -0,0 +1,3643 @@ + + + + + + +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 + + + +Oikarinen & Reed [Page 1] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 2] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + + + + + + + +Oikarinen & Reed [Page 3] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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 ] + + + +Oikarinen & Reed [Page 4] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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 + + + +Oikarinen & Reed [Page 5] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + + +Oikarinen & Reed [Page 6] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 7] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 8] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}' + + + +Oikarinen & Reed [Page 9] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + <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. + + + + + +Oikarinen & Reed [Page 10] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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. + + + + + +Oikarinen & Reed [Page 11] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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 + + + +Oikarinen & Reed [Page 12] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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: + + + + +Oikarinen & Reed [Page 13] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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. + + + +Oikarinen & Reed [Page 14] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 15] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + ; 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: + + + + +Oikarinen & Reed [Page 16] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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 + + + +Oikarinen & Reed [Page 17] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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. + + + + +Oikarinen & Reed [Page 18] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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; + + + + +Oikarinen & Reed [Page 19] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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>} + + + + +Oikarinen & Reed [Page 20] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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; + + + +Oikarinen & Reed [Page 21] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 22] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 23] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 24] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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). + + + +Oikarinen & Reed [Page 25] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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>] + + + + +Oikarinen & Reed [Page 26] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 27] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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: + + + + +Oikarinen & Reed [Page 28] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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 + + + +Oikarinen & Reed [Page 29] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +: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 + + + + +Oikarinen & Reed [Page 30] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +: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. + + + +Oikarinen & Reed [Page 31] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 32] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 33] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 34] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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. + + + + + +Oikarinen & Reed [Page 35] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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. + + + + + +Oikarinen & Reed [Page 36] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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 + + + +Oikarinen & Reed [Page 37] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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] + + + +Oikarinen & Reed [Page 38] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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. + + + +Oikarinen & Reed [Page 39] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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>] + + + +Oikarinen & Reed [Page 40] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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. + + + +Oikarinen & Reed [Page 41] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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. + + + +Oikarinen & Reed [Page 42] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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 \ + + + +Oikarinen & Reed [Page 43] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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>" + + + +Oikarinen & Reed [Page 44] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + - 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. + + + +Oikarinen & Reed [Page 45] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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. + + + +Oikarinen & Reed [Page 46] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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. + + + + +Oikarinen & Reed [Page 47] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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>" + + + +Oikarinen & Reed [Page 48] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 49] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 50] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 51] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + "<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 + + + +Oikarinen & Reed [Page 52] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + "<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 + + + +Oikarinen & Reed [Page 53] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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>" + + + + +Oikarinen & Reed [Page 54] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + - 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. + + + + + + + +Oikarinen & Reed [Page 55] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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 + + + +Oikarinen & Reed [Page 56] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 57] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 58] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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). + + + + + + + +Oikarinen & Reed [Page 59] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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 + + + +Oikarinen & Reed [Page 60] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + +Oikarinen & Reed [Page 61] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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. + + + +Oikarinen & Reed [Page 62] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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 + + + +Oikarinen & Reed [Page 63] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 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 + + + + +Oikarinen & Reed [Page 64] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Oikarinen & Reed [Page 65] + \ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/protocols/msn/PROTOCOL Sat Sep 15 21:15:36 2001 +0000 @@ -0,0 +1,1180 @@ +Some other notes not contained in this spec. +REA TrID UserHandle FriendlyName - will change your friendly name + +--- +Instant Messaging and Presence Protocol R. Movva +Internet Draft Microsoft +Category: Informational August, 1999 +Document: draft-movva-msn-messenger-protocol-00.txt +Document Expires: 2/00 W. Lai + Microsoft + August, 1999 + + + + MSN Messenger Service 1.0 Protocol + + + +Status of this Memo + + This document is an Internet-Draft and is NOT offered in accordance + with Section 10 of RFC2026, and the author does not provide the IETF + with any rights other than to publish as an Internet-Draft. + + 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 document and related documents are discussed on the impp + mailing list. To join the list, send mail to impp- + request@iastate.edu. To contribute to the discussion, send mail to + impp@iastate.edu. The archives are at http://lists.fsck.com/cgi- + bin/wilma/pip. The IMPP working group charter, including the current + list of group documents, can be found at + http://www.ietf.org/html.charters/impp-charter.html. + + + +1. Abstract + + Microsoft released a commercial Instant Messaging product in July of + 1999 called MSN Messenger Service. This document describes the + protocol used by that product for core instant messaging and + presence functionality. While this protocol does not meet many of + the requirements of the IMPP working group, it is provided as + background information on existing Instant Messaging + implementations. This protocol is provided 'as is' without warranty + of any kind. + + +Movva and Lai Category - Informational 1 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + +2. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC-2119. + + Protocol messages sent from client to server are preceded by "C:". + + Protocol messages sent from server to client are preceded by "S:". + + + +3. Introduction + + MSN Messenger Service enables a user to learn about the presence of + other people on the Internet, and to communicate with them in real- + time. This functionality is commonly referred to as "Instant + Messaging" (IM). + + This document describes the syntax and semantics of the MSN + Messenger Protocol, the communication protocol running between MSN + Messenger Service 1.0 clients and servers. Among the core services + that the MSN Messenger Servers provide to clients are: + + - Authenticated user logon. + - Adding and deleting members of the user's contact list. + - Changing the user's on-line state. + - Receipt of asynchronous, real-time, on-line state change + notifications from members of the user's contact list. + - Delivering lightweight, real-time messages to other users. + - Receipt of asynchronous, real-time messages from other users. + - Configuring the user's access permissions, to restrict the ability + of other users to view the user's on-line state or send messages + to the user. + + Additional background: + + 1. Some features extraneous to core instant messaging functionality + contained within the MSN Messenger Service 1.0 protocol are beyond + the scope of this document. Examples include client version + management and directory functionality. + + 2. The purpose of this document is to provide the members of the + IMPP working group with a reference implementation of a "monolithic" + IM system. That is, a system designed for massive scale, but not yet + capable of communication with servers other than those associated + with this specific service. Since any standard in this area will of + necessity be a "distributed" design that explicitly enables server- + to-server and service-to-service communication, this document will + serve primarily as a reference and example of one implementer's + choices when providing IM functionality at scale. + + +Movva and Lai Category - Informational 2 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + 3. This document reflects the protocol used in the 1.0 release of + MSN Messenger clients and servers, deployed on the Internet in July + of 1999. However, the service is in production and rapidly growing, + which almost certainly will necessitate changes to the protocol as + Microsoft gains operational experience with the service and expands + its feature set. This Internet Draft may not be updated with such + changes, and the changes may be made with little or no notice. + + + +4. MSN Messenger Server Component Overview + + MSN Messenger Service clients make connections to several different + kinds of servers. They are separate components to facilitate running + at scale - each component can be duplicated an arbitrary number of + times, independently of each other, to enable large numbers of + users. + +4.1 Dispatch Server (DS) + + The Dispatch Server is the initial point of connection between + client and server. Its primary functions are protocol version + negotiation, determination of which Notification Server (NS) is + associated with the client making a connection (via an algorithm of + the server's choosing), and referring the client to the proper NS. + +4.2 Notification Server (NS) + + The Notification Server is the primary server component. The client + and the Notification Server authenticate, synchronize user + properties, and exchange asynchronous event notifications. The + client's connection to the Notification Server occurs after the + referral from the Dispatch Server is completed, and persists without + interruption during the user's MSN Messenger Service session. + + Some of the events transmitted between a client and a Notification + Server are: State changes (e.g. client is on-line, client is + offline, client is idle), Switchboard Server invitation requests + (see below), and application-specific notifications that are beyond + the scope of this document. (E.g. new e-mail has arrived) + +4.3 Switchboard Server (SS) + + The Switchboard Server is the component through which clients can + establish lightweight communication sessions without requiring a + direct network connection between clients. The common usage of the + Switchboard Server is to provide instant messaging sessions. + When a client wishes to communicate with another client, it sends a + message to its Notification Server, which then refers the client to + a Switchboard Server. Once the SS connection is established, the + "destination" client receives a notification from its NS to connect + to the same SS. + + +Movva and Lai Category - Informational 3 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + +5. Protocol Conventions + +5.1 Connection Type + + The MSN Messenger Protocol currently works over TCP/IP. The MSN + Messenger server components support connections over port numbers + 1863, which is the registered port number assigned by the IANA + (http://www.isi.edu/in-notes/iana/assignments/port-numbers). + +5.2 Command Syntax + + MSN Messenger Protocol command syntax is ASCII and single line- + based. Commands begin with a case-sensitive, three-letter command + type, followed by zero or more parameters, and terminated by CRLF. + Parameters are separated by one or more whitespace characters and + cannot contain whitespace characters. Parameters that contain spaces + or extended (non 7-bit ASCII) characters should be encoded using + URL-style encoding (e.g. "%20" for space). Some commands accept un- + encoded binary data. In these cases, the length of the data is + transmitted as part of the command, and the data is transmitted + immediately following a CRLF of the command. + +5.3 Asynchronous Requests + + Commands issued from the client to the server that result in a reply + are known as requests. Requests are entirely asynchronous. The + client can submit several requests in sequence without waiting for + the server response after submitting each request. The server is + required to deliver a response or an error for each request + received, but it is not required to deliver the responses in the + same order as the requests were received. The client can determine + the request associated with a particular response by examining the + Transaction ID parameter (described below). + +5.4 User Handles + + MSN Messenger Protocol uses User Handles for identifying users. A + user handle (also known as "account name" and "logon name") is a + text representation of the user's identity that is both unique and + persistent. The user handle is syntactically equivalent to an e-mail + address, and as such is subject to the same restrictions for + character set, as described in RFC-822. Most notable among these + restrictions are the limitation to Latin alphanumeric characters and + a few symbols. The maximum acceptable length of the user handle is + 129 bytes. + + Implementation note: In the initial release of the client and + server, user handles are Hotmail account names. All user handles + must contain the "@hotmail.com" domain name, and user handles that + do not contain a domain name are not valid. + +5.5 Custom User Names + + +Movva and Lai Category - Informational 4 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + A custom user name (also known as "custom name" and "friendly name") + is a user's representation of the "friendly" textual name associated + with a user handle. (E.g. "Auntie Em" instead of em123@hotmail.com). + Custom user names are neither unique nor persistent, and can contain + any valid Unicode characters. Custom user names are represented in + UTF-8 as described in RFC-2044 and URL-encoded as described in RFC- + 1738 when transmitted between the client and server. The maximum + acceptable length of the encoded custom user name is 387 in the + current implementation. + +5.6 Transaction Identifiers + + The Transaction Identifier (a.k.a. Transaction ID) is a numeric + string representing a number between 0 and (2^32 - 1). It is a value + that a client includes with any command that it issues to the + server. In the current version of the protocol, the transaction + identifier is used to associate server responses with client-issued + commands. The server treats the transaction ID as an opaque number + and does not assume any relationship between successive Transaction + + IDs or any particular starting Transaction ID. It is the client's + responsibility to guarantee the uniqueness of the Transaction IDs + for the purpose of disambiguating the commands and/or responses. (A + future version of the protocol could enable the client to track the + status or cancel a particular transaction using the transaction ID.) + + When the server sends the response to a command to the client, it + must include in the response the transaction ID that the client sent + to the server when the client originally issued the command. In + cases where a server sends a command to a client that requires a + transaction ID but is not in response to a specific client command, + it will use 0 as the transaction ID. In cases where a server sends + multiple responses to a single client request, the server will use + the same transaction ID in each response. + +5.7 User List Types + + Some of the protocol commands are used to the manipulate lists of + users. The following types of user lists are supported by the + protocol: + + Forward List (FL) - The list of users for whom a given user wants to + receive state change notifications. The Forward List is what is most + commonly referred to as the user's "contact list." + + Reverse List (RL) - The list of users who have registered an + interest in seeing this user's state change notifications. + + Allow List (AL) - The list of users who the user has explicitly + allowed to see state change notifications and establish client-to- + client sessions via a Switchboard Server. + + + +Movva and Lai Category - Informational 5 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + Block List (BL) - The list of users who the user has explicitly + prevented from seeing state change notifications and establishing + client-to-client sessions via a Switchboard Server. + + + +6. Command Summary Table + + Command From To Description + ================================================================== + ACK Switchboard Client Sends a positive message + delivery acknowledgement. + ------------------------------------------------------------------- + ADD Client Notification Adds to the user's FL, AL, + Notification Client and BL. Notifies the client + of asynchronous additions + to a user's list. + ------------------------------------------------------------------- + ANS Client Switchboard Accepts a request for a + switchboard server session. + ------------------------------------------------------------------- + BLP Client Notification Changes the user's message + Notification Client privacy setting, which + determines how to treat + messages from users not + already in the BL or AL. + ------------------------------------------------------------------- + BYE Switchboard Client Notifies a client that a + user is no longer in the + session. + ------------------------------------------------------------------- + CAL Client Switchboard Initiates a switchboard + server session. + ------------------------------------------------------------------- + CHG Client Notification Sends a client state change + Notification Client to the server. + Echoes the success of + client's state change + request. + ------------------------------------------------------------------- + FLN Notification Client Notifies the client when + users in the FL go off- + line. + ------------------------------------------------------------------- + GTC Client Notification Changes the user's prompt + Notification Client setting, which determines + how the client reacts to + certain RL changes. + ------------------------------------------------------------------- + INF Client Dispatch, Requests set of support + Notification authentication protocol + Dispatch, Client from the server. + Notification Provides the set of + +Movva and Lai Category - Informational 6 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + supported authentication + protocols to the client. + ------------------------------------------------------------------- + ILN Notification Client Notifies the client of the + initial online state of a + user in the FL, while + either logging on or adding + a user to the FL. + ------------------------------------------------------------------- + IRO Switchboard Client Provides the initial roster + information for new users + joining the session. + ------------------------------------------------------------------- + JOI Switchboard Client Notifies a client that a + user is now in the session. + ------------------------------------------------------------------- + LST Client Notification Retrieves the server's + Notification Client version of the user's FL, + RL, AL, or BL. + ------------------------------------------------------------------- + MSG Client Switchboard Sends a message to the + members of the current + session. + ------------------------------------------------------------------- + MSG Notification, Client Delivers a message from + Switchboard another client or from a + server-side component. + ------------------------------------------------------------------- + NAK Switchboard Client Sends a negative message + delivery acknowledgement. + ------------------------------------------------------------------- + NLN Notification Client Notifies the client when + users in the FL go on-line + or when their on-line state + changes. + ------------------------------------------------------------------- + OUT All All Ends a client-server + Session. + ------------------------------------------------------------------- + REM Client Notification Removes from the user's FL, + Notification Client AL, and BL. + Notifies the client of + asynchronous removals from + a user's list. + ------------------------------------------------------------------- + RNG Notification Client Notifies the client of a + request by another client + to establish a session via + a switchboard server. + ------------------------------------------------------------------- + SYN Client Notification Initiates client-server + Notification Client property synchronization. + ------------------------------------------------------------------- + +Movva and Lai Category - Informational 7 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + USR All All Authenticates client with + server, possibly in + multiple passes. + ------------------------------------------------------------------ + VER Client Dispatch Negotiates common protocol + Dispatch Client dialect between client and + Server. + ------------------------------------------------------------------ + XFR Client Notification Requests a Switchboard + Notification Client server for use in + establishing a session. + ------------------------------------------------------------------- + XFR Dispatch Client Notification of login-NS to + Notification Client the client or notification + to move to a different NS. +======================================================================= + + + +7. Presence and State Protocol Details + + This is a detailed list of protocol commands associated with + presence functionality. They are defined in the order used by + clients. Commands associated with instant messages are discussed in + section 8 below. + +7.1 Protocol Versioning + + After the client connects to a dispatch server by opening a TCP + socket to port 1863, the client and server agree on a particular + protocol version before they proceed. The Client-Server protocol + version handshake involves the following command exchange: + + C: VER TrID dialect-name{ dialect-name...} + S: VER TrID dialect-name + + The client can provide multiple dialect names in preferred order. + The dialect-name parameter returned by the server is the version + server is designating for this connection + + The current protocol dialect-name supported by Messenger servers is + "MSNP2". The dialect names are not case-sensitive. + + The string "0" is a reserved dialect name and is used to indicate a + failure response. E.g.: + + S: VER TrID 0{ dialect-name ... } + +7.2 Server Policy Information + + The client next queries the server for variable "policy" + information. In this version of the protocol, the only policy + + +Movva and Lai Category - Informational 8 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + information returned by the server is the authentication package in + use. + + C: INF TrID + S: INF TrID SP{,SP...} + + SP identifies a security package - the name of the SASL mechanism to + use for authentication. "MD5" is used by the Notification Server, + "CKI" by the Switchboard Server. + +7.3 Authentication + + The client needs to authenticate itself after protocol version + handshake and identifying the security packages supported on the + server. The following are the client server interactions involved. + + C: USR TrID SP I{ AuthInitiateInfo} + S: USR TrID SP S{ AuthChallengeInfo} + C: USR TrID SP S{ AuthResponseInfo } + S: USR TrID OK UserHandle FriendlyName + + The SP parameter is the name of the security package("MD5"). The + next parameter is a sequence value, which must be I to (I)nitiate + the authentication process and S for all (S)ubsequent messages. If + authentication fails on the server, the client can start the + authentication process again. + + For the MD5 security package: + - The AuthInitiateInfo parameter provided by the client must be the + User handle. + - The AuthChallengeInfo parameter returned by the server contains a + challenge string. + - The AuthResponseInfo contains the binary response as a hexadecimal + string, which the MD5 hash of the challenge and the User password + strings concatenated together. + + The final response from the server contains, in addition to the user + handle, the current "Friendly Name" associated with the user handle. + This is a "Custom User Name" as described above. + +7.4 Referral + + There are three cases in which clients are referred from one server + to another: + + 1. The initial "Dispatch Server" refers the client to the + Notification Server to which it is assigned. + 2. Asynchronous referral by the Notification Server to reassign the + client to a different Notification Server if that server is + overloaded or undergoing maintenance. + 3. During Switchboard Session establishment, the assigned + Notification Server refers the client to a particular + switchboard server for use. This is discussed below. + +Movva and Lai Category - Informational 9 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + + In the current implementation the Dispatch Server uses the user + handle provided in the initial USR command above to assign the user + in question to a Notification Server. Alternate implementations + might not require referral at this stage. + + If received, referral is of the form: + + S: XFR TrID ReferralType Address[:PortNo] + + ReferralType is either "NS" or "SB" and defines the type of referral + to a Notification Server or Switchboard Server. + Address is a valid DNS name or IP address to a referred server, with + optional port# suffixed as ":PortNo". + + If this command is received from the server, the client should + attempt to log in to the server provided. + + In the case of "NS" referrals during logon, the Server automatically + closes the client connection after sending this XFR response so that + the client can connect to the new IP Address. + + If sent asynchronously, the client is responsible for closing the + connection. + + After a "NS" referral, the client will not receive any more messages + from the "old" NS, and also must not send any commands to the "old" + NS after receiving an XFR. + +7.5 Client User Property Synchronization + + Several of the user properties used by the Messenger application are + stored on the server. This is done for two reasons: + + 1) So that users can "roam", i.e. log in from different locations + and still have the appropriate data, such as their contact lists and + privacy settings. + 2) If changes occur to a user's Reverse List while that user was + offline (the user was added to another user's list), the client can + be updated with this information. + + For performance reasons it is useful to cache these properties on + the client, so that bandwidth usage is minimized in the typical case + where the user is not roaming and there were no Reverse List + changes. + + These requirements are met by the SYN command - synchronization. + + Once a client logs in successfully, it uses the SYN command to + ensure it has the latest version of the server-stored properties. + These properties include: Forward List, Reverse List, Block List, + Allow List, GTC setting (privacy setting when someone adds this user + to their Forward List), and BLP setting (the user's privacy mode). + +Movva and Lai Category - Informational 10 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + + The SYN command is: + + C: SYN TrID Ser# + S: SYN TrID Ser# + + The Ser# parameter sent by the client is the version of the + properties currently cached on the client. The server responds with + the current server version of the properties. If the server has a + newer version, the server will immediately follow the SYN reply by + updating the client with the latest version of the user properties. + These updates are done as described below, and are done without the + client explicitly initiating a LST, GTC or BLP command. Note that + the server will update all server-stored properties to the client, + regardless of how many entries have been changed. + + The following "List Retrieval and Property Management" section + describes the format of the user properties sent by the server. + After the SYN reply from the server, the user property updates will + be sent from the server in this sequence: GTC, BLP, LST FL, LST AL, + LST BL, LST RL. + + All the user property updates will share the same TrID as the SYN + command and reply. + +7.6 List Retrieval And Property Management + + Synchronizing can result in a batch of user properties and lists + getting sent by the server to the client. However, the client + application can also initiate a request to retrieve the server- + stored lists and properties. The following are the privacy property + and list retrieval commands. The response formats are the same + whether it is a client-initiated request, or whether it is a + response to the SYN process as described above. + + + List Command + + By issuing the LST command, the client can explicitly request that a + list be sent. The server will respond with a series of LST + responses, one LST response for each item in the requested list. + + C: LST TrID LIST + S: LST TrID LIST Ser# Item# TtlItems UserHandle CustomUserName + + - LIST is FL/RL/AL/BL for Forward List, Reverse List, Allow List, + and Block List, respectively. + - The Item# parameter contains the index of the item described in + this command message. (E.g. item 1 of N, 2 of N, etc.) + - The TtlItems parameter contains the total number of items in this + list. + - UserHandle is the user handle for this list item. + - CustomUserName is the friendly name for this list item. + + +Movva and Lai Category - Informational 11 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + If the list is empty, the response will be: + + S: LST TrID LIST Ser# 0 0 + + Reverse List Prompting + + The client can change its persistent setting for when to prompt the + user in reaction to an Reverse List change. This is accomplished via + the GTC command: + + C: GTC TrID [A | N] + S: GTC TrID Ser# [A | N] + + The value of the A/N parameter determines how the client should + behave when it discovers that a user is in its RL, but is not in its + AL or BL. (Note that this occurs when a user has been added to + another user's list, but has not been explicitly allowed or + blocked): + + A - Prompt the user as to whether the new user in the RL should be + added to the AL or the BL + N - Automatically add the new user in the RL to the AL + + The A/N parameter is not interpreted by the server, merely stored. + + The server will respond with the current setting if the change was + successful. Otherwise, it will return an error with the matching + TrID. If the client tries to change the setting to the same value as + the current setting, the server will respond with an error message. + + The default setting is A when a new user connects to the server for + the first time. + + Privacy Mode + + The client can change how the server handles instant messages from + users via the BLP command: + + C: BLP TrID [AL | BL] + S: BLP TrID Ser# [AL | BL] + + The AL/BL parameter determines how the server should treat messages + (MSG and RNG) from users. If the current setting is AL, messages + from users who are not in BL will be delivered. If the current + setting is BL, only messages from people who are in the AL will be + delivered. + + The server will respond with the current setting if the change was + successful. Otherwise, it will return an error with the matching + TrID. If the client tries to change the setting to the same value as + the current setting, the server will respond with an error message. + + + +Movva and Lai Category - Informational 12 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + The default setting is AL when a new user connects to the server for + the first time. + + +7.7 Client States + + After the client is authenticated and synchronized, the client + establishes its initial state with the server with the CHG command. + The syntax of the command is: + + C: CHG TrID State + S: CHG TrID State + + When the state is changed, the server will echo the settings back to + client. The state shall not be considered changed until the response + is received from the server. + + Note that the server can send a state change message to the client + at any time. If the server changes the state without a request from + the client, the TrID parameter will be 0. + + States are denoted by a string of three characters. The predefined + states that the server recognizes are: + + NLN - Make the client Online (after logging in) and send and receive + notifications about buddies. + FLN - Make the client Offline. If the client is already online, + offline notifications will be sent to users on the RL. No message + activity is allowed. In this state, the client can only synchronize + the lists as described above. + HDN - Make the client Hidden/Invisible. If the client is already + online, offline notifications will be sent to users on the RL. The + client will appear as Offline to others but can receive + online/offline notifications from other users, and can also + synchronize the lists. Clients cannot receive any instant messages + in this state. + + All other States are treated as sub-states of NLN (online). The + other States currently supported are: + BSY - Busy. + IDL - Idle. + BRB - Be Right Back. + AWY - Away From Computer. + PHN - On The Phone. + LUN - Out To Lunch. + +7.8 List Modifications + + The protocol supports generic commands to add and remove users from + various lists. This is used by clients to enable "Adding" contacts + to the list of folks being watched, or for the "Block" and "Allow" + features that define how users chooses to interact with one another. + + +Movva and Lai Category - Informational 13 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + However, these generic commands have different semantics based on + the list being modified. For example, only the server can add or + remove entries from the Reverse List - since it is an indirect + consequence of the user having been added to another user's Forward + List. + + The add and remove commands: + + C: ADD TrID LIST UserHandle CustomUserName + S: ADD TrID LIST ser# UserHandle CustomUserName + + C: REM TrID LIST UserHandle + S: REM TrID LIST ser# UserHandle + + Valid values for LIST in Client initiated adds and removes are + FL/AL/BL. + + All client initiated adds and removes will be echoed by the server + with a new serial number that should be persisted by the client + along with the list modification. If not successful, an error will + result. + + The protocol also supports the concept of an ADD or REM that the + client did not initiate. Server generated ADDs and REMs can have + LIST values of FL/AL/BL/RL. This is common with RL changes, which + are never initiated by the client, but is an indirect consequence of + this user having been added to someone's Forward List. If the RL + change happens while the user is online, it will trigger an + asynchronous ADD or REM command from the server. + + Asynchronous ADDs and REMs to the FL, AL, and BL can happen when the + server allows an authenticated user to make list changes from + another environment, such as a web site. In all of these cases, the + server will send the ADD or REM command with the TrID parameter + equal to 0. + +7.9 Notification Messages + + The client receives asynchronous notifications whenever a contact on + the user's Forward List changes its state. The notifications are of + the form: + + S: NLN Substate UserHandle FriendlyName + S: ILN TrID Substate UserHandle FriendlyName + S: FLN UserHandle + + NLN indicates that a user has come online. + - Substate can be any three-letter code (see "Client States" above). + - UserHandle and FriendlyName are the handle and names associated + with the user coming online. + + ILN is similar to the NLN message, and is received from the server + in response to an CHG or ADD command from the client: + +Movva and Lai Category - Informational 14 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + + 1. Immediately after the client logon and sends its first CHG + command to the NS. In this case several ILNs may be received - + one for each Forward List contact that is currently online. + 2. After the client sends an "ADD TrID FL UserHandle + CustomUserName" to the NS. (e.g. ILN for the new contact if that + contact is currently online) + + In both cases, TrID in the ILN is the same as the one sent by the + client in the CHG or ADD command. + + FLN means that the specified user is now offline. + +7.10 Connection Close + + The client issues the following command to logoff from the NS: + + C: OUT + S: OUT {StatusCode} + + The server will reply with an OUT to the client before it initiates + a disconnect, with an optional StatusCode. + + The StatusCode can be "OTH", which indicates that a client with the + same user handle and password has logged on to the server from + another location, or "SSD" meaning the server is being shut down for + maintenance. + + The server will drop the connection after sending the OUT. + +7.11 Error Information + + Error messages from the server are of the format: + + S: eee {TrID} {(error-info) {param...}} + + eee is a 3 digit decimal number indicating the error code. Error- + info contains the description of the error in a text string + localized to the server's locale. The optional parameters provide + indication of the client command causing the error. TrID is the + Transaction ID of the client command that caused this error. Any + server generated errors will not have Transaction IDs. + + + ERR_SYNTAX_ERROR 200 + ERR_INVALID_PARAMETER 201 + ERR_INVALID_USER 205 + ERR_FQDN_MISSING 206 + ERR_ALREADY_LOGIN 207 + ERR_INVALID_USERNAME 208 + ERR_INVALID_FRIENDLY_NAME 209 + ERR_LIST_FULL 210 + ERR_ALREADY_THERE 215 + +Movva and Lai Category - Informational 15 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + ERR_NOT_ON_LIST 216 + ERR_ALREADY_IN_THE_MODE 218 + ERR_ALREADY_IN_OPPOSITE_LIST 219 + ERR_SWITCHBOARD_FAILED 280 + ERR_NOTIFY_XFR_FAILED 281 + + ERR_REQUIRED_FIELDS_MISSING 300 + ERR_NOT_LOGGED_IN 302 + ERR_INTERNAL_SERVER 500 + ERR_DB_SERVER 501 + ERR_FILE_OPERATION 510 + ERR_MEMORY_ALLOC 520 + ERR_SERVER_BUSY 600 + ERR_SERVER_UNAVAILABLE 601 + ERR_PEER_NS_DOWN 602 + ERR_DB_CONNECT 603 + ERR_SERVER_GOING_DOWN 604 + ERR_CREATE_CONNECTION 707 + ERR_BLOCKING_WRITE 711 + ERR_SESSION_OVERLOAD 712 + ERR_USER_TOO_ACTIVE 713 + ERR_TOO_MANY_SESSIONS 714 + ERR_NOT_EXPECTED 715 + ERR_BAD_FRIEND_FILE 717 + ERR_AUTHENTICATION_FAILED 911 + ERR_NOT_ALLOWED_WHEN_OFFLINE 913 + ERR_NOT_ACCEPTING_NEW_USERS 920 + + + +8. Session based Instant Messaging Protocol Details + + MSN Messenger Service utilizes a lightweight, session-based + messaging scheme. In order for two clients to exchange instant + messages, they must first establish a common session via a + Switchboard Server. They can invite additional clients to join the + established session. + +8.1 Referral to Switchboard + + This process begins with a "calling" client requesting a referral + from its Notification Server to a Switchboard Server: + + C: XFR TrID SB + S: XFR TrID SB Address SP AuthChallengeInfo + + - SB is the type of referral being requested or granted. + - Address is the DNS name or IP address of a Switchboard Server that + has been assigned, and that the client should connect to. + - SP is the Security Package being used. In this version of the + protocol it is "CKI" only. + - AuthChallengeInfo is a cookie that the client needs to present to + the Switchboard server for authentication. + + +Movva and Lai Category - Informational 16 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + +8.2 Switchboard Connections and Authentication + + After the XFR reply is received, the client makes a TCP/IP + connection to the Switchboard server using port 1863. Note that a + lack of version negotiation in the switchboard connection is a + limitation of the current implementation. + + The client first needs to authenticates with the Switchboard Server: + + C: USR TrID UserHandle AuthResponseInfo + S: USR TrID OK UserHandle FriendlyName + + - AuthResponseInfo is the cookie for CKI security package returned + by the Notification Server in the XFR. + - UserHandle and FriendlyName are the Switchboard's echoes of the + user handle and friendly name of the user. + +8.3 Inviting Users to a Switchboard Session + + Any user in a Switchboard session can invite other users to join the + session. The CAL command is sent to the Switchboard server for this + purpose: + + C: CAL TrID UserHandle + S: CAL TrID Status SessionID + + The Messenger servers verify that the calling user has permissions + to contact the called user, with consideration given to the called + user's privacy settings and its online state. If instant messaging + with this user is not allowed, the server responds to the calling + user with an error. If it is allowed, the Switchboard server causes + a RNG command to be sent to the called client (see below), and + returns a CAL echo to the calling client. The CAL echo has these + parameters: + + - Status is a predefined status code - in this implementation it + must be "RINGING". + - SessionID is the ASCII representation of a decimal number that + uniquely identifies this session on the Switchboard Server. + +8.4 Getting Invited to a Switchboard Session + + The other side of the session establishment is the behavior of the + called client. The called client receives a RNG from its + Notification Server and is expected to connect to the Switchboard + Server and respond with an ANS. + + The client receives a RNG from the Notification Server as follows: + + S: RNG SessionID SwitchboardServerAddress SP AuthChallengeInfo + CallingUserHandle CallingUserFriendlyName + + - SessionID is a numeric ASCII session ID. + +Movva and Lai Category - Informational 17 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + - SwitchboardServerAddress is a DNS name or IP Address + - SP is the security package in use. In this implementation only + "CKI" is supported. + - AuthChallengeInfo is the cookie to be passed back to the + switchboard to gain entrance to the session. + - CallingUserHandle is the user handle of the caller. + - CallingUserFriendlyName is the custom user name of the caller. + + To join the session, the called client connects to the Switchboard + Server and carries out the following exchange to join the session: + + C: ANS TrID LocalUserHandle AuthResponseInfo SessionID + S: IRO TrID Participant# TotalParticipants UserHandle + FriendlyName + S: ANS TrID OK + + The IRO commands relay to the newly joined client roster information + about the current session. Each IRO command message from the + Switchboard contains one participant in the session. + - Participant# contains the index of the participant described in + this IRO command (e.g. 1 of N, 2 of N). + - TotalParticipants contains the total number of participants + currently in the session. + + The entire session roster will be sent to the new client joining the + session before any JOI or BYE commands described below. + + If no one is in the session when the user joins (an unexpected error + condition), the server skips directly to "ANS TrID OK" command. All + the responses from the server related to the issued ANS command will + contain the same TrID as the original client ANS request. + +8.5 Session Participant Changes + + When a new user joins a Switchboard session, the server sends the + following command to all participating clients, including the client + joining the session: + + S: JOI CalleeUserHandle CalleeUserFriendlyName + + - CalleeUserHandle is the user handle of the new participant. + - CalleeUserFriendlyName is the Custom User Name of the new + participant. + + If a client's connection with the Switchboard Server is dropped for + any reason, the server sends the following command to the remaining + clients in the session: + + S: BYE CalleeUserHandle + + - CalleeUserHandle is the user handle of the participant that left + the session. + + +Movva and Lai Category - Informational 18 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + Privacy Note: + If the client moved a contact to the BL while Switchboard sessions + are active, it is the client's responsibility to leave any session + that should now be blocked. The servers only enforce privacy + permissions when inviting users to a session. Further, the servers + only enforce privacy permission with respect to the calling user, + and not the other participants in a Switchboard session. Therefore, + in a multipoint session, it is possible for a user to participate in + a session with someone whom he has blocked, if a third party is + performing the invitation. + +8.6 Leaving a Switchboard Session + + When a client wishes to disconnect from the session, it sends the + following command and waits for the Switchboard to close the + connection: + + C: OUT + +8.7 Instant Messages + + Sending an Instant Message + + Once a client-to-client session has been established via the + Switchboard Server, sending an Instant Message to the participants + of the session is done as follows: + + C: MSG TrID [U | N | A] Length\r\nMessage + S: NAK TrID + S: ACK TrID + + U, N, and A correspond to the three delivery acknowledgement modes: + Unacknowledged, Negative-Acknowledgement-Only, and Acknowledgement. + Depending on the value of this parameter, either nothing, NAK, or + ACK will be sent back by the Switchboard Server to the client. + + For Unacknowledged mode, the Switchboard Server does not respond to + the sending client with the success or failure of message delivery. + + For Negative-Acknowledgement-Only mode, the Switchboard Server + responds to the send client only if the message could not be + delivered to the recipient client. + + Acknowledgement mode is not currently implemented. + + Length is the length of the Message parameter in bytes, whereas + Message is the actual message as described below. + +8.8 Receiving an Instant Message + + A client can receive a system-generated message from the + Notification Server, or it can receive an instant message from + + +Movva and Lai Category - Informational 19 + + MSN Messenger Service 1.0 Protocol Aug - 99 + + + another client via a Switchboard Server. The message is received in + the following format: + + S: MSG UserHandle FriendlyName Length\r\nMessage + + The UserHandle and FriendlyName are those of the sending user. + Length is the length of the message in bytes. + + Message is a MIME encoded stream, using a standard MIME header as + defined by RFC-1521 and RFC-822. + + Message is constructed as: + + MIME-Header\r\nMIME-Header\r\n\r\nMessageData + + MIME-Header is constructed as: + + string": "string + (E.g. "Content-Type: text/plain") + + The Content-Type MIME headers that the current client will use and + recognize are: + + "text/plain;charset=UTF-8" + "text/plain" + + If "charset=UTF-8" appears at the end of the Content-Type, the + Message Data is UTF-8 encoded. + + Note: The Switchboard Server does not interpret the contents of the + Message. + + + +9. Author's Addresses + + Ramu Movva + Microsoft Corporation + One Microsoft Way + Redmond WA 98052 + ramum@microsoft.com + + William Lai + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + wlai@microsoft.com + + + +Movva and Lai Category - Informational 20
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/protocols/toc/PROTOCOL Sat Sep 15 21:15:36 2001 +0000 @@ -0,0 +1,499 @@ +# Copyright (c) 1998-9 America Online, Inc. All Rights Reserved. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License +# as published by the Free Software Foundation; either version 2 +# of the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +# Note from Jim Duchek, gaim maintainer -- this may not be the latest +# version of this document, I provide it as a service. Download a copy +# of TiK (http://www.aim.aol.com/tik/) for the latest version of this +# doc. + +# Note from Eric Warmenhoven, random guy -- this appears to be the last +# published version of the protocol, and AOL has stopped hosting the TiK +# program. TiK is still being maintained and is hosted on sourceforge.net; +# this appears to be the same version of the protocol they're using. + +Version: TOC1.0 + +This document describes the protocol between TOC and TOC clients. +The protocol is built on TCP. Framing is done by SFLAP, +described at the bottom of this document. Inside each +SFLAP frame is a TOC command. + +The TOC protocol is ASCII based, and special attention +must be placed argument separation. The separator and +the rules of separation are different for messages inbound +to TOC and outbound to the client. The rules of separation +are described in sections below. + +The TOC server is built mainly to service the TIC and TiK clients. Since +the TIC client is a Java applet, and downloadable, TOC will NOT support +multiple TOC protocol versions at the same time. Therefore, TiK +users will be forced to upgrade if the protocol version changes. +TOC sends down the protocol version it expects the client +to speak and understand. Note, the protocol version is a string. + +Important Notes +=============== +* TOC will drop the connection if a command exceeds the maximum + length, which is currently 2048 bytes. So the client needs to + spend special attention to im, chat, and config message lengths. + There is an 8k length maximum from TOC to the client. + +* No commands should be sent to TOC (besides toc_signon) before + a SIGN_ON is received. If you do send a command before SIGN_ON + the command will be ignored, and in some case the connection + will be dropped. + +* Initial permit/deny items should be sent after receiving SIGN_ON + but before sending toc_init_done, otherwise the user will flash + on peoples buddylist who the user has denied. You will probably + want to send the toc_add_buddies at this time also. + +* After TOC sends the PAUSE message to a client, all messages sent + to TOC will be ignored, and in some cases the connection will + be dropped. Another SIGN_ON message will be sent to the client + when it is online again. The buddy list and permit/deny items must + be sent again, followed by the toc_init_done. In most cases the + SIGN_ON message will be sent between 1-2 seconds after the + PAUSE message. Therefore a client could choose to ignore the + PAUSE message and hope nothing bad happens. + + +Client -> TOC +============== +The commands and the arguments are usually separated by whitespaces. Arguments +with whitespace characters should be enclosed in quotes. Dollar signs, +curly brackets, square brackets, parentheses, quotes, and backslashes +must all be backslashed whether in quotes or not. It is usually +a good idea just to use quotes no matter what. All user names from clients +to TOC should be normalized (spaces removed and lowercased), and therefore +are the one exception to the always use quotes rule. + +When sending commands to the server you will not get a response +back confirming that the command format was correct or not! However +in some cases if the command format was incorrect the connection +will be dropped. + + +RoastingString="Tic/Toc" + +toc_signon <authorizer host> <authorizer port> <User Name> <Password> + <language> <version> + The password needs to be roasted with the Roasting String if + coming over a FLAP connection, CP connections don't use + roasted passwords. The language specified will be used + when generating web pages, such as the get info pages. + Currently the only supported language is "english". + If the language sent isn't found, the default "english" + language will be used. The version string will be used + for the client identity, and must be less then 50 + characters. + + Passwords are roasted when sent to the host. This is done so they + aren't sent in "clear text" over the wire, although they are still + trivial to decode. Roasting is performed by first xoring each byte + in the password with the equivalent modulo byte in the roasting + string. The result is then converted to ascii hex, and prepended + with "0x". So for example the password "password" roasts to + "0x2408105c23001130" + +toc_init_done + Tells TOC that we are ready to go online. TOC clients should first + send TOC the buddy list and any permit/deny lists. However toc_init_done + must be called within 30 seconds after toc_signon, or the connection + will be dropped. Remember, it can't be called until after the SIGN_ON + message is received. Calling this before or multiple times after a + SIGN_ON will cause the connection to be dropped. + +toc_send_im <Destination User> <Message> [auto] + Send a message to a remote user. Remember to quote and encode the + message. If the optional string "auto" is the last argument, then the + auto response flag will be turned on for the im. + +toc_add_buddy <Buddy User 1> [<Buddy User2> [<Buddy User 3> [...]]] + Add buddies to your buddy list. This does not change your + saved config. + +toc_remove_buddy <Buddy User 1> [<Buddy User2> [<Buddy User 3> [...]]] + Remove buddies from your buddy list. This does not change your + saved config. + +toc_set_config <Config Info> + Set the config information for this user. The config information + is line oriented with the first character being the item type, + followed by a space, with the rest of the line being the item + value. Only letters, numbers, and spaces should be used. Remember + you will have to enclose the entire config in quotes. + + Item Types: + g - Buddy Group (All Buddies until the next g or the end of config + are in this group.) + b - A Buddy + p - Person on permit list + d - Person on deny list + m - Permit/Deny Mode. Possible values are + 1 - Permit All + 2 - Deny All + 3 - Permit Some + 4 - Deny Some + +toc_evil <User> <norm|anon> + Evil/Warn someone else. The 2nd argument is either the string + "norm" for a normal warning, or "anon" for an anonymous + warning. You can only evil people who have recently sent you + ims. The higher someones evil level, the slower they can + send message. + +toc_add_permit [ <User 1> [<User 2> [...]]] + ADD the following people to your permit mode. If + you are in deny mode it will switch you to permit + mode first. With no arguments and in deny mode + this will switch you to permit none. If already + in permit mode, no arguments does nothing + and your permit list remains the same. + +toc_add_deny [ <User 1> [<User 2> [...]]] + ADD the following people to your deny mode. If + you are in permit mode it will switch you to + deny mode first. With no arguments and in permit + mode, this will switch you to deny none. If + already in deny mode, no arguments does nothing + and your deny list remains unchanged. + +toc_chat_join <Exchange> <Chat Room Name> + Join a chat room in the given exchange. Exchange is + an integer that represents a group of chat rooms. + Different exchanges have different properties. For + example some exchanges might have room replication (ie + a room never fills up, there are just multiple + instances.) and some exchanges might have navigational + information, and some exchanges might have ... Currently + exchange should always be 4, however this may + change in the future. You will either + receive an ERROR if the room couldn't be joined + or a CHAT_JOIN message. The Chat Room Name + is case insensitive and consecutive spaces + are removed. + +toc_chat_send <Chat Room ID> <Message> + Send a message in a chat room using the chat room + id from CHAT_JOIN. Since reflection is always on in + TOC, you do not need to add the message to your chat UI, + since you will get a CHAT_IN with the message. + Remember to quote and encode the message. + +toc_chat_whisper <Chat Room ID> <dst_user> <Message> + Send a message in a chat room using the chat room + id from CHAT_JOIN. This message is directed at + only one person. (Currently you DO need to add this to + your UI.) Remember to quote and encode the message. + Chat whispering is different from IMs since it is linked + to a chat room, and should usually be displayed in the chat + room UI. + +toc_chat_evil <Chat Room ID> <User> <norm|anon> + Evil/Warn someone else inside a chat room. The 3rd argument is either + the string "norm" for a normal warning, or "anon" for an anonymous + warning. Currently chat evil is not turned on in the chat complex. + +toc_chat_invite <Chat Room ID> <Invite Msg> <buddy1> [<buddy2> [<buddy3> [...]]] + Once you are inside a chat room you can invite other people into + that room. Remember to quote and encode the invite message. + +toc_chat_leave <Chat Room ID> + Leave the chat room. + +toc_chat_accept <Chat Room ID> + Accept a CHAT_INVITE message from TOC. The server will send a + CHAT_JOIN in response. + +toc_get_info <username> + Gets a user's info a GOTO_URL or ERROR message will be sent back to the + client. + +toc_set_info <info information> + Set the LOCATE user information. This is basic HTML. + Remember to encode the info. + +toc_set_away [<away message>] + if the away message is present, then the unavailable + status flag is set for the user. If the away message + is not present, then the unavailable status flag is + unset. The away message is basic HTML, remember to + encode the information. + +toc_get_dir <username> + Gets a user's dir info a GOTO_URL or ERROR message will be sent back to the + client. + +toc_set_dir <info information> + Set the DIR user information. This is a colon separated fields as in: + "first name":"middle name":"last name":"maiden name":"city":"state":"country":"email":"allow web searches" + Should return a DIR_STATUS msg. Having anything in the "allow web searches" + field allows people to use web-searches to find your directory info. + Otherwise, they'd have to use the client. + +toc_dir_search <info information> + Perform a search of the Oscar Directory, using colon separated fields as in: + "first name":"middle name":"last name":"maiden name":"city":"state":"country":"email" + Returns either a GOTO_URL or ERROR msg. + +toc_set_idle <idle secs> + Set idle information. If <idle secs> is 0 then the user isn't idle at all. + If <idle secs> is greater then 0 then the user has already been idle + for <idle secs> number of seconds. The server will automatically + keep incrementing this number, so do not repeatedly call with new + idle times. + +toc_set_caps [ <Capability 1> [<Capability 2> [...]]] + Set my capabilities. All capabilities that we support need to + be sent at the same time. Capabilities are represented by + UUIDs. + +toc_rvous_propose - Not Implemented Yet + +toc_rvous_accept <nick> <cookie> <service> <tlvlist> + Accept a rendezvous proposal from the user <nick>. + <cookie> is the cookie from the RVOUS_PROPOSE + message. <service> is the UUID the proposal was + for. <tlvlist> contains a list of tlv tags followed by + base64 encoded values. + +toc_rvous_cancel <nick> <cookie> <service> <tlvlist> + Cancel a rendezvous proposal from the user <nick>. + <cookie> is the cookie from the RVOUS_PROPOSE + message. <service> is the UUID the proposal was + for. <tlvlist> contains a list of tlv tags followed by + base64 encoded values. + +toc_format_nickname <new_format> + Reformat a user's nickname. An ADMIN_NICK_STATUS or ERROR message will + be sent back to the client. + +toc_change_passwd <existing_passwd new_passwd> + Change a user's password. An ADMIN_PASSWD_STATUS or ERROR message will + be sent back to the client. + + +TOC -> Client +============== +All user names from TOC to client are NOT normalized, and are +sent as they should be displayed. String are NOT encoded, instead +we use colons as separators. So that you can have colons inside +of messages, everything after the colon before :<Message> should +be considered part of the message (ie don't just "split" on colons, +instead split with a max number of results.) + + +SIGN_ON:<Client Version Supported> + This is sent after a successful toc_signon command is sent to TOC. + If the command was unsuccessful either the FLAP connection will + be dropped or you will receive a ERROR message. + +CONFIG:<config> + A user's config. Config can be empty in which case the host was not able to + retrieve it, or a config didn't exist for the user. See toc_set_config + above for the format. + +NICK:<Nickname> + Tells you your correct nickname (ie how it should be capitalized and + spacing) + +IM_IN:<Source User>:<Auto Response T/F?>:<Message> + Receive an IM from some one. Everything after the third colon is + the incoming message, including other colons. + +UPDATE_BUDDY:<Buddy User>:<Online? T/F>:<Evil Amount>:<Signon Time>:<IdleTime>:<UC> + This one command handles arrival/depart/updates. Evil Amount is + a percentage, Signon Time is UNIX epoc, idle time is in minutes, UC (User Class) + is a two/three character string. + uc[0]: + ' ' - Ignore + 'A' - On AOL + uc[1] + ' ' - Ignore + 'A' - Oscar Admin + 'U' - Oscar Unconfirmed + 'O' - Oscar Normal + uc[2] + '\0' - Ignore + ' ' - Ignore + 'U' - The user has set their unavailable flag. + + + +ERROR:<Error Code>:Var args + * General Errors * + 901 - $1 not currently available + 902 - Warning of $1 not currently available + 903 - A message has been dropped, you are exceeding + the server speed limit + + * Admin Errors * + 911 - Error validating input + 912 - Invalid account + 913 - Error encountered while processing request + 914 - Service unavailable + + * Chat Errors * + 950 - Chat in $1 is unavailable. + + * IM & Info Errors * + 960 - You are sending message too fast to $1 + 961 - You missed an im from $1 because it was too big. + 962 - You missed an im from $1 because it was sent too fast. + + * Dir Errors * + 970 - Failure + 971 - Too many matches + 972 - Need more qualifiers + 973 - Dir service temporarily unavailable + 974 - Email lookup restricted + 975 - Keyword Ignored + 976 - No Keywords + 977 - Language not supported + 978 - Country not supported + 979 - Failure unknown $1 + + * Auth errors * + 980 - Incorrect nickname or password. + 981 - The service is temporarily unavailable. + 982 - Your warning level is currently too high to sign on. + 983 - You have been connecting and + disconnecting too frequently. Wait 10 minutes and try again. + If you continue to try, you will need to wait even longer. + 989 - An unknown signon error has occurred $1 + + +EVILED:<new evil>:<name of eviler, blank if anonymous> + The user was just eviled. + +CHAT_JOIN:<Chat Room Id>:<Chat Room Name> + We were able to join this chat room. The Chat Room Id is + internal to TOC. + +CHAT_IN:<Chat Room Id>:<Source User>:<Whisper? T/F>:<Message> + A chat message was sent in a chat room. + +CHAT_UPDATE_BUDDY:<Chat Room Id>:<Inside? T/F>:<User 1>:<User 2>... + This one command handles arrival/departs from a chat room. The + very first message of this type for each chat room contains the + users already in the room. + +CHAT_INVITE:<Chat Room Name>:<Chat Room Id>:<Invite Sender>:<Message> + We are being invited to a chat room. + +CHAT_LEFT:<Chat Room Id> + Tells tic connection to chat room has been dropped + +GOTO_URL:<Window Name>:<Url> + Goto a URL. Window Name is the suggested internal name of the window + to use. (Java supports this.) + +DIR_STATUS:<Return Code>:<Optional args> + <Return Code> is always 0 for success status. + +ADMIN_NICK_STATUS:<Return Code>:<Optional args> + <Return Code> is always 0 for success status. + +ADMIN_PASSWD_STATUS:<Return Code>:<Optional args> + <Return Code> is always 0 for success status. + + +PAUSE + Tells TIC to pause so we can do migration + +RVOUS_PROPOSE:<user>:<uuid>:<cookie>:<seq>:<rip>:<pip>:<vip>:<port> + [:tlv tag1:tlv value1[:tlv tag2:tlv value2[:...]]] + Another user has proposed that we rendezvous with them to + perform the service specified by <uuid>. They want us + to connect to them, we have their rendezvous ip, their + proposer_ip, and their verified_ip. The tlv values are + base64 encoded. + +Typical Signon Process +====================== +Except for the section marked optional this is an sequential +process. Each line MUST occur before the following line. + +* Client connects to TOC +* Client sends "FLAPON\r\n\r\n" +* TOC sends Client FLAP SIGNON +* Client sends TOC FLAP SIGNON +* Client sends TOC "toc_signon" message +* if login fails TOC drops client's connection + else TOC sends client SIGN_ON reply +* if Client doesn't support version it drops the connection + +[BEGIN OPTIONAL] + * TOC sends Client CONFIG + * Client sends TOC permit/deny stuff + * Client sends TOC toc_add_buddy message +[END OPTIONAL] + +* Client sends TOC toc_init_done message + + +SFLAP Documentation +=================== +SFLAP is pretty much a FLAP connection except the DATA frame payload is a null +terminated string when traveling from client to host, it is NOT null +terminated when traveling from host to client. The FLAP Header is binary +data, and is in network byte order. The data portion is at offset 6, after the +header. The sequence number is sequential in each direction. So +packets from the server to client have one sequence number, while +the packets from the client to server have an independent +increasing number. + +FLAP Header (6 bytes) +----------- +Offset Size Type +0 1 ASTERISK (literal ASCII '*') +1 1 Frame Type +2 2 Sequence Number +4 2 Data Length + + +Valid Frame Type Values +----------------------- +1 SIGNON +2 DATA +3 ERROR (Not used by TOC) +4 SIGNOFF (Not used by TOC) +5 KEEP_ALIVE + + +TOC SIGNON FRAME TYPE +--------------------- +Sequence Number contains the initial sequence number used in each direction. +Data Length contains the payload length, with the payload described +below. The payload area is NOT null terminated. + +Host To Client: + 4 byte FLAP version (1) + +Client To Host: + 4 byte FLAP version (1) + 2 byte TLV Tag (1) + 2 byte Normalized User Name Length + N byte Normalized User Name (NOT null terminated) + + +TOC DATA FRAME TYPE +------------------- +Sequence Number contains the next sequence number. +Data Length is the length of the payload, including the null termination +from client to host. +