| TOC |
|
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 5, 2003.
Copyright (C) The Internet Society (2002). All Rights Reserved.
This memo presents a way for IRC servers and clients to negotiate optional features of protocol further used for their communication.
| TOC |
| TOC |
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[1], 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-standart 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.
| TOC |
The primary goals of protocol negotiation are as follows:
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:
<message> ::= "CAPAB" <SPACE> <type> [ <SPACE> : <token> ] <crlf>
<type> ::= "LS" | "ON" | "ACK" | "NAK"
<token> ::= [ '-' ] <name> [ '=' <value> ] [ <SPACE> <token> ]
<name> ::= <letter> { <letter> }
<value> ::= <letter> { <letter> }
<letter> ::= <alpha> | <digit> | '_'
<SPACE> ::= ' ' { ' ' }
<crlf> ::= CR LF
Note that value can be either a number or string which MUST NOT contain any whitespace characters.
The CAPAB command can be issued at any time by client, even during the IRC handshake (sending of NICK, USER and possibly PASS). Server can send no 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.
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 al 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. 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 turned off or reset to the default value, respectively.
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 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 IRC handshake 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 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.
Note that it is recommended to set up the capabilities during the IRC handshake, 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.
| TOC |
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 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.
| TOC |
In order to prevent possible man-in-the-middle attacks, any security-related capabilities should be issued as soon as possible, preferrably already during handshake. This involves for example TLS setup.
| TOC |
| [1] | Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993. |
| TOC |
| Petr Baudis | |
| Masarykovo nam. 4 | |
| Jihlava 58601 | |
| CZ | |
| Phone: | +420 776 584 544 |
| EMail: | pasky@ji.cz |
| URI: | http://pasky.ji.cz/ |
| TOC |
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.
| TOC |
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.
Funding for the RFC Editor function is currently provided by the Internet Society.