Masarykovo nam. 4 Jihlava 58601 CZ +420 776 584 544 pasky@ji.cz http://pasky.ji.cz/

Applications I-D Internet-Draft IRC Internet Relay Chat CAPAB Capabilities This memo presents a way for IRC servers and clients to negotiate optional features of protocol further used for their communication.

Due to the nature of IRC development in the past decade, with most organizations expanding and altering protocol specifications at will, the protocol for communication between IRC client and server contains a lot of slight differences and special unique features depending on the particular server used. This memo aims to standarize way of announcing such optional protocol features to clients and way of requesting such features by clients.

Servers, when interconnected, have the ability to use various different protocol specifications, usually unique to the IRC server type. Standarizing compatible server-server communication inside of one IRC network is matter of the IRC network administration and it does not influence users. Thus, server-server protocol is not the subject of this specification.

Due to the explosive growth of IRC, many networks are experiencing serious problems with raw bandwidth usage of client servers. While optimizations have been made to the server to server protocol to reduce bandwidth usage, client side connections still make up the bulk of bandwidth usage. Due to the expanded format of RFC 1459, there is a substantially large number of ways to address this problem without rewriting the protocol entirely.

There is a press inside of the IRC developers community to introduce non-standard changes to the protocol, which could violate the original IRC specification (RFC 1459) and introduce some incompatibilities to the client-server communication, resulting in problems with some clients. Using this specification, client could select only those of these changes, which it could understand.

The primary goals of protocol negotiation are as follows: Flexible expandible format that allows alternative protocol negotiation systems to be put into place for further altering of the protocol. Fully transparent backwards compatibility on the both client and server side, due to the vast number of clients which will not be compliant for many years.

The protocol capabilities of the actual connection are always maintained on the server side, which accepts requests and updates from the client.

Protocol negotiation happens through the CAPAB (short for CAPABilities) command. The pseudo BNF representation for this message is: ::= "CAPAB" [ ':' ] ::= "LS" | "ON" | "ACK" | "NAK" ::= [ '-' ] [ '=' ] [ ] ::= { } ::= { } ::= | | '_' ::= ' ' { ' ' } ::= CR LF ]]> Note that value obviously MUST NOT contain any whitespace characters.

The CAPAB command can be issued at any time by client, even during the client registration. Server MUST NOT send request CAPAB messages, only the informational ones.

This message is used to request or announce the list of supported capabilities. Only the client sends the capabilities list request and only the server sends the list of them now. If there is no token list sent along the message, it is considered as a list request. If there is a capability tokens list passed with the message, it is considered as the supported capabilities list which may or may not be a reply to a list request. Note that the tokens MUST NOT contain value nor any prefix in front of the name - only names alone can be in the list. Also, the server MUST return some string as the list, even an empty one. Otherwise, its reply could be understood as capability list request by the client. That means, if the server does not support any capabilities, it MUST NOT return "CAPAB LS", but "CAPAB LS :". Note that the capabilities list can vary depending on the capabilities already selected by client, so the new capabilities list should be re-retrieved by client each time when the client will turn on some capabilities successfully.

This message is used by client exclusively to turn on certain protocol capabilities. The client sends a list of capability tokens. The server replies with either CAPAB ACK or CAPAB NAK. Note that if already set tokens are included in the list, the capability value is possibly updated. No value means that the old value is kept and the token is silently ignored.

This message is used by server to acknowledge the CAPAB ON command previously issued by client. It means that the server confirmed all the capabilities sent by the client. They become effective immediatelly after <crlf> of this message is sent.

This message is used by server to indicate some problem with the list client sent along the CAPAB ON command. It means that none of these capabilities become effective, and no changes in the active capabilities list are not made by the server. The server SHOULD send the list of capabilities with unknown name or inappropriate value along this message, with same restrictions of their list as in CAPAB LS, unless the server couldn't properly parse the list received from client.

These tokens are formed by optional prefix, capability name and optional capability value, as described in the pseudo-BNF above. The name length SHOULD NOT exceed 20 characters nor be less than 3 characters. It should be chosen as short as possible, while staying meaningful. Only one prefix is defined now - a dash ('-'). If it is specified, it means that the capability should be reset to the default value (and the "boolean" capability should be turned off, as all boolean capabilities are off by default). Note that it may not be possible to turn off some capabilities (probably for example TLS) once they are turned on. Note that some capabilities may not be available all the time, but could be offered by the server only when some other capability(ies) is (are) already turned on. So, the capabilities can be theoretically formed in a virtual tree. The list of tokens is limited only by the 512 characters maximal IRC message length. The usual 15 parameters limit for IRC message does not apply, as the whole capabilities list is prefixed by a ':', thus should be recognized as a single string by the current IRC message parsers. The concrete tokens (names and possibly value types) will be defined in further documents published by the IRC development community.

In order to keep a virtually transparent compatibility with RFC 1459, protocol negotiation must be initiated by the client. This way, earlier clients not compatible with protocol negotiation can continue their RFC 1459 connection unaffected. An incompatible server will simply ignore the client initiation.

Virtually, the CAPAB commands can be used during the client registration as well as at any other time. However, the client must have some way how to determine whether the server supports capabilities or not, prone to any possible network lags. Probably the most viable way is using an empty NICK command after issuing the CAPAB LS command; if 431 or 461 numeric is retrieved from the server as a first message, it means that the server doesn't know how to reply to CAPAB LS. This is called "the NICK kludge". Note that it is recommended to set up the capabilities during the client registration, as after 001 sent by the server, it may be already too late. For example, the server can automatically join the client to some channel, or it would like to send it some special messages during connect. Also see Security Considerations.

The basic example of the protocol negotiation with the conforming server: CAPAB LS CLIENT> NICK SERVER> CAPAB LS :cap1 cap2 cap3 cap4 SERVER> :irc.proto.com 431 * :No nickname given CLIENT> CAPAB ON :cap2 cap3=11,cap5 SERVER> CAPAB NAK CLIENT> CAPAB ON :cap2 cap3=11 cap5 SERVER> CAPAB NAK :cap5 CLIENT> CAPAB ON :cap2 cap3=11 SERVER> CAPAB ACK CLIENT> CAPAB LS SERVER> CAPAB LS :cap1 cap2 xcap1 xcap2 xcap3 CLIENT> USER foo - - :test CLIENT> NICK bar SERVER> :irc.proto.com 001 bar :Welcome ]]>

The basic example of the protocol negotiation with an old server: CAPAB LS CLIENT> NICK SERVER> :irc.proto.com 431 * :No nickname given CLIENT> USER foo - - :test CLIENT> NICK bar SERVER> :irc.proto.com 001 bar :Welcome ]]>

The secondary purpose of this document is to provide a framework for definition of protocol enhancements. Documents will be published as Internet Drafts and possibly RFCs, after a careful review by the IRC development community. The IRC development community, as used in this document, is defined as the authors of prominent software in use. Currently, this consists of - but is not limited to - the development teams for the major IRC networks (including DALnet, EFnet, IRCnet and Undernet), as well as the development teams for the client packages - currently irssi, BitchX, EPIC, IRCle, and mIRC. These people (as now) are listed below.

All further specifications MUST be reviewed by the development community. In order for this review to take place, the author must contact the protocol discussion email list. The current list address is proto-desc@dal.net. The administrative contact for this list is epiphani@dal.net.

In order to prevent possible man-in-the-middle attacks, any security-related capabilities should be issued as soon as possible, preferrably already during the client registration. This involves for example TLS setup.

There should be set some alias for the administrative contact for the proto-desc mailing list; RFCs are hard to update. --cras There are proposals to use CAPAB END or 001-after-CAPAB ON instead of the nick kludge, but since the nick kludge would have to be still supported in the clients for negotiations before nick/user/pass, I decided not to use these for now. More discussion needed. --pasky

Tuirantie 17 as 9 Oulu 90500 FI jto@tolsun.oulu.fi

4 Pateman Street Watsonia Victoria 3087 AU avalon@coombs.anu.edu.au

The author especially gratefully acknowledges the contributions of: Lee Hardy, Timo Sirainen, Piotr Kucharski, Jakub Vlasek and others. The following people are part of the proto-desc@dal.net protocol discussion list. They have provided support, input and critism to this document. ... Name, Email address, Affiliation ... ... Name, Email address, Affiliation ... ... Name, Email address, Affiliation ...