{\rtf1\ansi\deff0\deftab720{\fonttbl{\f0\fswiss MS Sans Serif;}{\f1\froman\fcharset2 Symbol;}{\f2\fmodern Courier New;}} {\colortbl\red0\green0\blue0;} \deflang2057\pard\plain\f2\fs20 \par \par \par INTERNET-DRAFT Dalen Abraham \par Expires: December 16, 1998 Microsoft Corporation \par June 1998 \par \par \par \par Extensions to the Internet Relay Chat Protocol (IRCX) \par draft-pfenning-irc-extensions-04.txt \par \par \par 1. Status of this Memo \par \par This document is an Internet-Draft. Internet-Drafts are \par working documents of the Internet Engineering Task Force \par (IETF), its areas, and its working groups. Note that other \par groups may also distribute working documents as Internet \par Drafts. \par \par Internet-Drafts are draft documents valid for a maximum of six \par months and may be updated, replaced, or obsoleted by other \par documents at any time. It is inappropriate to use Internet- \par Drafts as reference material or to cite them other than as \par "work in progress." \par \par To view the entire list of current Internet-Drafts, please \par check the "1id-abstracts.txt" listing contained in the \par Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), \par ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern \par Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East \par Coast), or ftp.isi.edu (US West Coast). \par \par 2. Abstract \par \par This document describes IRCX, a set of extensions to the \par Internet Relay Chat (IRC) protocol defined in RFC 1459[1]. \par Only client-server interactions are defined. The added \par functionality includes user authentication for multiple \par security providers, support for UNICODE[2] characters, \par multilayer security, and a unified property mechanism. \par Chat server implementations can support channel or server \par services with full control over all messages and events. \par These services communicate with the core server over an \par extended IRC connection. \par \par All changes to the IRC protocol are designed such that \par existing clients will continue to work against servers \par implementing the extensions. Support for the extended protocol \par can be queried by clients to take advantage of the added \par functionality or to conform to the basic protocol as defined \par in RFC1459. \par \par \par \par \par \par \par \par \par \par [Page 1] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par 2.1. Contents \par \par 1. Status of this Memo.......................................1 \par 2. Abstract..................................................1 \par 2.1. Contents.............................................2 \par 3. Modified UTF8 Encoding of UNICODE characters..............5 \par 4. Terms and Definitions.....................................5 \par 4.1. User Access Levels...................................6 \par 4.2. Prefixes.............................................6 \par 5. IRCX Client Messages......................................7 \par 5.1. ACCESS command (new IRCX command)....................8 \par 5.1.1. Parameters.......................................8 \par 5.1.2. Results..........................................8 \par 5.1.3. Possible Errors..................................9 \par 5.1.4. Remarks..........................................9 \par 5.1.5. Examples.........................................9 \par 5.2. AUTH Command (new IRCX command).....................10 \par 5.2.1. Parameters......................................10 \par 5.2.2. Results.........................................10 \par 5.2.3. Possible Errors.................................10 \par 5.2.4. Remarks:........................................11 \par 5.2.5. Example:........................................11 \par 5.3. CREATE (new IRCX command)...........................11 \par 5.3.1. Parameters......................................11 \par 5.3.2. Results.........................................11 \par 5.3.3. Possible Errors.................................11 \par 5.3.4. Remarks.........................................12 \par 5.3.5. Examples........................................12 \par 5.4. DATA / REQUEST / REPLY (new IRCX command)...........12 \par 5.4.1. Parameters......................................12 \par 5.4.2. Results.........................................13 \par 5.4.3. Possible Errors.................................13 \par 5.4.4. Remarks.........................................13 \par 5.4.5. Example.........................................13 \par 5.5. EVENT (new IRCX command)............................13 \par 5.5.1. Parameters......................................13 \par 5.5.2. Results.........................................14 \par 5.5.3. Possible Errors.................................14 \par 5.5.4. Remarks.........................................14 \par 5.5.5. Examples:.......................................14 \par 5.6. IRCX (new IRCX command).............................15 \par 5.6.1. Parameters......................................15 \par 5.6.2. Results.........................................15 \par 5.6.3. Example.........................................15 \par 5.7. ISIRCX (new IRCX command)...........................15 \par 5.7.1. Results.........................................15 \par 5.8. LISTX (new IRCX command)............................15 \par 5.8.1. Parameters......................................16 \par 5.8.2. Results.........................................16 \par 5.8.3. Remarks.........................................17 \par 5.9. MODE (extension to RFC1459 command).................17 \par 5.9.1. Results.........................................17 \par 5.9.2. Remarks.........................................17 \par 5.10. NOTICE (extension to RFC1459 command)...............18 \par \par \par [Page 2] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par 5.10.1.Results.........................................18 \par 5.11. PRIVMSG (extension to RFC1459 command)..............18 \par 5.11.1.Results.........................................18 \par 5.12. PROP (new IRCX command).............................18 \par 5.12.1.Results.........................................18 \par 5.12.2.Possible Errors.................................19 \par 5.12.3.Remarks.........................................19 \par 5.12.4.Examples........................................19 \par 5.13. WHISPER (new IRCX command)..........................19 \par 5.13.1.Results.........................................19 \par 5.13.2.Possible Errors.................................19 \par 5.13.3.Remarks.........................................20 \par 6. IRCX Server Messages.....................................20 \par 6.1. AUTH (new IRCX message).............................20 \par 6.1.1. Parameters......................................20 \par 6.1.2. Remarks.........................................21 \par 6.2. CLONE (new IRCX message)............................21 \par 6.2.1. Parameters......................................21 \par 6.2.2. Remarks.........................................21 \par 6.2.3. Example.........................................21 \par 6.3. CREATE (new IRCX message)...........................21 \par 6.3.1. Parameters......................................21 \par 6.3.2. Remarks.........................................22 \par 6.3.3. Example.........................................22 \par 6.4. DATA / REQUEST / REPLY (new IRCX messages)..........22 \par 6.4.1. Parameters......................................22 \par 6.4.2. Remarks.........................................22 \par 6.5. EVENT (new IRCX message)............................23 \par 6.5.1. Parameters......................................23 \par 6.5.2. Example.........................................23 \par 6.6. KNOCK (new IRCX message)............................23 \par 6.6.1. Parameters......................................24 \par 6.6.2. Remarks.........................................24 \par 6.7. REDIRECT (new IRCX message).........................24 \par 6.7.1. Parameters......................................24 \par 6.7.2. Remarks.........................................24 \par 6.7.3. Example.........................................24 \par 6.8. WHISPER (new IRCX message)..........................24 \par 6.8.1. Parameters......................................24 \par 6.8.2. Remarks.........................................25 \par 6.8.3. Example.........................................25 \par 7. User Modes and Properties................................25 \par 7.1. OWNER (IRCX +q).....................................25 \par 7.2. GAG (IRCX +z).......................................25 \par 8. Channel Modes and Properties.............................26 \par 8.1. Modes...............................................26 \par 8.1.1. PUBLIC (RFC1459 default)........................26 \par 8.1.2. PRIVATE (RFC1459 +p)............................26 \par 8.1.3. HIDDEN (IRCX +h)................................26 \par 8.1.4. SECRET (RFC1459 +s).............................26 \par 8.1.5. MODERATED (RFC1459 +m)..........................27 \par 8.1.6. NOEXTERN (RFC1459 +n)...........................27 \par 8.1.7. TOPICOP (RFC1459 +t)............................27 \par 8.1.8. INVITE (RFC1459 +i).............................27 \par \par \par [Page 3] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par 8.1.9. KNOCK (IRCX +u).................................27 \par 8.1.10.NOFORMAT (IRCX +f)..............................27 \par 8.1.11.NOWHISPER (IRCX +w).............................28 \par 8.1.12.AUDITORIUM (IRCX +x)............................28 \par 8.1.13.REGISTERED (IRCX +r)............................28 \par 8.1.14.SERVICE (IRCX +z)...............................28 \par 8.1.15.AUTHONLY (IRCX +a)..............................29 \par 8.1.16.CLONEABLE (IRCX +d).............................29 \par 8.1.17.CLONE (IRCX +e).................................29 \par 8.2. Properties..........................................30 \par 8.2.1. OID (R/O).......................................30 \par 8.2.2. NAME (R/O)......................................30 \par 8.2.3. CREATION (R/O)..................................30 \par 8.2.4. LANGUAGE........................................30 \par 8.2.5. OWNERKEY........................................30 \par 8.2.6. HOSTKEY.........................................31 \par 8.2.7. MEMBERKEY.......................................31 \par 8.2.8. PICS............................................31 \par 8.2.9. TOPIC...........................................31 \par 8.2.10.SUBJECT.........................................31 \par 8.2.11.CLIENT..........................................31 \par 8.2.12.ONJOIN..........................................32 \par 8.2.13.ONPART..........................................32 \par 8.2.14.LAG.............................................32 \par 8.2.15.ACCOUNT.........................................32 \par 8.2.16.CLIENTGUID......................................32 \par 8.2.17.SERVICEPATH.....................................33 \par 9. IRCX Command Responses...................................33 \par 9.1. Command Replies.....................................33 \par 9.2. IRCX Error Replies..................................36 \par 10. Security Considerations..................................39 \par 11. Acknowledgements.........................................40 \par 12. References...............................................40 \par 13. Authors' Addresses.......................................40 \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par [Page 4] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par 3. Modified UTF8 Encoding of UNICODE characters \par \par Allowing UNICODE characters for all user visible strings \par introduces a set of compatibility problems if the protocol \par must be backward compatible. UTF8 encoding is used to convert \par wide UNICODE characters into a string compatible with existing \par IRC servers and clients. \par \par To permit the full range of UNICODE characters, we must \par introduce an additional post-processing step on the result of \par an UTF8 translation. \par \par Any string beginning with a '%' character (i.e. "reason" \par strings within a REDIRECT command) will be interpreted as \par UTF8-encoded UNICODE strings. \par \par UNICODE characters encoded in UTF8 may use more bytes than an \par ASCII character. To ensure compatibility, UNICODE strings \par such as nicknames and channel names must fit within the \par standard length measured in bytes, not in characters. \par \par The quoting character for the post-processing step is the '\\' \par character. All mappings are listed in the table below. \par \par Table 1 - Character Quoting in UTF8 \par \par \\b " " (blank) \par \par \\c "," \par \par \\\\ "\\" \par \par \\r CR \par \par \\n LF \par \par \\t TAB \par \par IRCX clients view UTF8-encoded UNICODE strings in their native \par form. So non-IRCX clients can inter-operate with UNICODE \par nicks, UNICODE nicks are translated by the server into a \par usable form before being sent to the non-IRCX client. This \par usable format is a simple hex format preceded by a '^' \par character. Non-IRCX clients can use this hex format nickname \par to specify the IRCX/UNICODE user. \par \par 4. Terms and Definitions \par \par Throughout this document we will use certain terms which are \par defined in the following pages. \par \par String lengths are indicated in "characters", referring to \par ASCII characters, because even UNICODE strings must be encoded \par in ASCII for the IRC protocol. \par \par \par [Page 5] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par Table 2 - Definition of Terms \par \par Chat Network A Chat Network is comprised of one or more \par servers linked together. \par \par Server A server is a single machine. \par \par Channel A channel (sometimes called a room or \par conference) is a conversation between one or \par more users. \par \par Member A member is a user that is part of a \par conversation in a channel. \par \par User A user is a client that makes a connection to \par the server. \par \par Objects An object is a general term for channels, \par users, members (users in a channel), and \par servers. The type of object can be determined \par from the first character of the object's name. \par \par 4.1. User Access Levels \par \par There are six user levels that define the ability of the user \par to perform operations. Some levels are determined on the \par context of the operation to be performed. \par \par Table 3 - Definition of Client Levels \par \par Sysop Manager A Sysop Manager has full access to online \par commands. \par \par Sysop A Chat Sysop oversees and controls the chat \par network. \par \par Channel Owner A Channel Owner manages a channel and the \par channel hosts. \par \par Channel Host A Channel Host manages a channel. Also \par referred to as a channel operator. \par \par Channel Member A Channel Member is a member of a channel. \par \par Chat User A Chat User is a client connected to the \par server. \par \par 4.2. Prefixes \par \par Each object contains a unique prefix that identifies the type \par of object. By tagging UNICODE objects with a special prefix, \par a client can easily decide whether to use standard ASCII or \par UNICODE when sending a message to a user or channel. The IRCX \par client is responsible, when sending a UNICODE string, for \par \par \par [Page 6] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par prefixing it with a '%' character so that other IRCX clients \par can interpret it as UNICODE. \par \par Table 4 - Object identifiers \par \par # The '#' prefix identifies a RFC1459 global channel. \par \par & The '&' prefix identifies a RFC1459 local channel. \par \par %# The "%#" prefix identifies an extended global channel \par name (a modified UTF8-encoded UNICODE string). \par \par %& The "%&" prefix identifies an extended local channel \par name (a modified UTF8-encoded UNICODE string). \par \par % The '%' character followed by a space or comma can \par identify the last channel that this client \par specified and is a member of. Its function is to \par optimize server processing of multiple messages from \par a client to a channel. \par \par A to \} The 'A' through '\}' prefix identifies a standard \par RFC1459 nickname. \par \par ' The ''' prefix identifies an extended IRCX nickname \par which consists of a modified UTF8-encoded UNICODE \par string. The ''' character followed by a space or \par comma is used to represent the local client \par connection. The characters following ''' can be '0' \par through '9', '-', and any character above 'A'. \par \par ^ The '^' prefix identifies a nickname which was \par translated from UTF8 into hex characters so that the \par nickname can be viewed by non-IRCX clients. The \par characters following '^' can be any standard RFC1459 \par nickname characters. \par \par 0 The '0' prefix identifies an internal object \par identifier (OID). The OID consists of the '0' \par prefix and eight hexadecimal characters. If not \par supported by the server, then OID must be returned as \par '0'. \par \par $ The '$' prefix identifies a server on the network. \par The '$' character followed by a space or comma may \par be used to represent the local server the client is \par connected to. \par \par 5. IRCX Client Messages \par \par This section details commands which have been added and \par commands which have been changed from RFC1459. Responses from \par the server are discussed in greater detail in later sections. \par \par \par \par [Page 7] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par 5.1. ACCESS command (new IRCX command) \par \par Create an "access entry" for an object to grant or deny access \par to an object, including a channel, a user, or the server. \par ACCESS LIST is used to list all access entries for an object \par and CLEAR is used to clear all entries or all entries of the \par same level. \par \par Syntax 1: ACCESS LIST \par \par Syntax 2: ACCESS ADD|DELETE \par [ [:]] \par \par Syntax 3: ACCESS CLEAR [] \par \par 5.1.1. Parameters \par \par The object to which access is being granted or \par limited. Can be a channel name, nickname, $ or *. \par \par The level of access being given or taken away. Can \par be: \par \par DENY Disallow access to an object that is accessible \par \par GRANT Allow access to an object that is inaccessible \par \par HOST Channel host access to specified channel \par \par OWNER Channel owner access to specified channel \par \par VOICE Voice access to specified channel \par \par Mask to identify user by nickname, userid, host or \par server characteristics. Supports wildcards * and ?. \par \par Minutes until the access entry is removed. A value \par of 0 indicates unlimited duration. \par \par Text reason shown when users are denied access due \par to the access entry. \par \par 5.1.2. Results \par \par IRCRPL_ACCESSADD \par \par IRCRPL_ACCESSDELETE \par \par IRCRPL_ACCESSSTART \par \par IRCRPL_ACCESSLIST \par \par IRCRPL_ACCESSEND \par \par \par \par [Page 8] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par 5.1.3. Possible Errors \par \par In this specification possible error messages are listed. \par \par IRCERR_BADLEVEL \par \par IRCERR_DUPACCESS \par \par IRCERR_MISACCESS \par \par IRCERR_TOOMANYACCESSES \par \par IRCERR_TOOMANYARGUMENTS \par \par IRCERR_BADCOMMAND \par \par IRCERR_NOTSUPPORTED \par \par IRCERR_NOACCESS \par \par 5.1.4. Remarks \par \par An object with GRANT access entries but no DENY entries is \par assumed to be off-limits to those users not covered by the \par GRANT entries. If there are multiple entries in the access \par list, the list is processed in the following order: OWNER, \par HOST, VOICE, GRANT, DENY. \par \par Hosts and Owners may add and delete access entries for their \par channel. Hosts may not remove access entries added by owners. \par Any user may add and delete access entries for themselves. \par Sysops and sysop managers on a server may add and delete \par access entries for that server or the entire network. \par \par A user who has blocked another user does not get any messages \par from the blocked user, including invites. \par \par 5.1.5. Examples \par \par To make a user, "piper", a channel host when they join the \par channel, "#mychan": \par \par ACCESS #mychan ADD HOST piper \par \par To grant normal access to the network to a few people but deny \par access to all others: \par \par ACCESS * ADD DENY * :closed for private party \par \par ACCESS * ADD GRANT *.company.com :these people can get on \par \par To delete the DENY access record on the network that denies \par access to '*' (note that this doesn't delete other DENY access \par records such as '*.com'): \par \par \par [Page 9] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par ACCESS * DELETE DENY * \par \par To clear all DENY-level entries on the local server: \par \par ACCESS $ CLEAR DENY \par \par To clear all access entries of any level for a channel: \par \par ACCESS #mychan CLEAR \par \par 5.2. AUTH Command (new IRCX command) \par \par Authenticate the client using an SASL[4] authentication \par mechanism. \par \par Syntax 1: AUTH [:] \par \par 5.2.1. Parameters \par \par The name of the SASL mechanism to use for \par authentication. \par \par The sequence is a value of 'I' or 'S'. The 'I' value \par is specified for the initial AUTH message and the 'S' value is \par specified for all subsequent AUTH messages. If the \par client specifies '*' for the sequence, the server will abort \par the authentication sequence and return \par IRCERR_AUTHENTICATIONFAILED. \par \par This is optional data sent as an argument with \par the AUTH messages. The content depends on the authentication \par mechanism being used. All content must use standard escaping \par formats (e.g. \\r for carriage return) to comply with IRC \par message format restrictions. \par \par 5.2.2. Results \par \par AUTH message \par \par 5.2.3. Possible Errors \par \par ERR_NEEDMOREPARAMS \par \par IRCERR_ALREADYAUTHENTICATED \par \par IRCERR_ALREADYREGISTERED \par \par IRCERR_AUTHENTICATIONFAILED \par \par IRCERR_AUTHENTICATIONSUSPENDED \par \par IRCERR_BADCOMMAND \par \par IRCERR_UNKNOWNPACKAGE \par \par \par [Page 10] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par 5.2.4. Remarks \par \par If the server is known to support IRCX with specific SASL \par mechanism(s), then the first message from an IRCX-compliant \par client must be the AUTH command (if authentication is to be \par used), before the USER and NICK commands. Use MODE ISIRCX to \par determine if the server supports IRCX. \par \par 5.2.5. Example \par \par Client: AUTH NTLM I : \par \par Server: AUTH NTLM S : \par \par Client: AUTH NTLM S : \par \par Server: AUTH NTLM * userid@domain 03FA4534C \par \par 5.3. CREATE (new IRCX command) \par \par Create a new channel and/or join an existing channel. \par \par Syntax: CREATE [ []] \par \par 5.3.1. Parameters \par \par The name of the channel. \par \par Initial channel modes, not separated by spaces (like \par MODE command). Includes mode 'e' to force a clone of a \par clonable channel. \par \par Optional mode arguments, separated by spaces, in \par the same order as the modes. For the mode 'l' the mode \par argument is the maximum number of members in the channel. \par For the mode 'k' the mode argument is the channel \par keyword. These are the only modes that require mode \par arguments. \par \par 5.3.2. Results \par \par CREATE message \par \par JOIN message \par \par RPL_TOPIC \par \par RPL_NAMEPLY \par \par RPL_ENDOFNAMES \par \par 5.3.3. Possible Errors \par \par IRCERR_CHANNELEXIST \par \par \par [Page 11] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par IRCERR_ALREADYONCHANNEL \par \par ERR_NEEDMOREPARAMS \par \par ERR_INVITEONLYCHAN \par \par ERR_CHANNELISFULL \par \par ERR_BANNEDFROMCHAN \par \par ERR_BADCHANNELKEY \par \par ERR_TOOMANYCHANNELS \par \par ERR_UNKNOWNCOMMAND \par \par 5.3.4. Remarks \par \par The CREATE command provides a method to specify channel \par properties at creation time, and also provides a method (flag \par 'c') to create and join a channel only if it does not already \par exist. If user is not in IRCX mode, server returns \par ERR_UNKNOWNCOMMAND. \par \par 5.3.5. Examples \par \par This example shows the creation of a moderated (m) channel \par with the following properties and modes: its topic can only \par be changed by an owner or host (t = TOPICOP), messages from \par outside the channel are blocked (n = NOEXTERN), it is limited \par to 50 members (l 50), it has a member key which is 'password' \par (k password), and it will be created only if it doesn't \par already exist (c = CREATE) \par \par Client: CREATE #MyChannel tnmlkc 50 password \par \par Server: CREATE #MyChannel 048532944 \par \par 5.4. DATA / REQUEST / REPLY (new IRCX command) \par \par Used to send tagged data, requests or replies. The syntax for \par each is the same, but clients can use REQUEST to indicate that \par a REPLY is desired, and use REPLY to indicate that a REQUEST \par was issued. If user is not in IRCX mode, server returns \par ERR_UNKNOWNCOMMAND. \par \par Syntax 1: DATA : \par \par 5.4.1. Parameters \par \par The target for the data. Target can be a nick, list \par of nicks, channel, list of channels, or channel followed \par by a list of some members of the channel. This \par \par \par \par [Page 12] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par definition for will be used throughout this \par document. \par \par Text field that clients use to know how to interpret \par the data. Valid characters are [A..z], [0..9] and \par period (.). The first character must be one of [A..z]. \par Maximum 15 characters. If the tag begins with ADM, SYS, \par OWN or HST then the originator must have appropriate \par privileges (Sysop Manager, Sysop, Channel Owner or \par Channel Host. Channel Owner & Host apply to the channel \par the message is being sent to.) The server itself can \par send tags beginning with these reserved strings. \par \par Payload or data for the message, ending with a \par newline. Any newlines or other control characters within \par the body of the message must be escaped. \par \par 5.4.2. Results \par \par DATA message \par \par 5.4.3. Possible Errors \par \par ERR_UNKNOWNCOMMAND \par \par 5.4.4. Remarks \par \par REPLY and REQUEST may be used to replace "DATA". IRCX servers \par should not send DATA commands to clients that have not \par indicated that they support IRCX. Clients should only process \par DATA messages if they know and support the tag used. \par \par Prefixes should indicate the organization that specified them, \par when appropriate. For example: MYORG.AVATAR could be a tag \par used by MyOrg, as would be all MYORG.* tags. \par \par 5.4.5. Example \par \par Sending ad banners from server sysop to channel, "#Channel": \par \par DATA #Channel SYS.AD.SMALL : \par \par 5.5. EVENT (new IRCX command) \par \par Add/Change/Delete event logging to the client connection. The \par list of event types and the way masks are applied is not \par specified here. \par \par Syntax 1: EVENT [ADD | DELETE] [] \par \par Syntax 2: EVENT LIST [] \par \par 5.5.1. Parameters \par \par \par \par [Page 13] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par Type of event, such as CHANNEL, MEMBER, SERVER, \par CONNECTION, SOCKET or USER. \par \par Optional mask for applying a selection criteria per \par event. \par \par 5.5.2. Results \par \par IRCRPL_EVENTADD \par \par IRCRPL_EVENTDEL \par \par IRCRPL_EVENTSTART \par \par IRCRPL_EVENTLIST \par \par IRCRPL_EVENTEND \par \par 5.5.3. Possible Errors \par \par ERR_NEEDMOREPARAMS \par \par ERR_NOPRIVILEGES \par \par IRCERR_BADFUNCTION \par \par IRCERR_EVENTDUP \par \par IRCERR_EVENTMIS \par \par IRCERR_NOSUCHEVENT \par \par IRCERR_TOOMANYEVENTS \par \par 5.5.4. Remarks \par \par The EVENT command can be used by other server implementations \par to define the events that a sysop manager or sysop of the \par server wishes to be notified of. Only sysop managers and/or \par sysops are allowed to receive event messages. \par \par 5.5.5. Examples \par \par Add channel events. \par \par Client: EVENT ADD CHANNEL \par \par Server: : 806 CHANNEL *!*@*$* \par \par Add a list event with no active events returned. \par \par Client: EVENT LIST \par \par Server: : 808 :Start of events \par \par \par [Page 14] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par : 809 CHANNEL *!*@*$* \par \par : 810 :End of events \par \par 5.6. IRCX (new IRCX command) \par \par Enables IRCX mode and displays IRCX status. Use MODE ISIRCX \par first to see if the server supports IRCX. \par \par Syntax: IRCX \par \par 5.6.1. Parameters \par \par None. \par \par 5.6.2. Results \par \par IRCRPL_IRCX \par \par 5.6.3. Example \par \par This example includes a server that supports IRCX and three \par authentication packages. \par \par Client: IRCX \par \par Server: : 800 1 0 NTLM,DPA,ANON 512 * \par \par 5.7. ISIRCX (new IRCX command) \par \par Queries whether or not the server supports the Extended \par RFC1459 protocol (IRCX). Server response is same as for IRCX \par message.\ \ \par Use ISIRCX after logging into the server. \par \par Syntax: ISIRCX \par \par 5.7.1. Results \par \par IRCRPL_IRCX \par \par 5.8. LISTX (new IRCX command) \par \par Extended version of the LIST command that returns additional \par channel properties. Channels with extended names will be \par returned, even to non-IRCX clients. Some channel modes and \par the PICS rating string are included with the result. Only the \par channel modes that do not define an additional argument \par (TOPICOP, NOEXTERN, etc.) are included in the field. \par Clients should use the query limit to avoid overloading the \par client or having the connection dropped by the server. \par \par Syntax 1: LISTX [] \par \par \par [Page 15] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par Syntax 2: LISTX [] \par \par 5.8.1. Parameters \par \par A list of channels may be specified in order \par to find the PICS ratings or modes of those channels. If \par no channels are specified, the server will send the \par entire matching list of channels. \par \par One or more query terms separated by spaces or \par commas. \par \par Table 5 - Query terms for LIST command \par \par <# Select channels with less than # members. \par \par ># Select channels with more than # members. \par \par C<# Select channels created less than # minutes \par ago. \par \par C># Select channels created greater than # minutes \par ago. \par \par L= Select channels with language property \par matching the mask string. \par \par N= Select channels with name matching the mask \par string. \par \par R=0 Select unregistered channels. \par \par R=1 Select registered channels. \par \par S= Select channels with subject matching the mask \par string. \par \par T<# Select channels with a topic changed less than \par # minutes ago. \par \par T># Select channels with a topic changed greater \par than # minutes ago. \par \par T= Select channels that topic matches the mask \par string. \par \par Maximum number of channels to be returned. \par \par Sequence of characters that is used to select \par a matching channel name or topic. The \par character * and ? are used for wildcard \par searches. \par \par 5.8.2. Results \par \par \par [Page 16] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par IRCRPL_LISTXSTART \par \par IRCRPL_LISTXLIST \par \par IRCRPL_LISTXPICS \par \par IRCRPL_LISTXTRUNC \par \par IRCRPL_LISTXEND \par \par 5.8.3. Remarks \par \par To compose a mask, use this character escaping scheme. \par \par Table 6 - Character escaping in mask-string \par \par \\b for " " blank \par \par \\c for "," \par \par \\\\ for "\\" \par \par \\* for * \par \par \\? for ? \par \par The PICS property is only returned if not null. \par \par A record limit of '0' (zero) or blank will be interpreted as \par unlimited. \par \par 5.9. MODE (extension to RFC1459 command) \par \par MODE command can now be used for new user or channel modes \par (see later sections). In addition, the special syntax "MODE \par ISIRCX" can be used to help clients find out whether a server \par supports IRCX prior to logging into the server. \par \par Syntax: MODE ISIRCX \par \par 5.9.1. Results \par \par MODE message \par \par IRCRPL_IRCX \par \par 5.9.2. Remarks \par \par The ISIRCX mode (must be in capital letters) is only \par functional before the user has registered with the server. \par IRCX servers respond with IRCRPL_IRCX and non-IRCX servers \par should return an error code. This allows unregistered users \par to query whether the server supports IRCX. \par \par \par \par [Page 17] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par See RFC1459 for more details on the original MODE command and \par its parameters. \par \par 5.10. NOTICE (extension to RFC1459 command) \par \par Sends a notice to a channel or user. In RFC1459 a notice \par could only be sent to a channel or a list of users. Now a \par notice can be sent to a list of users within the context of a \par channel. As before, users will not get the list of users that \par received the notice. \par \par Syntax: NOTICE : \par \par 5.10.1. Results \par \par Same as defined in RFC1459, but with the additional \par functionality of sending to a list of nicknames within the \par context of a channel. \par \par 5.11. PRIVMSG (extension to RFC1459 command) \par \par Sends a message to a channel or user. PRIVMSG is extended in \par the same way as NOTICE. \par \par Syntax: PRIVMSG : \par \par 5.11.1. Results \par \par Same as defined in RFC1459, but with the additional \par functionality of sending to a list of nicknames within the \par context of a channel. \par \par 5.12. PROP (new IRCX command) \par \par Add, change or delete a channel data property. \par \par To query a property: \par \par Syntax 1: PROP [,] \par \par To set or change a property: \par \par Syntax 2: PROP : \par \par To delete a property: \par \par Syntax 3: PROP : \par \par 5.12.1. Results \par \par PROP message \par \par IRCRPL_PROPLIST \par \par \par \par [Page 18] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par IRCRPL_PROPEND \par \par 5.12.2. Possible Errors \par \par IRCERR_BADCOMMAND \par \par IRCERR_BADPROPERTY \par \par IRCERR_SECURITY \par \par IRCERR_NOSUCHOBJECT \par \par IRCERR_TOOMANYARGUMENTS \par \par IRCERR_BADVALUE \par \par 5.12.3. Remarks \par \par The PROP command provides a new method for manipulating string \par and numeric properties of channels. If an optional channel \par property is not supported on the server, the server should \par return IRCERR_BADPROPERTY. \par \par See section 8.2 for definitions of channel properties. \par \par 5.12.4. Examples \par \par Client: PROP #MyChan TOPIC,ONJOIN \par \par Server: : 818 #MyChan TOPIC :This is the topic of \par my channel \par \par Server: : 818 #MyChan ONJOIN :Welcome to my \par channel! \par \par Server: : 819 #MyChan :End of properties \par \par \par \par Client: PROP #MyChannel TOPIC :Change my channel topic \par \par Server: PROP #MyChannel TOPIC :Change my channel topic \par \par 5.13. WHISPER (new IRCX command) \par \par Whisper to member(s) in a channel. \par \par Syntax: WHISPER : \par \par 5.13.1. Results \par \par WHISPER message \par \par 5.13.2. Possible Errors \par \par \par [Page 19] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par ERR_UNKNOWNCOMMAND \par \par ERR_CANNOTSENDTOCHAN \par \par ERR_USERNOTINCHANNEL \par \par ERR_NEEDMOREPARAMS \par \par IRCERR_NOTONCHANNEL \par \par IRCERR_TOOMANYTARGETS \par \par IRCERR_NOSUCHNICK \par \par IRCERR_NOSUCHCHANNEL \par \par IRCERR_NOWHISPER \par \par 5.13.3. Remarks \par \par The purpose of the WHISPER command is to whisper to one or \par more members in a channel within the context of that channel. \par The sender and all recipients must be in the channel \par specified. A whisper is different from a privmsg in that it \par includes both a user list and a channel name, indicating that \par the message is private but has a context. \par \par IRCX clients should display the WHISPER message within the \par context (possibly a window) of the specified channel. Non- \par IRCX clients receive a PRIVMSG with the content of the whisper \par (losing the context of the whisper). Only one whisper will be \par sent per nick. A user may whisper to themselves. \par \par The channel mode 'w' will disable whispers between ordinary \par members of the channel (but not whispers from or to channel \par operators). \par \par 6. IRCX Server Messages \par \par This section summarizes new extended messages which can be \par sent from the server. \par \par 6.1. AUTH (new IRCX message) \par \par Negotiates authentication with client or informs client that \par authorization was successful. \par \par Syntax 1 (negotiating authorization): AUTH S \par [:] \par \par Syntax 2 (authorization successful): AUTH * \par \par \par 6.1.1. Parameters \par \par \par [Page 20] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par The name of the SASL mechanism to use for \par authentication. \par \par The ident is the userid@domain of the authenticated \par client account. It is returned on the final response from the \par server (Syntax 2) when authentication is successful. \par \par The OID is the internal object identifier assigned to \par the client connection. If not supported by the server, then \par OID must be returned as '0'. \par \par This is optional data sent as an argument with \par the AUTH messages. \par \par 6.1.2. Remarks \par \par The server will send the syntax 2 form when the authentication \par process is complete or a numeric error reply. \par \par 6.2. CLONE (new IRCX message) \par \par Informs the hosts and owners in a CLONEABLE channel that a \par new CLONE channel was created. \par \par Syntax: CLONE \par \par 6.2.1. Parameters \par \par The name of the created CLONE channel. \par \par The object identifier for this new CLONE channel. The \par value is implementation-dependent and must equal 0 if not \par supported. \par \par 6.2.2. Remarks \par \par The CLONE message can be sent at anytime to the hosts/owners \par of a CLONEABLE channel to inform them that a new CLONE channel \par was created. This message is intended to be used by a custom \par application to automatically join the new CLONE channel. A \par non-IRCX client will not get this message. \par \par 6.2.3. Example \par \par Server: CLONE #MyChat1 034F8FF32 \par \par 6.3. CREATE (new IRCX message) \par \par Informs the client that a new channel was created. Response \par to the CREATE command. \par \par Syntax: CREATE \par \par 6.3.1. Parameters \par \par \par [Page 21] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par The name of the created channel. \par \par The object identifier for this new channel. The value \par is implementation- dependent and must equal 0 if not \par supported. \par \par 6.3.2. Remarks \par \par The CREATE message is sent in response to a CREATE command \par sent by the client application if the channel specified did \par not previously exist and was created by the server. \par \par 6.3.3. Example \par \par Server: CREATE #MyChat1 034F8FF32 \par \par 6.4. DATA / REQUEST / REPLY (new IRCX messages) \par \par The DATA message (could be REQUEST or REPLY also) is \par forwarded from another user or sent by the server. The \par payload or message should be interpreted according to the tag. \par If the tag is unknown, the message may be discarded. \par \par Syntax 1: :DATA : \par \par :REQUEST : \par \par :REPLY : \par \par If the DATA, REQUEST or REPLY message is sent to a number of \par members within a channel, the receiving user will see the \par channel name and their own nick in the message as follows: \par \par Syntax 2: :DATA : \par \par 6.4.1. Parameters \par \par May be a user or a server. \par \par Channel and/or nick list as defined above. \par \par Identifying tag. \par \par Payload. \par \par 6.4.2. Remarks \par \par The tag indicates what to do with the message. Tag types may \par be specified by administrators, client developers, server \par developers etc. \par \par A tag beginning with SYS can only be from a sysop, sysop \par manager or the server. A tag beginning with ADM can only be \par from a sysop manager or the server. \par \par \par [Page 22] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par DATA message functionality is different from client-to-client \par messaging in several respects. First, we encourage groups to \par define their own tags and data formats for special purposes, \par for example to indicate details for a user's avatar in \par graphical chats, or to indicate that an ad banner or image \par should be downloaded. Second, the DATA message is more \par appropriate for content that may go to several users, for \par example all users in a channel. Third, the DATA message may \par come from the server. Fourth, the SYS and ADM prefixes are \par specified so that important tags may be reserved for sysops, \par sysop managers and the server itself, with the server \par responsible for verifying the sender before forwarding the \par DATA message. \par \par 6.5. EVENT (new IRCX message) \par \par Notifies the client of an event. These events are intended \par for sysops and sysop managers, and are sent in addition to IRC \par events. \par \par Syntax: EVENT \par \par 6.5.1. Parameters \par \par The number of elapsed seconds from midnight \par (00:00:00) January 1, 1970 (coordinated universal time) until \par the time that the event occurred on the server. \par \par Objects can be Channel, Member, User, Connection, \par Socket or Server. \par \par Event type varies depending on the object. For \par example, events for channels can be Create, Destroy, Topic \par change, Mode change, Collision. \par \par Vary depending on event type. \par \par 6.5.2. Example \par \par This example is the event generated when a user logs onto \par server, "chat1" with the nickname, "john", showing the user's \par info including IP address and port. \par \par EVENT chat1 946080000 USER LOGON john!jsmith@uw.edu \par 192.29.93.93:1111 \par \par 6.6. KNOCK (new IRCX message) \par \par Informs the owners and hosts of a channel that a user has \par tried to enter the channel and could not (could be because of \par a full channel, keyword wrong, user ban, or other reasons). \par This message is only sent to the IRCX owners and hosts of the \par channel. \par \par \par \par [Page 23] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par Syntax: KNOCK \par \par 6.6.1. Parameters \par \par User field is of the format nick!userid@host. \par \par Name of the channel that the user tried to enter. \par \par Reason that the user received when they tried to \par join the channel. \par \par 6.6.2. Remarks \par \par A KNOCK message will not be sent to a non-IRCX client. \par \par 6.7. REDIRECT (new IRCX message) \par \par Informs the client that they need to connect to another \par server. \par \par Syntax: REDIRECT : \par \par 6.7.1. Parameters \par \par The server list is a comma separated list of \par host:port pairs. The server list can be specified either as \par a fully-qualified domain name or by the IP address in quad- \par dotted notation. \par \par The redirect reason is an implementation-dependent \par string which can optionally be displayed to the client. \par \par 6.7.2. Remarks \par \par The REDIRECT message can be sent to the client at any time to \par request that the client disconnect and reconnect to another \par server specified in the list. The REDIRECT message is \par generally sent when a server is to be shutdown. \par \par A REDIRECT message will not be sent to a non-IRCX client. \par \par 6.7.3. Example \par \par Server: REDIRECT chat.corp.net:6667,134.9.3.3:6667 :Server \par full. \par \par 6.8. WHISPER (new IRCX message) \par \par A whisper from another channel member. \par \par Syntax: WHISPER : \par \par 6.8.1. Parameters \par \par \par \par [Page 24] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par The nick-name of the person that sent the whisper. \par \par The channel that the message is sent to. \par \par The list of nicknames of channel members that will \par receive the whisper. \par \par The content of the whisper. \par \par 6.8.2. Remarks \par \par The server may transform a WHISPER into a PRIVMSG for clients \par that do not support IRCX. \par \par 6.8.3. Example \par \par Server: Joe WHISPER #test Jill :Test whisper. \par \par 7. User Modes and Properties \par \par These are new user modes and properties that have been added. \par The MODE command as defined in RFC1459 is used to add or \par remove modes. \par \par 7.1. OWNER (IRCX +q) \par \par The OWNER mode indicates that the user is an owner of a \par channel. Only a channel owner can give OWNER mode to another \par member of that channel, but any owner may remove OWNER mode \par from themselves. \par \par Clients in IRCX mode see owner nicknames with a '.' prefix \par and continue to see hosts with a '@' prefix (in results \par from NAMES, WHO, WHOIS and other commands which list \par nicknames). \par \par Note that HOST mode uses +o, which was "operator" mode in \par RFC1459. Syntax for these modes is the same as "operator" \par mode: \par \par MODE \{ + | - \}q \par \par 7.2. GAG (IRCX +z) \par \par The GAG mode is applied by a sysop or sysop manager on a user \par and may not be removed except by a sysop or sysop manager. \par The user may not be notified when this mode is applied because \par the mode can be a more effective tool for keeping order if the \par user doesn't know exactly when it is applied. \par \par The server will discard all messages from a user with GAG mode \par to any other user or to any channel. \par \par MODE \{ + | - \}z \par \par \par [Page 25] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par 8. Channel Modes and Properties \par \par New modes and properties have been added to channels. \par \par Channels support four mutually exclusive states of visibility: \par public, private, hidden, and secret. The visibility of a \par channel affects which modes and properties are available to a \par client. \par \par 8.1. Modes \par \par Each channel object contains a number of binary mode settings \par that can be queried and optionally updated via the RFC1459 \par MODE command. \par \par 8.1.1. PUBLIC (RFC1459 default) \par \par The channel is public and all information about the channel \par (except for text messages) can be queried by non-members. \par PUBLIC mode is mutually exclusive with the PRIVATE, HIDDEN and \par SECRET modes. \par \par This mode may be set and queried by sysop managers, owners and \par hosts of the channel. It may be queried by sysops, members of \par the channel, and users. \par \par 8.1.2. PRIVATE (RFC1459 +p) \par \par The channel is private and only the name, number of members \par and PICS property can be queried by non-members. PRIVATE \par mode is mutually exclusive with the PUBLIC, HIDDEN and SECRET \par modes. \par \par This mode may be set by sysop managers, owners and hosts of \par the channel. It may be not be queried by sysops or users. \par \par 8.1.3. HIDDEN (IRCX +h) \par \par The channel is hidden and cannot be located by enumeration \par queries from non-members. HIDDEN mode is mutually exclusive \par with the PUBLIC, PRIVATE, and SECRET modes. The purpose of \par the new HIDDEN channel mode is to permit the existence of \par channels that cannot be found using the standard LIST \par command, but whose properties can be queried if the exact \par channel name is known. Thus a HIDDEN channel is the same as \par a PUBLIC channel except that it cannot be enumerated by using \par a LIST or LISTX command. \par \par This mode may be set and queried like PUBLIC mode. \par \par 8.1.4. SECRET (RFC1459 +s) \par \par \par \par \par \par [Page 26] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par The channel is secret and cannot by located by any query from \par non-members. SECRET mode is mutually exclusive with the \par PUBLIC, PRIVATE, and HIDDEN modes. \par \par This mode may be set and queried like PRIVATE mode. \par \par 8.1.5. MODERATED (RFC1459 +m) \par \par Normally, new channel members may speak. In MODERATED mode \par however, new channel members may not speak by default. This \par is achieved by giving all new members the '-v' mode (no voice) \par for that channel. Usually -v mode has no effect, but in a \par MODERATED channel it does. \par \par This mode may be set and queried by sysop managers, owners and \par hosts of the channel. It may be queried by sysops and members \par of the channel. Users may query this mode if the channel is \par PUBLIC or HIDDEN. \par \par 8.1.6. NOEXTERN (RFC1459 +n) \par \par NOEXTERN mode blocks messages from non-members to the \par channel. A sysop manager can still send a message to the \par channel. \par \par This mode may be set and queried like MODERATED mode. \par \par 8.1.7. TOPICOP (RFC1459 +t) \par \par TOPICOP mode permits only channel owners and hosts to change \par the channel topic property. \par \par This mode may be set and queried like MODERATED mode. \par \par 8.1.8. INVITE (RFC1459 +i) \par \par INVITE mode permits only invited users to enter the channel. \par Only owners and hosts can issue an invitation when this mode \par is on. \par \par This mode may be set and queried like MODERATED mode. \par \par 8.1.9. KNOCK (IRCX +u) \par \par The KNOCK extended mode causes a KNOCK message to be sent to \par owners and hosts of the channel if a user attempts to join a \par channel and the server denies entrance. \par \par This mode may be set and queried like MODERATED mode. \par \par 8.1.10. NOFORMAT (IRCX +f) \par \par The NOFORMAT channel mode is an indication to the client \par application not to format text received from the channel. \par \par \par [Page 27] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par Normally clients will prefix text messages with "x said y" or \par "x whispers to y and x", if the NOFORMAT mode is set then \par just the raw text should be displayed moving to the next line \par at the end of the message. The client should not echo text \par sent by the client. This is to permit custom applications to \par control the formatting to clients. Clients may want to inform \par users that messages can be spoofed with this mode. \par \par This mode can only be set by sysop managers. It can be read \par by sysop managers, sysops, owners, hosts and members of the \par channel. It can be read by users if the channel is PUBLIC or \par HIDDEN. \par \par 8.1.11. NOWHISPER (IRCX +w) \par \par The NOWHISPER channel mode will prevent all messages sent to \par specific nicknames within the context of that channel. \par \par This channel mode may be set and read by sysop managers and \par owners. It can be read by sysops, hosts and members of the \par channel. It can be read by other users if the channel is \par PUBLIC or HIDDEN. \par \par 8.1.12. AUDITORIUM (IRCX +x) \par \par The AUDITORIUM channel mode restricts visibility and messaging \par within a channel. Members will only see themselves and the \par hosts/owners in the channel. Any message sent by a member \par will only be received by the hosts and owners. Hosts and \par owners will see all members in the channel and messages from a \par host or owner are seen by all channel members. Ordinary \par members will not receive JOIN/PART messages from other \par members. This mode is designed for channels with so many \par members that they do not want to see each other. Note that \par auditorium mode may only be set at channel creation time using \par the CREATE command. \par \par This mode may be set and read by sysop managers, sysops, and \par owners. It may be read by hosts and members of the channel. \par It can be read by other users if the channel is PUBLIC or \par HIDDEN. \par \par 8.1.13. REGISTERED (IRCX +r) \par \par The channel is registered by the administrator of the chat \par network. The registration procedure is not defined here. Only \par the server or server administrator can set this mode. \par \par It can be read by sysop managers, sysops, owners, hosts, and \par members of the channel. It can be read by users if the \par channel is PUBLIC or HIDDEN. \par \par 8.1.14. SERVICE (IRCX +z) \par \par \par \par [Page 28] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par A service is monitoring/controlling the channel. This is an \par indication to the client that message traffic sent to the \par channel is being monitored by a Chat Service which does not \par appear as a member in the channel. \par \par This mode can only be set by the Chat Server. It can be read \par by sysop managers, sysops, owners, hosts and members of the \par channel. It can be read by users if the channel is PUBLIC or \par HIDDEN. \par \par 8.1.15. AUTHONLY (IRCX +a) \par \par The AUTHONLY channel mode permits channel access only to users \par who have been authenticated by the server. Note that an \par authenticated user is any user that was successfully \par authenticated with the PASS command or the AUTH command. \par \par This mode can be set and read by sysop managers or owners of \par the channel. It can be read by sysops, hosts and members of \par the channel. It can be read by users if the channel is PUBLIC \par or HIDDEN. \par \par 8.1.16. CLONEABLE (IRCX +d) \par \par The CLONEABLE channel mode defines a channel that creates new \par clone channels if the parent channel is full. A clone channel \par is created with the same name as the parent cloneable channel \par with a numeric suffix starting at 1, ranging to 99. It is not \par valid to set the CLONEABLE channel mode of a parent channel \par that ends with a numeric character. The clone channel \par inherits modes and properties from the parent channel when it \par is set up. When a clone channel is created, any channel that \par has the same name is removed. This prevents channel takeover \par of a clone channel. \par \par It is advised that only sysop be allowed to set cloneable mode \par on a channel. The mode may be read by sysops, owners, hosts \par and members of the channel. It may be read by users if the \par channel is PUBLIC or HIDDEN. \par \par 8.1.17. CLONE (IRCX +e) \par \par The CLONE channel mode defines a channel that was created by \par the server when a parent CLONEABLE channel becomes full. \par Users should usually join the parent channel, although a user \par may join a clone channel that is not full. A sysop manager \par can set up a clone channel but only when the channel is being \par created. \par \par This mode can be set by the sysop manager and read like the \par SERVICE mode. \par \par \par \par \par \par [Page 29] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par 8.2. Properties \par \par Each channel object contains a number of properties that can \par be queried and optionally updated via the IRCX PROP command. \par Owners and hosts may update a property for their own channel. \par Sysop Managers and Sysops can use the PROP command on a \par channel only by becoming host/owner of that channel. Users \par and members can read properties only. \par \par 8.2.1. OID (R/O) \par \par The OID channel property is the internal object identifier for \par the channel. As a shortcut, the OID can be optionally used \par in place of the full string name of a channel. If the OID \par is set to "0", then this feature is not supported on the \par server. \par \par This property may be read by all users, except by ordinary \par users when the channel is SECRET or PRIVATE. \par \par 8.2.2. NAME (R/O) \par \par The NAME channel property is the name of the channel (limited \par to 63 characters, including 1 or 2 characters for channel \par prefix). Valid characters are as defined in RFC1459. \par \par This property may be set and read like the OID property. \par \par 8.2.3. CREATION (R/O) \par \par The CREATION channel property is the time that the channel \par was created, in number of seconds elapsed since midnight \par (00:00:00), January 1, 1970, (coordinated universal time). \par \par This property may be set and read like the OID property. \par \par 8.2.4. LANGUAGE \par \par The LANGUAGE channel property is the preferred language type. \par The LANGUAGE property is a string limited to 31 characters. \par We recommend following the guidelines of RFC1766[6] to form \par well-understood language-defining strings. \par \par This property may be set and read by sysop managers, owners \par and hosts of the channel. It may be read by sysop managers, \par sysops and members. It may be read by users if the channel is \par PUBLIC or HIDDEN. \par \par 8.2.5. OWNERKEY \par \par The OWNERKEY channel property is the owner keyword that will \par provide owner access when entering the channel. The OWNERKEY \par property is limited to 31 characters. \par \par \par \par [Page 30] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par This property may be set by the sysop manager or channel \par owner. It may never be read. \par \par 8.2.6. HOSTKEY \par \par The HOSTKEY channel property is the host keyword that will \par provide host (channel op) access when entering the channel. \par The HOSTKEY property is limited to 31 characters. \par \par This property may be set and read like the OWNERKEY property. \par \par 8.2.7. MEMBERKEY \par \par The MEMBERKEY channel property is the keyword required to \par enter the channel. The MEMBERKEY property is limited to 31 \par characters. This is backwards-compatible with RFC1459 because \par users can still use the MODE command as an alternative way to \par set this property. \par \par This property may be set and read like the OWNERKEY property. \par \par 8.2.8. PICS \par \par The PICS channel property is the current PICS rating of the \par channel. Chat clients that are PICS enabled can use this \par property to determine if the channel is appropriate for the \par user. The PICS property is limited to 255 characters. The \par format for this field is defined by PICS (see \par http://www.w3.org). \par \par This property may be set by sysop managers and read by all. \par It may not be read by ordinary users if the channel is SECRET. \par \par 8.2.9. TOPIC \par \par The TOPIC channel property is the current topic of the \par channel. The TOPIC property is limited to 160 characters. \par \par This property may be set and read by sysop managers, owners \par and hosts of the channel. It may be read by sysops and \par members of the channel. It may be read by users if the \par channel is PUBLIC or HIDDEN. \par \par 8.2.10. SUBJECT \par \par The SUBJECT channel property is a string that can contain \par subject keywords for search engines. The SUBJECT property is \par limited to 31 characters. \par \par This property may be set and read like the TOPIC property. \par \par 8.2.11. CLIENT \par \par \par \par \par [Page 31] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par The CLIENT channel property contains client-specified \par information. The format is not defined by the server. The \par CLIENT property is limited to 255 characters. \par \par This property may be set and read like the TOPIC property. \par \par 8.2.12. ONJOIN \par \par The ONJOIN channel property contains a string to be sent (via \par PRIVMSG) to a user after the user has joined the channel. The \par channel name is displayed as the sender of the message. Only \par the user joining the channel will see this message. Multiple \par lines can be generated by embedding '\\n' in the string. The \par ONJOIN property is limited to 255 characters. \par \par This property may be set and read by sysop managers, owners \par and hosts of the channel. It may additionally be read by \par sysops. \par \par 8.2.13. ONPART \par \par The ONPART channel property contains a string that is sent \par (via NOTICE) to a user after they have parted from the \par channel. The channel name is displayed as the sender of the \par message. Only the user parting the channel will see this \par message. Multiple lines can be generated by embedding '\\n' \par in the string. The ONPART property is limited to 255 \par characters. \par \par This property may be set and read like the ONJOIN property. \par \par 8.2.14. LAG \par \par The LAG channel property contains a numeric value between 0 to \par 2 seconds. The server will add an artificial delay of that \par length between subsequent messages from the same member. All \par messages to the channel are affected. \par \par This property may be set and read by sysop managers and \par owners. It can additionally be read by sysops, hosts, and \par members of the channel. It can be read by users if the \par channel is PUBLIC or HIDDEN. \par \par 8.2.15. ACCOUNT \par \par The ACCOUNT channel property contains an implementation- \par dependent string for attaching a security account. This \par controls access to the channel using the native OS security \par system. The ACCOUNT property is limited to 31 characters. \par \par This property may be set by sysop managers. It can only be \par read by sysop managers, sysops and owners of the channel. \par \par 8.2.16. CLIENTGUID \par \par [Page 32] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par The CLIENTGUID channel property contains a GUID that defines \par the client protocol to be used within the channel. \par \par This property may be set and read like the LAG property. \par \par 8.2.17. SERVICEPATH \par \par The SERVICEPATH channel property contains the path of a server \par side extension that is used to control the channel operation. \par Details are implementation-dependent. \par \par This property may be set and read like the LAG property. \par \par 9. IRCX Command Responses \par \par The new extended IRCX numeric replies follow the same \par convention as IRC replies, with a specific range for command \par responses and another range for error results. The IRCX \par command responses are in the range of 800 to 899 and 900 to \par 999 for the error results. \par \par 9.1. Command Replies \par \par 800 - IRCRPL_IRCX \par \par \par \par The response to the IRCX and ISIRCX commands. The \par indicates if the client has IRCX mode enabled (0 for disabled, \par 1 for enabled). The is the version of the IRCX \par protocol starting at 0. The contains a list \par of authentication packages supported by the server. The \par package name of "ANON" is reserved to indicate that anonymous \par connections are permitted. The defines the maximum \par message size permitted, with the standard being 512. The \par contains a list of options supported by the \par server; these are implementation-dependent. If no options are \par available, the '*' character is used. \par \par 801 - IRCRPL_ACCESSADD \par \par : \par \par Response to a successful ACCESS ADD command. The is \par the name of the object to which the access restrictions apply \par (i.e. channel name or user name). The is the level of \par access being added (i.e. GRANT, DENY). The is the \par selection mask. If no mask is provided in the ACCESS command, \par then the default mask of *!*@*$* is used. The is \par the amount of time this access entry will last. The is \par the one who added the new ACCESS record. The is the \par reason supplied in the ACCESS ADD command. \par \par 802 - IRCRPL_ACCESSDELETE \par \par \par [Page 33] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par \par \par Response to a successful ACCESS DELETE command. See reply \par 801 for explanation of the fields. \par \par 803 - IRCRPL_ACCESSSTART \par \par :Start of access entries \par \par Beginning of a list of access entries. is the object \par to which the access restrictions apply (i.e. channel name or \par user name). The next message will be an IRCRPL_ACCESSLIST or \par IRCRPL_ACCESSEND reply. \par \par 804 - IRCRPL_ACCESSLIST \par \par : \par \par One entry in a list of access entries. See reply 801 for \par explanation of the fields. \par \par 805 - IRCRPL_ACCESSEND \par \par :End of access entries \par \par End of a list of access entries. See reply 803 for explanation \par of the field. This reply will always follow an \par IRCRPL_ACCESSSTART or IRCRPL_ACCESSLIST reply. \par \par 806 - IRCRPL_EVENTADD \par \par \par \par The acknowledgment response to the EVENT ADD command. The \par contains the name of the event added. The is \par the selection mask. If no mask is provided in the EVENT \par command, then the default mask of *!*@*$* is used. \par \par 807 - IRCRPL_EVENTDEL \par \par \par \par The acknowledgment response to the EVENT DELETE command. The \par contains the name of the deleted event. The is \par the selection mask. If no mask is provided in the EVENT \par command, then the default mask of *!*@*$* is used. \par \par 808 - IRCRPL_EVENTSTART \par \par :Start of events \par \par Response to the EVENT LIST message that indicates the \par start of the event list. \par \par \par \par [Page 34] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par 809 - IRCRPL_EVENTLIST \par \ \ \par \par Response to the EVENT LIST message that displays a \par list of current events that the client is interested in. \par \par 810 - IRCRPL_EVENTEND \par \par :End of events \par \par Response to the EVENT LIST message that indicates the \par end of the event list. \par \par 811 - IRCRPL_LISTXSTART \par \par :Start of ListX \par \par First reply to a LISTX (extended list) command. Will always \par be followed by a reply of type 812, 816 or 817. \par \par 812 - IRCRPL_LISTXLIST \par \par : \par \par Single list item in an extended list of channels. The \par is the name of the channel in the list. The \par specify the current modes set on the channel. lists \par the members currently in the channel. returns \par the member limit of the channel. returns the topic of \par the channel. \par \par 813 - IRCRPL_LISTXPICS \par \par : \par \par PICS rating string for the last channel listed (follows an 812 \par message). \par \par 816 - IRCRPL_LISTXTRUNC \par \par :Truncation of ListX \par \par Last reply to a LISTX command, either because the user asked \par for a limited list of channels or because the server truncated \par the list to prevent output flooding. Always follows a reply \par of type 811, 812 or 813. \par \par 817 - IRCRPL_LISTXEND \par \par :End of ListX \par \par Last reply to a LISTX command, indicating that the list has \par ended. Always follows a reply of type 811, 812 or 813. \par \par \par [Page 35] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par 818 - IRCRPL_PROPLIST \par \par : \par \par A value in a property list. The is the name of the \par object (i.e., channel name). The is the property \par in the list. The is the value of the property listed. \par \par 819 - IRCRPL_PROPEND \par \par :End of properties \par \par Last message in a property list. \par \par 9.2. IRCX Error Replies. \par \par 900 - IRCERR_BADCOMMAND \par \par :Bad command \par \par Response to an incorrectly formatted command. \par \par 901 - IRCERR_TOOMANYARGUMENTS \par \par :Too many arguments \par \par Response to too many arguments being provided for a command. \par \par 902 - IRCERR_BADFUNCTION \par \par :Bad function \par \par Response to a command that supports functions, with invalid \par function sent by the user. For example, the EVENT command \par supports functions. \par \par 903 - IRCERR_BADLEVEL \par \par :Bad level \par \par Response to an ACCESS command with a bad level specified (i.e. \par not GRANT, DENY...) \par \par 904 - IRCERR_BADTAG \par \par :Bad message tag. \par \par Response to a DATA/REQUEST/REPLY with an incorrect message \par tag. \par \par 905 - IRCERR_BADPROPERTY \par \par :Bad property specified \par \par \par \par [Page 36] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par Response to a channel property command with a bad property \par specified. \par \par 906 - IRCERR_BADVALUE \par \par :Bad value specified \par \par Response to an attempt to set an integer property to a string \par value (PROP command). \par \par 907 - IRCERR_RESOURCE \par \par :Not enough resources \par \par Server does not have enough resources to perform command. \par \par 908 - IRCERR_SECURITY \par \par :No permissions to perform command \par \par For security reasons, the command/function/operation is not \par permitted for this level of client. \par \par 909 - IRCERR_ALREADYAUTHENTICATED \par \par :Already authenticated \par \par The client is already authenticated with the server. \par \par 910 - IRCERR_AUTHENTICATIONFAILED \par \par :Authentication failed \par \par The authentication failed due to a bad userid/password or \par server/network failure. \par \par 911 - IRCERR_AUTHENTICATIONSUSPENDED \par \par :Authentication suspended for this IP \par \par Authentication has been temporary disabled due to too many \par authentication failures from this IP. \par \par 912 - IRCERR_UNKNOWNPACKAGE \par \par :Unsupported authentication package \par \par The authentication package specified is not known to the \par server. ISIRCX command will return a list of supported \par authentication packages. \par \par 913 - IRCERR_NOACCESS \par \par :No access \par \par \par [Page 37] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par Response to a user trying to change the ACCESS list for an \par object the user does not have sufficient privileges to alter. \par \par 914 - IRCERR_DUPACCESS \par \par :Duplicate access entry \par \par An access entry already exists for the specified user mask. \par \par 915 - IRCERR_MISACCESS \par \par :Unknown access entry \par \par Response to ACCESS DELETE command when server does not \par recognize the entry to be removed. \par \par 916 - IRCERR_TOOMANYACCESSES \par \par :Too many access entries \par \par Response to ACCESS ADD command when maximum number of access \par entries has been reached. \par \par 918 - IRCERR_EVENTDUP \par \par :Duplicate event entry \par \par The user has asked for an event that is already being sent. \par \par 919 - IRCERR_EVENTMIS \par \par :Unknown event entry \par \par Response to event remove command when user is not already \par receiving the event specified. \par \par 920 - IRCERR_NOSUCHEVENT \par \par :No such event type \par \par Response to event add command when server does not recognize \par the event specified. \par \par 921 - IRCERR_TOOMANYEVENTS \par \par :Too many events specified \par \par Response to event add command when user may not add another \par event to monitor. \par \par 923 - IRCERR_NOWHISPER \par \par :Does not permit whispers \par \par \par \par [Page 38] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par Response to whisper command when channel does not permit \par whispers. \par \par 924 - IRCERR_NOSUCHOBJECT \par \par :No such object found \par \par Response to an attempt to define a property for an object \par which can't be found (PROP command). \par \par 925 - IRCERR_NOTSUPPORTED \par \par :Command not supported by object \par \par Response to PROP and ACCESS commands when a bad object was \par specified in the command. \par \par 926 - IRCERR_CHANNELEXIST \par \par :Channel already exists. \par \par The channel name in the CREATE command already exists on the \par server and the +c mode was specified. \par \par 927 - IRCERR_ALREADYONCHANNEL \par \par :Already in the channel. \par \par Response to join command when user is already in the channel. \par \par 999 - IRCERR_UNKNOWNERROR \par \par :Unknown error code \par \par The internal error generated doesn't map to a valid IRCX error \par reply. The error code is implementation-dependent. \par \par 10. Security Considerations \par \par Security issues are also discussed in the authentication \par section. \par \par The IRCX and ISIRCX commands return a set of authentication \par mechanisms supported by the server. This method is open to a \par middle man attack whereby an attacker modifies the list of \par returned authentication methods and only offers a clear-text \par password transaction. In order to avoid this type of \par attack, only authentication methods with a challenge response \par mechanism should be used. \par \par Since all administration commands for RFC1459 and IRCX are \par sent in clear text, a stream layer encryption mechanism like \par SSL[5] or IPSEC is required to protect the integrity and \par confidentiality of the transactions. The mechanisms for \par \par \par [Page 39] \par \par \par \par \par INTERNET-DRAFT IRCX June 1998 \par \par \par establishing these connection are outside the scope of this \par document. \par \par 11. Acknowledgements \par \par Specific acknowledgments must be extended to the following \par people as the editors of the previous versions: \par \par Kent Cedola, Lisa Dusseault, and Thomas Pfenning \par \par In addition it has benefited from many rounds of review and \par comments. As so, any list of contributors is bound to be \par incomplete; please regard the following as only a selection \par from the group of people who have contributed to make this \par document what it is today. \par \par In alphabetical order: \par \par Josh Cohen, Alex Hoppman, David Kurlander, Robert Uttecht, and \par Teoman Smith \par \par 12. References \par \par [1] "Internet Relay Chat Protocol", Network Working Group RFC \par 1459, J. Oikarinen, D. Reed, May 1993 \par \par [2] The Unicode Consortium, "The Unicode Standard Version \par 2.0", Addison Wesley Developers Press, July 1996 \par \par [3] "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", \par Network Working Group RFC 2060, M. Crispin, December 1996 \par \par [4] "Simple Authentication and Security Layer (SASL)", Work \par in Progress, draft-myers-auth-sasl-07.txt, J. Myers, December \par 1996 \par \par [5] "The SSL Protocol Version 3.0", Work in Progress, draft- \par ietf-tls-ssl-version3-00.txt, Alan O. Freier, Philip Karlton, \par Paul C. Kocher, November 1996 \par \par [6] "Tags for the Identification of Languages", Network \par Working Group RFC 1766, H. Alvestrand, March 1995 \par \par 13. Authors' Addresses \par \par Dalen Abraham \par \par Microsoft Corporation \par \par One Microsoft Way \par \par Redmond, WA 98052 \par \par EMail: dalena@microsoft.com \par \par \par [Page 40] \par \par \par \par }