| 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 12, 2003.
Copyright (C) The Internet Society (2002). All Rights Reserved.
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.
| 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 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.
- 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.
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-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).
The primary goals of the protocol negotiation and IRC/2 protocol capabilities negotiation are as follows:
| TOC |
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 for example 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 in this document.
The protocol negotiation happens through the PROTOCOL command. The ABNF[2] representation for this message is:
<message> = "PROTOCOL" *( 1*<SP> <token> ) <CRLF> <token> = <protocol> "/" <number> *( '.' <number> ) <protocol> = 1*<letter> <letter> = <ALPHA> / <DIGIT> / "_" / "-" <number> = 1*<DIGIT>
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. This document specifies only one protocol named "IRC" and describes its version 2 (this version has no minor subversioning).
Note that the following section matters only to clients which want to possibly talk by the original IRC protocol. Clients supporting the 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.
| TOC |
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.
Protocol negotiation happens through the CAPAB (short for CAPABilities) command. The ABNF[2] representation for this message is:
<message> = "CAPAB" 1*<SP> <type> [ 1*<SP> ":" <token> ] <CRLF> <type> = "LS" / "LSEND" / "RQ" / "ACK" / "NAK" <token> = [ "-" ] <name> [ "=" <value> ] [ 1*<SP> <token> ] <name> = <letterS> 2*19<letter> <value> = 1*<letter> <letterS> = <ALPHA> / <DIGIT> / "_" <letter> = <ALPHA> / <DIGIT> / "_" / "-"
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. The list can take multiple CAPAB LS messages, if it would exceed the 512 characters limit; see also CAPAB ENDLS.
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 some capabilities successfully.
Each chain of CAPAB LS MUST be terminated by a CAPAB ENDLS message, indicating that no more CAPAB LS messages will come, as the one list can take more than one CAPAB LS message. Note that this message MUST be sent even if only one message is going to take the whole list. The syntax of the CAPAB ENDLS message is same as the syntax of CAPAB LS message.
This message is used by client exclusively to turn on certain IRC/2 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 RQ command previously issued by client. It contains a list of capability tokens 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 <crlf> 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 <crlf> terminating this CAPAB ACK message.
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.
These tokens are formed by optional prefix, capability name and optional capability value, as described in the ABNF above. The name length MUST NOT exceed 20 characters nor be shorter 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 MUST be reset to the default value (and the "boolean" capability MUST 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 (thus, the effective length is 512 without the length of the message preceding it (ie. 500 characters for "CAPAB LS :...\r\n")). 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.
This command is used by client to indicate that it consider its part of the registration done and excepts 001 from the server. The ABNF representation for this message is:
<message> = "REGISTER" <CRLF>
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 the list of supported capabilities, properly terminated by CAPAB LSEND (if server wants to send anything else at the startup of IRC/2 protocol, it MUST send it before the capabilities list). 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.
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> CAPAB LS :cap1 cap2 cap3 cap4 SERVER> CAPAB LSEND :cap5 cap6 CLIENT> CAPAB ON :cap2 cap3=11,cap7 SERVER> CAPAB NAK CLIENT> CAPAB ON :cap2 cap3=11 cap7 SERVER> CAPAB NAK :cap7 CLIENT> CAPAB ON :cap2 cap3=11 SERVER> CAPAB ACK :cap2 cap3=11 CLIENT> CAPAB ACK :cap2 cap3=11 CLIENT> CAPAB LS SERVER> CAPAB LSEND :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
| 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 actual list of PROTOCOL and CAPAB tokens will be published by Internet Assigned Numers Authority (IANA).
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.
| 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 the client registration. This involves for example TLS setup.
| TOC |
| [1] | Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993. |
| [2] | Crocker, D. and P. Overell, "ABNF for Syntax Specifications", RFC 2234, November 1997. |
| TOC |
| Petr Baudis | |
| Masarykovo nam. 4 | |
| Jihlava 58601 | |
| CZ | |
| Phone: | +420 776 584 544 |
| EMail: | pasky@ji.cz |
| URI: | http://pasky.ji.cz/ |
| Aaron Wiebe | |
| 90 A Victoria St. N | |
| New Hamburg, Ontario N0B 2G0 | |
| CA | |
| Phone: | +519 662 9432 |
| EMail: | epiphani@powertrip.net |
| TOC |
| TOC |
The authors especially gratefully acknowledge the contributions of: Lee Hardy, Timo Sirainen, Kurt Roecx, Simon Butcher, 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.