<html lang="en"><head><title>IRC Client Capabilities Extension</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="IRC Client Capabilities Extension">
<meta name="keywords" content="IRC, Internet Relay Chat, Extension, Protocol, Capability, Capabilities">
<style type='text/css'>
<!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
margin: 2em;
font-size: small ; color: #000000 ; background-color: #ffffff ; }
.title { color: #990000; font-size: x-large ;
font-weight: bold; text-align: right;
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
background-color: transparent; }
.filename { color: #666666; font-size: 18px; line-height: 28px;
font-weight: bold; text-align: right;
font-family: helvetica, arial, sans-serif;
background-color: transparent; }
td.rfcbug { background-color: #000000 ; width: 30px ; height: 30px ;
text-align: justify; vertical-align: middle ; padding-top: 2px ; }
td.rfcbug span.RFC { color: #666666; font-weight: bold; text-decoration: none;
background-color: #000000 ;
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-size: x-small ; }
td.rfcbug span.hotText { color: #ffffff; font-weight: normal; text-decoration: none;
text-align: center ;
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-size: x-small ; background-color: #000000; }
div#counter{margin-top: 100px}
a.info{
position:relative; /*this is the key*/
z-index:24;
text-decoration:none}
a.info:hover{z-index:25; background-color:#990000 ; color: #ffffff ;}
a.info span{display: none}
a.info:hover span.info{ /*the span will display just on :hover state*/
display:block;
position:absolute;
font-size: smaller ;
top:2em; left:2em; width:15em;
padding: 2px ;
border:1px solid #333333;
background-color:#eeeeee; color:#990000;
text-align: left ;}
A { font-weight: bold; }
A:link { color: #990000; background-color: transparent ; }
A:visited { color: #333333; background-color: transparent ; }
A:active { color: #333333; background-color: transparent ; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small ; }
p.toc { font-size: small ; font-weight: bold ; margin-left: 3em ;}
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
span.emph { font-style: italic; }
span.strong { font-weight: bold; }
span.verb, span.vbare { font-family: "Courier New", Courier, monospace ; }
span.vemph { font-style: italic; font-family: "Courier New", Courier, monospace ; }
span.vstrong { font-weight: bold; font-family: "Courier New", Courier, monospace ; }
span.vdeluxe { font-weight: bold; font-style: italic; font-family: "Courier New", Courier, monospace ; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
pre { margin-left: 3em; color: #333333; background-color: transparent;
font-family: "Courier New", Courier, monospace ; font-size: small ;
text-align: left;
}
h3 { color: #333333; font-size: medium ;
font-family: helvetica, arial, sans-serif ;
background-color: transparent; }
h4 { font-size: small; font-family: helvetica, arial, sans-serif ; }
table.bug { width: 30px ; height: 15px ; }
td.bug { color: #ffffff ; background-color: #990000 ;
text-align: center ; width: 30px ; height: 15px ;
}
td.bug A.link2 { color: #ffffff ; font-weight: bold;
text-decoration: none;
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-size: x-small ; background-color: transparent }
td.header { color: #ffffff; font-size: x-small ;
font-family: arial, helvetica, sans-serif; vertical-align: top;
background-color: #666666 ; width: 33% ; }
td.author { font-weight: bold; margin-left: 4em; font-size: x-small ; }
td.author-text { font-size: x-small; }
table.full { vertical-align: top ; border-collapse: collapse ;
border-style: solid solid solid solid ;
border-color: black black black black ;
font-size: small ; text-align: center ; }
table.headers, table.none { vertical-align: top ; border-collapse: collapse ;
border-style: none;
font-size: small ; text-align: center ; }
table.full th { font-weight: bold ;
border-style: solid ;
border-color: black black black black ; }
table.headers th { font-weight: bold ;
border-style: none none solid none;
border-color: black black black black ; }
table.none th { font-weight: bold ;
border-style: none; }
table.full td {
border-style: solid solid solid solid ;
border-color: #333333 #333333 #333333 #333333 ; }
table.headers td, table.none td { border-style: none; }
hr { height: 1px }
-->
</style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Network Working Group</td><td class="header">K. Mitchell</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">P. Lorier</td></tr>
<tr><td class="header">Expires: September 2, 2005</td><td class="header">Undernet IRC Network</td></tr>
<tr><td class="header"> </td><td class="header">L. Hardy</td></tr>
<tr><td class="header"> </td><td class="header">ircd-ratbox</td></tr>
<tr><td class="header"> </td><td class="header">P. Kucharski</td></tr>
<tr><td class="header"> </td><td class="header">IRCnet</td></tr>
<tr><td class="header"> </td><td class="header">March 2005</td></tr>
</table></td></tr></table>
<div align="right"><span class="title"><br />IRC Client Capabilities Extension</span></div>
<div align="right"><span class="title"><br />draft-mitchell-irc-capabilities-02</span></div>
<h3>Status of this Memo</h3>
<p>
By submitting this Internet-Draft,
each author represents that any applicable patent or other IPR claims of which
he or she is aware have been or will be disclosed,
and any of which he or she becomes aware will be disclosed,
in accordance with Section 6 of BCP 79.</p>
<p>
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.</p>
<p>
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 material or to cite
them other than as “work in progress.”</p>
<p>
The list of current Internet-Drafts can be accessed at
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<p>
This Internet-Draft will expire on September 2, 2005.</p>
<h3>Copyright Notice</h3>
<p>
Copyright © The Internet Society (2005).</p>
<h3>Abstract</h3>
<p>IRC (Internet Relay Chat) is a long-standing protocol for
real-time chatting. The basic client-server protocol is a very
simple text-based protocol with no explicit mechanism for
introducing or negotiating backwards-incompatible extensions.
This memo presents a mechanism for negotiation of such
extensions.
</p>
<h3>Requirements Language</h3>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in <a class="info" href="#RFC2119">RFC 2119<span> (</span><span class="info">Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [1].
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#intro">1.</a>
Introduction<br />
<br />
<a href="#problems">2.</a>
Problems to be Solved<br />
<br />
<a href="#cap">3.</a>
The CAP Command<br />
<a href="#ls">3.1.</a>
CAP LS<br />
<a href="#list">3.2.</a>
CAP LIST<br />
<a href="#req">3.3.</a>
CAP REQ<br />
<a href="#ack">3.4.</a>
CAP ACK<br />
<a href="#nak">3.5.</a>
CAP NAK<br />
<a href="#clear">3.6.</a>
CAP CLEAR<br />
<a href="#end">3.7.</a>
CAP END<br />
<br />
<a href="#negotiation">4.</a>
Capability Negotiation<br />
<br />
<a href="#capabilities">5.</a>
Capabilities<br />
<a href="#modifiers">5.1.</a>
Capability Modifiers<br />
<br />
<a href="#iana">6.</a>
IANA Considerations<br />
<br />
<a href="#security">7.</a>
Security Considerations<br />
<br />
<a href="#acknowledgments">8.</a>
Acknowledgments<br />
<br />
<a href="#rfc.references1">9.</a>
References<br />
<br />
<a href="#example">Appendix A.</a>
Examples<br />
<br />
<a href="#abnf">Appendix B.</a>
ABNF Description of Capabilities<br />
<br />
<a href="#changelog">Appendix C.</a>
ChangeLog<br />
<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
<a href="#rfc.copyright">§</a>
Intellectual Property and Copyright Statements<br />
</p>
<br clear="all" />
<a name="intro"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1. Introduction</h3>
<p>The IRC protocol, as originally documented by <a class="info" href="#RFC1459">RFC 1459<span> (</span><span class="info">Oikarinen, J. and D. Reed, “Internet Relay Chat Protocol,” May 1993.</span><span>)</span></a> [2] and
updated by <a class="info" href="#RFC2812">RFC 2812<span> (</span><span class="info">Kalt, C., “Internet Relay Chat: Client Protocol,” April 2000.</span><span>)</span></a> [3], is a simple, text-based conferencing
protocol, involving a number of users spread across a number of
interconnected servers. These users may chat with other
individual users, or may chat with groups of users on
"channels"--what other chat systems refer to as "rooms" or "chat
rooms".
</p>
<p>Over the years, various extensions to the basic IRC protocol
have been made by IRC server programmers. Often, these
extensions are intended to conserve bandwidth, close loopholes
left by the original protocol specification, or add features for
users or for the server administrators. Most of these changes
are backwards-compatible with the original protocol
specification: A command may be added, a reply may be extended
to contain more parameters, etc. Recently, however, there has
been a desire to introduce changes that would not be
backwards-compatible with existing IRC clients. Ideally, these
protocol changes would only be used with clients and servers
that can understand the revised protocol. Unfortunately, the
IRC protocol does not provide any form of extension or protocol
negotiation, making it impossible to determine support for such
extensions.
</p>
<p>This memo introduces a standardized mechanism for negotiation
of protocol extensions, known as <span class="emph">capabilities</span>, that will be
backwards-compatible with all existing IRC clients and servers.
Any server not implementing this extension will still
interoperate with clients that do implement it; similarly,
clients that do not implement the capabilities extension may
successfully communicate with a server that does implement the
extension.
</p>
<a name="problems"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2. Problems to be Solved</h3>
<p>The IRC protocol is not a lockstep protocol. This means that
a client may issue additional commands before the server has
finished responding to the first one. Additionally, unlike
other protocols, the server does not necessarily issue a banner
response upon initial connection. This, combined with the fact
that some servers do not complain about unknown commands prior
to completion of the client registration phase, means that a
client cannot know for certain whether a server implements the
extension. If a client had to wait for a banner message, it
would fail to interoperate with a server not implementing the
capabilities extension. If the client must issue a command and
then wait for a response, a similar problem results. As some
potential protocol extensions must be set up prior to completion
of the client registration phase, there is no reliable way a
server may indicate implementation of the capabilities extension
to a client.
</p>
<p>The solution to these problems turns out to be to extend the
client registration procedure. The client sends a request to
begin capability negotiation, as well as the other information
necessary for client registration (user name, nick name,
optional password, etc.). If the server understands the
capabilities extension, it will suspend completion of the
registration phase until the negotiation is complete;
negotiation may then proceed in a lockstep fashion. If the
server does not understand capabilities, then the registration
will complete immediately, and the client will receive the 001
numeric. This will signal to the client that the server does
not implement the capabilities extension.
</p>
<a name="cap"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3. The CAP Command</h3>
<p>The capabilities extension is implemented by addition of one
command with several subcommands. The command added is <span class="emph">CAP</span>. CAP takes a single, required
subcommand, optionally followed by a single parameter consisting
of a space-separated list of capabilities. Each capability
within the list MAY be preceded by a <a class="info" href="#modifiers">capability modifier.<span> (</span><span class="info">Capability Modifiers</span><span>)</span></a>
</p>
<p>The subcommands defined for CAP are:<br />
<br />
</p>
<ol class="text">
<li><a class="info" href="#ls">LS<span> (</span><span class="info">CAP LS</span><span>)</span></a>
</li>
<li><a class="info" href="#list">LIST<span> (</span><span class="info">CAP LIST</span><span>)</span></a>
</li>
<li><a class="info" href="#req">REQ<span> (</span><span class="info">CAP REQ</span><span>)</span></a>
</li>
<li><a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a>
</li>
<li><a class="info" href="#nak">NAK<span> (</span><span class="info">CAP NAK</span><span>)</span></a>
</li>
<li><a class="info" href="#clear">CLEAR<span> (</span><span class="info">CAP CLEAR</span><span>)</span></a>
</li>
<li><a class="info" href="#end">END<span> (</span><span class="info">CAP END</span><span>)</span></a>
</li>
</ol><p>
</p>
<p>The <a class="info" href="#ls">LS<span> (</span><span class="info">CAP LS</span><span>)</span></a>, <a class="info" href="#list">LIST<span> (</span><span class="info">CAP LIST</span><span>)</span></a>, <a class="info" href="#req">REQ<span> (</span><span class="info">CAP REQ</span><span>)</span></a>, <a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a>, and <a class="info" href="#nak">NAK<span> (</span><span class="info">CAP NAK</span><span>)</span></a> subcommands may be
followed by a single parameter consisting of a space-separated
list of capability names. If more than one capability is named,
this argument MUST be preceded by the IRC protocol colon (':')
sentinel to signal that the remainder of the line is a single
argument.
</p>
<p>If a client sends a subcommand not listed above or issues an
invalid command, the server SHOULD reply with the
ERR_INVALIDCAPCMD numeric response, 410. The first parameter
after the client nickname SHALL be the subcommand the client
sent; the second parameter SHOULD be a textual description of
the error.
</p>
<p>In <a class="info" href="#RFC2234">ABNF<span> (</span><span class="info">Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [4] notation:
</p><pre>
capcmd = [ ":" servername SP ] "CAP" SP subcmd
subcmd = lscmd / listcmd / reqcmd / ackcmd /
nakcmd / clearcmd / endcmd
capcmderr = ":" servername SP "410" SP nick SP badcmd
SP ":Invalid CAP subcommand"
; badcmd is the unrecognized subcommand
caplist = [ ":" ] *( capmod ) capab
caplist =/ ":" *( capmod ) capab 1*( SP *( capmod ) capab )
</pre>
<p>where SP is as designated in Appendix A of
<a class="info" href="#RFC2234">RFC 2234<span> (</span><span class="info">Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [4], and servername and nick are as designated in
section 2.3.1 of <a class="info" href="#RFC1459">RFC 1459<span> (</span><span class="info">Oikarinen, J. and D. Reed, “Internet Relay Chat Protocol,” May 1993.</span><span>)</span></a> [2].
</p>
<p>The discussion in the following sections applies only to
clients and servers implementing the capabilities extension.
Servers (and clients) not implementing the capabilities
extension are exempted from the requirements of this
section.
</p>
<a name="ls"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1. CAP LS</h3>
<p>The LS subcommand is used to list the capabilities
supported by the server. The client SHALL send an LS
subcommand with no arguments to solicit a list of supported
capabilities from the server. Servers MUST respond to such LS
subcommands with one or more LS subcommands containing the
list of recognized capabilities. All but the last subcommand
MUST have a parameter containing only an asterisk ('*')
preceding the capability list.
</p>
<p>If a client issues an LS subcommand during the client
registration phase, client registration MUST be suspended
until an <a class="info" href="#end">END<span> (</span><span class="info">CAP END</span><span>)</span></a> subcommand is received.
</p>
<p><a class="info" href="#RFC2234">ABNF<span> (</span><span class="info">Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [4] description of the LS
subcommand:
</p><pre>
lscmd = "LS"
lscmd =/ "LS" SP [ "*" SP ] caplist
</pre>
<a name="list"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2. CAP LIST</h3>
<p>The LIST subcommand is provided to permit the client to
request a list of the capabilities currently active for the
connection. It is similar to the <a class="info" href="#ls">LS<span> (</span><span class="info">CAP LS</span><span>)</span></a> subcommand--if a client
issues a LIST subcommand with no arguments, the server MUST
respond with a sequence of LIST subcommands, all but the last
of which MUST have a single parameter consisting solely of an
asterisk ('*') preceding the list of capabilities. If no
capabilities have been enabled, the server MUST send a LIST
command with an empty capability list; the parameter MUST NOT
be omitted. The active capabilities MAY be listed in any
order.
</p>
<p><a class="info" href="#RFC2234">ABNF<span> (</span><span class="info">Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [4] description of the LIST
subcommand:
</p><pre>
listcmd = "LIST"
listcmd =/ "LIST" SP ":"
listcmd =/ "LIST" SP [ "*" SP ] caplist
</pre>
<a name="req"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.3"></a><h3>3.3. CAP REQ</h3>
<p>The REQ subcommand is sent by the client to request that a
capability or set of capabilities be enabled or disabled. Its
sole parameter MUST be a space-separated list of
capabilities. Each capability name MAY be preceded by a dash
('-') to indicate that the capability should be disabled.
Additionally, receipt of this subcommand during the client
registration MUST suspend client registration until an <a class="info" href="#end">END<span> (</span><span class="info">CAP END</span><span>)</span></a>
subcommand is received.
</p>
<p>Servers MUST respond to a REQ command with either the <a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a>
or <a class="info" href="#nak">NAK<span> (</span><span class="info">CAP NAK</span><span>)</span></a> subcommands to indicate acceptance or rejection of
the capability set requested by the client. A server MUST
accept the entire capability set or reject it whole; servers
MUST NOT accept some capabilities in the set while rejecting
others. If a client requests that a "sticky" capability be
disabled, the server MUST reject the capability set.
</p>
<p><a class="info" href="#RFC2234">ABNF<span> (</span><span class="info">Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [4] description of the REQ
subcommand:
</p><pre>
reqcmd = "REQ" SP caplist
</pre>
<a name="ack"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.4"></a><h3>3.4. CAP ACK</h3>
<p>The ACK subcommand has three uses. It is used by the
server to acknowledge a <a class="info" href="#req">REQ<span> (</span><span class="info">CAP REQ</span><span>)</span></a> subcommand; by the server to
acknowledge a <a class="info" href="#clear">CLEAR<span> (</span><span class="info">CAP CLEAR</span><span>)</span></a> subcommand and list the removed
capabilities; and by the client to acknowledge certain
capabilities designated as requiring acknowledgment. If more
than one ACK is required due to the IRC line length limitation
of 512 characters, all but the last SHALL contain a parameter
consisting of a single asterisk ('*') immediately preceding
the list of capabilities, as for <a class="info" href="#ls">LS<span> (</span><span class="info">CAP LS</span><span>)</span></a> and <a class="info" href="#list">LIST<span> (</span><span class="info">CAP LIST</span><span>)</span></a>.
</p>
<p>If an ACK reply originating from the server is spread
across multiple lines, a client MUST NOT change capabilities
until the last ACK of the set is received. Equally, a server
MUST NOT change the capabilities of the client until the last
ACK of the set has been sent.
</p>
<p>In the first usage, acknowledging a <a class="info" href="#req">REQ<span> (</span><span class="info">CAP REQ</span><span>)</span></a> subcommand, the
ACK subcommand has a single parameter consisting of a space
separated list of capability names, which may optionally be
preceded with one or more <a class="info" href="#modifiers">modifiers<span> (</span><span class="info">Capability Modifiers</span><span>)</span></a>.
</p>
<p>The second usage, acknowledging a <a class="info" href="#clear">CLEAR<span> (</span><span class="info">CAP CLEAR</span><span>)</span></a> subcommand, is
similar to the first usage. When a <a class="info" href="#clear">CLEAR<span> (</span><span class="info">CAP CLEAR</span><span>)</span></a> subcommand is
issued, all non-"sticky" capabilities are disabled, and a set
of ACK subcommands will be generated by the server with the
disable modifier preceding each capability.
</p>
<p>The third usage is when, in the preceding two cases, some
capability names have been preceded with the ack modifier.
ACK in this case is used to fully enable or disable the
capability. Clients MUST NOT issue an ACK subcommand for any
capability not marked with the ack modifier in a
server-generated ACK subcommand.
</p>
<p><a class="info" href="#RFC2234">ABNF<span> (</span><span class="info">Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [4] description of the ACK
subcommand:
</p><pre>
ackcmd = "ACK" SP [ "*" SP ] caplist
</pre>
<a name="nak"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.5"></a><h3>3.5. CAP NAK</h3>
<p>The NAK subcommand MUST be sent by the server in response
to a <a class="info" href="#req">REQ<span> (</span><span class="info">CAP REQ</span><span>)</span></a> subcommand when any capability change requested
cannot be performed for any reason. The server MUST NOT make
any change to the set of capabilities for the client if it
responds with a NAK subcommand. The argument of the NAK
subcommand MUST consist of at least the first one hundred
characters of the capability list in the <a class="info" href="#req">REQ<span> (</span><span class="info">CAP REQ</span><span>)</span></a> subcommand
which triggered the NAK.
</p>
<p><a class="info" href="#RFC2234">ABNF<span> (</span><span class="info">Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [4] description of the NAK
subcommand:
</p><pre>
nakcmd = "NAK" SP ":" acklist
; acklist is at least 100 characters of
; the capability list from the REQ
</pre>
<a name="clear"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.6"></a><h3>3.6. CAP CLEAR</h3>
<p>The CLEAR subcommand requests that the server clear the
capability set for the client. The server MUST respond with a
set of <a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a> subcommands indicating the capabilities being
deactivated.
</p>
<p><a class="info" href="#RFC2234">ABNF<span> (</span><span class="info">Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [4] description of the CLEAR
subcommand:
</p><pre>
clearcmd = "CLEAR"
</pre>
<a name="end"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3.7"></a><h3>3.7. CAP END</h3>
<p>The END subcommand signals to the server that capability
negotiation is complete and requests that the server continue
with client registration. If the client is already
registered, this command MUST be ignored by the server.
</p>
<p>Clients that support capabilities but do not wish to enter
negotiation SHOULD send CAP END upon connection to the
server.
</p>
<p><a class="info" href="#RFC2234">ABNF<span> (</span><span class="info">Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [4] description of the END
subcommand:
</p><pre>
endcmd = "END"
</pre>
<a name="negotiation"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4. Capability Negotiation</h3>
<p>Clients implementing this extension SHOULD take one of the
following three actions upon initial connection to a
server:<br />
<br />
</p>
<ul class="text">
<li>Issue an <a class="info" href="#ls">LS<span> (</span><span class="info">CAP LS</span><span>)</span></a> subcommand (with an empty capability list)
to solicit a list of supported capabilities from the
server;<br />
<br />
</li>
<li>Issue the <a class="info" href="#req">REQ<span> (</span><span class="info">CAP REQ</span><span>)</span></a> subcommand to request a particular set of
capabilities without knowing what capabilities the server
supports or if it supports the capabilities extension;
or<br />
<br />
</li>
<li>Issue the <a class="info" href="#end">END<span> (</span><span class="info">CAP END</span><span>)</span></a> subcommand to signal implementation of
the capabilities extension without entering into capability
negotiation.
</li>
</ul><p>
</p>
<p>Although a client is permitted to not issue any CAP commands
upon connection, this is NOT RECOMMENDED. Servers MAY assume a
client does not implement the capabilities extension if it does
not issue any CAP commands upon initial connection.
</p>
<p>Clients SHOULD follow CAP commands issued upon connection
with the standard IRC client registration commands without
waiting for any responses from the server. See <a class="info" href="#RFC1459">RFC 1459<span> (</span><span class="info">Oikarinen, J. and D. Reed, “Internet Relay Chat Protocol,” May 1993.</span><span>)</span></a> [2] for
more details about the client registration procedure.
</p>
<p>If a client issues the <a class="info" href="#ls">LS<span> (</span><span class="info">CAP LS</span><span>)</span></a> or <a class="info" href="#req">REQ<span> (</span><span class="info">CAP REQ</span><span>)</span></a> subcommands during the
client registration procedure, a server implementing the
capabilities extension MUST NOT complete the client registration
until the client issues the <a class="info" href="#end">END<span> (</span><span class="info">CAP END</span><span>)</span></a> subcommand. A client that
sees a RPL_WELCOME (001) numeric response before it sends CAP
<a class="info" href="#end">END<span> (</span><span class="info">CAP END</span><span>)</span></a> SHOULD assume that the server does not support the
capabilities extension.
</p>
<p>Once the client is registered, CAP commands SHALL have no
effect on other connection operations, except that a client MAY
change the capabilities it has set. In particular, CAP commands
and their responses MAY be interspersed with other protocol
messages. The <a class="info" href="#end">END<span> (</span><span class="info">CAP END</span><span>)</span></a> subcommand SHALL have no effect once client
registration has been completed.
</p>
<a name="capabilities"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5. Capabilities</h3>
<p>Capabilities are designated by a name composed of one or more
elements. Name elements are not case-sensitive. They must
begin with a letter and may contain any number of letters,
numbers, and the dash character ('-'). Names containing more
than one name element MUST also contain a period character ('.')
in the first name element. Name elements are separated from
each other via the slash character ('/').
</p>
<p>There are two capability name spaces:<br />
<br />
</p>
<blockquote class="text"><dl>
<dt>Network Specific:</dt>
<dd>Names whose first element
contains a period character ('.') designate a delegated
capability name space. The first element MUST be a valid,
existing DNS domain name. These names MUST contain at least
two elements.<br />
</dd>
<dt>Standardized:</dt>
<dd>All other names MUST correspond
to capabilities documented by an RFC. Further, these names
MUST contain only one element.
</dd>
</dl></blockquote><p>
</p>
<p>These rules are summarized by the following <a class="info" href="#RFC2234">ABNF<span> (</span><span class="info">Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [4]
representation:
</p><pre>
elem = ALPHA *( ALPHA / DIGIT / "-" )
netname = elem 1*( "." elem )
netDeleg = netname 1*( "/" elem )
standardized = elem
capab = netDeleg / standardized
</pre>
<p>where ALPHA and DIGIT are as designated in Appendix
A of <a class="info" href="#RFC2234">RFC 2234<span> (</span><span class="info">Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [4].
</p>
<a name="modifiers"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1. Capability Modifiers</h3>
<p>There are various capability modifiers available. If a
capability modifier is to be used, it MUST directly precede
the capability name. The following are the modifiers defined
for capabilities. Certain modifiers MAY be combined.
</p>
<p>The disable modifier is used by both the server and the
client to indicate that a capability should be disabled. The
disable modifier is defined as the dash character ('-'). A
client MUST only use the disable modifier in the <a class="info" href="#req">REQ<span> (</span><span class="info">CAP REQ</span><span>)</span></a> and
<a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a> subcommands. A server MUST use the disable modifier in
the <a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a> subcommand when disabling a capability, or in
conjunction with a ack modifier in the <a class="info" href="#list">LIST<span> (</span><span class="info">CAP LIST</span><span>)</span></a> subcommand. The
server MUST NOT use the disable modifier in any other command
response.
</p>
<p>The sticky modifier is used by the server to indicate a
capability that, once enabled, cannot be disabled. The sticky
modifier is defined as the equals character ('='). A client
MUST NOT use the sticky modifier. A server MUST only use the
sticky modifier in the <a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a>, <a class="info" href="#list">LIST<span> (</span><span class="info">CAP LIST</span><span>)</span></a> and <a class="info" href="#ls">LS<span> (</span><span class="info">CAP LS</span><span>)</span></a> subcommands and
MUST use the modifier for all such capabilities.
</p>
<p>The ack modifier is used by the server to indicate that the
client must issue an <a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a> subcommand to fully enable or
disable the capability. The ack modifier is defined as the
tilde character ('~'). The ack modifier indicates that
traffic originating from the server SHALL make use of the
capability, but the server SHALL NOT expect traffic
originating from the client to make use of the capability.
When combined with the disable modifier, it indicates traffic
originating from the server SHALL NOT make use of the
capability, but the server expects traffic originating from
the client SHALL make use of the capability. The ack modifier
MAY be combined with the sticky modifier.
</p>
<p>A server MUST use the ack modifier in the <a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a> and <a class="info" href="#list">LIST<span> (</span><span class="info">CAP LIST</span><span>)</span></a>
subcommands to indicate capabilities that require an <a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a>
subcommand from the client to be fully enabled or disabled.
Servers MUST also use the ack modifier in the response to an
<a class="info" href="#ls">LS<span> (</span><span class="info">CAP LS</span><span>)</span></a> subcommand to indicate capabilities which will require
<a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a> subcommands from the client. Clients MUST NOT use the
ack modifier, but SHOULD issue the <a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a> subcommand as soon as
possible after receiving an <a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a> or <a class="info" href="#req">REQ<span> (</span><span class="info">CAP REQ</span><span>)</span></a> subcommand from the
server that contains a capability marked with the ack
modifier.
</p>
<p>In <a class="info" href="#RFC2234">ABNF<span> (</span><span class="info">Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [4] notation:
</p><pre>
dismod = "-"
stickymod = "="
ackmod = "~"
capmod = dismod / stickymod / ackmod
</pre>
<a name="iana"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6. IANA Considerations</h3>
<p>The standardized capability name space shall be managed by
IANA in accordance with the description of capability names in
<a class="info" href="#capabilities">Section 5<span> (</span><span class="info">Capabilities</span><span>)</span></a>. In particular, any name not
containing the period character ('.') must be specified by an
RFC.
</p>
<a name="security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7. Security Considerations</h3>
<p>Capabilities are an extension to a preexisting, insecure chat
protocol. This extension does not add and does not purport to
add any security to the IRC protocol. Capability negotiation
occurs after client registration has already begun. Moreover,
no mechanism is defined that allows parameters to be passed for
specific capabilities. Although such a mechanism could be
added, cryptographic security systems frequently require several
exchanges to establish a secure context, particularly if
authentication must also be negotiated. Thus, the capabilities
extension is unsuited to the implementation of those protocols,
and other mechanisms, such as SSL-encapsulated IRC, should be
used.
</p>
<a name="acknowledgments"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8. Acknowledgments</h3>
<p>The authors wish to gratefully acknowledge the participation
of Aaron Wiebe and the members of the proto-desc@dal.net email
list in the design of this protocol extension.
</p>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>9. References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="RFC2119">[1]</a></td>
<tr><td class="author-text" valign="top"><a name="RFC1459">[2]</a></td>
<td class="author-text"><a href="mailto:jto@tolsun.oulu.fi">Oikarinen, J.</a> and <a href="mailto:avalon@coombs.anu.edu.au">D. Reed</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc1459.txt">Internet Relay Chat Protocol</a>,” RFC 1459, May 1993.</td></tr><tr><td class="author-text" valign="top"><a name="RFC2812">[3]</a></td>
<tr><td class="author-text" valign="top"><a name="RFC2234">[4]</a></td>
<tr><td class="author-text" valign="top"><a name="RFC3978">[5]</a></td>
</table>
<a name="example"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A. Examples</h3>
<p>In the following examples, lines preceded by "CLIENT:"
indicate protocol messages sent by the client, and lines
preceded by "SERVER:" indicate protocol messages sent by the
server. For clarity, the origin field for server-originated
protocol messages has been omitted. This field would consist of
a colon (':') followed by the full server name, and would be the
first field in the command.
</p>
<p>A client communicating with a server not supporting
CAP.
</p><pre>
CLIENT: CAP LS
CLIENT: NICK nickname
CLIENT: USER username ignored ignored :real name
SERVER: 001 [...]
</pre>
<p>A client which does not wish to enter capability
negotiation.
</p><pre>
CLIENT: CAP END
CLIENT: NICK nickname
CLIENT: USER username ignored ignored :real name
SERVER: 001 [...]
</pre>
<p>A client entering into capability negotiation during
registration, and requesting a set of capabilities that the
server does not support.
</p><pre>
CLIENT: CAP LS
CLIENT: NICK nickname
CLIENT: USER username ignored ignored :real name
SERVER: CAP LS * :A B C D E F G H
SERVER: CAP LS :I J
CLIENT: CAP REQ :A B C D E F
SERVER: CAP NAK :A B C D E F
CLIENT: CAP REQ :A C E F
SERVER: CAP ACK :A C E F
CLIENT: CAP REQ :B
SERVER: CAP ACK :B
CLIENT: CAP REQ :D
SERVER: CAP NAK :D
CLIENT: CAP END
SERVER: 001 [...]
</pre>
<p>A client requesting a capability that requires an
<a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a> subcommand from the client to be enabled.
</p><pre>
CLIENT: CAP LS
SERVER: CAP LS :~I ~J K
CLIENT: CAP REQ :I J K
SERVER: CAP ACK :~I ~J K
CLIENT: CAP ACK :I J
</pre>
<p>A client requesting a capability that requires an
<a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a> subcommand from the client to be enabled and disabled,
using the <a class="info" href="#list">LIST<span> (</span><span class="info">CAP LIST</span><span>)</span></a> subcommand in between.
</p><pre>
CLIENT: CAP LS
SERVER: CAP LS :~A ~B
CLIENT: CAP REQ :A B
SERVER: CAP ACK :~A ~B
CLIENT: CAP LIST
SERVER: CAP LIST :~A ~B
CLIENT: CAP ACK :A B
CLIENT: CAP LIST
SERVER: CAP LIST :A B
CLIENT: CAP REQ :-B
SERVER: CAP ACK :-~B
CLIENT: CAP LIST
SERVER: CAP LIST :A -~B
CLIENT: CAP ACK :-B
CLIENT: CAP LIST
SERVER: CAP LIST :A
</pre>
<p>A client requesting a capability that is
sticky.
</p><pre>
CLIENT: CAP LS
SERVER: CAP LS :=I J
CLIENT: CAP REQ :I J
SERVER: CAP ACK :=I J
</pre>
<p>A client requesting a capability be
disabled.
</p><pre>
CLIENT: CAP LIST
SERVER: CAP LIST :=A B C D
CLIENT: CAP REQ :-B -C
SERVER: CAP ACK :-B -C
</pre>
<a name="abnf"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.B"></a><h3>Appendix B. ABNF Description of Capabilities</h3>
<p>This section summarizes the <a class="info" href="#RFC2234">ABNF<span> (</span><span class="info">Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.</span><span>)</span></a> [4] description of the
capabilities extension.
</p><pre>
capcmd = [ ":" servername SP ] "CAP" SP subcmd
subcmd = lscmd / listcmd / reqcmd / ackcmd /
nakcmd / clearcmd / endcmd
capcmderr = ":" servername SP "410" SP nick SP badcmd
SP ":Invalid CAP subcommand"
; badcmd is the unrecognized subcommand
caplist = [ ":" ] *( capmod ) capab
caplist =/ ":" *( capmod ) capab 1*( SP *( capmod ) capab )
lscmd = "LS"
lscmd =/ "LS" SP [ "*" SP ] caplist
listcmd = "LIST"
listcmd =/ "LIST" SP ":"
listcmd =/ "LIST" SP [ "*" SP ] caplist
reqcmd = "REQ" SP caplist
ackcmd = "ACK" SP [ "*" SP ] caplist
nakcmd = "NAK" SP ":" acklist
; acklist is at least 100 characters of
; the capability list from the REQ
clearcmd = "CLEAR"
endcmd = "END"
elem = ALPHA *( ALPHA / DIGIT / "-" )
netname = elem 1*( "." elem )
netDeleg = netname 1*( "/" elem )
standardized = elem
capab = netDeleg / standardized
dismod = "-"
stickymod = "="
ackmod = "~"
capmod = dismod / stickymod / ackmod
</pre>
<a name="changelog"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.C"></a><h3>Appendix C. ChangeLog</h3>
<p>Note to RFC Editor: This section may be removed on
publication as an RFC.
</p>
<p>Here is a log of changes to this document:<br />
<br />
</p>
<blockquote class="text"><dl>
<dt>2004-12-15 KLM</dt>
<dd>Initial draft written.<br />
</dd>
<dt>2004-12-16 KLM</dt>
<dd><br />
<ul class="text">
<li>Added description of the argument to some CAP commands
in <a class="info" href="#cap">Section 3<span> (</span><span class="info">The CAP Command</span><span>)</span></a>.<br />
<br />
</li>
<li>Clarified that requirements of <a class="info" href="#cap">Section 3<span> (</span><span class="info">The CAP Command</span><span>)</span></a>
only apply to clients and servers implementing
capabilities.<br />
<br />
</li>
<li>Substitution of "performed" for "done" in <a class="info" href="#nak">Section 3.5<span> (</span><span class="info">CAP NAK</span><span>)</span></a><br />
<br />
</li>
<li>Added <a class="info" href="#list">LIST<span> (</span><span class="info">CAP LIST</span><span>)</span></a> subcommand to provide a mechanism to query
active capabilities.<br />
<br />
</li>
<li>Added reference to <a class="info" href="#RFC2812">RFC 2812<span> (</span><span class="info">Kalt, C., “Internet Relay Chat: Client Protocol,” April 2000.</span><span>)</span></a> [3].<br />
<br />
</li>
<li>Moved <a class="info" href="#example">Examples<span> (</span><span class="info">Examples</span><span>)</span></a> section
into the back matter.<br />
<br />
</li>
<li>Corrected Perry Lorier's email address.<br />
<br />
</li>
<li>Added this ChangeLog section.<br />
<br />
</li>
<li>Corrected typo in <a class="info" href="#end">Section 3.7<span> (</span><span class="info">CAP END</span><span>)</span></a>: "sent" for
"send".<br />
<br />
</li>
<li>Added <vspace> elements to enhance
readability.<br />
<br />
</li>
<li>Changed to non-compact form.<br />
<br />
</li>
<li>Changed anchor for <a class="info" href="#capabilities">Section 5<span> (</span><span class="info">Capabilities</span><span>)</span></a> to
"capabilities" from "caps" to reduce possible
confusion.<br />
<br />
</li>
<li>Revise last sentence of first paragraph of <a class="info" href="#problems">Section 2<span> (</span><span class="info">Problems to be Solved</span><span>)</span></a> to remove redundancy.<br />
<br />
</li>
<li>Revise last sentence of second paragraph of <a class="info" href="#problems">Section 2<span> (</span><span class="info">Problems to be Solved</span><span>)</span></a><br />
<br />
</li>
<li>Added email addresses for Lee H and Beeth; updated
contact information for Isomer.<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2004-12-17 KLM</dt>
<dd><br />
<ul class="text">
<li>Augmented description of CAP command and subcommands
with ABNF description.<br />
<br />
</li>
<li>Revised <a class="info" href="#capabilities">Section 5<span> (</span><span class="info">Capabilities</span><span>)</span></a> to remove "net."
name space and replace it with a delegated name space
beginning with a DNS domain name (suggested by
Isomer).<br />
<br />
</li>
<li>Augmented ABNF description of capability
names.<br />
<br />
</li>
<li>Revised <a class="info" href="#iana">Section 6<span> (</span><span class="info">IANA Considerations</span><span>)</span></a> to reflect change in
capability name space.<br />
<br />
</li>
<li>Added <a class="info" href="#abnf">Appendix B<span> (</span><span class="info">ABNF Description of Capabilities</span><span>)</span></a> to bring together the
entire ABNF description of capabilities.<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2004-12-18 KLM</dt>
<dd><br />
<ul class="text">
<li>Added explanation of what should happen if an
unrecognized subcommand is given.<br />
<br />
</li>
<li>Clarified what to do if a client sends a subcommand
that shouldn't come from a client.<br />
<br />
</li>
<li>Add references to <a class="info" href="#list">LIST<span> (</span><span class="info">CAP LIST</span><span>)</span></a> to LSL and <a class="info" href="#ls">Section 3.1<span> (</span><span class="info">CAP LS</span><span>)</span></a>.<br />
<br />
</li>
<li><a class="info" href="#req">Section 3.3<span> (</span><span class="info">CAP REQ</span><span>)</span></a> omitted the caplist argument for
the REQ command; corrected.<br />
<br />
</li>
<li>Relax the prohibition against a client acknowledging a
capability that doesn't modify the protocol stream in
<a class="info" href="#ack">Section 3.4<span> (</span><span class="info">CAP ACK</span><span>)</span></a><br />
<br />
</li>
<li>Relax the requirement for a client that understands
capabilities to send CAP END in <a class="info" href="#end">Section 3.7<span> (</span><span class="info">CAP END</span><span>)</span></a><br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2004-12-19 KLM</dt>
<dd><br />
<ul class="text">
<li>Converted a number of common xrefs into internal
entities to simplify the text.<br />
<br />
</li>
<li>Inserted some white space to make the <front>
section a bit more readable.<br />
<br />
</li>
<li>Added the keyword "Protocol".<br />
<br />
</li>
<li>Added the term "NOT RECOMMENDED" to the note on
"Requirements Language".<br />
<br />
</li>
<li>Moved <a class="info" href="#list">LIST<span> (</span><span class="info">CAP LIST</span><span>)</span></a> up in the list of CAP
subcommands.<br />
<br />
</li>
<li>Minor formatting change to the ABNF representation of
subcmd.<br />
<br />
</li>
<li>Capitalized "MAY" in "empty" subcommand.<br />
<br />
</li>
<li>Added text about capability list order and what to do
if no capabilities are implemented to "empty"
subcommand.<br />
<br />
</li>
<li>Mention <a class="info" href="#list">LIST<span> (</span><span class="info">CAP LIST</span><span>)</span></a> also in LSL when talking about sending
more than one LSL subcommand.<br />
<br />
</li>
<li>Clarify language in <a class="info" href="#ls">Section 3.1<span> (</span><span class="info">CAP LS</span><span>)</span></a> a little
bit.<br />
<br />
</li>
<li>Substitute "set of capabilities" for "list of
capabilities" in <a class="info" href="#req">Section 3.3<span> (</span><span class="info">CAP REQ</span><span>)</span></a>.<br />
<br />
</li>
<li>Fix minor typo in preamble to ABNF description of <a class="info" href="#nak">NAK<span> (</span><span class="info">CAP NAK</span><span>)</span></a>
subcommand: substitution of "ACK" for "NAK".<br />
<br />
</li>
<li>Add note about servers ignoring <a class="info" href="#end">END<span> (</span><span class="info">CAP END</span><span>)</span></a> after client
registration.<br />
<br />
</li>
<li>Fix minor typo in preamble to ABNF description of
<a class="info" href="#list">LIST<span> (</span><span class="info">CAP LIST</span><span>)</span></a> subcommand: substitution of "END" for
"LIST".<br />
<br />
</li>
<li>Added <a class="info" href="#negotiation">Section 4<span> (</span><span class="info">Capability Negotiation</span><span>)</span></a> discussing
capability negotiation.<br />
<br />
</li>
<li>Add ".xml" extension to include files in references
section.<br />
<br />
</li>
<li>Simplification of preamble of first <a class="info" href="#example">example<span> (</span><span class="info">Examples</span><span>)</span></a>.<br />
<br />
</li>
<li>Add 'type="ABNF"' to <artwork> sections so that
they can be extracted and used to create the abnf.xml now
included in <a class="info" href="#abnf">Appendix B<span> (</span><span class="info">ABNF Description of Capabilities</span><span>)</span></a>.<br />
<br />
</li>
<li>It's now RFC 3667, not RFC 2026...<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2004-12-27 KLM</dt>
<dd><br />
<ul class="text">
<li>Minor wording changes to second paragraph of <a class="info" href="#intro">Section 1<span> (</span><span class="info">Introduction</span><span>)</span></a><br />
<br />
</li>
<li>Minor wording change to first paragraph of <a class="info" href="#problems">Section 2<span> (</span><span class="info">Problems to be Solved</span><span>)</span></a><br />
<br />
</li>
<li>Minor wording changes to first paragraph of <a class="info" href="#cap">Section 3<span> (</span><span class="info">The CAP Command</span><span>)</span></a>; remove redundant note about the IRC colon
sentinel.<br />
<br />
</li>
<li>Change a "must" to a "MUST" in <a class="info" href="#ack">Section 3.4<span> (</span><span class="info">CAP ACK</span><span>)</span></a>;
note that capability list may be truncated if it would
otherwise exceed the 512 character limit.<br />
<br />
</li>
<li>In <a class="info" href="#nak">Section 3.5<span> (</span><span class="info">CAP NAK</span><span>)</span></a>, note that capability list may
be truncated if it would otherwise exceed the 512
character limit.<br />
<br />
</li>
<li>Remove redundant line about ignoring <a class="info" href="#end">END<span> (</span><span class="info">CAP END</span><span>)</span></a> commands
after registration.<br />
<br />
</li>
<li>Correct spelling of "acknowledgments".<br />
<br />
</li>
<li>Empty <organization> elements for Lee H and
Beeth; put Beeth's real name, Piotr Kucharski, in the
right place.<br />
<br />
</li>
<li>Switch to using a new preprocessor that consolidates
all the ABNF artwork and inserts it with the processing
instruction <?art type="foo"?>.<br />
<br />
</li>
<li>Remove deliberate page break after <abstract>
section.<br />
<br />
</li>
<li>Reorder authors section to consolidate
<organization> elements for everyone.<br />
<br />
</li>
<li>Drop abbreviation for Undernet.<br />
<br />
</li>
<li>Expand <a class="info" href="#security">Section 7<span> (</span><span class="info">Security Considerations</span><span>)</span></a> a bit to try to
explain why capabilities are not suited to securing
IRC.<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-01-04 KLM</dt>
<dd><br />
<ul class="text">
<li>Add Lee Hardy's information to the list of
authors.<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-01-05 KLM</dt>
<dd><br />
<ul class="text">
<li>Replace UNKNOWNCAPCMD with INVALIDCAPCMD.<br />
<br />
</li>
<li>Begin rewriting <a class="info" href="#ls">LS<span> (</span><span class="info">CAP LS</span><span>)</span></a> documentation<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-01-19 KLM</dt>
<dd><br />
<ul class="text">
<li>Redesign the protocol substantially to simplify
it.<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-01-20 KLM</dt>
<dd><br />
<ul class="text">
<li>Update Piotr's contact information.<br />
<br />
</li>
<li>Drop the "x-" namespace...<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-01-20 LH</dt>
<dd><br />
<ul class="text">
<li>Some servers do issue banner responses, now.<br />
<br />
</li>
<li>The CAP subcommand is now a requirement.<br />
<br />
</li>
<li>Minor grammatical fix-up in documentation of <a class="info" href="#req">REQ<span> (</span><span class="info">CAP REQ</span><span>)</span></a>
("acceptance of or rejection of"--strike first
"of").<br />
<br />
</li>
<li>Clarify that sticky capabilities cause a <a class="info" href="#req">REQ<span> (</span><span class="info">CAP REQ</span><span>)</span></a> to be
<a class="info" href="#nak">NAK<span> (</span><span class="info">CAP NAK</span><span>)</span></a>ed.<br />
<br />
</li>
<li>Mark the third case of an <a class="info" href="#ack">ACK<span> (</span><span class="info">CAP ACK</span><span>)</span></a> with an explicit
indicator that it's the third case...<br />
<br />
</li>
<li>Strike redundant mention of not suspending client
registration in documentation for <a class="info" href="#end">END<span> (</span><span class="info">CAP END</span><span>)</span></a>.<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-01-21 LH</dt>
<dd><br />
<ul class="text">
<li>Move all references on capability modifiers to its own
section<br />
<br />
</li>
<li>Clarify instructions on the ack ('~') modifier,
indicating it can be used with sticky
capabilities.<br />
<br />
</li>
<li>Add a note into CAP section about capability
modifiers<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-01-21 KLM</dt>
<dd><br />
<ul class="text">
<li>Subcommands are not optional anymore; updated the
description of CAP and the ABNF to reflect
this.<br />
<br />
</li>
<li>More than one modifier may precede a capability
name.<br />
<br />
</li>
<li>Move ABNF for capmod into the "Capability Modifiers"
section.<br />
<br />
</li>
<li>Fix a few minor grammatical errors (I
think).<br />
<br />
</li>
<li>Note that capability names may be preceded by modifiers
in the first form of ACK.<br />
<br />
</li>
<li>Remove an unnecessary "MAY" in documentation for the
third usage of ACK.<br />
<br />
</li>
<li>Explicitly note in the ABNF for NAK that the parameter
is an opaque repeat of at least the first 100 characters
of the argument to REQ.<br />
<br />
</li>
<li>CLEAR may result in more than one ACK.<br />
<br />
</li>
<li>Clarify the language of what composes a capability
name.<br />
<br />
</li>
<li>Add missing </figure>.<br />
<br />
</li>
<li>ACK subcommand should be sent in response to ACK with
ack modifier as soon as possible...<br />
<br />
</li>
<li>Allow disable modifier in LIST, but only in conjunction
with an ack modifier.<br />
<br />
</li>
<li>The ack modifier may also show up in an LS response;
rewrote the final paragraph to indicate that and clarify
the language.<br />
<br />
</li>
<li>Add "Client" to the title in the appropriate
place...<br />
<br />
</li>
<li>The "capability" rule in the ABNF got changed to
"capab" for brevity.<br />
<br />
</li>
<li>Update "date" to be current.<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-01-22 LH</dt>
<dd><br />
<ul class="text">
<li>Clarify a client must not act upon an ACK spread across
multiple lines until it receives the final ACK of the
set.<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-01-23 KLM</dt>
<dd><br />
<ul class="text">
<li>Bump version number in preparation for any suggested
edits...<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-01-26 LH</dt>
<dd><br />
<ul class="text">
<li>Clarify a server also must not change capabilities
until its finished sending its ACKs.<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-01-27 KLM</dt>
<dd><br />
<ul class="text">
<li>Acknowledge Aaron Wiebe as participating.<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-03-01 LH</dt>
<dd><br />
<ul class="text">
<li>Add examples on sticky modifiers, the removal modifier and
the sticky modifier.<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-03-07 KLM</dt>
<dd><br />
<ul class="text">
<li>Submit second draft...<br />
<br />
</li>
<li>Prepare third draft, just in case...<br />
<br />
</li>
</ul><br />
<br />
</dd>
<dt>2005-11-04 KLM</dt>
<dd><br />
<ul class="text">
<li>RFC 3667 is now superseded by <a class="info" href="#RFC3978">RFC 3978<span> (</span><span class="info">Bradner, S., “IETF Rights in Contributions,” March 2005.</span><span>)</span></a> [5]<br />
<br />
</li>
</ul><br />
<br />
</dd>
</dl></blockquote><p>
</p>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Kevin L. Mitchell</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Undernet IRC Network</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">38 Eighth St., Apt. 7</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Cambridge, Massachusetts 02141</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">US</td></tr>
<tr><td class="author" align="right">Phone: </td>
<td class="author-text">+1-617-230-1021</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:klmitch@mit.edu">klmitch@mit.edu</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Perry Lorier</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Undernet IRC Network</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">3 Liston Cres</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Hamilton, Waikato 2001</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">NZ</td></tr>
<tr><td class="author" align="right">Phone: </td>
<td class="author-text">+64-7-859-1109</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:isomer@undernet.org">isomer@undernet.org</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Lee Hardy</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">ircd-ratbox Development
Team</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:lee@leeh.co.uk">lee@leeh.co.uk</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Piotr Kucharski</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">IRCnet</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:Beeth@irc.pl">Beeth@irc.pl</a></td></tr>
<tr><td class="author" align="right">URI: </td>
</table>
<a name="rfc.copyright"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>Intellectual Property Statement</h3>
<p class='copyright'>
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.</p>
<p class='copyright'>
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available,
or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
<p class='copyright'>
The IETF invites any interested party to bring to its attention
any copyrights,
patents or patent applications,
or other
proprietary rights that may cover technology that may be required
to implement this standard.
Please address the information to the IETF at <a href='mailto:ietf-ipr@ietf.org'>ietf-ipr@ietf.org</a>.</p>
<h3>Disclaimer of Validity</h3>
<p class='copyright'>
This document and the information contained herein are provided
on an “AS IS” basis and THE CONTRIBUTOR,
THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
ALL WARRANTIES,
EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p>
<h3>Copyright Statement</h3>
<p class='copyright'>
Copyright © The Internet Society (2005).
This document is subject to the rights,
licenses and restrictions contained in BCP 78,
and except as set forth therein,
the authors retain all their rights.</p>
<h3>Acknowledgment</h3>
<p class='copyright'>
Funding for the RFC Editor function is currently provided by the
Internet Society.</p>
</body></html>