----- Forwarded message from Aaron <[EMAIL PROTECTED]> -----
Date: Tue, 12 Nov 2002 02:47:30 -0800 (PST)
From: Aaron <[EMAIL PROTECTED]>
Reply-To: Aaron <[EMAIL PROTECTED]>
Subject: [PROTO-DESC] CAPAB draft 00 - Comments Needed
To: [EMAIL PROTECTED]
Hey All,
We really need to hear from a number of you before we post this
publically. I'm specifically interested in getting comments from someone
from EFnet and Undernet, as well as hearing from someone in the client
realm. Khaled, the ircII and BX crews are my specific interest there.
I don't know about the most of you, but I'm relatively happy about this.
I just want to feel secure about someone accually implementing it other
than DALnet. All I'm looking for is a "yeah, we're in" type responce.
Everyone will have their own little suggestions for this draft - even I
have things I would change. But in the interest of accually getting some
progress, I'll gladly have a few things different than my ideal.
We've got about a week now til this is submitted.
-epi
On Mon, 4 Nov 2002, Aaron wrote:
> Network Working Group P. Baudis
> Internet-Draft A. Wiebe
> Expires: May 5, 2003 November 4, 2002
>
>
> IRC client capabilities negotiation
> draft-baudis-irc-capab-00
>
> 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 May 5, 2003.
>
> Copyright Notice
>
> Copyright (C) The Internet Society (2002). All Rights Reserved.
>
> Abstract
>
> This memo presents a way for IRC servers and clients to negotiate
> optional features of the IRC protocol, mainly those which need to be
> explicitly supported by the client and are either backwards
> incompatible with the original IRC protocol or involve the format of
> data sent by the client.
>
>
>
>
>
>
>
>
>
>
> Baudis & Wiebe Expires May 5, 2003 [Page 1]
>
> Internet-Draft IRC client capabilities negotiation November 2002
>
>
> Table of Contents
>
> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
> 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
> 1.2 Impacts to the server-server protocols . . . . . . . . . . . 3
> 1.3 Current Problems . . . . . . . . . . . . . . . . . . . . . . 3
> 1.3.1 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 3
> 1.3.2 Compatibility . . . . . . . . . . . . . . . . . . . . . . . 3
> 1.4 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
> 2. Special handshake . . . . . . . . . . . . . . . . . . . . . 5
> 2.1 Handshake message . . . . . . . . . . . . . . . . . . . . . 5
> 2.2 Register message . . . . . . . . . . . . . . . . . . . . . . 5
> 2.3 Compatibility . . . . . . . . . . . . . . . . . . . . . . . 5
> 3. Capabilities negotiation . . . . . . . . . . . . . . . . . . 7
> 3.1 Capab message . . . . . . . . . . . . . . . . . . . . . . . 7
> 3.1.1 CAP LS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
> 3.1.2 CAP ENDLS . . . . . . . . . . . . . . . . . . . . . . . . . 8
> 3.1.3 CAP RQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
> 3.1.4 CAP ACK . . . . . . . . . . . . . . . . . . . . . . . . . . 8
> 3.1.5 CAP NAK . . . . . . . . . . . . . . . . . . . . . . . . . . 8
> 3.1.6 Capability Tokens . . . . . . . . . . . . . . . . . . . . . 9
> 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
> 5. Further Documents . . . . . . . . . . . . . . . . . . . . . 11
> 5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
> 6. Security Considerations . . . . . . . . . . . . . . . . . . 12
> References . . . . . . . . . . . . . . . . . . . . . . . . . 13
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
> A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
> Full Copyright Statement . . . . . . . . . . . . . . . . . . 15
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Baudis & Wiebe Expires May 5, 2003 [Page 2]
>
> Internet-Draft IRC client capabilities negotiation November 2002
>
>
> 1. Introduction
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119.
>
> 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 standardize way of
> announcing such optional IRC 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 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. Standardizing 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.3 Current Problems
>
> 1.3.1 Bandwidth
>
> 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 original RFC 1459 [1], there is a
> substantially large number of ways to address this problem without
> rewriting the protocol entirely.
>
> 1.3.2 Compatibility
>
> There is a press inside of the IRC developers community to introduce
> non-standard but valuable and useful changes to the protocol, which
>
>
>
> Baudis & Wiebe Expires May 5, 2003 [Page 3]
>
> Internet-Draft IRC client capabilities negotiation November 2002
>
>
> 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.
>
> Clients supporting extensions described in this document SHOULD still
> be backwards compatible to the original protocol as described in RFC
> 1459.
>
> 1.4 Goals
>
> The primary goals of the IRC protocol capabilities negotiation are as
> follows:
>
> o Flexible expandable format that allows alternative capabilities
> 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 & Wiebe Expires May 5, 2003 [Page 4]
>
> Internet-Draft IRC client capabilities negotiation November 2002
>
>
> 2. Special handshake
>
> In order to be able to effectively set up unlimited number of
> capabilities in a correct way during the handshake (before user
> registration), special new handshake must be introduced. This
> handshake only differs from the regular handshake in requirement of
> explicitly finish. That is, the handshake MUST NOT be taken as
> complete by the server until the client doesn't explicitly indicate
> that.
>
> The special handshake involves two newly introduced commands: it is
> started by the HANDSHAKE command and finished by the REGISTER
> command.
>
> 2.1 Handshake message
>
> The special handshake is started by the HANDSHAKE command. The ABNF
> [2] representation for this message is:
>
> message = "HANDSHAKE" CRLF
>
> The server responds by the HANDSHAKE message of the same format as
> the command has. Note that for forward compatibility,
> implementations SHOULD ignore any possible parameters sent along.
>
> Then, the server MUST send the CAP ENDLS message, possibly preceded
> by a number of CAP LS messages, as further described below. In
> future, some more messages MAY be inserted between the HANDSHAKE
> message and capabilities list.
>
> 2.2 Register message
>
> This command is used by client to indicate that it considers its part
> of the handshake done and expects 001 numeric from the server. The
> ABNF [2] representation for this message is:
>
> message = "REGISTER" <CRLF>
>
> The server responds by the 001 numeric or the appropriate error
> numeric if the informations sent by client were incomplete or the
> registration failed for some other reason. Note that for forward
> compatibility, implementations SHOULD ignore any possible parameters
> sent along the REGISTER command.
>
> 2.3 Compatibility
>
> In order to preserve the backwards compatibility with the original
> IRC protocol, the client SHOULD send the HANDSHAKE message and then
>
>
>
> Baudis & Wiebe Expires May 5, 2003 [Page 5]
>
> Internet-Draft IRC client capabilities negotiation November 2002
>
>
> try to register using the original IRC protocol, not waiting for the
> HANDSHAKE reply which may not come if the server doesn't support the
> special handshake. If the server doesn't support HANDSHAKE, it will
> reply with the 001 message, otherwise it will reply with the
> HANDSHAKE message and it will postpone finishing of the registration
> until the REGISTER command will be received.
>
> Note that each server supporting the capabilities negotiation MUST
> support the special handshake and vice versa, thus the clients may
> rely on that.
>
> 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
> HANDSHAKE 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Baudis & Wiebe Expires May 5, 2003 [Page 6]
>
> Internet-Draft IRC client capabilities negotiation November 2002
>
>
> 3. Capabilities negotiation
>
> The capabilities negotiation is done by exchange of the CAP messages,
> which is usually initiated by the client. The first negotiation is
> expected to happen during the special handshake; obviously the client
> could negotiate even during the regular handshake, but it SHOULD NOT
> since there's no clean lag-prune method to do that while staying
> backwards compatible. Also, there is no known reason why the special
> handshake should not be used and it provides flexible base for
> further extensions of the registration process.
>
> 3.1 Capab message
>
> Capabilities negotiation happens through the CAP (short for
> CAPabilities) command. The ABNF [2] representation for this message
> is:
>
> message = "CAP" 1*SP type [ 1*SP ":" token ] CRLF
> type = "LS" / "ENDLS" / "RQ" / "ACK" / "NAK"
> token = [ "-" ] name [ "=" value ] [ 1*SP token ]
> name = letterS *19letter
> value = 1*letter
>
> letterS = ALPHA / DIGIT / "_"
> letter = ALPHA / DIGIT / "_" / "-"
>
> Note that the value obviously MUST NOT contain any whitespace
> characters.
>
> The CAP command can be issued at any time by client, even during the
> client registration. Server MUST NOT send request CAP messages, only
> the informational ones.
>
> 3.1.1 CAP 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. The list can take
> multiple CAP LS messages, if it would exceed the 512 characters
> limit; see also CAP ENDLS.
>
> When requesting the capabilities list, no extra parameters should be
> sent. If the message is the capabilities list announcement sent by
> server, a list of capability tokens is sent as third parameter,
> unless there are no particular capabilities supported.
>
> Note that the capabilities list can vary depending on the
> capabilities already selected by client, so the new capabilities list
>
>
>
> Baudis & Wiebe Expires May 5, 2003 [Page 7]
>
> Internet-Draft IRC client capabilities negotiation November 2002
>
>
> SHOULD be re-retrieved by client each time the client will turn on
> some capabilities successfully.
>
> 3.1.2 CAP ENDLS
>
> Each chain of CAP LS MUST be terminated by a CAP ENDLS message,
> indicating that no more CAP LS messages will come, as the one list
> can take more than one CAP LS message. Note that this message MUST
> be sent even if only one message is going to take the whole list;
> then, the server can send only the CAP ENDLS message standalone,
> without any preceding CAP LS messages. The syntax of the CAP ENDLS
> message is same as the syntax of CAP LS message.
>
> 3.1.3 CAP RQ
>
> This message is used by client exclusively to turn on certain IRC
> protocol capabilities. The client sends a list of capability tokens
> (Section 3.1.6). The server replies with either CAP ACK or CAP NAK.
> Note that if tokens already set are included in the list, the
> capability value is updated, if it's relevant for the value type (no
> value means that the old value is kept and the token is silently
> ignored).
>
> 3.1.4 CAP ACK
>
> This message is used by server to acknowledge the CAP RQ command
> previously issued by client. It contains a list of capability tokens
> (Section 3.1.6) acknowledged by the server (same or subset of the
> list of capability tokens in client's CAP RQ). The server starts
> sending of the messages using the new capability tokens immediately
> after sending the <crlf> terminating this CAP ACK message. The
> client has to respond to this message by another CAP ACK message
> which MUST contain the same list of capability tokens; then, it MUST
> start using those capabilities immediately after sending the <crlf>
> terminating this CAP ACK message.
>
> 3.1.5 CAP NAK
>
> This message is used by server to indicate some problem with the list
> client sent along the CAP 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 CAP LS,
> unless the server couldn't properly parse the list received from
> client.
>
>
>
>
> Baudis & Wiebe Expires May 5, 2003 [Page 8]
>
> Internet-Draft IRC client capabilities negotiation November 2002
>
>
> 3.1.6 Capability Tokens
>
> 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 - server then MUST send a CAP NAK for that capability
> (obviously not including the dash in the capability token).
>
> 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. 502 characters for "CAP 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
> (Section 5). There is a special namespace defined in this document
> already, though. All capability names beginning with "x-" or "X-"
> string are reserved for experimental capabilities not standarized yet
> and for non-standard capabilities which don't need to be standarized
> officially (as they are ie. used only in closed environment of
> clients and servers or privately).
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Baudis & Wiebe Expires May 5, 2003 [Page 9]
>
> Internet-Draft IRC client capabilities negotiation November 2002
>
>
> 4. Examples
>
> The basic example of the complete negotiation with the conforming
> server:
>
> CLIENT> HANDSHAKE
> CLIENT> USER foo - - :text
> CLIENT> NICK bar
> SERVER> HANDSHAKE
> SERVER> CAP LS :cap1 cap2 cap3 cap4
> SERVER> CAP ENDLS :cap5 cap6
> CLIENT> CAP RQ :cap2 cap3=11,cap7
> SERVER> CAP NAK
> CLIENT> CAP RQ :cap2 cap3=11 cap7
> SERVER> CAP NAK :cap7
> CLIENT> CAP RQ :cap2 cap3=11
> SERVER> CAP ACK :cap2 cap3=11
> CLIENT> CAP ACK :cap2 cap3=11
> CLIENT> CAP LS
> SERVER> CAP ENDLS :cap1 cap2 somenewcap anothernewcap whataboutthiscap
> CLIENT> REGISTER
> SERVER> :irc.xy.com 001 bar :Welcome
>
> The basic example of the complete negotiation with an old server:
>
> CLIENT> HANDSHAKE
> CLIENT> USER foo - - :test
> CLIENT> NICK bar
> SERVER> :irc.xy.com 001 bar :Welcome
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Baudis & Wiebe Expires May 5, 2003 [Page 10]
>
> Internet-Draft IRC client capabilities negotiation November 2002
>
>
> 5. 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 actual list of the CAP tokens will be
> published by Internet Assigned Numbers 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.
>
> 5.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 [EMAIL PROTECTED] The administrative contact for this list is
> [EMAIL PROTECTED]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Baudis & Wiebe Expires May 5, 2003 [Page 11]
>
> Internet-Draft IRC client capabilities negotiation November 2002
>
>
> 6. Security Considerations
>
> In order to prevent possible disclosure of any confidential
> information, any security-related capabilities SHOULD be issued as
> soon as possible, preferably already during the client registration.
> This involves for example TLS setup.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Baudis & Wiebe Expires May 5, 2003 [Page 12]
>
> Internet-Draft IRC client capabilities negotiation November 2002
>
>
> References
>
> [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.
>
>
> Authors' Addresses
>
> Petr Baudis
> Masarykovo nam. 4
> Jihlava 58601
> CZ
>
> Phone: +420 776 584 544
> EMail: [EMAIL PROTECTED]
> URI: http://pasky.ji.cz/
>
>
> Aaron Wiebe
> 90 A Victoria St. N
> New Hamburg, Ontario N0B 2G0
> CA
>
> Phone: +519 662 9432
> EMail: [EMAIL PROTECTED]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Baudis & Wiebe Expires May 5, 2003 [Page 13]
>
> Internet-Draft IRC client capabilities negotiation November 2002
>
>
> Appendix A. Acknowledgements
>
> The authors especially gratefully acknowledge the contributions of:
>
> Simon Butcher
>
> Lee Hardy
>
> Piotr Kucharski
>
> Kurt Roecx
>
> Timo Sirainen
>
> Jakub Vlasek
>
> ...and others.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Baudis & Wiebe Expires May 5, 2003 [Page 14]
>
> Internet-Draft IRC client capabilities negotiation November 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 & Wiebe Expires May 5, 2003 [Page 15]
>
>
> --OwLcNYc0lM97+oe1--
>
----- End forwarded message -----
