Network Working Group P. Baudis Internet-Draft September 8, 2002 Expires: March 9, 2003 IRC protocol and capabilities selection draft-baudis-irc-capab-00b Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 9, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo presents a way for communication servers and clients to negotiate used protocol and a way to negotiate optional features of IRC/2 protocol further used for their communication. Baudis Expires March 9, 2003 [Page 1] Internet-Draft IRC protocol and capabilities selection September 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Impacts to the server-server protocols . . . . . . . . . . . 3 1.4 Current Problems . . . . . . . . . . . . . . . . . . . . . . 3 1.4.1 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4.2 Compatibility . . . . . . . . . . . . . . . . . . . . . . . 4 1.5 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Negotiation . . . . . . . . . . . . . . . . . . . . 5 2.1 Protocol message . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Compatibility . . . . . . . . . . . . . . . . . . . . . . . 5 3. The IRC/2 Protocol . . . . . . . . . . . . . . . . . . . . . 7 3.1 Capab message . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1 CAPAB LS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2 CAPAB RQ . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.3 CAPAB ACK . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.4 CAPAB NAK . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.5 Capability Tokens . . . . . . . . . . . . . . . . . . . . . 8 3.2 005 numeric . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Register message . . . . . . . . . . . . . . . . . . . . . . 10 3.4 The Registration Process . . . . . . . . . . . . . . . . . . 10 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Further Documents . . . . . . . . . . . . . . . . . . . . . 12 4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 References . . . . . . . . . . . . . . . . . . . . . . . . . 14 A. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . 17 Baudis Expires March 9, 2003 [Page 2] Internet-Draft IRC protocol and capabilities selection September 2002 1. Introduction 1.1 Motivation 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 IRC/2 protocol capabilities to clients and way of requesting such features by clients. Due to existence of various concurrent protocols aside of IRC and because some IRC clients can support those protocols as well, this memo also covers negotiation of the protocol used for communication with the server. 1.2 Terminology original IRC protocol: The original IRC protocol as described in RFC 1459 [1]. IRC/2 protocol: The original IRC protocol with support for commands described in this document; not neccessarily with support for any particular capabilities. protocol negotiation: The negotiation of protocol being used during the communication. IRC/2 protocol capabilities negotiation: The negotiation of extensions to the IRC/2 protocol. 1.3 Impacts to the server-server protocols 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. 1.4 Current Problems 1.4.1 Bandwidth Due to the explosive growth of IRC, many networks are experiencing serious problems with raw bandwidth usage of client servers. While Baudis Expires March 9, 2003 [Page 3] Internet-Draft IRC protocol and capabilities selection September 2002 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 [1], there is a substantially large number of ways to address this problem without rewriting the protocol entirely. 1.4.2 Compatibility 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 [1]) 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 clients supporting IRC/2 protocol should still be backwards compatible to the original RFC 1459 protocol (IRC/2 without any protocol capabilities is equivalent to it, except the support for CAPAB command and PROTOCOL command). 1.5 Goals The primary goals of the protocol negotiation and IRC/2 protocol capabilities negotiation are as follows: o Flexible expandible format that allows alternative protocol negotiation systems to be put into place for further altering of the protocol. o 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. Baudis Expires March 9, 2003 [Page 4] Internet-Draft IRC protocol and capabilities selection September 2002 2. Protocol Negotiation The client can select particular protocol to be used during communication with the server. This protocol doesn't neccessarily have to be IRC/2, it can be SILC, IRC/3 (whatever that will be) etc. The protocol negotiation happens immediatelly after establishing of the connection. It is initiated by the client, who sends the list of protocol it wishes to use. The server chooses the one it supports (if the server supports multiple protocols, it SHOULD select the first one asked by client, reading the client's message from left to right) and acknowledges it. The further communication depends on the protocol chosen; we describe the further communication for the IRC/2 protocol below (Section 3) in this document. 2.1 Protocol message The protocol negotiation happens through the PROTOCOL command. The pseudo BNF representation for this message is: ::= "PROTOCOL" [ { } ] ::= '/' { '.' } ::= { } ::= | | '_' | '-' ::= { } ::= ' ' { ' ' } ::= CR LF Each token specifies protocol name and version (major and optionally minor). The PROTOCOL message sent by client MUST contain at least one token, while the PROTOCOL message sent by server MUST contain at least zero and at most one token. If the server's PROTOCOL message doesn't include any protocol token, the server does not support any protocol listed by client and the client MUST either resend the PROTOCOL message with different set of tokens or close the connection. The concrete protocol names (and possible versions) will be defined in further documents published by the IRC development community (Section 4). This document specifies only one protocol named "IRC" and describes (Section 3) its version 2 (this version has no minor subversioning). 2.2 Compatibility Note that the following section matters only to clients which want to possibly talk by the original IRC protocol. Clients supporting the Baudis Expires March 9, 2003 [Page 5] Internet-Draft IRC protocol and capabilities selection September 2002 IRC/2 protocol SHOULD be able to talk so. In order to preserve the backwards compatibility with the original IRC protocol, the client should send the PROTOCOL message and then try to register using the original IRC protocol. If the server doesn't support PROTOCOL, it will reply with the 001 message, otherwise it will reply with the PROTOCOL and in case of IRC/2 protocol, it will postpone finishing of the registration as described below (Section 3.4). Baudis Expires March 9, 2003 [Page 6] Internet-Draft IRC protocol and capabilities selection September 2002 3. The IRC/2 Protocol The IRC/2 protocol is superset of the original IRC protocol - it additionally contains the support for PROTOCOL, CAPAB and REGISTER messages and the registration process is slightly changed. 3.1 Capab message Protocol negotiation happens through the CAPAB (short for CAPABilities) command. The pseudo BNF representation for this message is: ::= "CAPAB" [ ':' ] ::= "LS" | "RQ" | "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. 3.1.1 CAPAB LS 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 (Section 3.1.5) 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 the client will turn on Baudis Expires March 9, 2003 [Page 7] Internet-Draft IRC protocol and capabilities selection September 2002 some capabilities successfully. 3.1.2 CAPAB RQ This message is used by client exclusively to turn on certain IRC/2 protocol capabilities. The client sends a list of capability tokens (Section 3.1.5). 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). 3.1.3 CAPAB ACK This message is used by server to acknowledge the CAPAB RQ command previously issued by client. It contains a list of capability tokens (Section 3.1.5) acknowledged by the server (same or subset of the list of capability tokens in client's CAPAB RQ). The server starts sending of the messages using the new capability tokens immediatelly after sending the terminating this CAPAB ACK message. The client has to respond to this message by another CAPAB ACK message which MUST contain the same list of capability tokens; then, it MUST start using those capabilites immediatelly after sending the terminating this CAPAB ACK message. 3.1.4 CAPAB NAK This message is used by server to indicate some problem with the list client sent along the CAPAB RQ 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 conflicting with another capability being set already) 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. 3.1.5 Capability Tokens 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 Baudis Expires March 9, 2003 [Page 8] Internet-Draft IRC protocol and capabilities selection September 2002 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 (Section 4). 3.2 005 numeric This numeric is used by server to announce its global extensions against the standart IRC protocol which are available to client, and announcing some more specific parameters of the IRC server/network. The pseudo BNF representation for this message is: ::= ":" "005" 1*13( ) ":are supported by this server" ::= { } ::= { } ::= [ '=' ] ::= | | '_' ::= ' ' { ' ' } ::= CR LF Note that value obviously MUST NOT contain any whitespace characters. RFC 1459 [1] defines a limit of 15 parameters, which include the nickname and the text. This limits us to 13 parameters we can use per message, thus the client MUST support more than one 005 message. The concrete tokens (names and possible values) will be defined in further documents published by the IRC development community (Section 4). The list of available tokens is also accessible at The 005 Technical Specification page [2]. Baudis Expires March 9, 2003 [Page 9] Internet-Draft IRC protocol and capabilities selection September 2002 3.3 Register message This command is used by client to indicate that it consider its part of the registration done and excepts 001 from the server. The pseudo BNF representation for this message is: ::= "REGISTER" ::= CR LF 3.4 The Registration Process The registration process is slightly different from the original IRC protocol. The client could use USER and NICK commands as many times as it wants, while the new invocation overrides settings of the previous ones. This is important because USER and NICK possibly sent before PROTOCOL acknowledge from server count to the registration process as well, but the client may want to re-issue those commands with some of the capabilities turned on. After acknowledging the IRC/2 protocol, server MUST send 005 numeric and CAPAB LS with the list of supported capabilities. Then, the client can negotiate the capabilities and possibly re-send the USER, NICK or PASS commands. The registration process is finished when the client sends the REGISTER command. Baudis Expires March 9, 2003 [Page 10] Internet-Draft IRC protocol and capabilities selection September 2002 3.5 Examples The basic example of the complete negotiation with the conforming server: CLIENT> PROTOCOL :IRC/2 CLIENT> USER foo - - :text CLIENT> NICK bar SERVER> PROTOCOL :IRC/2 SERVER> :irc.xy.com 005 bar PREFIX=(ov)@+ MODES=3 :are supported by this server SERVER> CAPAB LS :cap1 cap2 cap3 cap4 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 :cap2 cap3=11 CLIENT> CAPAB ACK :cap2 cap3=11 CLIENT> CAPAB LS SERVER> CAPAB LS :cap1 cap2 xcap1 xcap2 xcap3 CLIENT> REGISTER SERVER> :irc.xy.com 001 bar :Welcome The basic example of the complete negotiation with an old server: CLIENT> PROTOCOL :IRC/2 CLIENT> USER foo - - :test CLIENT> NICK bar SERVER> :irc.xy.com 001 bar :Welcome Baudis Expires March 9, 2003 [Page 11] Internet-Draft IRC protocol and capabilities selection September 2002 4. Further Documents 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 (Appendix B). 4.1 Requirements 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. Baudis Expires March 9, 2003 [Page 12] Internet-Draft IRC protocol and capabilities selection September 2002 5. Security Considerations 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. Baudis Expires March 9, 2003 [Page 13] Internet-Draft IRC protocol and capabilities selection September 2002 References [1] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993. [2] Author's Address Petr Baudis Masarykovo nam. 4 Jihlava 58601 CZ Phone: +420 776 584 544 EMail: pasky@ji.cz URI: http://pasky.ji.cz/ Baudis Expires March 9, 2003 [Page 14] Internet-Draft IRC protocol and capabilities selection September 2002 Appendix A. TODO 1. There should be set some alias for the administrative contact for the proto-desc mailing list; RFCs are hard to update. --cras 2. There should be some standart long-term URL where all CAPABs would be listed; RFC for each (set of) capab(s) is nonsense ;-). Baudis Expires March 9, 2003 [Page 15] Internet-Draft IRC protocol and capabilities selection September 2002 Appendix B. Acknowledgements The author especially gratefully acknowledges the contributions of: Lee Hardy, Timo Sirainen, Kurt Roecx, Simon Butcher, Aaron Wiebe, 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. o ... Name, Email address, Affiliation ... o ... Name, Email address, Affiliation ... o ... Name, Email address, Affiliation ... Baudis Expires March 9, 2003 [Page 16] Internet-Draft IRC protocol and capabilities selection September 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Baudis Expires March 9, 2003 [Page 17]