Network Working Group E. Brocklesby Internet-Draft September 12, 2002 Expires: March 13, 2003 IRC Command Prefix Capability draft-brocklesby-irc-usercmdpfx-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 March 13, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo presents a method for a client to prefix commands sent to an IRC (Internet Relay Chat) server with a label, in order to match server replies against commands previously sent, without having to keeping excessive state on the server connection. It is a primary goal to implement this in a way which is completely backwards- compatible with existing IRC servers. Brocklesby Expires March 13, 2003 [Page 1] Internet-Draft IRC Command Prefix Capability September 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Outline of the protocol . . . . . . . . . . . . . . . . . . . 3 3. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Impact on the server-server protocol . . . . . . . . . . . . . 4 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Interaction with remote commands . . . . . . . . . . . . . . . 5 7. Capability negotiation . . . . . . . . . . . . . . . . . . . . 6 7.1 Draft IRC Capability proposal . . . . . . . . . . . . . . . . 6 7.2 RPL_ISUPPORT (005) numeric . . . . . . . . . . . . . . . . . . 6 7.3 Ad-hoc protocol detection . . . . . . . . . . . . . . . . . . 7 7.4 Preferred negotiation method . . . . . . . . . . . . . . . . . 7 8. New numerics . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1 ERR_REMOTEPFX (525) . . . . . . . . . . . . . . . . . . . . . 8 8.2 ERR_PFXUNROUTABLE (526) . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Unsolved problems and other considerations . . . . . . . . . . 8 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 Brocklesby Expires March 13, 2003 [Page 2] Internet-Draft IRC Command Prefix Capability September 2002 1. Introduction 1.1 Motivation Currently, interaction between the IRC client and the server requires the client to keep an amount of state regarding the current connection. For example, caching of other client's usernames and hosts by the client requires that it request a listing of channel members (via the WHO command) and process the reply. In order to prevent misinterpreting WHO requests by the user, the client must keep state on the order of WHO commands which have been sent to the server, and match each received reply to a command on the queue. This is prone to error, and does not gracefully handle losing the state of the queue. This memo proposes an alternative method for tracking the state of commands sent to the server; it is not specific to the WHO command, but may be applied to any command. 1.2 Terminology Original IRC protocol: The original IRC protocol as described in RFC 1459 [5]. Protocol negotiation: The CAPAB protocol for negotiating capabilities between the server and client is defined in draft-baudis-irc- capab-00d [1]. 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 [3]. The ABNF syntax used in this document is defined in RFC 2234 [4]. The phrase "keeping state" is used in this document to mean storing information in the client about the state of the connection to the server; for example, commands for which it is expecting replies. 2. Outline of the protocol The command prefix proposal allows a client to prefix each command sent to the server with a label, followed by the actual command. The server will then use this prefix when sending replies generated by this command to the client. An example session might be: Client --> "*W001 WHO #epic" Server <-- "*W001 :irc.ipv6.homelien.no 352 larne #epic chady irc.concentric.net irc.concentric.net chady H*@ :5 Moo!" Brocklesby Expires March 13, 2003 [Page 3] Internet-Draft IRC Command Prefix Capability September 2002 Server <-- "*W001 :irc.ipv6.homelien.no 315 larne #epic :End of /WHO list." Client --> "*T001 TIME" Client --> "*J001 JOIN #testing123" Server <-- "*T001 :irc.ipv6.homelien.no 391 larne irc.ipv6.homelien.no :Thursday September 12 2002 -- 01:54:19 +02:00" Server <-- "*J001 :larne!ejb@ipng-uk-gw1-gif1-int.ipv6.hades.skumler.net JOIN :#testing123" Server <-- "*J001 :irc.ipv6.homelien.no MODE #testing123 +nt" Server <-- "*J001 :irc.ipv6.homelien.no 353 larne = #testing123 :@larne" Server <-- "*J001 :irc.ipv6.homelien.no 366 larne #testing123 :End of /NAMES list." Client --> "QUIT" Server <-- "ERROR :Closing Link: ipng-uk-gw1-gif1-int.ipv6.hades.skumler.net (Client Quit)" The client is therefore able to determine exactly which request generated the replies it receives. The client and server should negotiate to determine whether support for command prefixes is available; this process is described in section 7. 3. Compatibility Because the command prefix capability is negotiated by the client and server, it will only be used when both the server and client agree to support it. This memo therefore does not introduce any incompatible changes to the IRC protocol. 4. Impact on the server-server protocol While the command prefix proposal allows remote prefixes, which would presumably require a change in the server-server protocol used by the IRC server software to communicate, the author does not believe that it is beneficial to the IRC community to attempt to define any aspect of the server protocol. Therefore this memo does not address the server-server protocol. 5. Message Format Any command sent to the server by the client may be proceeded by a prefix token, followed by a single space. It is not required that the client sends a prefix for a command. The ABNF representation of a prefix is: prefix = "*" 1*10alnum alnum = ALPHA / DIGIT Brocklesby Expires March 13, 2003 [Page 4] Internet-Draft IRC Command Prefix Capability September 2002 An asterisk was chosen to introduce the prefix because it is not a valid character in this position under normal circumstances, and thus no ambiguity is introduced in the prefix message. This prefix should be present at the start of the line sent to the server, and the command should follow the prefix unchanged. The prefix must be followed by exactly one space character (ASCII 0x20). When the server receives a command from a client with a prefix present, it MUST prefix all replies (both numerics and commands) generated by that command with the prefix the client specified. The returned prefix shall have the same form as that sent by the client; that is, it shall occur at the beginning of the line, and should be separated from the reply by exactly 1 space character. The rest of the reply shall follow on the same line as the prefix as normal. If the client sends a prefix which has an invalid format, for example it is over 10 characters in length, the server should ignore the prefix, and process the command as if the prefix was not provided. The server MUST NOT send a prefix to replies when the client did not specify a prefix in the command generating the reply. If the client receives a prefix which it was not expecting -- for example, it did not send a command with a corresponding prefix -- it should treat the message as if it did not contain a prefix. It is expected that this could occur during remote queries where the client changes its nickname before the reply is received. Note, however, that the client should not use presence of an unexpected prefix to indicate misdelivery of a message. 6. Interaction with remote commands Unless the server indicates that it allows the use of prefixes for remote commands, the client should not send a prefix for a command which it believes will be executed remotely (that is, forwarded to another server for processing). If the server does not support prefixes for remote commands, yet receives a prefixed command from a client that would ordinarily be executed remotely, it MUST NOT forward or execute the command. Instead, it should return the numeric ERR_NOREMOTEPFX (525), which has two arguments, the client's nickname and a descriptive text. This reply MUST be delivered with the prefix supplied by the client for the original message. If the server does support remote prefixes, the command should be forwarded as normal, along with the prefix. Any replies generated in response to this command, whether from the local server, the target (remote) server or any intermediate server forwarding the command, MUST contain the prefix specified by the client. Brocklesby Expires March 13, 2003 [Page 5] Internet-Draft IRC Command Prefix Capability September 2002 If the message is unable to be delivered to the target server with the prefix intact, the command MUST NOT be executed by any server. Instead, the server which is unable to forward the message should reply to the client with an ERR_PFXUNROUTABLE (526) numeric. This reply MUST be delivered with the prefix supplied by the client for the original message. Note that the server should take all reasonable measures to ensure that an error message is delivered to the client in the case where a prefixed message cannot be delivered. However, it is sometimes unavoidable that messages will be lost in transit, and never arrive. The client therefore SHOULD NOT rely on a reply to any remote prefixed command being delivered. 7. Capability negotiation The client should not send command prefixes to the server unless the server has indicated that it understands them. Three methods are described below for this process. 7.1 Draft IRC Capability proposal The client and server may negotiate support for command via the draft proposal for IRC capability negotiation described in draft-baudis- irc-capab-00d [1], in which case the the capability tokens USERCMDPFX and USERCMDPFXREMOTE may be used. It is recommended that the server allow the client to disable command prefix support at any point during the connection, via the '-' prefix described in the CAPAB specification; however, this is not a requirement. The token USERCMDPFX should be used to negotiate local (non- forwarded) prefix commands, and the token USERCMDPFXREMOTE for remote prefixed commands. The client MUST NOT request USERCMDPFXREMOTE without USERCMDPFX, and the server MUST NOT advertise USERCMDPFXREMOTE without USERCMDPFX. In either of these cases, the lack of USERCMDPFX should be treated as if USERCMDPFXREMOTE was also not available. A value MUST NOT be specified for the USERCMDPFX or USERCMDPFXREMOTE tokens. If the client specifies a value, the server should refuse to honour the capability request via the NAK response. If only the request for USERCMDPFXREMOTE is in error, the server SHOULD still honour USERCMDPFX. 7.2 RPL_ISUPPORT (005) numeric Alternatively, the server may advertise to the client that it supports command prefixes via the RPL_ISUPPORT numeric. This numeric Brocklesby Expires March 13, 2003 [Page 6] Internet-Draft IRC Command Prefix Capability September 2002 is non-standard, but is widely implemented by both servers and clients to indicate server protocol extensions. In this case, the ISUPPORT token USERCMDPFX should be sent by the server to indicate that it supports local (non-forwarded) command prefixes. If the server additionally supports remote prefixes, it should advertise this via the ISUPPORT token USERCMDPFXREMOTE. The RPL_ISUPPORT numeric is documented in http://www.irc.org/ tech_docs/005.html [2]. 7.3 Ad-hoc protocol detection If neither ISUPPORT nor CAPAB support is available, the client may attempt to determine whether the command prefix system is available via an ad-hoc method. In order to detect whether prefixes are available, the client should send an invalid command, specified with a prefix. If the server replies with a numeric ERR_UNKNOWNCOMMAND (421), with the prefix as the second argument, then the client should assume that prefixes are not supported by this server. If the server replies with a numeric ERR_UNKNOWNCOMMAND, with the invalid command specified by the client as the second argument, and the client-supplied prefix with the message, then the client may assume that the server does support command prefixes. Given any other response by the server, including none, the client should assume that the server does not support command prefixes, unless this is negotiated via a method other than ad-hoc protocol detection at a future time during the connection. 7.4 Preferred negotiation method It is as yet uncertain which is the preferred method to negotiate support for command prefixes. While the CAPAB system might be preferable, as it is extensible and will hopefully become an Internet standard, RPL_ISUPPORT is already implemented in both clients and servers, and may well lead to faster take-up of the command prefix system. It is uncertain whether the flexibility of the CAPAB system is required for this application. The ad-hoc protocol detection method should be considered the least desirable solution; it violates the existing IRC protocol, and is more prone to failure than either of the two alternatives. 8. New numerics This memo introduces two new numerics. Brocklesby Expires March 13, 2003 [Page 7] Internet-Draft IRC Command Prefix Capability September 2002 8.1 ERR_REMOTEPFX (525) " :Prefixed command may not be executed remotely." The ERR_REMOTEPFX reply is sent by the server when a command with a prefix would have been forwarded to another server for remote execution. This reply MUST contain a client-specified prefix, and indicates that the command was not executed. If the client wishes to execute the command (with no prefix attached to the replies), it should resend the command without the prefix. 8.2 ERR_PFXUNROUTABLE (526) " :Remote prefixed command could not be delivered." The ERR_PFXUNROUTABLE reply is sent by the server when a command with a prefix which was due to be forwarded to another server for execution could not be delivered. This reply MUST contain the prefix specified by the client for the original message. 9. Security Considerations This memo does not raise any security considerations. 10. Unsolved problems and other considerations There are still a number of problems with the current proposal. 1. Neither the CAPAB system nor the RPL_ISUPPORT numeric have been standardised; it is therefore not possible to depend on them in an Internet standards document. This leaves only the undesired ad- hoc protocol detection method. It is hoped that the CAPAB proposal will be standardised in future; however, until then it is not clear how this problem can be solved. 2. The use of both USERCMDPFX and USERCMDPFXREMOTE in the CAPAB system is considered substandard. It would be preferable for the client to be able to request USERCMDPFX only, and the server either NAK the request, or ACK USERCMDPFX=LOCAL (for only local prefixes), or USERCMDPFX=REMOTE (for both local AND remote prefixes). Discussion is ongoing with the author of the CAPAB draft proposal to solve this problem. 11. Acknowledgments The author gratefully acknowledges the contributions of Jeremy Nelson, Daniel C. Sobral, Bill Fenner, Kurt Roeckx, and Petr Baudis Brocklesby Expires March 13, 2003 [Page 8] Internet-Draft IRC Command Prefix Capability September 2002 in the preparation of this document. References [1] Baudis, P., "IRC protocol and capabilities selection", September 2002. [2] Roeckx, K., "The 005 numeric", September 2002. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [5] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993. Author's Address Edward Brocklesby 57 Williamson Way Oxford OX4 4TU UK Phone: +44 1865 452230 EMail: ejb@hades.skumler.net Brocklesby Expires March 13, 2003 [Page 9] Internet-Draft IRC Command Prefix Capability September 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. Brocklesby Expires March 13, 2003 [Page 10]