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]