INTERNET-DRAFT Kent Cedola File: <draft-pfenning-irc-extensions-01.txt> Microsoft Corporation 13 February 1997 Thomas Pfenning Microsoft Corporation Extensions to the Internet Relay Chat Protocol (IRCX) 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 mate- rial or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as <draft- pfenning-irc-extensions-00.txt>, and expires July 13, 1997. Please send comments to the authors. 2. Abstract This document describes extensions to the Internet Relay Chat protocol defined in RFC 1459[1]. The added functionality includes optional user authentication for multiple security providers, support for UNICODE[2] characters, multilayer security, and a unified property mechanism. Chat server implementations can optionally support channel or server services with full control over all messages and events. These ser- vices communicate with the core server over an extended IRC connec- tion. All changes to the IRC protocol are designed in a way that existing clients will continue to work against servers implementing the exten- sions. Support for the extended protocol can be queried by clients to take advantage of the added functionality or to conform to the basic protocol as defined in RFC 1459. Cedola & Pfenning [Page 1]
INTERNET-DRAFT 13 February 1997 3. Modified UTF7 Encoding of UNICODE characters Allowing UNICODE characters for all user visible strings introduces a set of compatibility problems if the protocol must be backwards com- patible. While UTF7 encoding[1] maintains readability for pure ASCII strings, the BASE64 encoding of extended characters can contain char- acters which have a special meaning to the parser. In order to provide backwards compatibility with exisiting IRC clients and to allow new client to use a subset of UNICODE features on existing IRC server we introduce an additional postprocessing step on the result of an UTF7 translation. The quoting character for the postprocessing step is ''. All mappings are listed in the table below. +------------------------------------+ |Table 1 - Character Quoting in UTF7 | +----------------+-------------------+ | \b | for " " blank | | \c | for "," | | \\ | for "\" | | \r | for CR | | \n | for LF | +----------------+-------------------+ This mechanism is a first proposal and subject to change if we dicover a more general solution to this problem. Since a similar problem was discovered in the context of the IMAP protocol[3] it might be worth- while to define a new safe encoding of UNICODE which translates to alphanumeric characters only. It seems, that every special character has a special meaning in one or the other protocol. 4. Terms and Definitions Throughout the document we will use certain terms which are defined in this section. Cedola & Pfenning [Page 2]
INTERNET-DRAFT 13 February 1997 +------------------------------------------------------------------+ | Table 2 - Definition of Terms | +---------------+--------------------------------------------------+ | Chat Network | Chat Network is comprised of one or more | | | servers linked together. | | Server | A server is a single machine. | | Channel | A channel (sometimes called a room or confer- | | | ence) is conversation between one or more | | | users. | | Member | A member is a user that is part of a conversa- | | | tion in a channel. | | User | A user is a client that makes a connection to | | | the server. | | Objects | An object is a general term for channels, | | | users, members (users in a channel), and | | | servers. The type of object can be determined | | | from the first character of the object's name. | +---------------+--------------------------------------------------+ 4.1. User Access Levels Each client falls into one of eight level that define the ability to perform operations. Some levels are determined on the context of the operation to be performed. +------------------------------------------------------------------+ | Table 3 - Definition of Client Levels | +---------------------+--------------------------------------------+ | Chat Administrator | A Chat Administrator has full access to | | | all aspect of the server. | | Chat Service | A Chat Service is defined for external | | | application to provide extended services | | | to the chat network. Also refered to as | | | bots. | | A Chat Manager | A Chat Manager is a senior sysop access | | | level that is permitted a wider range of | | | opertions than a Chat Sysop. | | A Chat Sysop | A Chat Sysop is a user that is ability | | | to oversee and control the chat network. | | A Chat Owner | A Chat Owner is a owner of a channel | | | that has the ability to manage channel | | | hosts. | | A Chat Host | A Chat Host is a member of a channel | | | with the ability to manage a channel. | | | Also refered to as a channel operator. | | A Chat Member | An Chat Member is a member of a channel. | | A Chat User | An Chat User is a client connected to | | | the server. | +---------------------+--------------------------------------------+ Cedola & Pfenning [Page 3]
INTERNET-DRAFT 13 February 1997 4.2. Prefixes Each object contains a unique prefix that identifies the type of object. By tagging UNICODE objects with a special prefix a client can easily decide whether to use standard ASCII or UNICODE when sending a message to a user or channel. +-----------------------------------------------------------------+ | Table 4 - Object identifiers | +---------+-------------------------------------------------------+ | # | The '#' prefix identifies an IRC2 global channel. | | & | The '&' prefix identifies an IRC2 local channel. | | + | The '+' prefix identifies an IRC2 modeless channel. | | %# | The "%#" prefix identifies an extended global chan- | | | nel name which consist of a modified UTF7 encoded | | | Unicode string. | | %& | The "%&" prefix identifies an extended local chan- | | | nel name which consist of a modified UTF7 encoded | | | Unicode string. | | %+ | The "%+" prefix identifies an extended modeless | | | channel name which consist of a modified UTF7 | | | encoded Unicode string. | | % | The '%' character identifies the last channel that | | | this client specified and is a member of. The '%' | | | character must be followed by a space or comma. It | | | is used to optimize server processing of multiple | | | messages from a client to a channel. | | A to } | The 'A' through '}' prefix identifies a standard | | | IRC2 nick name. | | ' | The ''' prefix identifies an extended IRCX nick | | | name which consist of a modified UTF7 encoded Uni- | | | code string. The ''' character followed by a space | | | or comma represents the local client connection. | | 0 | The '0' prefix identifies an internal object iden- | | | tifier (OID). The OID consists of the '0' prefix | | | and 8 hexadecimal characters. The use of OID is | | | implementation dependent. | | $ | The '$' prefix identifies a server on the network. | | | Just '$' represents the local server the client is | | | connected to. | +---------+-------------------------------------------------------+ 5. Channels Channels support four mutually exclusive states of visibility; public, private, hidden and secret. The visibility of a channel effects which modes and properties are available to a client. Each mode/property is followed by a table that consists of a matrix of the channel's visi- bility state and each type of client. R/W is for Read/Write access, WO for Write Only access, RO for Read Only access, "-" for no access (can't be queried) and N/A for does not apply. These access rights are listed for the different adminstrative levels. Cedola & Pfenning [Page 4]
INTERNET-DRAFT 13 February 1997 5.1. Modes Each channel object contains a number of binary mode settings that can be queried and optionally updated via the IRC2 MODE and/or the IRCX MODEX command. The IRC2 mode, if available, is presented with the +<Letter> format after the name of the mode. 5.1.1. PUBLIC (IRC2 default) The channel is public and all information about the channel (except for text messages) can be queried by non-members. The PUBLIC mode is mutually exclusive with the PRIVATE, HIDDEN and SECRET modes. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO R/W R/W RO RO Private N/A N/A N/A N/A N/A N/A N/A N/A Hidden N/A N/A N/A N/A N/A N/A N/A N/A Secret N/A N/A N/A N/A N/A N/A N/A N/A 5.1.2. PRIVATE (IRC2 +P) The channel is private and only the name and number of members can be queried by non-members. The PRIVATE mode is mutually exclusive with the PUBLIC, HIDDEN and SECRET modes. Admin Service Manager Sysop Owner Host Member User Public N/A N/A N/A N/A N/A N/A N/A N/A Private R/W R/W RO RO R/W R/W RO RO Hidden N/A N/A N/A N/A N/A N/A N/A N/A Secret N/A N/A N/A N/A N/A N/A N/A N/A 5.1.3. HIDDEN (IRCX +Q) The channel is hidden and can not by located by enumeration queries. The HIDDEN mode is mutually exclusive with the PUBLIC, PRIVATE, and SECRET modes. The purpose of the new HIDDEN channel mode is to permit channels that can not be found using the standard LIST command, but properties can be queried if the exact name is known. Thus a HIDDEN channel is the same as a PUBLIC channel except that it can not be enu- merated by using the LIST command. Admin Service Manager Sysop Owner Host Member User Public N/A N/A N/A N/A N/A N/A N/A N/A Private N/A N/A N/A N/A N/A N/A N/A N/A Hidden R/W R/W RO RO R/W R/W RO RO Secret N/A N/A N/A N/A N/A N/A N/A N/A Cedola & Pfenning [Page 5]
INTERNET-DRAFT 13 February 1997 5.1.4. SECRET (IRC2 +S) The channel is secret and can not by located by any query. The SECRET mode is mutually exclusive with the PUBLIC, PRIVATE, and HIDDEN modes. Admin Service Manager Sysop Owner Host Member User Public N/A N/A N/A N/A N/A N/A N/A N/A Private N/A N/A N/A N/A N/A N/A N/A N/A Hidden N/A N/A N/A N/A N/A N/A N/A N/A Secret R/W R/W RO RO R/W R/W RO RO 5.1.5. MODERATED (IRC2 +M) The MODERATED mode changes the default speaker setting for new members to off. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO R/W R/W RO RO Private R/W R/W RO RO R/W R/W RO - Hidden R/W R/W RO RO R/W R/W RO RO Secret R/W R/W RO RO R/W R/W RO - 5.1.6. NOEXTERN (IRC2 +N) The NOEXTERN mode blocks messages from non-members to the channel. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO R/W R/W RO RO Private R/W R/W RO RO R/W R/W RO - Hidden R/W R/W RO RO R/W R/W RO RO Secret R/W R/W RO RO R/W R/W RO - 5.1.7. TOPICOP (IRC2 +T) The TOPICOP mode only permits channel hosts the ability to change the channel topic property. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO R/W R/W RO RO Private R/W R/W RO RO R/W R/W RO - Hidden R/W R/W RO RO R/W R/W RO RO Secret R/W R/W RO RO R/W R/W RO - 5.1.8. INVITE (IRC2 +I) The INVITE mode only permits invited users to enter the channel. Cedola & Pfenning [Page 6]
INTERNET-DRAFT 13 February 1997 Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO R/W R/W RO RO Private R/W R/W RO RO R/W R/W RO - Hidden R/W R/W RO RO R/W R/W RO RO Secret R/W R/W RO RO R/W R/W RO - 5.1.9. KNOCK (IRCX +J) The KNOCK extended mode causes a KNOCK message to be sent to all chan- nel hosts if an uninvited user attempts to join an invite only chan- nel. Useful for clients that wish to use custom access control of a channel and will automatically issue an invite to a select group of users. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO R/W RO RO RO Private R/W R/W RO RO R/W RO RO - Hidden R/W R/W RO RO R/W RO RO RO Secret R/W R/W RO RO R/W RO RO - 5.1.10. NODATA (IRCX +D) The NODATA channel mode will disable CTCP messages from being sent to a channel. A CTCP message is defined as a message that contains Control-A as the first character of the message text. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO R/W RO RO RO Private R/W R/W RO RO R/W RO RO - Hidden R/W R/W RO RO R/W RO RO RO Secret R/W R/W RO RO R/W RO RO - 5.1.11. NOFORMAT (IRCX +F) The NOFORMAT channel mode is an indication to the client application not to format text received from the chan- nel. Normally clients will prefix text messages with "x said y" or "x whispers to y and x", if the NOFORMAT mode is set then just the raw text should be displayed moving to the next line at the end of the message. The client should not echo text sent by the client. This is to permit custom applications to control the formatting to clients. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO R/W RO RO RO Private R/W R/W RO RO R/W RO RO - Hidden R/W R/W RO RO R/W RO RO RO Secret R/W R/W RO RO R/W RO RO - Cedola & Pfenning [Page 7]
INTERNET-DRAFT 13 February 1997 5.1.12. NOWHISPER (IRCX +W) The NOWHISPER channel mode will disable WHISPER messages from being sent to a channel. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO R/W RO RO RO Private R/W R/W RO RO R/W RO RO - Hidden R/W R/W RO RO R/W RO RO RO Secret R/W R/W RO RO R/W RO RO - 5.1.13. BROADCAST (IRCX +E) The BROADCAST channel mode is a special mode used for channels that will send information one way from channel hosts to channel members. Each member in a channel will only see themself in the channel. Client applications should expect messages from host members that do not appear in the channel member list via the WHO or NAMES commands. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO RO RO RO RO Private R/W R/W RO RO RO RO RO - Hidden R/W R/W RO RO RO RO RO RO Secret R/W R/W RO RO RO RO RO - 5.1.14. EXTERNAL (IRCX +X) The EXTERNAL channel mode restricts the visibility and messaging within a channel. Members will only see themself and other hosts in the channel. Any message sent by a member will only be received by the host members. Hosts will see all members in the channel and mes- sages from a host are seen by all members. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO R/W RO RO RO Private R/W R/W RO RO R/W RO RO - Hidden R/W R/W RO RO R/W RO RO RO Secret R/W R/W RO RO R/W RO RO - 5.1.15. REGISTERED (IRCX +R) The channel has been registered via a chat service. Cedola & Pfenning [Page 8]
INTERNET-DRAFT 13 February 1997 Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO RO RO RO RO Private R/W R/W RO RO RO RO RO - Hidden R/W R/W RO RO RO RO RO RO Secret R/W R/W RO RO RO RO RO - 5.1.16. SERVICE (IRCX +Z) A service is monitoring/controlling the channel. This is an indica- tion to the client that message traffic sent to the channel is being monitored by a Chat Service which does not appear as a member in the channel. The SERVICE flag is only set by the Chat Server. Admin Service Manager Sysop Owner Host Member User Public RO RO RO RO RO RO RO RO Private RO RO RO RO RO RO RO - Hidden RO RO RO RO RO RO RO RO Secret RO RO RO RO RO RO RO - 5.1.17. AUTHONLY The AUTHONLY channel mode restricts access to the channel to only users that have been authenticated by the server. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO R/W RO RO RO Private R/W R/W RO RO R/W RO RO - Hidden R/W R/W RO RO R/W RO RO RO Secret R/W R/W RO RO R/W RO RO - 5.1.18. CLONEABLE The CLONEABLE channel mode defines a channel that will create new clone channels if the parent channel is full. A clone channel is cre- ated with the same name as the parent cloneable channel with a numeric suffix starting at 1, ranging to 99. It is not valid to set the CLONEABLE channel mode of a channel that ends with a numeric charac- ter. When a clone channel is created, any channel that has the same name will be removed. This is to prevent channel take over of a clone channel. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO RO RO RO RO Private R/W R/W RO RO RO RO RO - Hidden R/W R/W RO RO RO RO RO RO Secret R/W R/W RO RO RO RO RO - Cedola & Pfenning [Page 9]
INTERNET-DRAFT 13 February 1997 5.1.19. CLONE The CLONE channel mode defines a channel that was created by the server when a parent CLONEABLE channel was full. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO (1) RO RO RO Private R/W R/W RO RO (1) RO RO - Hidden R/W R/W RO RO (1) RO RO RO Secret R/W R/W RO RO (1) RO RO - 1. The CLONE channel mode can only be set on a channel that has the same base name as a CLONEABLE channel the user is also an owner of. This is to permit a channel owner to pre-create clone channels. 5.2. Properties Each channel object contains a number of properties that can be queried and optionally updated via the IRCX PROP command. 5.2.1. OID (R/O) The OID channel property is the internal object identifier for the channel. The OID can be optionally used in place of the full string name of a channel as a short cut. If the OID is "0", then this fea- ture is not supported on the server. Admin Service Manager Sysop Owner Host Member User Public RO RO RO RO RO RO RO RO Private RO RO RO RO RO RO RO - Hidden RO RO RO RO RO RO RO RO Secret RO RO RO RO RO RO RO - 5.2.2. NAME (R/O) The NAME channel property is the name of the channel. Admin Service Manager Sysop Owner Host Member User Public RO RO RO RO RO RO RO RO Private RO RO RO RO RO RO RO - Hidden RO RO RO RO RO RO RO RO Secret RO RO RO RO RO RO RO - 5.2.3. KEYWORD The KEYWORD channel property is the keyword required to enter the channel. Cedola & Pfenning [Page 10]
INTERNET-DRAFT 13 February 1997 Admin Service Manager Sysop Owner Host Member User Public R/W R/W - - R/W R/W RO RO Private R/W R/W - - R/W R/W RO - Hidden R/W R/W - - R/W R/W RO RO Secret R/W R/W - - R/W R/W RO - 5.2.4. HOSTKEY The HOSTKEY channel property is the host keyword that will provide host (channel op) access when entering the channel. Admin Service Manager Sysop Owner Host Member User Public R/W R/W WO - R/W RO - - Private R/W R/W WO - R/W RO - - Hidden R/W R/W WO - R/W RO - - Secret R/W R/W WO - R/W RO - - 5.2.5. OWNERKEY The OWNERKEY channel property is the owner keyword that will provide owner access when entering the channel. Admin Service Manager Sysop Owner Host Member User Public R/W R/W - - R/W - - - Private R/W R/W - - R/W - - - Hidden R/W R/W - - R/W - - - Secret R/W R/W - - R/W - - - 5.2.6. TOPIC The TOPIC channel property is the current topic of the channel. Admin Service Manager Sysop Owner Host Member User Public R/W R/W RO RO R/W R/W (1) RO Private R/W R/W RO RO R/W R/W (1) - Hidden R/W R/W RO RO R/W R/W (1) RO Secret R/W R/W RO RO R/W R/W (1) - 1. The TOPIC property can only be set by members if the TOPICOP chan- nel mode is not set. 5.2.7. PICS The PICS channel property is the current PICS rating of the channel. Chat clients that are PICS enabled can use this property to determine if the channel is appropriate for the user. .LP Cedola & Pfenning [Page 11]
INTERNET-DRAFT 13 February 1997 Admin Service Manager Sysop Owner Host Member User Public R/W R/W R/W RO RO RO RO RO Private R/W R/W R/W RO RO RO RO RO Hidden R/W R/W R/W RO RO RO RO RO Secret R/W R/W R/W RO RO RO RO - 6. IRCX Server Messages This section summarizes all extended messages which can be send unso- licited from the server. 6.1. CLONE (new IRCX message) Informs the hosts in a CLONEABLE channel of the creation of a new CLONE channel. Syntax: CLONE <channel-name> <oid> 6.1.1. Parameters <channel-name> The name of the created CLONE channel. <oid> The object identifier for this new CLONE channel. The value is implementation dependent and must be 0 if not supported. 6.1.2. Remarks The CLONE message can be sent at anytime to the hosts of a CLONEABLE channel of the creation of a CLONE channel. Normally used by custom application to automatically join the new CLONE channel. 6.1.3. Example Server: CLONE #MyChat1 034F8FF32 6.2. EVENT (new IRCX message) Notification to the client of an event. Syntax 1: EVENT CHANNEL <time-stamp> CREATE <user> Syntax 2: EVENT CHANNEL <time-stamp> DELETE <user> Syntax 3: EVENT CHANNEL <time-stamp> KILL <user> :<reason> Syntax 4: EVENT MEMBER <time-stamp> JOIN <user> Cedola & Pfenning [Page 12]
INTERNET-DRAFT 13 February 1997 Syntax 5: EVENT MEMBER <time-stamp> PART <user> :<reason> Syntax 6: EVENT MEMBER <time-stamp> KICK <user> :<reason> Syntax 7: EVENT USER <time-stamp> REGISTER <user> <local-ip/port> <remote-ip/port> <access> Syntax 8: EVENT USER <time-stamp> QUIT <user> :<reason> Syntax 9: EVENT USER <time-stamp> KILL <user> :<reason> 6.2.1. Parameters <time-stamp> The number of seconds elapsed since midnight (00:00:00), January 1, 1970, coordinated universal time when the event occured on the server. <user> The user's nick, userid, host and server in nick!user@host$server format that triggered the event. <reason> {same as for REDIRECT} <local-ip:port> The local server IP address and port number of the <user>. <remote-ip:port> The remote client IP address and port number of the <user>. 6.2.2. Remarks The EVENT command is to use to define the events that the client is interested in. 6.3. REDIRECT (new IRCX message) Informs the client to connect to another server. Syntax: REDIRECT <server-list> :<reason> 6.3.1. Parameters <server-list> The server list is a comma seperated list of host:port pairs. That can be specified either as a FQDN or by the IP address in quuad dotted notation. <reason> The redirect reason is an implementation dependent string which can optionally be displayed at the client. If the string starts with a '%' character is is handled as modified UTF7 according to sec- tion 4. Cedola & Pfenning [Page 13]
INTERNET-DRAFT 13 February 1997 6.3.2. Remarks The REDIRECT message can be sent to the client at anytime to request the client to disconnect and reconnect to another server specified in the list. The REDIRECT message is generally sent when a server is to be shutdown. 6.3.3. Example Server: REDIRECT chat.corp.net:6667,134.9.3.3:6667 :Server full. 7. IRCX Client Messages All messages sent from the client to an IRCX server can optionally be tagged with a message prefix. This implies that the client has veri- fied, that the server it is talking to supports the extended IRC pro- tocol. A tag is a string enclosed in square brackets. Only the charac- ters [a-z,A-Z,0-9] are valid in a tag. The string can contain a mini- mum of 1 and a maxminum of 16 charcters. An empty string is not allowed. All replies from the server to a client message prefixed with a tag will have the same tag prepended. This feature allows the matching of replies to multiple outstandig messages and easy dispatch of messages to multithreaded clients. The tag will not be sent to other clients. Tagged data messages can be used for indicating a certain payload to other clients. Syntax [alphanumeric string] <IRCX-message> Parameters <IRCX-message> This argument is any valid client message according to the IRC or IRCX specification. 7.1. AUTH Command (new IRCX command) Authenticate the client using an SASL[4] authentication mechanism. The details of the authentication mechanisms is specified in a profile that should be registered with the IANA. Syntax 1: AUTH <name> <seq>: [<parameter>] Syntax 2 (from server to client only): AUTH <name> OK <ident> <uid> Cedola & Pfenning [Page 14]
INTERNET-DRAFT 13 February 1997 7.1.1. Parameters <name> The name of the SASL mechanism to use for authentication. The specific SASL mechanisms supported are implementation dependent. <seq> The sequence is a value of 'I' or 'S'. The 'I' value is speci- fied for the initial AUTH message and 'S' for all subsequence AUTH messages. If the client specifies '*' for the sequence the server will abort the authentication sequence and return IRCERR_AUTHENTICA- TIONFAILED. <parameter> This is optional data send as an argument with the AUTH messages. The content is depends on the autentication mechanism being used. <ident> The ident is the userid@domain of the authenticated client account. It is returned on the final response from the server (Syn- tax2) when authentication is successful. <uid> The uid is the internal object identifier assigned to the client connection. If not supported by the server then '0' must be returned. 7.1.2. Results: AUTH message IRCERR_ALREADYAUTHENTICATED IRCERR_ALREADYREGISTERED IRCERR_AUTHENTICATIONFAILED IRCERR_AUTHENTICATIONSUSPENDED IRCERR_BADCOMMAND IRCERR_BADPREFIX IRCERR_NEEDMOREPARAMS IRCERR_UNKNOWNPACKAGE 7.1.3. Remarks: If the server is known to support IRCX with specific SASL mechanism(s) then the first message must be the AUTH command (if authentication is to be used). If the server state is unknown, send the message "ISIRCX\r\nPING\r\n" and non IRCX servers will return the PONG reply without the IRCX message (or an error message and then the PONG), IRCX servers will return the IRCRPL_IRCX message (see IRCX command for more info) and then the PONG reply. The server will send the syntax 2 form when the authentication process is complete or a numeric error reply. 7.1.4. Example: Cedola & Pfenning [Page 15]
INTERNET-DRAFT 13 February 1997 Client: AUTH NTLM I: <-quoted blob data> Server: AUTH NTLM S: <-quoted blob data> Client: AUTH NTLM S: <-quoted blob data> Server: AUTH NTLM OK userid@domain 03FA4534C 7.2. EVENT (new IRCX command) Add/Change/Delete event logging to the client connection. Syntax 1: EVENT [ADD | DEL] <event> [<mask>] Syntax 2: EVENT LIST [<event>] 7.2.1. Parameters <event> Type of event, CHANNEL, MEMBER and USER. <mask> Option mask for apply a selection critical per event. 7.2.2. Results IRCRPL_EVENTADD IRCRPL_EVENTDELETE IRCRPL_EVENTLIST IRCRPL_EVENTEND IRCERR_NEEDMOREPARAMS IRCERR_BADFUNCTION IRCERR_EVENTDUP IRCERR_EVENTMIS IRCERR_NOSUCHEVENT IRCERR_TOOMANYEVENTS 7.2.3. Events See the EVENT section for IRCX Server Messages for more detail of gen- erated events. 7.2.4. Remarks The EVENT command is a sysop only function to select which events the client is interested in. 7.2.5. Examples Add channel events Cedola & Pfenning [Page 16]
INTERNET-DRAFT 13 February 1997 Client: EVENT ADD CHANNEL Server: 801 CHANNEL *!*@*$* Add list event with no active events returned Client: EVENT LIST Server: 803 CHANNEL *!*@*$* 804 * :End of events. 7.3. IRCX (new IRCX command) Enables IRCX mode and displays IRCX status. Syntax: IRCX 7.3.1. Parameters None. 7.3.2. Results IRCRPL_IRCX 7.3.3. Remarks Before a client is registered with a non-IRCX server, sending the ISIRCX command will result in no response from the server. Recommend sending the ISIRCX command followed by the PING command, and if a PONG is just returned then the server doesn't support IRCX. 7.3.4. Example Client: IRCX Server: :<host> 800 <nick> 1 0 NTLM,DPA,ANON * ://http:chat.mysite.net 7.4. ISIRCX (new IRCX command) Queries if the server supports the Extended IRC2 protocol (RCX). Syntax: ISIRCX Cedola & Pfenning [Page 17]
INTERNET-DRAFT 13 February 1997 7.4.1. Results IRCRPL_IRCX 7.4.2. Remarks Before a client is registered with a non-IRCX server, sending the ISIRCX command will result in no response from the server. Recommend sending the ISIRCX command followed by the PING command, and if a PONG is just returned then the server doesn't support IRCX. 7.4.3. Example Client: ISIRCX Server: :<host> 800<nick> 1 0 NTLM,DPA,ANON * ://http:chat.mysite.net 7.5. LIST (extension to IRC2 command) List channels with extended filters. Syntax 1: LIST [channel-list] Syntax 2: LIST [query-list] [query-list ...] 7.5.1. Parameters <query-list> One or more <query-terms> <query-term> This parameter allows the specification of certain fil- ters for the search operation. +------------------------------------------------------------------+ | Table 5 - Search filters for LIST command | +---------+--------------------------------------------------------+ | <# | Select channels with less than # members | | ># | Select channels with more than # members | | C<# | Select channels created less than # minutes ago | | C># | Select channels created greater than # minutes ago | | T<# | Select channels with a topic changed less than # | | | minutes ago | | T># | Select channels with a topic changed greater than # | | | minutes ago | +---------+--------------------------------------------------------+ Cedola & Pfenning [Page 18]
INTERNET-DRAFT 13 February 1997 7.5.2. Results Same as defined in RFC 1459. 7.5.3. Remarks The LIST extension was first implemented for the Undernet version of the standard IRC2 server. 7.6. MODE (extension to IRC2 command) Enumerates, adds or changes modes of a channel or user. Syntax 1: MODE <nick> Syntax 2: MODE <nick> {+ | - } { o } 7.6.1. Parameters <nick> The nick name of a user. 7.6.2. Results MODE message IRCERR_NOPRIVILEGES 7.6.3. Remarks Client that have authenticated as a sysop can enable or disable their sysop access via the +/- o mode parameter. 7.6.4. Example Client: MODE MyNick -o Server: MODE MyNick -o 7.7. MODEX (new IRCX command) Enumerates, adds or changes extended modes of a channel or user. Syntax 1: MODEX <object> Syntax 2: MODEX <object> {+ | -} <modex> [...] Cedola & Pfenning [Page 19]
INTERNET-DRAFT 13 February 1997 7.7.1. Parameters <object> The name of a user, channel, member or server. <modex> An extended mode (see MODEX under the specific object type). 7.7.2. Results MODEX message IRCRPL_MODELIST IRCRPL_MODELIST2 IRCRPL_MODEEND IRCRPL_BADMODE IRCERR_NOPRIVILEGES IRCERR_CHANOPRIVSNEEDED IRCERR_CHANOWNPRIVSNEEDED 7.7.3. Remarks The MODEX command is a replacement to the standard IRC2 MODE command, but unlike the single character letter used by MODE, MODEX supports named mode settings. The MODEX command only effects binary (on or off) modes of an object. To issue a MODEX command on a channel member, the <object> field con- sists of the channel name, followed by a comma and then the nick of the member. For example, "MODEX #MyChannel,Nick" to list the modes of the user Nick member information in the channel #MyChannel. The IRCRPL_MODELIST (805) message contains the channel modes settable by client connections, the IRCRPL_MODELIST2 (806) message contains the channel flags that are only settable by the server or a chat service. If an error occurs, no modes are updated. 7.7.4. Examples Client: MODEX #MyChannel Server: 805 #MyChannel PUBLIC TOPICOP NOEXTERN 806 #MyChannel PERSISTENT 807 #MyChannel :End of modes Longer transaction with query and setting of particular modes. Cedola & Pfenning [Page 20]
INTERNET-DRAFT 13 February 1997 Client: MODEX #MyChannel Server: 805 #MyChannel PUBLIC TOPICOP NOEXTERN 807 #MyChannel :End of modes Client: MODEX #MyChannel +PRIVATE -TOPICOP +NODATA +NOWHISPER Server: MODEX #MyChannel +PRIVATE +NOEXTERN +NODATA +NOWHISPER Client: MODEX #MyChannel Server: 805 #MyChannel PRIVATE NOEXTERN NODATA NOWHISPER 807 #MyChannel :End of modes 7.8. NOTICE (extension to IRC2 command) Send a notice to a channel or user. Syntax 1: NOTICE <channel|nick> :<message> Syntax 2: NOTICE <channel> <nick-list> :<message> 7.8.1. Results Same as defined in RFC 1459. 7.9. PRIVMSG (extension to IRC2 command) Send a message to a channel or user. Syntax 1: PRIVMSG <channel|nick> :<message> Sybtax 2: PRIVMSG <channel> <nick-list> :<message> 7.9.1. Results Same as defined in RFC 1459. 7.10. PROP (new IRCX command) Add/Changes/Deletes a channel data property. Syntax 1: PROP <channel> Syntax 2: PROP <channel> * Cedola & Pfenning [Page 21]
INTERNET-DRAFT 13 February 1997 Syntax 3: PROP <channel> <property>[,<property>] Syntax 4: PROP <channel> <property> :<data> 7.10.1. Results PROP message IRCRPL_PROPLIST IRCRPL_PROPEND IRCRPL_PROPVALUE IRCERR_BADPROPERTY IRCERR_NOPRIVILEGES IRCERR_CHANOPRIVSNEEDED IRCERR_CHANOWNPRIVSNEEDED 7.10.2. Remarks The PROP command provides a new method for manipulating string and number properties of server, user, channel and member objects based of a label name. Members of channels are defined by specifying the name of the member's channel, a comma delimited, followed by the user's nick. 7.10.3. Examples Client: PROP #MyChannel Server: 808 #MyChannel TOPIC HOSTKEY PICS 809 #MyChannel :End of properties Client: PROP #MyChannel TOPIC Server: 810 #MyChannel TOPIC :This is the topic of my channel Client: PROP #MyChannel TOPIC :Change my channel topic to something Server: PROP #MyChannel TOPIC :Change my channel topic to something 7.11. WHISPER (new IRCX command) Whisper to member(s) in a channel. Syntax: WHISPER <channel> <nick-list> :<message> 7.11.1. Results Cedola & Pfenning [Page 22]
INTERNET-DRAFT 13 February 1997 WHISPER message IRCERR_NEEDMOREPARAMS IRCERR_NORECIPIENT IRCERR_NOTEXTTOSEND IRCERR_NOTONCHANNEL IRCERR_CANNOTSENDTOCHANNEL IRCERR_TOOMANYTARGETS IRCERR_NOSUCHNICK IRCERR_NOSUCHCHANNEL 7.11.2. Remarks The purpose of the WHISPER command is to whisper to one or more mem- bers in a channel within the context of that channel. IRCX clients must display the WHISPER message within the context (window) of the channel specified. 8. IRCX Command Responses The new extended IRCX numeric replies follow the same convention as with IRC with a specific range for command responses and another range for error results. The IRCX command responses are in the ranage of 800 to 899 and 900 to 999 for the error results. The prefix field is optional if the host generating the error is the same as the host the client is connected to. 8.1. Command Replies 800 - IRCRPL_IRCX <state> <version> <package-list> <option-list> :<admin url> The response to the IRCX command. The <state> indicates if the has IRCX mode enabled (0 for disabled, 1 for enabled). The <version> is the version of the IRCX protocol starting at 0. The <package-list> contains a list of authentication packages supported by the server. The package name of "ANON" is reserved to indicate anonymous connec- tions are permitted. The <option-list> contains a list of options supported by the server; theses are implementation dependent. If no options are available, the '*' character should be used. The <admin- url> field contains an administrator defined URL. 801 - IRCRPL_EVENTADD <event> <mask> The acknowledgment response to the EVENT ADD command. The <event> contains the name of the event added. The <mask> is the selection Cedola & Pfenning [Page 23]
INTERNET-DRAFT 13 February 1997 mask. If no mask was provided in the EVENT command, then the default mask of *!*@*$* is used. 802 - IRCRPL_EVENTDEL <event> <mask> The acknowledgment response to the EVENT DEL command. The <event> contains the name of the event deleted. The <mask> is the selection mask. If no mask was provided in the EVENT command, then the default mask of *!*@*$* is used. 803 - IRCRPL_EVENTLIST <event> <mask> Response to the EVENT LIST <event> message to display a list of cur- rent events the client is interested in. 804 - IRCRPL_EVENTEND :End of events Response to the EVENT LIST <event> message to indicate the end of the event list. 805 - IRCRPL_MODELIST <object> <mode-list> Response to the MODEX command of extended modes. 806 - IRCRPL_MODELIST2 <object> <mode-list> Response to the MODEX command of extended flags that are only set by the server. 807 - IRCRPL_MODEEND <object> :End of modes Last message in an extended mode list. 808 - IRCRPL_PROPLIST Cedola & Pfenning [Page 24]
INTERNET-DRAFT 13 February 1997 <object> <property-list> Response to the PROP command to list properties of an object. Multi- ple IRCRPL_PROPLIST messages can be generated per list. 809 - IRCRPL_PROPEND <object> :End of properties Last message in a property list. 810 - IRCRPL_PROPVALUE <object> <property> :<value> Response to a PROP query of a specific property. 8.2. IRCX Error Replies. 900 - IRCERR_BADCOMMAND <command> :Bad command In response to an incorrectly formatted command. 901 - IRCERR_BADPREFIX <command> :Bad command prefix specified A message prefix is not supported for this command. 902 - IRCERR_BADTAG <channel> <property> :Bad property specified The message tag is incorrect. 903 - IRCERR_ALREADYAUTHENTICATED <package> :Already authentication The client has already authenticated with the server. 904 - IRCERR_AUTHENTICATIONFAILED Cedola & Pfenning [Page 25]
INTERNET-DRAFT 13 February 1997 <package> :Authentication failed The authentication failed due to a bad userid/password or server/net- work failure. 905 - IRCERR_AUTHENTICATIONSUSPENDED <package> :Authentication suspended for this IP Authentication has been temporary disabled due to too many authentica- tion failures from this IP. 906 - IRCERR_UNKNOWNPACKAGE <package> :Unsupported authentication package The authentication package specified is not known to the server. ISIRCX command will return a list of supported authentication pack- ages. 907 - IRCERR_EVENTDUP <event> <mask> :Duplicate event entry 908 - IRCERR_EVENTMIS <event> <mask> :Unknown event entry 909 - IRCERR_NOSUCHEVENT <event> :No such event type 10 - IRCERR_TOOMANYEVENTS <event> :Too many events specifed 911 - IRCERR_UNKNOWNFUNCTION <command> :Unknown function A unknown command function was specified. 912 - IRCERR_UNKNOWNMODE <mode> :Unknown mode Cedola & Pfenning [Page 26]
INTERNET-DRAFT 13 February 1997 913 - IRCERR_UNKNOWNPROPERTY <property> :Unknown property 914 - IRCERR_NODATA <object> :Does not permit data messages 915 - IRCERR_NOWHISPER <object> :Does not permit whisper messages 916 - IRCERR_NOREMOTE <object> :Does not remote clients to join this channel 917 - IRCERR_RESTRICTED <command> :Restricted by the administrator The command/function/operation was not executed due to an administra- tor restriction on this client connection. 918 - IRCERR_SECURITY <command> :Security failure The command/function/operation is not permited for this level of client due to security. 999 - IRCERR_INTERNALERROR :Internal error code <error-code> Internal error generated that doesn't map to a valid IRCX error reply. The error code is implementation dependent. 9. Security Considerations Security issues are discussed in the authentication section. The IRCX command returns a set of authentication mechanisms supported by the server. This method is open to a middle man attack whereby an attacker modifies the list of returned authentication method and only offer a cleartext password transaction. In order to avoid this type of attack only authentication methods with a challenge response mechanism Cedola & Pfenning [Page 27]
INTERNET-DRAFT 13 February 1997 should be used whenever security is a concern. Since all administration commands for IRC and IRCX are send in cleart- ext a stream layer encryption mechanism like SSL[5] or IPSEC is required to protect the integrity and confidentiality of the transac- tions. The mechanisms for establishing these connection are outside the scope of this document. 10. References [1] "Internet Relay Chat Protocol", Network Working Group RFC 1459, J. Oikarinen, D. Reed, May 1993 [2] The Unicode Consortium, "The Unicode Standard Version 2.0", Addi- son Wesley Developers Press, July 1996 [3] "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", Network Work- ing Group RFC 2060, M. Crispin, December 1996 [4] "Simple Authentication and Security Layer (SASL)", Work in Progress, draft-myers-auth-sasl-07.txt, J. Myers, December 1996 [5] "The SSL Protocol Version 3.0", Work in Progress, draft-ietf-tls- ssl-version3-00.txt, Alan O. Freier, Philip Karlton, Paul C. Kocher, November 1996 11. Authors' Addresses Kent Cedola Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: kentce@microsoft.com Thomas Pfenning Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: thomaspf@microsoft.com Cedola & Pfenning [Page 28]