INTERNET-DRAFT Simon Butcher Expires April 2004 Alien Internet Services October 2003 Uniform Resource Locator Schemes for Internet Relay Chat Servers <draft-butcher-irc-url-00.txt> Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Distribution of this document is unlimited. Comments should be sent to the author. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document specifies two URL (Uniform Resource Locator) schemes, using the URI (Uniform Resource Indicator) names "irc" and "ircs", for the location of IRC (Internet Relay Chat) servers. These URLs allow for easy location of an IRC server, optionally also specifying an IRC channel to join or person to contact upon connection. Butcher Expires April 2004 [Page 1]
INTERNET-DRAFT URL Schemes for IRC October 2003 1. Introduction Since its introduction, Internet Relay Chat (IRC) has become widely known and used within the Internet Community as a real-time chat medium. IRC networks are steadily growing larger, not only with regards to the number of regular uses, but also the number of channels and servers required to support the demand. Due to the nature of IRC as a simple real-time chat service, it has been known to be used for a wide variety of uses such as software support, job interviews, and of course just for a casual chat. While IRC is progressing, the need for an appropriate Uniform Resource Locator (URL) scheme has become apparent. Applications for such a scheme would range quite widely, including IRC network server lists on a website, software support contact details, or even a meeting location with an e-mail including a specific IRC channel. 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 [RFC2119]. In this document, the term "client" is defined as the IRC client software, and the term "user" is the end-user of that software. 2. URL Definition An IRC URL begins with either the Uniform Resource Identifiers (URIs) "irc" or "ircs", denoting normal and secured connections respectively. Normal sessions are via the existing transport, as defined in [RFC2812], and secured sessions are the same, only via a secure transport layer such as [TLS] (or [SSL], the predecessor to TLS). The URL scheme for IRC follows the Generic URL Syntax, defined in [RFC2396]. Butcher Expires April 2004 [Page 2]
INTERNET-DRAFT URL Schemes for IRC October 2003 2.1. ABNF Syntax The following is the definition for an IRC URL in [ABNF] grammar: ircURL = type "://" location "/" [ channel ] [ options ] type = "irc" / "ircs" location = [ authinfo "@" ] hostport ; See Section 3.2.2 of [RFC2396] for ; the definition of 'hostport'. authinfo = [ nickname *2( ";" nickname ) ] [ ":" password ] nickname = ALPHA / DIGIT / %x23-25 / %x2A-2F ; Further restrictions may apply upon ; connection, depending on the server. ; Some common nickname characters must be ; encoded, as per recommendations in Section ; 2.4.3 in [RFC2396]. password = ALPHA / DIGIT / %x23-24 / %x2A-2F / ";" / "=" / "?" channel = ALPHA / DIGIT / %x23-24 / %x2A-2F ; See [RFC2811] for the definition of ; a channel. options = "?" option *( "&" option ) option = optname [ "=" optvalue ] optname = ALPHA optvalue = ALPHA / DIGIT / %x23-24 / %x2A-2F / ":" / ";" / "@" ; Other characters (such as [Unicode] ; characters in [UTF-8]) must be escaped ; as per rules in Section 2.2.5 of [RFC2718]. ; See also Section 4 of this document. The use of the "%" character (%x25) is used to facilitate escaped characters. Should the "%" character itself be needed, it must be escaped, such as "%25". The use of spaces, escaped (%20) or otherwise, SHOULD NOT be allowed for channel names or nicknames, as they are currently unsupported by existing IRC protocols. Butcher Expires April 2004 [Page 3]
INTERNET-DRAFT URL Schemes for IRC October 2003 2.2. Authentication Multiple nicknames MAY be specified, and pending any error or lack of availability, the IRC client software MAY request the next nickname in the list. Clients MUST NOT accept any more than three (3) nicknames, and any more nicknames specified MUST be ignored to curtail potential abuse. Clients may only attempt to use alternative nicknames given during the one connection. Clients MUST NOT reconnect to the server to try alternative nicknames. Should the client run out of alternative nicknames to try, but the server is willing to accept another attempt, the client MAY either disconnect from the server and show the user an error message, or prompt the user for another nickname to try. The use of passwords is not recommended, as they present a significant security problem. They are allowed purely for convenience. Users of the password field must be aware of the security issues discussed in Section 6 of this document. 2.3. Server Ports Special consideration must be given to URLs without ports specified. Almost all IRC servers are contactable on a variety of standard ports as allocated by the IANA. Should an IRC URL be specified without a port, a client SHOULD try a number of standard ports: - For the "irc" URI, it is RECOMMENDED that the server is attempts connection to the ports 194, 6665, 6666, 6667, 6668 and 6669. - For the "ircs" URI, it is RECOMMENDED that the default port used is 994. User-space ports (those above port 1023) may have questionable authenticity, and SHOULD NOT be used unless explicitly specified. Port numbers shown here are in decimal, and have been assigned by the IANA. Butcher Expires April 2004 [Page 4]
INTERNET-DRAFT URL Schemes for IRC October 2003 2.4. Channels For compatibility with older implementations, and to allow simplification of the specification, channels MAY be specified without the use of the "channel" option detailed in Section 2.5.1. Only one channel can be specified, and this facility has the same functionality as the "channel" option. See Section 3 of this document for examples of the equivalence between this and the "channel" option in Section 2.5.1. 2.5. Additional Options Additional options may be added to control what action the client software MAY take following connection to the IRC server. Unsupported options should simply be ignored. These options listed here may be expanded on at a later date by updated RFC's. 2.5.1. The "channel" Option This instructs the client to join the specified channel, allowing the user to participate in discussions within the channel. The value given with the channel option is a channel name, and optionally a "key" (see Section 4.2.10 of [RFC2811]). Its value can be defined in [ABNF] as follows: optvalue = name [ "," key ] See Section 2.1 of this document for information on acceptable characters. The "," character is not allowed in either the channel name, or key, unless it is escaped ("%x2C"). The number of channels which can be joined at once is normally restricted by the server, but no hard-limit is given by this specification as this is a matter of individual server policy. As such, multiple "channel" options may be given. An automated message MUST NOT be sent to the channel upon joining it. It is NOT RECOMMENDED to use the channel key feature. Please see Section 6 of this document. If a key is required to join a channel, and one is not given, the IRC client MAY wish to prompt the user for the key. Butcher Expires April 2004 [Page 5]
INTERNET-DRAFT URL Schemes for IRC October 2003 2.5.2. The "query" Option For each "query" option, the client is requested to open some interface where by users may type a message to the given query target. For example, the client may open up a window where messages may be typed to, and received from the target. Some clients may not have the ability to open up a specific window or dialogue box. These clients MAY prompt the user for a message to be sent to the target, or otherwise this option MAY be ignored and hence unsupported. The option value is the same as the message target value specified in Section 3.3.1 of [RFC2812], except that the client MUST only accept one target. Multiple targets per "query" option MUST NOT be accepted, and the entire query MUST be considered invalid and ignored. A message MUST NOT be automatically sent to the target, simply an interface created to allow the user to send a message to the target. The IRC client software MAY wish to check the availability of the target prior to opening the interface if inclined to do so, however any method of testing the availability MUST NOT generate any automatic message being sent to the target. Multiple targets MAY be referenced with multiple query options, however in order to reduce the potential for abuse, it is RECOMMENDED that additional query options are ignored. There are valid reasons for having multiple targets, and abuse is minimal as no messages are sent to the targets. 3. Examples While examples of every situation cannot be shown here because of space considerations, the following examples provide a rough overview of how the IRC URL can be used. <irc://irc.undernet.org/> In its simplest form, the above complete URL can be used to direct a client to a specific IRC server, which in this case is "irc.undernet.org". The client should presume to use default port settings. <irc://pickle@irc.efnet.org:6667/> Butcher Expires April 2004 [Page 6]
INTERNET-DRAFT URL Schemes for IRC October 2003 The above URL specifies that the IRC client should try to connect to "irc.efnet.org" on the port 6667, rather than use whatever is considered the default. It also tells the IRC client it should try to use a nickname of "pickle", if it is available. <irc://%C4%B0dil;idil@irc.austnet.org/> This shows a properly [UTF-8] encoded URL, specifying the nickname Idil (with the first character being a Turkish Latin capital letter "I" with a dot above it, [Unicode] codepoint U+0130). Failing that, the second nickname, "idil", may be used if the first one is rejected, perhaps by an older IRC server. <irc://pickle:secret@172.16.0.12:194/> The above URL will instruct the IRC client to connect to a server with the address 172.16.0.12, which is an IRC server that is presumably password protected. The client should request to use the nickname "pickle", with the password "secret" to authenticate the session to the remote server. This URL also enforces the standard IRC port, 194, and will stop IRC clients from hunting for ports. <irc://irc.ircnet.net/#worldchat> <irc://irc.ircnet.net/%23worldchat> <irc://irc.ircnet.net/?channel=%23worldchat> All three of these URLs connects to the IRCnet network, and will join the client to the channel "#worldchat" upon connection. <irc://irc.alien.net.au/?query=pickle&channel=%2Bprivate,foo> This will connect to the server "irc.alien.net.au" and will provoke the client to open up a window (or similar) associated with sending messages to the nickname 'pickle'. It will also join the channel "+private" using the channel key "foo". <irc://irc.austnet.org/%23melbourne?channel=%23sydney> This will connect to AUSTnet and join two channels, "#melbourne" and "#sydney". <irc://irc.undernet.org/?query=pickle%25butcher.id.au> This will open a dialogue box prepared to send a message to "pickle%butcher.id.au". Please refer to Section 3.3.1 of [RFC2812] for more details. Butcher Expires April 2004 [Page 7]
INTERNET-DRAFT URL Schemes for IRC October 2003 4. Internationalisation Considerations With the inevitable adoption of [Unicode] on IRC, and indeed the Internet as a whole, URLs MUST be encoded using the [UTF-8] character set, with potentially unsafe octets encoded using %HH notation (where HH is a hexadecimal value), as per Section 2.2.5 of [RFC-2718]. For example, the word for "alias" in Japanese, using Unicode code- points, is U+5225 U+540D. Correctly encoded, this would appear in the URL as: "%E5%88%A5%E5%90%8D". An example of this use in action can be found in Section 3. 5. Interoperability Considerations Many existing implementations fail to acknowledge the correct use of the generic URL syntax defined in [RFC2396], but continue to use the format regardless. Some implementations do not take into consideration the use of prefix characters on channels names, as defined by [RFC2811], and therefore cannot correctly reference channels appropriately. Software SHOULD NOT guess the channel type, or hence the channel's prefix character, unless the probability of an accurate guess is 100% (for example, the server only supports one type of channel). Some current implementations will need slight modification to accept the extended format defined in this specification, however most implementations which parse the URL in a standard form will continue to work. The majority of incongruities are simply caused by the problem of developers ignoring RFC-2396. The use of the channel name without specifying the channel option is to both maintain compatibility with the existing implementations, whilst providing an abbreviated form, similar to the design of the "mailto:" scheme defined by [RFC2368]. 6. Security Considerations Security problems arise only when the authentication portion of the URL is used, or channel keys are given. While the use of the password/key extensions is considered to be rare, they have been included for completeness. As the passwords and channel keys are unfortunately in clear-text, Butcher Expires April 2004 [Page 8]
INTERNET-DRAFT URL Schemes for IRC October 2003 any user using the IRC URL should be aware of obvious insecurities. Furthermore, it is RECOMMENDED that user software does not automatically initiate the connection specified by the URL without the knowledge and consent of the user. To do so would open the implementation up to a variety of malicious activities including, but not limited to, the purposes of direct advertising or channel advertising (also known as "spam") by way of pop-ups. When connecting using a secure connection ("ircs://"), user-space ports (those above port 1023) SHOULD NOT be used automatically, as their authority is questionable. If a secure connection cannot be established, the client MUST either give up, or prompt the user before attempting an insecure ("irc://") connection. Beyond this, there are security concerns with regards with associated protocols, including IRC and TLS, which MUST be taken into consideration, but are beyond the scope of this document. 7. Acknowledgments Thanks must go to Khaled Mardam-Bey for his early implementation in his software, "mIRC", which provided the inspiration to clarify the specification. I would also like to acknowledge the members of the IRC development community who encouraged me to publish this draft, after more than 18 months of pretermission. Butcher Expires April 2004 [Page 9]
INTERNET-DRAFT URL Schemes for IRC October 2003 8. References [ABNF] Crocker, D., and Overell, P., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2368] Hoffman, P., Masinter, L., Zawinski, J., "The mailto URL scheme", RFC 2368, July 1998. [RFC2396] Berners-Lee, T, Fielding, T., Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., "Guidelines for new URL Schemes", RFC 2718, November 1999. [RFC2811] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000. [RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2819, April 2000. [SSL] Hickman, K., "The SSL Protocol", Netscape Communications Corp., February 9, 1995. [TLS] Dierks, T. and Allen, C., "The TLS Protocol Version 1.0", RFC 2246, January 1999. [Unicode] The Unicode Consortium. The Unicode Standard, Version 4.0.0, (Reading, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1). [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. Butcher Expires April 2004 [Page 10]
INTERNET-DRAFT URL Schemes for IRC October 2003 9. Author's Address Simon Butcher Alien Internet Services PO Box 7041 Croydon South VIC 3136 Australia Phone: +61-3-9879-8052 Fax: +61-3-9893-2793 Email: simonb@alien.net.au Document Expiration and Filename Please note that this is a draft document and it shall expire April 2004. Its filename is draft-butcher-irc-url-00.txt Butcher Expires April 2004 [Page 11]