IRCv3.2 Client Capability Negotiation
Copyright © 2004-2012 Kevin L. Mitchell <firstname.lastname@example.org>
Copyright © 2004-2012 Perry Lorier <email@example.com>
Copyright © 2004-2012 Lee Hardy <firstname.lastname@example.org>
Copyright © 2009-2012 William Pitcock <email@example.com>
Copyright © 2014 Attila Molnar <firstname.lastname@example.org>
Unlimited redistribution and modification of this document is allowed provided that the above copyright notice and this permission notice remains intact.
New in version 3.2
The LS subcommand now has an additional argument which is the raw version number of the latest capability negotiation protocol supported by the client.
This document describes version
Servers MUST NOT send messages described by this document if the client only supports version 3.1.
The client SHOULD send the latest raw version of the capability negotiation protocol it supports as the next argument of the command after LS. If no other arguments are present, version 3.1 is assumed.
Capabilities with values
Servers MAY specify additional data for each capability using the
<name>[=<value>] format for
CAP LS and
The meaning of the value (if present) depends on the capability in question.
Multiline replies to
CAP LS and
Servers MAY reply with multiple lines in response to
If the reply consists of multiple lines (due to IRC line length limitations)
all but the last subcommand MUST have a parameter containing only an asterisk
*) preceding the capability list.
The same applies for replies generated by
The client MUST handle multi-line
CAP LIST replies if it has claimed 3.2
or later support in the initial
Two new CAP subcommands are introduced:
Refer to the specification of
cap-notify for details about them.
Deprecation of sticky (
=) and ack-required (
~) capability modifiers
Servers SHOULD NOT denote capabilities which are sticky with the
= capability modifier. Instead,
they should send a
NAK to any request which would disable the sticky capability.
Capabilities MUST NOT require an
ACK from the client to be activated.
Example where the client uses CAP 3.2 and the reply contains a cap with a value:
Client: CAP LS 302 Server: CAP * LS :multi-prefix sasl=EXTERNAL Client: CAP REQ :sasl multi-prefix
Example where the client uses CAP 3.2 and gets a multiline reply:
Client: CAP LS 302 Server: CAP * LS * :multi-prefix extended-join account-notify batch invite-notify tls Server: CAP * LS * :cap-notify server-time example.org/dummy-cap=dummyvalue example.org/second-dummy-cap Server: CAP * LS :userhost-in-names sasl=EXTERNAL,DH-AES,DH-BLOWFISH,ECDSA-NIST256P-CHALLENGE,PLAIN
Example where a 3.2-supporting client uses CAP LIST and gets a multiline reply:
Client: CAP LIST Server: CAP modernclient LIST * :example.org/example-cap example.org/second-example-cap account-notify Server: CAP modernclient LIST :invite-notify batch example.org/third-example-cap
A previous version of this specification did not specify when to use
<name>[=<value>] format. This was clarified to limit capability
CAP LS and
CAP NEW replies.