Innovative Logic Corp.
February 2, 1997
Internet Relay Chat
Client To Client Protocol
Changes have been made to Section 2.1 as of February 12, 1997.
Status of this Memo
This document is a result of ongoing discussions among the
IRC client coders CTCP Working Group. The mailing list for the
group may be subscribed to by sending a mail message to
email@example.com. Comments may be sent to this
mailing list, or to the author at mmclagan (at) invlogic.com
or in writing at his address on last page.
Distribution of this memo is unlimited.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet
Drafts as reference material, or to cite them other than as a
''working draft'' or ''work in progress.''
This document discusses messages exchanged between IRC (RFC 1459)
clients. The intent of these messages, and the protocol described
herein, is to enhance the use of IRC. These include text
formatting codes, information exchange, direct conversation and
exchanging of files. A de facto standard exists today, but is
undefined and usually different from client to client. With this
draft, and ultimately an RFC, a clearly defined standard will be
Table of Contents:
- Any valid request, as discussed in 3. Sequence of chacters
A-Z, a-z and 0-9. A space is used to mark the end of the
- Any arbitrary text, subject to quoting as discussed in 2b.
[ ] Optional item
... Item repeated as desired
- Character used to begin and end a user request. Currently ^A, \001.
- Text which is passed thru a quoting mechanism as yet
undefined. Not currently used.
- Name of a file for transmission using DCC. File names
should be presented without path information. Path
separators contained in a filename will invalidate the
request. Each client will be required to accept and convert
a filename to local conventions.
- Character used to begin and optionally end a text formatting
request. Currently ^F, \006.
- An extended text attribute specification is terminated by a
- Required space.
- Request/Format argument.
- Colour selected from the table below. Each spec will be
preceded by an I, indicating this is an indexed value.
Single character, 0-9 and A-F.
- 3 byte value, representing Red, Green & Blue attributes as
values from 0 - 255. Each byte will be encoded in
hexadecimal and converted to text. Characters 0-9 and A-F
will be permitted. Each such value will be preceded by a #,
Example: #00FF00 << produces light green, btw.
- A colour specification. This can either be an indexed colour
or an RGB value.
Specification: <index> | <RGB>
- TCP/IP port number, 1024 - 65535
- Internet Protocol number, as follows:
- IP4 dotted notation (d.d.d.d)
- IP6 hex notation, also compressed format (x:x:x:x:x:x:x:x)
See RFC 1884, chapter 2.2 for more info.
- IP6 mixed hex notation (x:x:x:x:x:x:d.d.d.d)
- 32-bit IP4 number
This will be phased out, but is deprecated as of this RFC.
Retained for compatibility with current DCC CHAT implementation.
- Either a nickname or channel, something that IRC messages can be sent to.
- A 3 character ID code assigned to each known IRC client, used as part of extended text attributes or extended request.
All specifications will be spaced for legibility, white space used for this purpose will not be considered part of the format of a given command. Only spaces shown as <space> are required by the protocol.
Each colour will be an index, selected from the following table:
| 0|| Black|| 000,000,000
| 1|| Blue|| 000,000,128
| 2|| Green|| 000,128,000
| 3|| Cyan|| 000,128,128
| 4|| Red|| 128,000,000
| 5|| Purple|| 128,000,128
| 6|| Brown|| 128,128,000
| 7|| Lt Gray|| 204,204,204
| 8|| Gray|| 128,128,128
| 9|| Lt Blue|| 000,000,255
| A|| Lt Green|| 000,255,000
| B|| Lt Cyan|| 000,255,255
| C|| Lt Red|| 255,000,000
| D|| Pink|| 255,000,255
| E|| Yellow|| 255,255,000
| F|| White|| 255,255,255
The primary task of an IRC Client program is to display text to the user,
and allow text messages to be sent to other users. As such, the
following specifications affect all aspects of a particular client's
display. All text presented to the user should be assessed for
attribute changes. It is up to each client how it interprets the
request, as well as whether or not to present a particular attribute
All attributes are cumulative, that is to say, no specific attribute
overrides any other attribute type. All attributes requests may be
ignored, and any particular combination of attributes may be ignored,
either by design or by user request. Certain combinations may not make
sense in all environments, and are therefore not required to be
In order to facilitate the exchange of information with in the IRC
networks, users have indicated desire to transmit files, determine
transmission times and send specialized text messages. As RFC 1459
offers no direct means to exchange such requests, a protocol built upon
RFC1459's is required. Over the course of time, the use of PRIVMSG and
NOTICE encapsulated within the <marker> character, ^A, has come to be
standard. This will be an attempt to clarify earlier documents on this
subject, as well as provide additional functionality.
The basic format of any request will be as follows:
Within the framework of these requests, some may generate a response.
This response will take the following general form:
Requests which are not recognised or are invalid may return an error
message similar to the following:
RFC 1459 indicates that the servers will contain flood control
mechanisms, which will disconnect clients that send excessive amounts of
text to their server within short periods of time. Given that this
method is used by less desirable elements of the IRC community to take
over channels, gain access to otherwise used nicknames and to disrupt
the pursuit of enjoyment, each client must take steps to avoid this
For this reason, requests may be ignored by the client, based on
selected criteria. Each client must determine, for the benefit of its
users, what means it will provide to ensure that excessive text is not
sent to the server. Suggestions include sending only 1 CTCP reply per
second, counting requests and not responding to more than X requests per
Y seconds, and others. The use of ignore commands within clients may
also be used to reject requests.
Innovative Logic Corp.
P.O. Box 1068
Laurel, MD 20725-1068
EMail: mmclagan (at) invlogic.com
Report any access issues to our
Last modified: 05-Feb-2003 05:15PM.
Material copyright ©1996-1997, Innovative Logic Corp.
Design copyright ©1996-1997,
Innovative Web Creations.
All rights reserved.