diff options
Diffstat (limited to 'doc/technical/draft-mitchell-irc-capabilities-01.txt')
| -rw-r--r-- | doc/technical/draft-mitchell-irc-capabilities-01.txt | 1298 |
1 files changed, 1298 insertions, 0 deletions
diff --git a/doc/technical/draft-mitchell-irc-capabilities-01.txt b/doc/technical/draft-mitchell-irc-capabilities-01.txt new file mode 100644 index 0000000..f0c6736 --- /dev/null +++ b/doc/technical/draft-mitchell-irc-capabilities-01.txt @@ -0,0 +1,1298 @@ + +Network Working Group K. Mitchell +Internet-Draft P. Lorier +Expires: September 5, 2005 Undernet IRC Network + L. Hardy + ircd-ratbox + P. Kucharski + IRCnet + March 7, 2005 + + IRC Client Capabilities Extension + draft-mitchell-irc-capabilities-01 + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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 September 5, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + IRC (Internet Relay Chat) is a long-standing protocol for real-time + chatting. The basic client-server protocol is a very simple + text-based protocol with no explicit mechanism for introducing or + + +Mitchell, et al. Expires September 5, 2005 [Page 1] +Internet-Draft IRC CAP March 2005 + + negotiating backwards-incompatible extensions. This memo presents a + mechanism for negotiation of such extensions. + +Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [1]. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + + 2. Problems to be Solved . . . . . . . . . . . . . . . . . . . . 4 + + 3. The CAP Command . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1 CAP LS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.2 CAP LIST . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.3 CAP REQ . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.4 CAP ACK . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.5 CAP NAK . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.6 CAP CLEAR . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.7 CAP END . . . . . . . . . . . . . . . . . . . . . . . . . 8 + + 4. Capability Negotiation . . . . . . . . . . . . . . . . . . . . 10 + + 5. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.1 Capability Modifiers . . . . . . . . . . . . . . . . . . . 11 + + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 + + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 + + A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + + B. ABNF Description of Capabilities . . . . . . . . . . . . . . . 19 + + C. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + + Intellectual Property and Copyright Statements . . . . . . . . 28 + + +Mitchell, et al. Expires September 5, 2005 [Page 2] +Internet-Draft IRC CAP March 2005 + +1. Introduction + + The IRC protocol, as originally documented by RFC 1459 [2] and + updated by RFC 2812 [3], is a simple, text-based conferencing + protocol, involving a number of users spread across a number of + interconnected servers. These users may chat with other individual + users, or may chat with groups of users on "channels"--what other + chat systems refer to as "rooms" or "chat rooms". + + Over the years, various extensions to the basic IRC protocol have + been made by IRC server programmers. Often, these extensions are + intended to conserve bandwidth, close loopholes left by the original + protocol specification, or add features for users or for the server + administrators. Most of these changes are backwards-compatible with + the original protocol specification: A command may be added, a reply + may be extended to contain more parameters, etc. Recently, however, + there has been a desire to introduce changes that would not be + backwards-compatible with existing IRC clients. Ideally, these + protocol changes would only be used with clients and servers that can + understand the revised protocol. Unfortunately, the IRC protocol + does not provide any form of extension or protocol negotiation, + making it impossible to determine support for such extensions. + + This memo introduces a standardized mechanism for negotiation of + protocol extensions, known as *capabilities*, that will be + backwards-compatible with all existing IRC clients and servers. Any + server not implementing this extension will still interoperate with + clients that do implement it; similarly, clients that do not + implement the capabilities extension may successfully communicate + with a server that does implement the extension. + + + + + + + + + + + +Mitchell, et al. Expires September 5, 2005 [Page 3] +Internet-Draft IRC CAP March 2005 + +2. Problems to be Solved + + The IRC protocol is not a lockstep protocol. This means that a + client may issue additional commands before the server has finished + responding to the first one. Additionally, unlike other protocols, + the server does not necessarily issue a banner response upon initial + connection. This, combined with the fact that some servers do not + complain about unknown commands prior to completion of the client + registration phase, means that a client cannot know for certain + whether a server implements the extension. If a client had to wait + for a banner message, it would fail to interoperate with a server not + implementing the capabilities extension. If the client must issue a + command and then wait for a response, a similar problem results. As + some potential protocol extensions must be set up prior to completion + of the client registration phase, there is no reliable way a server + may indicate implementation of the capabilities extension to a + client. + + The solution to these problems turns out to be to extend the client + registration procedure. The client sends a request to begin + capability negotiation, as well as the other information necessary + for client registration (user name, nick name, optional password, + etc.). If the server understands the capabilities extension, it will + suspend completion of the registration phase until the negotiation is + complete; negotiation may then proceed in a lockstep fashion. If the + server does not understand capabilities, then the registration will + complete immediately, and the client will receive the 001 numeric. + This will signal to the client that the server does not implement the + capabilities extension. + + + + + + + + + + + +Mitchell, et al. Expires September 5, 2005 [Page 4] +Internet-Draft IRC CAP March 2005 + +3. The CAP Command + + The capabilities extension is implemented by addition of one command + with several subcommands. The command added is *CAP*. CAP takes a + single, required subcommand, optionally followed by a single + parameter consisting of a space-separated list of capabilities. Each + capability within the list MAY be preceded by a capability modifier. + (Section 5.1) + + The subcommands defined for CAP are: + + 1. LS (Section 3.1) + 2. LIST (Section 3.2) + 3. REQ (Section 3.3) + 4. ACK (Section 3.4) + 5. NAK (Section 3.5) + 6. CLEAR (Section 3.6) + 7. END (Section 3.7) + + The LS (Section 3.1), LIST (Section 3.2), REQ (Section 3.3), ACK + (Section 3.4), and NAK (Section 3.5) subcommands may be followed by a + single parameter consisting of a space-separated list of capability + names. If more than one capability is named, this argument MUST be + preceded by the IRC protocol colon (':') sentinel to signal that the + remainder of the line is a single argument. + + If a client sends a subcommand not listed above or issues an invalid + command, the server SHOULD reply with the ERR_INVALIDCAPCMD numeric + response, 410. The first parameter after the client nickname SHALL + be the subcommand the client sent; the second parameter SHOULD be a + textual description of the error. + + In ABNF [4] notation: + + capcmd = [ ":" servername SP ] "CAP" SP subcmd + + subcmd = lscmd / listcmd / reqcmd / ackcmd / + nakcmd / clearcmd / endcmd + + capcmderr = ":" servername SP "410" SP nick SP badcmd + SP ":Invalid CAP subcommand" + ; badcmd is the unrecognized subcommand + + caplist = [ ":" ] *( capmod ) capab + caplist =/ ":" *( capmod ) capab 1*( SP *( capmod ) capab ) + + where SP is as designated in Appendix A of RFC 2234 [4], and + servername and nick are as designated in section 2.3.1 of RFC 1459 + + +Mitchell, et al. Expires September 5, 2005 [Page 5] +Internet-Draft IRC CAP March 2005 + + [2]. + + The discussion in the following sections applies only to clients and + servers implementing the capabilities extension. Servers (and + clients) not implementing the capabilities extension are exempted + from the requirements of this section. + +3.1 CAP LS + + The LS subcommand is used to list the capabilities supported by the + server. The client SHALL send an LS subcommand with no arguments to + solicit a list of supported capabilities from the server. Servers + MUST respond to such LS subcommands with one or more LS subcommands + containing the list of recognized capabilities. All but the last + subcommand MUST have a parameter containing only an asterisk ('*') + preceding the capability list. + + If a client issues an LS subcommand during the client registration + phase, client registration MUST be suspended until an END (Section + 3.7) subcommand is received. + + ABNF [4] description of the LS subcommand: + + lscmd = "LS" + lscmd =/ "LS" SP [ "*" SP ] caplist + +3.2 CAP LIST + + The LIST subcommand is provided to permit the client to request a + list of the capabilities currently active for the connection. It is + similar to the LS (Section 3.1) subcommand--if a client issues a LIST + subcommand with no arguments, the server MUST respond with a sequence + of LIST subcommands, all but the last of which MUST have a single + parameter consisting solely of an asterisk ('*') preceding the list + of capabilities. If no capabilities have been enabled, the server + MUST send a LIST command with an empty capability list; the parameter + MUST NOT be omitted. The active capabilities MAY be listed in any + order. + + ABNF [4] description of the LIST subcommand: + + listcmd = "LIST" + listcmd =/ "LIST" SP ":" + listcmd =/ "LIST" SP [ "*" SP ] caplist + + + +Mitchell, et al. Expires September 5, 2005 [Page 6] +Internet-Draft IRC CAP March 2005 + +3.3 CAP REQ + + The REQ subcommand is sent by the client to request that a capability + or set of capabilities be enabled or disabled. Its sole parameter + MUST be a space-separated list of capabilities. Each capability name + MAY be preceded by a dash ('-') to indicate that the capability + should be disabled. Additionally, receipt of this subcommand during + the client registration MUST suspend client registration until an END + (Section 3.7) subcommand is received. + + Servers MUST respond to a REQ command with either the ACK (Section + 3.4) or NAK (Section 3.5) subcommands to indicate acceptance or + rejection of the capability set requested by the client. A server + MUST accept the entire capability set or reject it whole; servers + MUST NOT accept some capabilities in the set while rejecting others. + If a client requests that a "sticky" capability be disabled, the + server MUST reject the capability set. + + ABNF [4] description of the REQ subcommand: + + reqcmd = "REQ" SP caplist + +3.4 CAP ACK + + The ACK subcommand has three uses. It is used by the server to + acknowledge a REQ (Section 3.3) subcommand; by the server to + acknowledge a CLEAR (Section 3.6) subcommand and list the removed + capabilities; and by the client to acknowledge certain capabilities + designated as requiring acknowledgment. If more than one ACK is + required due to the IRC line length limitation of 512 characters, all + but the last SHALL contain a parameter consisting of a single + asterisk ('*') immediately preceding the list of capabilities, as for + LS (Section 3.1) and LIST (Section 3.2). + + If an ACK reply originating from the server is spread across multiple + lines, a client MUST NOT change capabilities until the last ACK of + the set is received. Equally, a server MUST NOT change the + capabilities of the client until the last ACK of the set has been + sent. + + In the first usage, acknowledging a REQ (Section 3.3) subcommand, the + ACK subcommand has a single parameter consisting of a space separated + list of capability names, which may optionally be preceded with one + or more modifiers (Section 5.1). + + The second usage, acknowledging a CLEAR (Section 3.6) subcommand, is + similar to the first usage. When a CLEAR (Section 3.6) subcommand is + + +Mitchell, et al. Expires September 5, 2005 [Page 7] +Internet-Draft IRC CAP March 2005 + + issued, all non-"sticky" capabilities are disabled, and a set of ACK + subcommands will be generated by the server with the disable modifier + preceding each capability. + + The third usage is when, in the preceding two cases, some capability + names have been preceded with the ack modifier. ACK in this case is + used to fully enable or disable the capability. Clients MUST NOT + issue an ACK subcommand for any capability not marked with the ack + modifier in a server-generated ACK subcommand. + + ABNF [4] description of the ACK subcommand: + + ackcmd = "ACK" SP [ "*" SP ] caplist + +3.5 CAP NAK + + The NAK subcommand MUST be sent by the server in response to a REQ + (Section 3.3) subcommand when any capability change requested cannot + be performed for any reason. The server MUST NOT make any change to + the set of capabilities for the client if it responds with a NAK + subcommand. The argument of the NAK subcommand MUST consist of at + least the first one hundred characters of the capability list in the + REQ (Section 3.3) subcommand which triggered the NAK. + + ABNF [4] description of the NAK subcommand: + + nakcmd = "NAK" SP ":" acklist + ; acklist is at least 100 characters of the + ; capability list from the REQ + +3.6 CAP CLEAR + + The CLEAR subcommand requests that the server clear the capability + set for the client. The server MUST respond with a set of ACK + (Section 3.4) subcommands indicating the capabilities being + deactivated. + + ABNF [4] description of the CLEAR subcommand: + + clearcmd = "CLEAR" + +3.7 CAP END + + The END subcommand signals to the server that capability negotiation + is complete and requests that the server continue with client + + +Mitchell, et al. Expires September 5, 2005 [Page 8] +Internet-Draft IRC CAP March 2005 + + registration. If the client is already registered, this command MUST + be ignored by the server. + + Clients that support capabilities but do not wish to enter + negotiation SHOULD send CAP END upon connection to the server. + + ABNF [4] description of the END subcommand: + + endcmd = "END" + + + + + + + + + + + + + + + + + + + + + +Mitchell, et al. Expires September 5, 2005 [Page 9] +Internet-Draft IRC CAP March 2005 + +4. Capability Negotiation + + Clients implementing this extension SHOULD take one of the following + three actions upon initial connection to a server: + + o Issue an LS (Section 3.1) subcommand (with an empty capability + list) to solicit a list of supported capabilities from the server; + + o Issue the REQ (Section 3.3) subcommand to request a particular set + of capabilities without knowing what capabilities the server + supports or if it supports the capabilities extension; or + + o Issue the END (Section 3.7) subcommand to signal implementation of + the capabilities extension without entering into capability + negotiation. + + Although a client is permitted to not issue any CAP commands upon + connection, this is NOT RECOMMENDED. Servers MAY assume a client + does not implement the capabilities extension if it does not issue + any CAP commands upon initial connection. + + Clients SHOULD follow CAP commands issued upon connection with the + standard IRC client registration commands without waiting for any + responses from the server. See RFC 1459 [2] for more details about + the client registration procedure. + + If a client issues the LS (Section 3.1) or REQ (Section 3.3) + subcommands during the client registration procedure, a server + implementing the capabilities extension MUST NOT complete the client + registration until the client issues the END (Section 3.7) + subcommand. A client that sees a RPL_WELCOME (001) numeric response + before it sends CAP END (Section 3.7) SHOULD assume that the server + does not support the capabilities extension. + + Once the client is registered, CAP commands SHALL have no effect on + other connection operations, except that a client MAY change the + capabilities it has set. In particular, CAP commands and their + responses MAY be interspersed with other protocol messages. The END + (Section 3.7) subcommand SHALL have no effect once client + registration has been completed. + + + + + + +Mitchell, et al. Expires September 5, 2005 [Page 10] +Internet-Draft IRC CAP March 2005 + +5. Capabilities + + Capabilities are designated by a name composed of one or more + elements. Name elements are not case-sensitive. They must begin + with a letter and may contain any number of letters, numbers, and the + dash character ('-'). Names containing more than one name element + MUST also contain a period character ('.') in the first name element. + Name elements are separated from each other via the slash character + ('/'). + + There are two capability name spaces: + + Network Specific: Names whose first element contains a period + character ('.') designate a delegated capability name space. The + first element MUST be a valid, existing DNS domain name. These + names MUST contain at least two elements. + + Standardized: All other names MUST correspond to capabilities + documented by an RFC. Further, these names MUST contain only one + element. + + These rules are summarized by the following ABNF [4] representation: + + elem = ALPHA *( ALPHA / DIGIT / "-" ) + + netname = elem 1*( "." elem ) + + netDeleg = netname 1*( "/" elem ) + + standardized = elem + + capab = netDeleg / standardized + + where ALPHA and DIGIT are as designated in Appendix A of RFC 2234 + [4]. + +5.1 Capability Modifiers + + There are various capability modifiers available. If a capability + modifier is to be used, it MUST directly precede the capability name. + The following are the modifiers defined for capabilities. Certain + modifiers MAY be combined. + + The disable modifier is used by both the server and the client to + indicate that a capability should be disabled. The disable modifier + is defined as the dash character ('-'). A client MUST only use the + disable modifier in the REQ (Section 3.3) and ACK (Section 3.4) + subcommands. A server MUST use the disable modifier in the ACK + + +Mitchell, et al. Expires September 5, 2005 [Page 11] +Internet-Draft IRC CAP March 2005 + + (Section 3.4) subcommand when disabling a capability, or in + conjunction with a ack modifier in the LIST (Section 3.2) subcommand. + The server MUST NOT use the disable modifier in any other command + response. + + The sticky modifier is used by the server to indicate a capability + that, once enabled, cannot be disabled. The sticky modifier is + defined as the equals character ('='). A client MUST NOT use the + sticky modifier. A server MUST only use the sticky modifier in the + ACK (Section 3.4), LIST (Section 3.2) and LS (Section 3.1) + subcommands and MUST use the modifier for all such capabilities. + + The ack modifier is used by the server to indicate that the client + must issue an ACK (Section 3.4) subcommand to fully enable or disable + the capability. The ack modifier is defined as the tilde character + ('~'). The ack modifier indicates that traffic originating from the + server SHALL make use of the capability, but the server SHALL NOT + expect traffic originating from the client to make use of the + capability. When combined with the disable modifier, it indicates + traffic originating from the server SHALL NOT make use of the + capability, but the server expects traffic originating from the + client SHALL make use of the capability. The ack modifier MAY be + combined with the sticky modifier. + + A server MUST use the ack modifier in the ACK (Section 3.4) and LIST + (Section 3.2) subcommands to indicate capabilities that require an + ACK (Section 3.4) subcommand from the client to be fully enabled or + disabled. Servers MUST also use the ack modifier in the response to + an LS (Section 3.1) subcommand to indicate capabilities which will + require ACK (Section 3.4) subcommands from the client. Clients MUST + NOT use the ack modifier, but SHOULD issue the ACK (Section 3.4) + subcommand as soon as possible after receiving an ACK (Section 3.4) + or REQ (Section 3.3) subcommand from the server that contains a + capability marked with the ack modifier. + + In ABNF [4] notation: + + dismod = "-" + stickymod = "=" + ackmod = "~" + + capmod = dismod / stickymod / ackmod + + + + + +Mitchell, et al. Expires September 5, 2005 [Page 12] +Internet-Draft IRC CAP March 2005 + +6. IANA Considerations + + The standardized capability name space shall be managed by IANA in + accordance with the description of capability names in Section 5. In + particular, any name not containing the period character ('.') must + be specified by an RFC. + + + + + + + + + + + + + + + + + + + + + + + +Mitchell, et al. Expires September 5, 2005 [Page 13] +Internet-Draft IRC CAP March 2005 + +7. Security Considerations + + Capabilities are an extension to a preexisting, insecure chat + protocol. This extension does not add and does not purport to add + any security to the IRC protocol. Capability negotiation occurs + after client registration has already begun. Moreover, no mechanism + is defined that allows parameters to be passed for specific + capabilities. Although such a mechanism could be added, + cryptographic security systems frequently require several exchanges + to establish a secure context, particularly if authentication must + also be negotiated. Thus, the capabilities extension is unsuited to + the implementation of those protocols, and other mechanisms, such as + SSL-encapsulated IRC, should be used. + + + + + + + + + + + + + + + + + + + +Mitchell, et al. Expires September 5, 2005 [Page 14] +Internet-Draft IRC CAP March 2005 + +8. Acknowledgments + + The authors wish to gratefully acknowledge the participation of Aaron + Wiebe and the members of the proto-desc@dal.net email list in the + design of this protocol extension. + +9 References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC + 1459, May 1993. + + [3] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, + April 2000. + + [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [5] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, + February 2004. + +Authors' Addresses + + Kevin L. Mitchell + Undernet IRC Network + 38 Eighth St., Apt. 7 + Cambridge, Massachusetts 02141 + US + + Phone: +1-617-230-1021 + EMail: klmitch@mit.edu + URI: http://www.mit.edu/~klmitch/ + + Perry Lorier + Undernet IRC Network + 3 Liston Cres + Hamilton, Waikato 2001 + NZ + + Phone: +64-7-859-1109 + EMail: isomer@undernet.org + + + +Mitchell, et al. Expires September 5, 2005 [Page 15] +Internet-Draft IRC CAP March 2005 + + Lee Hardy + ircd-ratbox Development Team + + EMail: lee@leeh.co.uk + URI: http://www.leeh.co.uk + + Piotr Kucharski + IRCnet + + EMail: Beeth@irc.pl + URI: http://42.pl/ + + + + + + + + + + + + + + + + + + + + +Mitchell, et al. Expires September 5, 2005 [Page 16] +Internet-Draft IRC CAP March 2005 + +Appendix A. Examples + + In the following examples, lines preceded by "CLIENT:" indicate + protocol messages sent by the client, and lines preceded by "SERVER:" + indicate protocol messages sent by the server. For clarity, the + origin field for server-originated protocol messages has been + omitted. This field would consist of a colon (':') followed by the + full server name, and would be the first field in the command. + + A client communicating with a server not supporting CAP. + + CLIENT: CAP LS + CLIENT: NICK nickname + CLIENT: USER username ignored ignored :real name + SERVER: 001 [...] + + A client which does not wish to enter capability negotiation. + + CLIENT: CAP END + CLIENT: NICK nickname + CLIENT: USER username ignored ignored :real name + SERVER: 001 [...] + + A client entering into capability negotiation during registration, + and requesting a set of capabilities that the server does not + support. + + CLIENT: CAP LS + CLIENT: NICK nickname + CLIENT: USER username ignored ignored :real name + SERVER: CAP LS * :A B C D E F G H + SERVER: CAP LS :I J + CLIENT: CAP REQ :A B C D E F + SERVER: CAP NAK :A B C D E F + CLIENT: CAP REQ :A C E F + SERVER: CAP ACK :A C E F + CLIENT: CAP REQ :B + SERVER: CAP ACK :B + CLIENT: CAP REQ :D + SERVER: CAP NAK :D + CLIENT: CAP END + SERVER: 001 [...] + + + + + +Mitchell, et al. Expires September 5, 2005 [Page 17] +Internet-Draft IRC CAP March 2005 + + A client requesting a capability that requires an ACK (Section 3.4) + subcommand from the client to be enabled. + + CLIENT: CAP LS + SERVER: CAP LS :~I ~J K + CLIENT: CAP REQ :I J K + SERVER: CAP ACK :~I ~J K + CLIENT: CAP ACK :I J + + A client requesting a capability that requires an ACK (Section 3.4) + subcommand from the client to be enabled and disabled, using the LIST + (Section 3.2) subcommand in between. + + CLIENT: CAP LS + SERVER: CAP LS :~A ~B + CLIENT: CAP REQ :A B + SERVER: CAP ACK :~A ~B + CLIENT: CAP LIST + SERVER: CAP LIST :~A ~B + CLIENT: CAP ACK :A B + CLIENT: CAP LIST + SERVER: CAP LIST :A B + CLIENT: CAP REQ :-B + SERVER: CAP ACK :-~B + CLIENT: CAP LIST + SERVER: CAP LIST :A -~B + CLIENT: CAP ACK :-B + CLIENT: CAP LIST + SERVER: CAP LIST :A + + A client requesting a capability that is sticky. + + CLIENT: CAP LS + SERVER: CAP LS :=I J + CLIENT: CAP REQ :I J + SERVER: CAP ACK :=I J + + A client requesting a capability be disabled. + + CLIENT: CAP LIST + SERVER: CAP LIST :=A B C D + CLIENT: CAP REQ :-B -C + SERVER: CAP ACK :-B -C + + + + +Mitchell, et al. Expires September 5, 2005 [Page 18] +Internet-Draft IRC CAP March 2005 + +Appendix B. ABNF Description of Capabilities + + This section summarizes the ABNF [4] description of the capabilities + extension. + + capcmd = [ ":" servername SP ] "CAP" SP subcmd + + subcmd = lscmd / listcmd / reqcmd / ackcmd / + nakcmd / clearcmd / endcmd + + capcmderr = ":" servername SP "410" SP nick SP badcmd + SP ":Invalid CAP subcommand" + ; badcmd is the unrecognized subcommand + + caplist = [ ":" ] *( capmod ) capab + caplist =/ ":" *( capmod ) capab 1*( SP *( capmod ) capab ) + + lscmd = "LS" + lscmd =/ "LS" SP [ "*" SP ] caplist + + listcmd = "LIST" + listcmd =/ "LIST" SP ":" + listcmd =/ "LIST" SP [ "*" SP ] caplist + + reqcmd = "REQ" SP caplist + + ackcmd = "ACK" SP [ "*" SP ] caplist + + nakcmd = "NAK" SP ":" acklist + ; acklist is at least 100 characters of the + ; capability list from the REQ + + clearcmd = "CLEAR" + + endcmd = "END" + + elem = ALPHA *( ALPHA / DIGIT / "-" ) + + netname = elem 1*( "." elem ) + + netDeleg = netname 1*( "/" elem ) + + standardized = elem + + capab = netDeleg / standardized + + dismod = "-" + stickymod = "=" + + +Mitchell, et al. Expires September 5, 2005 [Page 19] +Internet-Draft IRC CAP March 2005 + + ackmod = "~" + + capmod = dismod / stickymod / ackmod + + + + + + + + + + + + + + + + + + + + + + + + +Mitchell, et al. Expires September 5, 2005 [Page 20] +Internet-Draft IRC CAP March 2005 + +Appendix C. ChangeLog + + Note to RFC Editor: This section may be removed on publication as an + RFC. + + Here is a log of changes to this document: + + 2004-12-15 KLM Initial draft written. + + 2004-12-16 KLM + + * Added description of the argument to some CAP commands in + Section 3. + + * Clarified that requirements of Section 3 only apply to clients + and servers implementing capabilities. + + * Substitution of "performed" for "done" in Section 3.5 + + * Added LIST (Section 3.2) subcommand to provide a mechanism to + query active capabilities. + + * Added reference to RFC 2812 [3]. + + * Moved Examples (Appendix A) section into the back matter. + + * Corrected Perry Lorier's email address. + + * Added this ChangeLog section. + + * Corrected typo in Section 3.7: "sent" for "send". + + * Added <vspace> elements to enhance readability. + + * Changed to non-compact form. + + * Changed anchor for Section 5 to "capabilities" from "caps" to + reduce possible confusion. + + * Revise last sentence of first paragraph of Section 2 to remove + redundancy. + + * Revise last sentence of second paragraph of Section 2 + + * Added email addresses for Lee H and Beeth; updated contact + information for Isomer. + + + +Mitchell, et al. Expires September 5, 2005 [Page 21] +Internet-Draft IRC CAP March 2005 + + 2004-12-17 KLM + + * Augmented description of CAP command and subcommands with ABNF + description. + + * Revised Section 5 to remove "net." name space and replace it + with a delegated name space beginning with a DNS domain name + (suggested by Isomer). + + * Augmented ABNF description of capability names. + + * Revised Section 6 to reflect change in capability name space. + + * Added Appendix B to bring together the entire ABNF description + of capabilities. + + 2004-12-18 KLM + + * Added explanation of what should happen if an unrecognized + subcommand is given. + + * Clarified what to do if a client sends a subcommand that + shouldn't come from a client. + + * Add references to LIST (Section 3.2) to LSL and Section 3.1. + + * Section 3.3 omitted the caplist argument for the REQ command; + corrected. + + * Relax the prohibition against a client acknowledging a + capability that doesn't modify the protocol stream in Section + 3.4 + + * Relax the requirement for a client that understands + capabilities to send CAP END in Section 3.7 + + 2004-12-19 KLM + + * Converted a number of common xrefs into internal entities to + simplify the text. + + * Inserted some white space to make the <front> section a bit + more readable. + + * Added the keyword "Protocol". + + +Mitchell, et al. Expires September 5, 2005 [Page 22] +Internet-Draft IRC CAP March 2005 + + * Added the term "NOT RECOMMENDED" to the note on "Requirements + Language". + + * Moved LIST (Section 3.2) up in the list of CAP subcommands. + + * Minor formatting change to the ABNF representation of subcmd. + + * Capitalized "MAY" in "empty" subcommand. + + * Added text about capability list order and what to do if no + capabilities are implemented to "empty" subcommand. + + * Mention LIST (Section 3.2) also in LSL when talking about + sending more than one LSL subcommand. + + * Clarify language in Section 3.1 a little bit. + + * Substitute "set of capabilities" for "list of capabilities" in + Section 3.3. + + * Fix minor typo in preamble to ABNF description of NAK (Section + 3.5) subcommand: substitution of "ACK" for "NAK". + + * Add note about servers ignoring END (Section 3.7) after client + registration. + + * Fix minor typo in preamble to ABNF description of LIST (Section + 3.2) subcommand: substitution of "END" for "LIST". + + * Added Section 4 discussing capability negotiation. + + * Add ".xml" extension to include files in references section. + + * Simplification of preamble of first example (Appendix A). + + * Add 'type="ABNF"' to <artwork> sections so that they can be + extracted and used to create the abnf.xml now included in + Appendix B. + + * It's now RFC 3667 [5], not RFC 2026... + + 2004-12-27 KLM + + * Minor wording changes to second paragraph of Section 1 + + * Minor wording change to first paragraph of Section 2 + + +Mitchell, et al. Expires September 5, 2005 [Page 23] +Internet-Draft IRC CAP March 2005 + + * Minor wording changes to first paragraph of Section 3; remove + redundant note about the IRC colon sentinel. + + * Change a "must" to a "MUST" in Section 3.4; note that + capability list may be truncated if it would otherwise exceed + the 512 character limit. + + * In Section 3.5, note that capability list may be truncated if + it would otherwise exceed the 512 character limit. + + * Remove redundant line about ignoring END (Section 3.7) commands + after registration. + + * Correct spelling of "acknowledgments". + + * Empty <organization> elements for Lee H and Beeth; put Beeth's + real name, Piotr Kucharski, in the right place. + + * Switch to using a new preprocessor that consolidates all the + ABNF artwork and inserts it with the processing instruction + <?art type="foo"?>. + + * Remove deliberate page break after <abstract> section. + + * Reorder authors section to consolidate <organization> elements + for everyone. + + * Drop abbreviation for Undernet. + + * Expand Section 7 a bit to try to explain why capabilities are + not suited to securing IRC. + + 2005-01-04 KLM + + * Add Lee Hardy's information to the list of authors. + + 2005-01-05 KLM + + * Replace UNKNOWNCAPCMD with INVALIDCAPCMD. + + * Begin rewriting LS (Section 3.1) documentation + + + + +Mitchell, et al. Expires September 5, 2005 [Page 24] +Internet-Draft IRC CAP March 2005 + + 2005-01-19 KLM + + * Redesign the protocol substantially to simplify it. + + 2005-01-20 KLM + + * Update Piotr's contact information. + + * Drop the "x-" namespace... + + 2005-01-20 LH + + * Some servers do issue banner responses, now. + + * The CAP subcommand is now a requirement. + + * Minor grammatical fix-up in documentation of REQ (Section 3.3) + ("acceptance of or rejection of"--strike first "of"). + + * Clarify that sticky capabilities cause a REQ (Section 3.3) to + be NAK (Section 3.5)ed. + + * Mark the third case of an ACK (Section 3.4) with an explicit + indicator that it's the third case... + + * Strike redundant mention of not suspending client registration + in documentation for END (Section 3.7). + + 2005-01-21 LH + + * Move all references on capability modifiers to its own section + + * Clarify instructions on the ack ('~') modifier, indicating it + can be used with sticky capabilities. + + * Add a note into CAP section about capability modifiers + + 2005-01-21 KLM + + * Subcommands are not optional anymore; updated the description + of CAP and the ABNF to reflect this. + + * More than one modifier may precede a capability name. + + +Mitchell, et al. Expires September 5, 2005 [Page 25] +Internet-Draft IRC CAP March 2005 + + * Move ABNF for capmod into the "Capability Modifiers" section. + + * Fix a few minor grammatical errors (I think). + + * Note that capability names may be preceded by modifiers in the + first form of ACK. + + * Remove an unnecessary "MAY" in documentation for the third + usage of ACK. + + * Explicitly note in the ABNF for NAK that the parameter is an + opaque repeat of at least the first 100 characters of the + argument to REQ. + + * CLEAR may result in more than one ACK. + + * Clarify the language of what composes a capability name. + + * Add missing </figure>. + + * ACK subcommand should be sent in response to ACK with ack + modifier as soon as possible... + + * Allow disable modifier in LIST, but only in conjunction with an + ack modifier. + + * The ack modifier may also show up in an LS response; rewrote + the final paragraph to indicate that and clarify the language. + + * Add "Client" to the title in the appropriate place... + + * The "capability" rule in the ABNF got changed to "capab" for + brevity. + + * Update "date" to be current. + + 2005-01-22 LH + + * Clarify a client must not act upon an ACK spread across + multiple lines until it receives the final ACK of the set. + + 2005-01-23 KLM + + * Bump version number in preparation for any suggested edits... + + + +Mitchell, et al. Expires September 5, 2005 [Page 26] +Internet-Draft IRC CAP March 2005 + + 2005-01-26 LH + + * Clarify a server also must not change capabilities until its + finished sending its ACKs. + + 2005-01-27 KLM + + * Acknowledge Aaron Wiebe as participating. + + 2005-03-01 LH + + * Add examples on sticky modifiers, the removal modifier and the + sticky modifier. + + 2005-03-07 KLM + + * Submit second draft... + + + + + + + + + + + + + + + + +Mitchell, et al. Expires September 5, 2005 [Page 27] +Internet-Draft IRC CAP March 2005 + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + +Mitchell, et al. Expires September 5, 2005 [Page 28] |