IRC Client Capabilities Extension draft-mitchell-irc-capabilities-02 Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 2, 2005. Copyright Notice Copyright © 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 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [1]. Table of Contents 1. Introduction 2. Problems to be Solved 3. The CAP Command 3.1. CAP LS 3.2. CAP LIST 3.3. CAP REQ 3.4. CAP ACK 3.5. CAP NAK 3.6. CAP CLEAR 3.7. CAP END 4. Capability Negotiation 5. Capabilities 5.1. Capability Modifiers 6. IANA Considerations 7. Security Considerations 8. Acknowledgments 9. References Appendix A. Examples Appendix B. ABNF Description of Capabilities Appendix C. ChangeLog § Authors' Addresses § Intellectual Property and Copyright Statements 1. Introduction The IRC protocol, as originally documented by RFC 1459 (Oikarinen, J. and D. Reed, “Internet Relay Chat Protocol,” May 1993.) [2] and updated by RFC 2812 (Kalt, C., “Internet Relay Chat: Client Protocol,” April 2000.) [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. 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. 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. (Capability Modifiers) The subcommands defined for CAP are: 1. LS (CAP LS) 2. LIST (CAP LIST) 3. REQ (CAP REQ) 4. ACK (CAP ACK) 5. NAK (CAP NAK) 6. CLEAR (CAP CLEAR) 7. END (CAP END) The LS (CAP LS), LIST (CAP LIST), REQ (CAP REQ), ACK (CAP ACK), and NAK (CAP NAK) 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 (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [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 (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [4], and servername and nick are as designated in section 2.3.1 of RFC 1459 (Oikarinen, J. and D. Reed, “Internet Relay Chat Protocol,” May 1993.) [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 (CAP END) subcommand is received. ABNF (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [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 (CAP LS) 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 (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [4] description of the LIST subcommand: listcmd = "LIST" listcmd =/ "LIST" SP ":" listcmd =/ "LIST" SP [ "*" SP ] caplist 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 (CAP END) subcommand is received. Servers MUST respond to a REQ command with either the ACK (CAP ACK) or NAK (CAP NAK) 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 (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [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 (CAP REQ) subcommand; by the server to acknowledge a CLEAR (CAP CLEAR) 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 (CAP LS) and LIST (CAP LIST). 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 (CAP REQ) 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 (Capability Modifiers). The second usage, acknowledging a CLEAR (CAP CLEAR) subcommand, is similar to the first usage. When a CLEAR (CAP CLEAR) subcommand is 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 (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [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 (CAP REQ) 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 (CAP REQ) subcommand which triggered the NAK. ABNF (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [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 (CAP ACK) subcommands indicating the capabilities being deactivated. ABNF (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [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 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 (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [4] description of the END subcommand: endcmd = "END" 4. Capability Negotiation Clients implementing this extension SHOULD take one of the following three actions upon initial connection to a server: * Issue an LS (CAP LS) subcommand (with an empty capability list) to solicit a list of supported capabilities from the server; * Issue the REQ (CAP REQ) subcommand to request a particular set of capabilities without knowing what capabilities the server supports or if it supports the capabilities extension; or * Issue the END (CAP END) 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 (Oikarinen, J. and D. Reed, “Internet Relay Chat Protocol,” May 1993.) [2] for more details about the client registration procedure. If a client issues the LS (CAP LS) or REQ (CAP REQ) subcommands during the client registration procedure, a server implementing the capabilities extension MUST NOT complete the client registration until the client issues the END (CAP END) subcommand. A client that sees a RPL_WELCOME (001) numeric response before it sends CAP END (CAP END) 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 (CAP END) subcommand SHALL have no effect once client registration has been completed. 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 (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [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 (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [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 (CAP REQ) and ACK (CAP ACK) subcommands. A server MUST use the disable modifier in the ACK (CAP ACK) subcommand when disabling a capability, or in conjunction with a ack modifier in the LIST (CAP LIST) 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 (CAP ACK), LIST (CAP LIST) and LS (CAP LS) 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 (CAP ACK) 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 (CAP ACK) and LIST (CAP LIST) subcommands to indicate capabilities that require an ACK (CAP ACK) subcommand from the client to be fully enabled or disabled. Servers MUST also use the ack modifier in the response to an LS (CAP LS) subcommand to indicate capabilities which will require ACK (CAP ACK) subcommands from the client. Clients MUST NOT use the ack modifier, but SHOULD issue the ACK (CAP ACK) subcommand as soon as possible after receiving an ACK (CAP ACK) or REQ (CAP REQ) subcommand from the server that contains a capability marked with the ack modifier. In ABNF (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [4] notation: dismod = "-" stickymod = "=" ackmod = "~" capmod = dismod / stickymod / ackmod 6. IANA Considerations The standardized capability name space shall be managed by IANA in accordance with the description of capability names in Section 5 (Capabilities). In particular, any name not containing the period character ('.') must be specified by an RFC. 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. 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 (TXT, HTML, XML). [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., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” RFC 2234, November 1997 (TXT, HTML, XML). [5] Bradner, S., “IETF Rights in Contributions,” BCP 78, RFC 3978, 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 [...] A client requesting a capability that requires an ACK (CAP ACK) 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 (CAP ACK) subcommand from the client to be enabled and disabled, using the LIST (CAP LIST) 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 Appendix B. ABNF Description of Capabilities This section summarizes the ABNF (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [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 = "=" ackmod = "~" capmod = dismod / stickymod / ackmod 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 (The CAP Command). * Clarified that requirements of Section 3 (The CAP Command) only apply to clients and servers implementing capabilities. * Substitution of "performed" for "done" in Section 3.5 (CAP NAK) * Added LIST (CAP LIST) subcommand to provide a mechanism to query active capabilities. * Added reference to RFC 2812 (Kalt, C., “Internet Relay Chat: Client Protocol,” April 2000.) [3]. * Moved Examples (Examples) section into the back matter. * Corrected Perry Lorier's email address. * Added this ChangeLog section. * Corrected typo in Section 3.7 (CAP END): "sent" for "send". * Added elements to enhance readability. * Changed to non-compact form. * Changed anchor for Section 5 (Capabilities) to "capabilities" from "caps" to reduce possible confusion. * Revise last sentence of first paragraph of Section 2 (Problems to be Solved) to remove redundancy. * Revise last sentence of second paragraph of Section 2 (Problems to be Solved) * Added email addresses for Lee H and Beeth; updated contact information for Isomer. 2004-12-17 KLM * Augmented description of CAP command and subcommands with ABNF description. * Revised Section 5 (Capabilities) 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 (IANA Considerations) to reflect change in capability name space. * Added Appendix B (ABNF Description of Capabilities) 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 (CAP LIST) to LSL and Section 3.1 (CAP LS). * Section 3.3 (CAP REQ) 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 (CAP ACK) * Relax the requirement for a client that understands capabilities to send CAP END in Section 3.7 (CAP END) 2004-12-19 KLM * Converted a number of common xrefs into internal entities to simplify the text. * Inserted some white space to make the section a bit more readable. * Added the keyword "Protocol". * Added the term "NOT RECOMMENDED" to the note on "Requirements Language". * Moved LIST (CAP LIST) 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 (CAP LIST) also in LSL when talking about sending more than one LSL subcommand. * Clarify language in Section 3.1 (CAP LS) a little bit. * Substitute "set of capabilities" for "list of capabilities" in Section 3.3 (CAP REQ). * Fix minor typo in preamble to ABNF description of NAK (CAP NAK) subcommand: substitution of "ACK" for "NAK". * Add note about servers ignoring END (CAP END) after client registration. * Fix minor typo in preamble to ABNF description of LIST (CAP LIST) subcommand: substitution of "END" for "LIST". * Added Section 4 (Capability Negotiation) discussing capability negotiation. * Add ".xml" extension to include files in references section. * Simplification of preamble of first example (Examples). * Add 'type="ABNF"' to sections so that they can be extracted and used to create the abnf.xml now included in Appendix B (ABNF Description of Capabilities). * It's now RFC 3667, not RFC 2026... 2004-12-27 KLM * Minor wording changes to second paragraph of Section 1 (Introduction) * Minor wording change to first paragraph of Section 2 (Problems to be Solved) * Minor wording changes to first paragraph of Section 3 (The CAP Command); remove redundant note about the IRC colon sentinel. * Change a "must" to a "MUST" in Section 3.4 (CAP ACK); note that capability list may be truncated if it would otherwise exceed the 512 character limit. * In Section 3.5 (CAP NAK), note that capability list may be truncated if it would otherwise exceed the 512 character limit. * Remove redundant line about ignoring END (CAP END) commands after registration. * Correct spelling of "acknowledgments". * Empty 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 . * Remove deliberate page break after section. * Reorder authors section to consolidate elements for everyone. * Drop abbreviation for Undernet. * Expand Section 7 (Security Considerations) 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 (CAP LS) documentation 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 (CAP REQ) ("acceptance of or rejection of"--strike first "of"). * Clarify that sticky capabilities cause a REQ (CAP REQ) to be NAK (CAP NAK)ed. * Mark the third case of an ACK (CAP ACK) with an explicit indicator that it's the third case... * Strike redundant mention of not suspending client registration in documentation for END (CAP END). 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. * 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 . * 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... 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... * Prepare third draft, just in case... 2005-11-04 KLM * RFC 3667 is now superseded by RFC 3978 (Bradner, S., “IETF Rights in Contributions,” March 2005.) [5] 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 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/ 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 © 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.