Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-pfenning-irc-extensions-02.txt < prev next >

Wrap

Text File | 1997-08-21 | 86KB | 2,575 lines

INTERNET-DRAFT Kent Cedola File: <draft-pfenning-irc-extensions-02.txt> Lisa Dusseault 20 August 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-01.txt>, and expires February 25, 1998. Please send comments to the authors. 2. Abstract This document describes extensions to the Internet Relay Chat (IRC) protocol defined in RFC 1459[1]. Only client-server interactions are defined. 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 services communicate with the core server over an extended IRC connection. 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 RFC1459. Cedola, Dusseault & Pfenning [Page 1] INTERNET-DRAFT 20 August 1997 3. Modified UTF8 Encoding of UNICODE characters Allowing UNICODE characters for all user visible strings introduces a set of compatibility problems if the protocol must be backward compat- ible. UTF8 encoding is used to convert wide UNICODE characters into a string compatible with existing IRC servers and clients. To permit the full range of UNICODE characters, we must introduce an additional postprocessing step on the result of an UTF8 translation. Any string beginning with a '%' character (i.e. "reason" strings within a REDIRECT command) may be interpreted as UTF8-encoded UNICODE strings. UNICODE characters encoded in UTF8 may use more bytes than an ASCII character. To ensure compatibility, UNICODE strings such as nicknames and channel names must fit within the standard length measured in bytes, not in characters. The quoting character for the postprocessing step is the '\' charac- ter. All mappings are listed in the table below. +------------------------------------+ |Table 1 - Character Quoting in UTF8 | +----------------+-------------------+ | \b | for " " blank | | \c | for "," | | \\ | for "\" | | \r | for CR | | \n | for LF | | \t | for TAB | +----------------+-------------------+ IRCX clients will view UNICODE strings in their native form. So that non-IRCX clients can interoperate with UNICODE nicks, UNICODE nicks are translated by the server into a usable form before being sent to the non-IRCX client. Usable format is a simple hex format preceded by a '^' character. Non-IRCX clients can use this hex format nickname to specify the IRCX/UNICODE user. The server may prevent duplicate nicks by preventing users from setting their nick to a valid hex translation (a '^' character followed by an even number of hex characters). 4. Terms and Definitions Throughout this document we will use certain terms which are defined in the following pages. String lengths are indicated in "characters", referring to ASCII char- acters, because even UNICODE strings must be encoded in ASCII for the IRC protocol. Cedola, Dusseault & Pfenning [Page 2] INTERNET-DRAFT 20 August 1997 +------------------------------------------------------------------+ | Table 2 - Definition of Terms | +---------------+--------------------------------------------------+ | Chat Network | A 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 a 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 There are six user levels that define the ability of the user to per- form 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 | | | the server. | | Chat Sysop | A Chat Sysop oversees and controls the | | | chat network. | | Channel Owner | A Channel Owner manages a channel and | | | the channel hosts. | | Channel Host | A Channel Host manages a channel. Also | | | referred to as a channel operator. | | Channel Member | A Channel Member is a member of a chan- | | | nel. | | Chat User | A Chat User is a client connected to the | | | server. | +---------------------+--------------------------------------------+ 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 send- ing a message to a user or channel. The IRCX client is responsible, when sending a UNICODE string, for prefixing it with a '%' character so that other IRCX clients can interpret it as UNICODE. Cedola, Dusseault & Pfenning [Page 3] INTERNET-DRAFT 20 August 1997 +-----------------------------------------------------------------+ | Table 4 - Object identifiers | +---------+-------------------------------------------------------+ | # | The '#' prefix identifies a RFC1459 global channel. | | & | The '&' prefix identifies a RFC1459 local channel. | | %# | The "%#" prefix identifies an extended global chan- | | | nel name (a modified UTF8-encoded UNICODE string). | | %& | The "%&" prefix identifies an extended local chan- | | | nel name (a modified UTF8-encoded UNICODE string). | | % | The '%' character followed by a space or comma can | | | identify the last channel that this client speci- | | | fied and is a member of. Its function is to opti- | | | mize server processing of multiple messages from a | | | client to a channel. Support for this feature is | | | optional. | | A to } | The 'A' through '}' prefix identifies a standard | | | RFC1459 nickname. | | ' | The ''' prefix identifies an extended IRCX nickname | | | which consists of a modified UTF8-encoded UNICODE | | | string. The ''' character followed by a space or | | | comma may be used to represent the local client | | | connection (support for this feature is optional). | | | The characters following ''' can be '0' through | | | '9', '-', and any character above 'A'. | | ^ | The '^' prefix identifies a nickname which was | | | translated from UTF8 into hex characters so that | | | the nickname can be viewed by non-IRCX clients. | | | The characters following '^' can be any standard | | | RFC1459 nickname characters. | | 0 | The '0' prefix identifies an internal object iden- | | | tifier (OID). The OID consists of the '0' prefix | | | and eight hexadecimal characters. Use of the OID | | | is implementation dependent. | | $ | The '$' prefix identifies a server on the network. | | | The '$' character followed by a space or comma may | | | be used to represent the local server the client is | | | connected to (support for this feature is | | | optional). | +---------+-------------------------------------------------------+ 5. IRCX Client Messages This section details commands which have been added and commands which have changed from RFC1459. Responses from the server are discussed in greater detail in later sections. 5.1. ACCESS command (new IRCX command) Create an "access entry" for an object to grant or deny access to an object, including a channel, a user, or the server. ACCESS LIST is used to list all access entries for an object and CLEAR is used to clear all entries or all entries of the same level. Syntax 1: ACCESS <object> LIST Cedola, Dusseault & Pfenning [Page 4] INTERNET-DRAFT 20 August 1997 Syntax 2: ACCESS <object> ADD|DELETE <level> <mask> [<timeout>] [:<reason>] Syntax 3: ACCESS <object> CLEAR [<level>] 5.1.1. Parameters <object> The object to which access is being granted or limited. Can be: <channel> Channel <nick> Nickname $ Chat server to which the command is sent * All chat servers on the network <level> The level of access being given or taken away. Can be: DENY Disallow access to an object that is accessible GRANT Allow access to an object that is inaccessible HOST Channel host access to specified channel OWNER Channel owner access to specified channel VOICE Voice access to specified channel <mask> Mask to identify user by nickname, userid, host or server characteristics. Supports wildcards * and ?. <timeout> Minutes until the access entry is removed. A value of 0 indicates unlimited duration. <reason> Text reason shown when users are denied access due to the access entry. 5.1.2. Results IRCRPL_ACCESSADD IRCRPL_ACCESSDELETE IRCRPL_ACCESSSTART IRCRPL_ACCESSLIST IRCRPL_ACCESSEND 5.1.3. Possible Errors In this specification possible error messages are listed. Which error messages are used is dependent on the server implementation. Cedola, Dusseault & Pfenning [Page 5] INTERNET-DRAFT 20 August 1997 IRCERR_BADLEVEL IRCERR_DUPACCESS IRCERR_MISACCESS IRCERR_TOOMANYACCESSES IRCERR_TOOMANYARGUMENTS IRCERR_BADCOMMAND IRCERR_SECURITY 5.1.4. Remarks An object with GRANT access entries but no DENY entries is assumed to be off-limits to those users not covered by the GRANT entries. If there are multiple entries in the access list, the list is processed in the following order: OWNER, HOST, VOICE, GRANT, DENY. Hosts and Owners may add and delete access entries for their channel. Hosts may not remove access entries added by owners. Any user may add and delete access entries for themselves. Sysops and admins on a server may add and delete access entries for that server or the entire network. A user who has blocked another user should not get any messages from the blocked user, including invites. 5.1.5. Example: To make a user a channel host when they join the channel: ACCESS #mychan ADD HOST piper To grant normal access to the network to a few people but deny access to all others: ACCESS * ADD DENY * :closed for private party ACCESS * ADD GRANT *.company.com :these are the people that can get on To delete the DENY access record on the network that denies access to '*' (note that this doesn't delete other DENY access records such as '*.com'): ACCESS * DELETE DENY * To clear all DENY-level entries on the local server: ACCESS $ CLEAR DENY To clear all access entries of any level for a channel: ACCESS #mychan CLEAR Cedola, Dusseault & Pfenning [Page 6] INTERNET-DRAFT 20 August 1997 5.2. AUTH Command (new IRCX command) Authenticate the client using an SASL[4] authentication mechanism. The details of the authentication mechanisms are specified in a profile that should be registered with the IANA. Syntax 1: AUTH <name> <seq>: [<parameter>] 5.2.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 the 'S' value is specified for all subsequent AUTH messages. If the client specifies '*' for the sequence, the server will abort the authentication sequence and return IRCERR_AUTHENTICATIONFAILED. <parameter> This is optional data sent as an argument with the AUTH messages. The content depends on the authentication mechanism being used. All content must use standard escaping formats (eg. \r for car- riage return) to comply with IRC message format restrictions. 5.2.2. Results AUTH message 5.2.3. Possible Errors IRCERR_ALREADYAUTHENTICATED IRCERR_ALREADYREGISTERED IRCERR_AUTHENTICATIONFAILED IRCERR_AUTHENTICATIONSUSPENDED IRCERR_BADCOMMAND IRCERR_NEEDMOREPARAMS IRCERR_UNKNOWNPACKAGE 5.2.4. Remarks: If the server is known to support IRCX with specific SASL mecha- nism(s), then the first message must be the AUTH command (if authenti- cation is to be used), before the USER and NICK commands. Use MODE ISIRCX to determine if the server supports IRCX. 5.2.5. Example: Cedola, Dusseault & Pfenning [Page 7] INTERNET-DRAFT 20 August 1997 Client: AUTH NTLM I: <data> Server: AUTH NTLM S: <data> Client: AUTH NTLM S: <data> Server: AUTH NTLM * userid@domain 03FA4534C 5.3. CREATE (new IRCX command) Create a new channel and/or join an existing channel. Syntax: CREATE <channel> <modes> [<modeargs>] 5.3.1. Parameters <channel> The name of the channel. <modes> Initial channel modes, not separated by spaces (like MODE command). Includes mode 'e' to force a clone of a clonable channel. <modeargs> Optional mode arguments, separated by spaces, in the same order as the modes. For the mode 'l' the mode argument is the maximum number of members in the channel. For the mode 'k' the mode argument is the channel keyword. These are the only modes that require mode arguments. 5.3.2. Results CREATE message JOIN message. RPL_TOPIC RPL_NAMEPLY RPL_ENDOFNAMES 5.3.3. Possible Errors IRCERR_CHANNELEXIST IRCERR_ALREADYONCHANNEL ERR_NEEDMOREPARAMS ERR_INVITEONLYCHAN ERR_CHANNELISFULL ERR_BANNEDFROMCHAN ERR_BADCHANNELKEY ERR_TOOMANYCHANNELS ERR_UNKNOWNCOMMAND 5.3.4. Remarks The CREATE command provides a method to specify channel properties at creation time, and also provides a method (flag 'c') to create and join a channel only if it does not already exist. If user is not in IRCX mode, server returns ERR_UNKNOWNCOMMAND. Cedola, Dusseault & Pfenning [Page 8] INTERNET-DRAFT 20 August 1997 5.3.5. Examples This example shows the creation of a moderated (m) channel with the following properties and modes: its topic can only be changed by an owner or host (t = TOPICOP), messages from outside the channel are blocked (n = NOEXTERN), it is limited to 50 members (l 50), it has a member key which is 'password' (k password), and it will be created only if it doesn't already exist (c = CREATE) Client: CREATE #MyChannel tnmlkc 50 password Server: CREATE #MyChannel 048532944 5.4. DATA / REQUEST / REPLY Used to send tagged data, requests or replies. The syntax for each is the same, but clients can use REQUEST to indicate that a REPLY is desired, and use REPLY to indicate that a REQUEST was issued. If user is not in IRCX mode, server returns ERR_UNKNOWNCOMMAND. Syntax 1: DATA <target> <tag> :<message> 5.4.1. Parameters <target> The target for the data. Target can be a nick, list of nicks, channel, list of channels, or channel followed by a list of some members of the channel. This definition for <target> will be used throughout this document. <tag> Text field that clients use to know how to interpret the data. Valid characters are [A..z], [0..9] and period (.). The first charac- ter must be one of [A..z]. Maximum 15 characters. If the tag begins with SYS or ADM then the originator must have sysop or admin privi- leges. The server itself can send tags beginning with SYS or ADM. <message> Payload or data for the message, ending with a newline. Any newlines or other control characters within the body of the mes- sage must be escaped. 5.4.2. Results DATA message 5.4.3. Possible Errors ERR_UNKNOWNCOMMAND Cedola, Dusseault & Pfenning [Page 9] INTERNET-DRAFT 20 August 1997 5.4.4. Remarks REPLY and REQUEST may be used to replace "DATA". IRCX servers should not send DATA commands to clients that have not indicated that they support IRCX. Clients should only process DATA messages if they know and support the tag used. Prefixes should indicate the organization that specified them, when appropriate. For example: MYORG.AVATAR could be a tag used by MyOrg, as would be all MYORG.* tags. 5.4.5. Example Sending ad banners from server admin to channel DATA #Channel SYS.AD.SMALL :<url-stuff> 5.5. EVENT (new IRCX command) Add/Change/Delete event logging to the client connection. The list of event types and the way masks are applied may vary depending on the server implementation. Syntax 1: EVENT [ADD | DELETE] <event> [<mask>] Syntax 2: EVENT LIST [<event>] 5.5.1. Parameters <event> Type of event, such as CHANNEL, MEMBER, SERVER, CONNECTION, SOCKET or USER. <mask> Optional mask for applying a selection criteria per event. 5.5.2. Results IRCRPL_EVENTADD IRCRPL_EVENTDEL IRCRPL_EVENTSTART IRCRPL_EVENTLIST IRCRPL_EVENTEND 5.5.3. Possible Errors IRCERR_NEEDMOREPARAMS IRCERR_BADFUNCTION IRCERR_EVENTDUP IRCERR_EVENTMIS IRCERR_NOSUCHEVENT IRCERR_TOOMANYEVENTS ERR_NOPRIVILEGES Cedola, Dusseault & Pfenning [Page 10] INTERNET-DRAFT 20 August 1997 5.5.4. Remarks Use the EVENT command to define the events that an admin or sysop wishes to be notified of. The format above is the recommended format for this optional command. It is advised that only admins and/or sysops be allowed to receive event messages. 5.5.5. Examples: Add channel events. Client: EVENT ADD CHANNEL Server: :<host> 806 <nick> CHANNEL *!*@*$* Add a list event with no active events returned. Client: EVENT LIST Server: :<host> 808 <nick> :Start of events :<host> 809 <nick> CHANNEL *!*@*$* :<host> 810 <nick> :End of events. 5.6. IRCX (new IRCX command) Enables IRCX mode and displays IRCX status. Use MODE ISIRCX first to see if the server supports IRCX. Syntax: IRCX 5.6.1. Parameters None. 5.6.2. Results IRCRPL_IRCX 5.6.3. Example This example includes a server that supports IRCX and three authenti- cation packages. Client: IRCX Server: :<host> 800 <nick> 1 0 NTLM,DPA,ANON 512 * 5.7. ISIRCX (new IRCX command) Queries whether or not the server supports the Extended RFC1459 proto- col (IRCX). Server response is same as for IRCX message. Syntax: ISIRCX Cedola, Dusseault & Pfenning [Page 11] INTERNET-DRAFT 20 August 1997 5.7.1. Results IRCRPL_IRCX 5.8. LISTX (new IRCX command) Extended version of the LIST command that returns additional channel properties. Channels with extended names will be returned, even to non-IRCX clients. Some channel modes and the PICS rating string are included with the result. Only the channel modes that do not define an additional argument (TOPICOP, NOEXTERN, etc.) are included in the <modes> field. Clients should use the query limit to avoid overloading the client or having the connection dropped by the server. Syntax 1: LISTX [<channel list>] Syntax 2: LISTX <query list> [<query limit>] 5.8.1. Parameters <channel list> A list of channels may be specified in order to find the PICS ratings or modes of those channels. If no channels are spec- ified, the server will send the entire matching list of channels. <query list> One or more query terms separated by spaces or commas. +--------------------------------------------------------------------+ | Table 5 - Query terms 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 | | L=<mask> | Select channels with language property matching the | | | mask string | | N=<mask> | Select channels with name matching the mask string | | R=0 | Select unregistered channels | | R=1 | Select registered channels | | S=<mask> | Select channels with subject matching the mask | | | string | | T<# | Select channels with a topic changed less than # | | | minutes ago | | T># | Select channels with a topic changed greater than # | | | minutes ago | | T=<mask> | Select channels that topic matches the mask string | +-----------+--------------------------------------------------------+ <query limit> Maximum number of channels to be returned. <mask> Sequence of characters that is used to select a matching chan- nel name or topic. The character * and ? are used for wildcard Cedola, Dusseault & Pfenning [Page 12] INTERNET-DRAFT 20 August 1997 searches. 5.8.2. Results IRCRPL_LISTXSTART IRCRPL_LISTXLIST IRCRPL_LISTXPICS IRCRPL_LISTXTRUNC IRCRPL_LISTXEND 5.8.3. Remarks To compose a mask, use this character escaping scheme. +--------------------------------------------+ |Table 6 - Character escaping in mask-string | +--------------------+-----------------------+ | \b | for " " blank | | \c | for "," | | \\ | for "\" | | \* | for * | | \? | for ? | +--------------------+-----------------------+ The PICS property is only returned if not null. A record limit of '0' (zero) or blank will be interpreted as unlim- ited. 5.9. MODE (extension to RFC1459 command) MODE command can now be used for new user or channel modes (see later sections). In addition, the special syntax "MODE ISIRCX" can be used to help clients find out whether a server supports IRCX. Syntax: MODE ISIRCX 5.9.1. Results MODE message IRCRPL_IRCX 5.9.2. Remarks The ISIRCX mode (must be in capital letters) is only functional before the user has registered with the server. IRCX servers respond with IRCRPL_IRCX and non-IRCX servers should return an error code. This allows unregistered users to query whether the server supports IRCX. See RFC1459 for more details on the original MODE command and its Cedola, Dusseault & Pfenning [Page 13] INTERNET-DRAFT 20 August 1997 parameters. 5.10. NOTICE (extension to RFC1459 command) Sends a notice to a channel or user. In RFC1459 a notice could only be sent to a channel or a list of users. Now a notice can be sent to a list of users within the context of a channel. As before, users will not get the list of users that received the notice. Syntax: NOTICE <target> :<message> 5.10.1. Results Same as defined in RFC1459, but with the additional functionality of sending to a list of nicknames within the context of a channel. 5.11. PRIVMSG (extension to RFC1459 command) Sends a message to a channel or user. PRIVMSG is extended in the same way as NOTICE. Syntax: PRIVMSG <target> :<message> 5.11.1. Results Same as defined in RFC1459, but with the additional functionality of sending to a list of nicknames within the context of a channel. 5.12. PROP (new IRCX command) Add, change or delete a channel data property. To query a property: Syntax 1: PROP <channel> <property>[,<property>] To set or change a property: Syntax 2: PROP <channel> <property> :<data> To delete a property: Syntax 3: PROP <channel> <property> : 5.12.1. Results PROP message IRCRPL_PROPLIST IRCRPL_PROPEND Cedola, Dusseault & Pfenning [Page 14] INTERNET-DRAFT 20 August 1997 5.12.2. Possible Errors IRCERR_BADCOMMAND IRCERR_BADPROPERTY IRCERR_SECURITY IRCERR_NOSUCHOBJECT IRCERR_TOOMANYARGUMENTS IRCERR_BADVALUE 5.12.3. Remarks The PROP command provides a new method for manipulating string and numeric properties of channels. If an optional channel property is not supported on the server, the server should return IRCERR_BADPROP- ERTY. See section 8.2 for definitions of channel properties. 5.12.4. Examples Client: PROP #MyChan TOPIC,ONJOIN Server: :<host> 818 <nick> #MyChan TOPIC :This is the topic of my channel Server: :<host> 818 <nick> #MyChan ONJOIN :Welcome to my channel! Server: :<host> 819 <nick> #MyChan :End of properties Client: PROP #MyChannel TOPIC :Change my channel topic to something Server: PROP #MyChannel TOPIC :Change my channel topic to something 5.13. WHISPER (new IRCX command) Whisper to member(s) in a channel. Syntax: WHISPER <channel> <nick-list> :<message> 5.13.1. Results WHISPER message 5.13.2. Possible Errors ERR_UNKNOWNCOMMAND IRCERR_NEEDMOREPARAMS IRCERR_NOTONCHANNEL IRCERR_CANNOTSENDTOCHANNEL IRCERR_TOOMANYTARGETS IRCERR_NOSUCHNICK IRCERR_NOSUCHCHANNEL IRCERR_NOWHISPER ERR_USERNOTINCHANNEL Cedola, Dusseault & Pfenning [Page 15] INTERNET-DRAFT 20 August 1997 5.13.3. 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. The sender and all recipients must be in the channel specified. IRCX clients should display the WHISPER message within the context (window) of the specified channel. Non-IRCX clients may receive a PRIVMSG with the content of the whisper. Only one whisper will be sent per nick. A user may whisper to themselves. The channel mode 'w' will disable whispers between ordinary members of the channel (but not whispers from or to channel operators). 6. IRCX Server Messages This section summarizes new extended messages which can be sent from the server. 6.1. AUTH (new IRCX message) Negotiates authentication with client or informs client that autho- rization was successful. Syntax 1 (negotiating authorization): AUTH <name> S: [<parameter>] Syntax 2 (authorization successful): AUTH <name> * <ident> <oid> 6.1.1. Parameters <name> The name of the SASL mechanism to use for authentication. The specific SASL mechanisms supported are implementation-dependent. <ident> The ident is the userid@domain of the authenticated client account. It is returned on the final response from the server (Syntax 2) when authentication is successful. <oid> The OID is the internal object identifier assigned to the client connection. If not supported by the server, then '0' must be returned. <parameter> This is optional data sent as an argument with the AUTH messages. The content depends on the authentication mechanism being used. 6.1.2. Remarks The server will send the syntax 2 form when the authentication process is complete or a numeric error reply. Cedola, Dusseault & Pfenning [Page 16] INTERNET-DRAFT 20 August 1997 6.2. CLONE (new IRCX message) Informs the hosts and owners in a CLONEABLE channel that a new CLONE channel was created. Syntax: CLONE <channel-name> <oid> 6.2.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 equal 0 if not supported. 6.2.2. Remarks The CLONE message can be sent at anytime to the hosts/owners of a CLONEABLE channel to inform them that a new CLONE channel was created. This message is intended to be used by a custom application to auto- matically join the new CLONE channel. A non-IRCX client will not get this message. 6.2.3. Example: Server: CLONE #MyChat1 034F8FF32 6.3. CREATE (new IRCX message) Informs the client that a new channel was created. Response to the CREATE command. Syntax: CREATE <channel-name> <oid> 6.3.1. Parameters <channel-name> The name of the created channel. <oid> The object identifier for this new channel. The value is imple- mentation- dependent and must equal 0 if not supported. 6.3.2. Remarks The CREATE message is sent in response to a CREATE command sent by the client application if the channel specified did not previously exist and was created by the server. 6.3.3. Example: Server: CREATE #MyChat1 034F8FF32 Cedola, Dusseault & Pfenning [Page 17] INTERNET-DRAFT 20 August 1997 6.4. DATA / REQUEST / REPLY (new IRCX messages) The DATA message (could be REQUEST or REPLY also) is forwarded from another user or sent by the server. The payload or message should be interpreted according to the tag. If the tag is unknown, the message may be discarded. Syntax 1: <sender> :DATA <target> <tag> :<message> <sender> :REQUEST <target> <tag> :<message> <sender> :REPLY <target> <tag> :<message> If the DATA, REQUEST or REPLY message is sent to a number of members within a channel, the receiving user will see the channel name and their own nick in the message as follows: Syntax 2: <sender> :DATA <channel> <nick> <tag> :<message> 6.4.1. Parameters <sender> May be a user or a server. <target> Channel and/or nick list as defined above. <tag> Identifying tag. <message> Payload. 6.4.2. Remarks The tag indicates what to do with the message. Tag types may be spec- ified by administrators, client developers, server developers etc. A tag beginning with SYS can only be from a sysop, admin or the server. A tag beginning with ADM can only be from an admin or the server. DATA message functionality is different from a simple client-to-client message in several respects. First, we encourage groups to define their own tags and data formats for special purposes, for example to indicate details for a user's avatar in graphical chats, or to indi- cate that an ad banner or image should be downloaded. Second, the DATA message is more appropriate for content that may go to several users, for example all users in a channel. Third, the DATA message may come from the server. Fourth, the SYS and ADM prefixes are speci- fied so that important tags may be reserved for sysops, admins and the server itself, with the server responsible for verifying the sender before forwarding the DATA message. 6.5. EVENT (new optional IRCX message) Notifies the client of an event. These events are intended for sysops and admins, and are sent in addition to IRC events. Specific event messages and message types are implementation-dependent. Cedola, Dusseault & Pfenning [Page 18] INTERNET-DRAFT 20 August 1997 Syntax: EVENT <time-stamp> <object> <event type> <parameters> 6.5.1. Parameters <time-stamp> The number of elapsed seconds from midnight (00:00:00) January 1, 1970 (coordinated universal time) until the time that the event occurred on the server. <object> Objects can be Channel, Member, User, Connection, Socket or Server. <event type> Event type varies depending on the object. For example, events for channels can be Create, Destroy, Topic change, Mode change, Collision. <parameters> Vary depending on event type. 6.5.2. Example This example is the event generated when a user logs onto server chat1 with the nickname john, showing the user's info including IP address and port. EVENT chat1 946080000 USER LOGON john!jsmith@uw.edu 192.29.93.93:1111 6.6. KNOCK (new IRCX message) Informs the owners and hosts of a channel that a user has tried to enter the channel and could not (could be because of a full channel, keyword set, user ban, or other reasons). This message is only sent to the owners and hosts of the channel in IRCX mode. Syntax: <user> KNOCK <channel-name> <reason> 6.6.1. Parameters <user> User field is of the format nick!userid@host. <channel-name> Name of the channel that the user tried to enter. <reason> Reason that the user received when they tried to join the channel. 6.6.2. Remarks A KNOCK message will not be sent to a non-IRCX client. Cedola, Dusseault & Pfenning [Page 19] INTERNET-DRAFT 20 August 1997 6.7. REDIRECT (new IRCX message) Informs the client that they need to connect to another server. Syntax: REDIRECT <server-list> :<reason> 6.7.1. Parameters <server-list> The server list is a comma seperated list of host:port pairs. The server list can be specified either as a fully-qualified domain name or by the IP address in quad-dotted notation. <reason> The redirect reason is an implementation-dependent string which can optionally be displayed to the client. 6.7.2. Remarks The REDIRECT message can be sent to the client at any time to request that the client disconnect and reconnect to another server specified in the list. The REDIRECT message is generally sent when a server is to be shutdown. A REDIRECT message will not be sent to a non-IRCX client. 6.7.3. Example Server: REDIRECT chat.corp.net:6667,134.9.3.3:6667 :Server full. 6.8. WHISPER (new IRCX message) A whisper from another channel member. Syntax: <sender> WHISPER <channel> <nick list> :<text> 6.8.1. Parameters <sender> The nick-name of the person that sent the whisper. <channel> The channel that the message is sent to. <nick list> The list of nicknames of channel members that will receive the whisper. <text> The content of the whisper. 6.8.2. Remarks The server may transform a WHISPER into a PRIVMSG for clients that do not support IRCX. Cedola, Dusseault & Pfenning [Page 20] INTERNET-DRAFT 20 August 1997 6.8.3. Example Server: Joe WHISPER #test :Test whisper. 7. User Modes and Properties These are new user modes and properties that have been added. The MODE command as defined in RFC1459 is used to add or remove modes. 7.1. OWNER (IRCX +q) The OWNER mode indicates that the user is an owner of a channel. Only a channel owner can give OWNER mode to another member of that channel, but any owner may remove OWNER mode from themself. Clients in IRCX mode see owner nicknames with a '.' prefix and con- tinue to see hosts with a '@' prefix (in results from NAMES, WHO, WHOIS and other commands which list nicknames). Note that HOST mode uses +o, which was "operator" mode in RFC1459. Syntax for these modes is the same as "operator" mode: MODE <channel> { + | - }q <nick> 7.2. GAG (IRCX +z) The GAG mode is applied by a sysop or admin on a user and may not be removed except by a sysop or admin. The user may not be notified when this mode is applied because the mode can be a more effective tool for keeping order if the user doesn't know exactly when it is applied. The server will discard all messages from a user with GAG mode to any other user or to any channel. MODE <nick> { + | - }z 8. Channel Modes and Properties New modes and properties have been added to channels. Some of these are optional and are marked as such. Channels support four mutually exclusive states of visibility: public, private, hidden, and secret. The visibility of a channel affects which modes and properties are available to a client. Each mode/prop- erty is followed by a table that consists of a matrix of the channel's visibility 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), "*" for special access explained in the mode description, and N/A for does not apply. These access rights are listed for the different access levels. Cedola, Dusseault & Pfenning [Page 21] INTERNET-DRAFT 20 August 1997 8.1. Modes Each channel object contains a number of binary mode settings that can be queried and optionally updated via the RFC1459 MODE command. 8.1.1. PUBLIC (RFC1459 default) The channel is public and all information about the channel (except for text messages) can be queried by non-members. PUBLIC mode is mutually exclusive with the PRIVATE, HIDDEN and SECRET modes. Admin Sysop Owner Host Member User Public R/W RO R/W R/W RO RO Private 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 Secret N/A N/A N/A N/A N/A N/A 8.1.2. PRIVATE (RFC1459 +p) The channel is private and only the name, number of members and PICS property can be queried by non-members. PRIVATE mode is mutually exclusive with the PUBLIC, HIDDEN and SECRET modes. Admin Sysop Owner Host Member User Public N/A N/A N/A N/A N/A N/A Private R/W RO R/W R/W RO - Hidden 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 8.1.3. HIDDEN (IRCX +h) The channel is hidden and cannot be located by enumeration queries from non-members. HIDDEN mode is mutually exclusive with the PUBLIC, PRIVATE, and SECRET modes. The purpose of the new HIDDEN channel mode is to permit the existence of channels that cannot be found using the standard LIST command, but whose properties can be queried if the exact channel name is known. Thus a HIDDEN channel is the same as a PUBLIC channel except that it cannot be enumerated by using a LIST or LISTX command. Admin Sysop Owner Host Member User Public 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 Hidden R/W RO R/W R/W RO RO Secret N/A N/A N/A N/A N/A N/A 8.1.4. SECRET (RFC1459 +s) The channel is secret and cannot by located by any query from non-mem- bers. SECRET mode is mutually exclusive with the PUBLIC, PRIVATE, and Cedola, Dusseault & Pfenning [Page 22] INTERNET-DRAFT 20 August 1997 HIDDEN modes. Admin Sysop Owner Host Member User Public 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 Hidden N/A N/A N/A N/A N/A N/A Secret R/W RO R/W R/W RO - 8.1.5. MODERATED (RFC1459 +m) Normally, new channel members may speak. In MODERATED mode however, new channel members may not speak by default. This is achieved by giving all new members the '-v' mode (no voice) for that channel. Usually -v mode has no effect, but in a MODERATED channel it does. Admin Sysop Owner Host Member User Public R/W RO R/W R/W RO RO Private R/W RO R/W R/W RO - Hidden R/W RO R/W R/W RO RO Secret R/W RO R/W R/W RO - 8.1.6. NOEXTERN (RFC1459 +n) NOEXTERN mode blocks messages from non-members to the channel. An administrator can still send a message to the channel. Admin Sysop Owner Host Member User Public R/W RO R/W R/W RO RO Private R/W RO R/W R/W RO - Hidden R/W RO R/W R/W RO RO Secret R/W RO R/W R/W RO - 8.1.7. TOPICOP (RFC1459 +t) TOPICOP mode permits only channel owners and hosts to change the chan- nel topic property. Admin Sysop Owner Host Member User Public R/W RO R/W R/W RO RO Private R/W RO R/W R/W RO - Hidden R/W RO R/W R/W RO RO Secret R/W RO R/W R/W RO - 8.1.8. INVITE (RFC1459 +i) INVITE mode permits only invited users to enter the channel. Only owners and hosts can issue an invitation when this mode is on. Cedola, Dusseault & Pfenning [Page 23] INTERNET-DRAFT 20 August 1997 Admin Sysop Owner Host Member User Public R/W RO R/W R/W RO RO Private R/W RO R/W R/W RO - Hidden R/W RO R/W R/W RO RO Secret R/W RO R/W R/W RO - 8.1.9. KNOCK (IRCX +u) The KNOCK extended mode causes a KNOCK message to be sent to owners and hosts of the channel if user attempts to join a channel and the server denies entrance. Admin Sysop Owner Host Member User Public R/W RO R/W R/W RO RO Private R/W RO R/W R/W RO - Hidden R/W RO R/W R/W RO RO Secret R/W RO R/W R/W RO - 8.1.10. NOFORMAT (IRCX +f) The NOFORMAT channel mode is an indication to the client application not to format text received from the channel. 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 dis- played 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. Clients may want to inform users that messages can be spoofed with this mode. Admin Sysop Owner Host Member User Public R/W RO RO RO RO RO Private R/W RO RO RO RO - Hidden R/W RO RO RO RO RO Secret R/W RO RO RO RO - 8.1.11. NOWHISPER (IRCX +w) The NOWHISPER channel mode will prevent all messages sent to specific nicknames within the context of that channel. Admin Sysop Owner Host Member User Public R/W RO R/W RO RO RO Private R/W RO R/W RO RO - Hidden R/W RO R/W RO RO RO Secret R/W RO R/W RO RO - 8.1.12. AUDITORIUM (IRCX +x) The AUDITORIUM channel mode restricts visibility and messaging within a channel. Members will only see themselves and the hosts/owners in Cedola, Dusseault & Pfenning [Page 24] INTERNET-DRAFT 20 August 1997 the channel. Any message sent by a member will only be received by the hosts and owners. Hosts and owners will see all members in the channel and messages from a host or owner are seen by all channel mem- bers. Ordinary members will not receive JOIN/PART messages from other members. This mode is designed for channels with so many members that they do not want to see each other. Note that auditorium mode may only be set at channel creation time using the CREATE command. Admin Sysop Owner Host Member User Public R/W R/W R/W RO RO RO Private R/W R/W R/W RO RO - Hidden R/W R/W R/W RO RO RO Secret R/W R/W R/W RO RO - 8.1.13. REGISTERED (IRCX +r) The channel is registered by the administrator of the chat network. The registration procedure is not defined here and is implementation- dependent. Only the server or admin can set this mode. Admin Sysop Owner Host Member User Public R/W RO RO RO RO RO Private R/W RO RO RO RO - Hidden R/W RO RO RO RO RO Secret R/W RO RO RO RO - 8.1.14. 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 can only be set by the Chat Server. Admin Sysop Owner Host Member User Public RO RO RO RO RO RO Private RO RO RO RO RO - Hidden RO RO RO RO RO RO Secret RO RO RO RO RO - 8.1.15. AUTHONLY (IRCX +a) The AUTHONLY channel mode permits channel access only to users who have been authenticated by the server. Note that an authenticated user is any user that was successfully authenticated with the PASS command or the AUTH command. Cedola, Dusseault & Pfenning [Page 25] INTERNET-DRAFT 20 August 1997 Admin Sysop Owner Host Member User Public R/W RO R/W RO RO RO Private R/W RO R/W RO RO - Hidden R/W RO R/W RO RO RO Secret R/W RO R/W RO RO - 8.1.16. CLONEABLE (IRCX +d) The CLONEABLE channel mode defines a channel that creates new clone channels if the parent channel is full. A clone channel is created with the same name as the parent cloneable channel with a numeric suf- fix starting at 1, ranging to 99. It is not valid to set the CLONE- ABLE channel mode of a parent channel that ends with a numeric charac- ter. The clone channel inherits modes and properties from the parent channel when it is set up. When a clone channel is created, any chan- nel that has the same name is removed. This prevents channel take over of a clone channel. It is advised that only administrators be allowed to set cloneable mode on a channel. Admin Sysop Owner Host Member User Public R/W RO RO RO RO RO Private R/W RO RO RO RO - Hidden R/W RO RO RO RO RO Secret R/W RO RO RO RO - 8.1.17. CLONE (IRCX +e) The CLONE channel mode defines a channel that was created by the server when a parent CLONEABLE channel becomes full. Users should usually join the parent channel, although a user may join a clone channel that is not full. An admin can set up a clone channel but only when the channel is being created. Admin Sysop Owner Host Member User Public * RO RO RO RO RO Private * RO RO RO RO - Hidden * RO RO RO RO RO Secret * RO RO RO RO - 8.2. Properties Each channel object contains a number of properties that can be queried and optionally updated via the IRCX PROP command. Owners and hosts may update a property for their own channel. Admins and Sysops can use the PROP command on a channel only by becoming host/owner of that channel. Users and members can read properties only. 8.2.1. OID (R/O) The OID channel property is the internal object identifier for the channel. As a shortcut, the OID can be optionally used in place of Cedola, Dusseault & Pfenning [Page 26] INTERNET-DRAFT 20 August 1997 the full string name of a channel. If the OID is set to "0", then this feature is not supported on the server. Admin Sysop Owner Host Member User Public RO RO RO RO RO RO Private RO RO RO RO RO - Hidden RO RO RO RO RO RO Secret RO RO RO RO RO - 8.2.2. NAME (R/O) The NAME channel property is the name of the channel (limited to 63 characters, including 1 or 2 characters for channel prefix). Valid characters are as defined in RFC1459. Admin Sysop Owner Host Member User Public RO RO RO RO RO RO Private RO RO RO RO RO - Hidden RO RO RO RO RO RO Secret RO RO RO RO RO - 8.2.3. CREATION (R/O) The CREATION channel property is the time that the channel was cre- ated, in number of seconds elapsed since midnight (00:00:00), January 1, 1970, (coordinated universal time). Admin Sysop Owner Host Member User Public RO RO RO RO RO RO Private RO RO RO RO RO - Hidden RO RO RO RO RO RO Secret RO RO RO RO RO - 8.2.4. LANGUAGE The LANGUAGE channel property is the perferred language type. The LANGUAGE property is a string limited to 31 characters. We recommend following the guidelines of RFC1766 to form well-understood language- defining strings. Admin Sysop Owner Host Member User Public R/W RO R/W R/W RO RO Private R/W RO R/W R/W RO - Hidden R/W RO R/W R/W RO RO Secret R/W RO R/W R/W RO - 8.2.5. OWNERKEY The OWNERKEY channel property is the owner keyword that will provide owner access when entering the channel. The OWNERKEY property is Cedola, Dusseault & Pfenning [Page 27] INTERNET-DRAFT 20 August 1997 limited to 31 characters. Admin Sysop Owner Host Member User Public WO - WO - - - Private WO - WO - - - Hidden WO - WO - - - Secret WO - WO - - - 8.2.6. HOSTKEY The HOSTKEY channel property is the host keyword that will provide host (channel op) access when entering the channel. The HOSTKEY prop- erty is limited to 31 characters. Admin Sysop Owner Host Member User Public WO - WO - - - Private WO - WO - - - Hidden WO - WO - - - Secret WO - WO - - - 8.2.7. MEMBERKEY The MEMBERKEY channel property is the keyword required to enter the channel. The MEMBERKEY property is limited to 31 characters. This is backwards-compatible with RFC1459 because users can still use the MODE command as an alternative way to set this property. Admin Sysop Owner Host Member User Public WO - WO - - - Private WO - WO - - - Hidden WO - WO - - - Secret WO - WO - - - 8.2.8. PICS (Optional) 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. The PICS property is lim- ited to 255 characters. The format for this field is defined by PICS (see http://www.w3.org). Admin Sysop Owner Host Member User Public R/W RO RO RO RO RO Private R/W RO RO RO RO RO Hidden R/W RO RO RO RO RO Secret R/W RO RO RO RO - Cedola, Dusseault & Pfenning [Page 28] INTERNET-DRAFT 20 August 1997 8.2.9. TOPIC The TOPIC channel property is the current topic of the channel. The TOPIC property is limited to 160 characters. Admin Sysop Owner Host Member User Public R/W RO R/W R/W RO RO Private R/W RO R/W R/W RO - Hidden R/W RO R/W R/W RO RO Secret R/W RO R/W R/W RO - 8.2.10. SUBJECT The SUBJECT channel property is a string that can contain subject key- words. The SUBJECT property is limited to 31 characters. Admin Sysop Owner Host Member User Public R/W RO R/W R/W RO RO Private R/W RO R/W R/W RO - Hidden R/W RO R/W R/W RO RO Secret R/W RO R/W R/W RO - 8.2.11. CLIENT (Optional) The CLIENT channel property contains client specified information. The format is not defined by the server. The CLIENT property is lim- ited to 255 characters. Admin Sysop Owner Host Member User Public R/W RO R/W RO RO RO Private R/W RO R/W RO RO - Hidden R/W RO R/W RO RO RO Secret R/W RO R/W RO RO - 8.2.12. ONJOIN (Optional) The ONJOIN channel property contains a string to be sent (via PRIVMSG) to a user after the user has joined the channel. The channel name is displayed as the sender of the message. Only the user joining the channel will see this message. Multiple lines can be generated by embedding '\n' in the string. The ONJOIN property is limited to 255 characters. Admin Sysop Owner Host Member User Public R/W RO R/W R/W - - Private R/W RO R/W R/W - - Hidden R/W RO R/W R/W - - Secret R/W RO R/W R/W - - Cedola, Dusseault & Pfenning [Page 29] INTERNET-DRAFT 20 August 1997 8.2.13. ONPART (Optional) The ONPART channel property contains a string that is sent (via NOTICE) to a user after they have parted from the channel. The chan- nel name is displayed as the sender of the message. Only the user parting the channel will see this message. Multiple lines can be gen- erated by embedding '\n' in the string. The ONPART property is lim- ited to 255 characters. Admin Sysop Owner Host Member User Public R/W RO R/W R/W - - Private R/W RO R/W R/W - - Hidden R/W RO R/W R/W - - Secret R/W RO R/W R/W - - 8.2.14. LAG (Optional) The LAG channel property contains a numeric value between 0 to 2 sec- onds. The server will add an artificial delay of that length between subsequent messages from the same member. All messages to the channel are affected. Admin Sysop Owner Host Member User Public R/W RO R/W RO RO RO Private R/W RO R/W RO RO - Hidden R/W RO R/W RO RO RO Secret R/W RO R/W RO RO - 8.2.15. ACCOUNT (Optional) The ACCOUNT channel property contains an implementation-dependent string for attaching a security account. This controls access to the channel using the native OS security system. The ACCOUNT property is limited to 31 characters. Admin Sysop Owner Host Member User Public R/W RO RO - - - Private R/W RO RO - - - Hidden R/W RO RO - - - Secret R/W RO RO - - - 8.2.16. CLIENTGUID (Optional) The CLIENTGUID channel property contains a GUID that defines the client protocol to be used within the channel. Cedola, Dusseault & Pfenning [Page 30] INTERNET-DRAFT 20 August 1997 Admin Sysop Owner Host Member User Public R/W RO R/W RO RO RO Private R/W RO R/W RO RO - Hidden R/W RO R/W RO RO RO Secret R/W RO R/W RO RO - 8.2.17. SERVICEPATH (Optional) The SERVICEPATH channel property contains the path of a server side extension that is used to control the channel operation. Details are implementation-dependent. Admin Sysop Owner Host Member User Public R/W RO RO RO - - Private R/W RO RO RO - - Hidden R/W RO RO RO - - Secret R/W RO RO RO - - 9. IRCX Command Responses The new extended IRCX numeric replies follow the same convention as IRC replies, with a specific range for command responses and another range for error results. The IRCX command responses are in the range of 800 to 899 and 900 to 999 for the error results. The prefix field is optional if the server generating the error is the server that the client is connected to. 9.1. Command Replies 800 - IRCRPL_IRCX <state> <version> <package-list> <maxmsg> <option-list> The response to the IRCX and ISIRCX commands. The <state> indicates if the client 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 that anonymous connections are permitted. The <maxmsg> defines the maximum message size permitted, with the standard being 512. The <option-list> contains a list of options supported by the server; these are imple- mentation-dependent. If no options are available, the '*' character is used. 801 - IRCRPL_ACCESSADD Cedola, Dusseault & Pfenning [Page 31] INTERNET-DRAFT 20 August 1997 <object> <level> <mask> <timeout> <user> :<reason> Response to a successful ACCESS ADD command. The <object> is the name of the object to which the access restrictions apply (i.e. channel name or user name). The <level> is the level of access being added (i.e. GRANT, DENY). The <mask> is the selection mask. If no mask is provided in the ACCESS command, then the default mask of *!*@*$* is used. The <timeout> is the amount of time this access entry will last. The <user> is the one who added the new ACCESS record. The <reason> is the reason supplied in the ACCESS ADD command. 802 - IRCRPL_ACCESSDELETE <object> <level> <mask> <timeout> Response to a successful ACCESS DELETE command. See reply 801 for explanation of the fields. 803 - IRCRPL_ACCESSSTART <object> :Start of access entries Beginning of a list of access entries. <object> is the object to which the access restrictions apply (i.e. channel name or user name). The next message will be an IRCRPL_ACCESSLIST or IRCRPL_ACCESSEND reply. 804 - IRCRPL_ACCESSLIST <object> <level> <mask> <timeout> <user> :<reason> One entry in a list of access entries. See reply 801 for explanation of the fields. 805 - IRCRPL_ACCESSEND <object> :End of access entries End of a list of access entries. See reply 803 for explanation of the field. This reply will always follow an IRCRPL_ACCESSSTART or IRCRPL_ACCESSLIST reply. 806 - 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 mask. If no mask is provided in the EVENT command, then the default Cedola, Dusseault & Pfenning [Page 32] INTERNET-DRAFT 20 August 1997 mask of *!*@*$* is used. 807 - IRCRPL_EVENTDEL <event> <mask> The acknowledgment response to the EVENT DEL command. The <event> contains the name of the deleted event. The <mask> is the selection mask. If no mask is provided in the EVENT command, then the default mask of *!*@*$* is used. 808 - IRCRPL_EVENTSTART :Start of events Response to the EVENT LIST <event> message that indicates the start of the event list. 809 - IRCRPL_EVENTLIST <event> <mask> Response to the EVENT LIST <event> message that displays a list of current events that the client is interested in. 810 - IRCRPL_EVENTEND :End of events Response to the EVENT LIST <event> message that indicates the end of the event list. 811 - IRCRPL_LISTXSTART :Start of ListX First reply to a LISTX (extended list) command. Will always be fol- lowed by a reply of type 812, 816 or 817. 812 - IRCRPL_LISTXLIST <object> <channel> <modes> <members> <member limit> :<topic> Single list item in an extended list of channels. 813 - IRCRPL_LISTXPICS Cedola, Dusseault & Pfenning [Page 33] INTERNET-DRAFT 20 August 1997 :<PICS-rating> PICS rating string for the last channel listed (follows an 812 mes- sage). 816 - IRCRPL_LISTXTRUNC :Truncation of ListX Last reply to a LISTX command, either because the user asked for a limited list of channels or because the server truncated the list to prevent output flooding. Always follows a reply of type 811, 812 or 813. 817 - IRCRPL_LISTXEND :End of ListX Last reply to a LISTX command, indicating that the list has ended. Always follows a reply of type 811, 812 or 813. 818 - IRCRPL_PROPLIST <object> <property> :<value> A value in a property list. 819 - IRCRPL_PROPEND <object> :End of properties Last message in a property list. 9.2. IRCX Error Replies. 900 - IRCERR_BADCOMMAND <command> :Bad command Response to an incorrectly formatted command. 901 - IRCERR_TOOMANYARGUMENTS <command> :Too many arguments Response to too many arguments being provided for a command. Cedola, Dusseault & Pfenning [Page 34] INTERNET-DRAFT 20 August 1997 902 - IRCERR_BADFUNCTION <command> :Bad function Response to a command that supports functions, with invalid function sent by the user. For example, the EVENT command supports functions. 903 - IRCERR_BADLEVEL <command> :Bad level Response to an ACCESS command with a bad level specified (i.e. not GRANT, DENY...) 904 - IRCERR_BADTAG <command> :Bad message tag. The message tag format is incorrect. 905 - IRCERR_BADPROPERTY <channel> :Bad property specified Response to a channel property command with a bad property specified. 906 - IRCERR_BADVALUE <channel> :Bad value specified Response to an attempt to set an integer property to a string value (PROP command). 907 - IRCERR_RESOURCE :Not enough resources Server does not have enough resources to perform command. 908 - IRCERR_SECURITY :No permissions to perform command For security reasons, the command/function/operation is not permitted for this level of client. Cedola, Dusseault & Pfenning [Page 35] INTERNET-DRAFT 20 August 1997 909 - IRCERR_ALREADYAUTHENTICATED <package> :Already authenticated The client is already authenticated with the server. 910 - IRCERR_AUTHENTICATIONFAILED <package> :Authentication failed The authentication failed due to a bad userid/password or server/net- work failure. 911 - IRCERR_AUTHENTICATIONSUSPENDED <package> :Authentication suspended for this IP Authentication has been temporary disabled due to too many authentica- tion failures from this IP. 912 - 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. 913 - IRCERR_NOACCESS <command> :No access Response to a user trying to change the ACCESS list for an object the user does not have sufficient privileges to alter. 914 - IRCERR_DUPACCESS :Duplicate access entry An access entry already exists for the specified user mask. 915 - IRCERR_MISACCESS :Unknown access entry Response to ACCESS DELETE command when server does not recognize the entry to be removed. Cedola, Dusseault & Pfenning [Page 36] INTERNET-DRAFT 20 August 1997 916 - IRCERR_TOOMANYACCESSES :Too many access entries Response to ACCESS ADD command when maximum number of access entries has been reached. 918 - IRCERR_EVENTDUP <event> <mask> :Duplicate event entry The user has asked for an event that is already being sent. 919 - IRCERR_EVENTMIS <event> <mask> :Unknown event entry Response to event remove command when user is not already receiving the event specified. 920 - IRCERR_NOSUCHEVENT <event> :No such event type Response to event add command when server does not recognize the event specified. 921 - IRCERR_TOOMANYEVENTS <event> :Too many events specifed Response to event add command when user may not add another event to monitor. 923 - IRCERR_NOWHISPER <object> :Does not permit whispers Response to whisper command when channel does not permit whispers. 924 - IRCERR_NOSUCHOBJECT <object> :No such object found Response to an attempt to define a property for an object which can't be found (PROP command). Cedola, Dusseault & Pfenning [Page 37] INTERNET-DRAFT 20 August 1997 926 - IRCERR_CHANNELEXIST <channel> :Channel already exists. The channel name in the CREATE command already exist on the server and the +c mode was specified. 927 - IRCERR_ALREADYONCHANNEL <channel> :Already in the channel. Response to join command when user is already in the channel. 999 - IRCERR_UNKNOWNERROR :Unknown error code <error-code> The internal error generated doesn't map to a valid IRCX error reply. The error code is implementation-dependent. 10. Security Considerations Security issues are discussed in the authentication section. The IRCX and ISIRCX commands return 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 meth- ods and only offers a cleartext password transaction. In order to avoid this type of attack, only authentication methods with a chal- lenge response mechanism should be used. Since all administration commands for RFC1459 and IRCX are sent in clear text, a stream layer encryption mechanism like SSL[5] or IPSEC is required to protect the integrity and confidentiality of the trans- actions. The mechanisms for establishing these connection are outside the scope of this document. 11. 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 Cedola, Dusseault & Pfenning [Page 38] INTERNET-DRAFT 20 August 1997 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 12. Authors' Addresses Kent Cedola Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: kentce@microsoft.com Lisa Dusseault Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: lisadu@microsoft.com Thomas Pfenning Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: thomaspf@microsoft.com Cedola, Dusseault & Pfenning [Page 39]