idnits 2.17.1 draft-butcher-irc-url-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2003) is 7498 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-2718' is mentioned on line 309, but not defined ** Obsolete undefined reference: RFC 2718 (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2368 (Obsoleted by RFC 6068) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2718 (Obsoleted by RFC 4395) ** Downref: Normative reference to an Informational RFC: RFC 2811 -- Possible downref: Non-RFC (?) normative reference: ref. 'SSL' ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Simon Butcher 3 Expires April 2004 Alien Internet Services 4 October 2003 6 Uniform Resource Locator Schemes for 7 Internet Relay Chat Servers 8 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. Distribution of this document is 14 unlimited. Comments should be sent to the author. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document specifies two URL (Uniform Resource Locator) schemes, 35 using the URI (Uniform Resource Indicator) names "irc" and "ircs", 36 for the location of IRC (Internet Relay Chat) servers. These URLs 37 allow for easy location of an IRC server, optionally also specifying 38 an IRC channel to join or person to contact upon connection. 40 1. Introduction 42 Since its introduction, Internet Relay Chat (IRC) has become widely 43 known and used within the Internet Community as a real-time chat 44 medium. IRC networks are steadily growing larger, not only with 45 regards to the number of regular uses, but also the number of 46 channels and servers required to support the demand. 48 Due to the nature of IRC as a simple real-time chat service, it has 49 been known to be used for a wide variety of uses such as software 50 support, job interviews, and of course just for a casual chat. 52 While IRC is progressing, the need for an appropriate Uniform 53 Resource Locator (URL) scheme has become apparent. Applications for 54 such a scheme would range quite widely, including IRC network server 55 lists on a website, software support contact details, or even a 56 meeting location with an e-mail including a specific IRC channel. 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in [RFC2119]. 62 In this document, the term "client" is defined as the IRC client 63 software, and the term "user" is the end-user of that software. 65 2. URL Definition 67 An IRC URL begins with either the Uniform Resource Identifiers (URIs) 68 "irc" or "ircs", denoting normal and secured connections 69 respectively. Normal sessions are via the existing transport, as 70 defined in [RFC2812], and secured sessions are the same, only via a 71 secure transport layer such as [TLS] (or [SSL], the predecessor to 72 TLS). 74 The URL scheme for IRC follows the Generic URL Syntax, defined in 75 [RFC2396]. 77 2.1. ABNF Syntax 79 The following is the definition for an IRC URL in [ABNF] grammar: 81 ircURL = type "://" location "/" [ channel ] [ options ] 83 type = "irc" / "ircs" 85 location = [ authinfo "@" ] hostport 86 ; See Section 3.2.2 of [RFC2396] for 87 ; the definition of 'hostport'. 89 authinfo = [ nickname *2( ";" nickname ) ] [ ":" password ] 91 nickname = ALPHA / DIGIT / %x23-25 / %x2A-2F 92 ; Further restrictions may apply upon 93 ; connection, depending on the server. 94 ; Some common nickname characters must be 95 ; encoded, as per recommendations in Section 96 ; 2.4.3 in [RFC2396]. 98 password = ALPHA / DIGIT / %x23-24 / %x2A-2F / ";" / "=" / "?" 100 channel = ALPHA / DIGIT / %x23-24 / %x2A-2F 101 ; See [RFC2811] for the definition of 102 ; a channel. 104 options = "?" option *( "&" option ) 106 option = optname [ "=" optvalue ] 108 optname = ALPHA 110 optvalue = ALPHA / DIGIT / %x23-24 / %x2A-2F / ":" / ";" / "@" 111 ; Other characters (such as [Unicode] 112 ; characters in [UTF-8]) must be escaped 113 ; as per rules in Section 2.2.5 of [RFC2718]. 114 ; See also Section 4 of this document. 116 The use of the "%" character (%x25) is used to facilitate escaped 117 characters. Should the "%" character itself be needed, it must be 118 escaped, such as "%25". The use of spaces, escaped (%20) or 119 otherwise, SHOULD NOT be allowed for channel names or nicknames, as 120 they are currently unsupported by existing IRC protocols. 122 2.2. Authentication 124 Multiple nicknames MAY be specified, and pending any error or lack of 125 availability, the IRC client software MAY request the next nickname 126 in the list. 128 Clients MUST NOT accept any more than three (3) nicknames, and any 129 more nicknames specified MUST be ignored to curtail potential abuse. 131 Clients may only attempt to use alternative nicknames given during 132 the one connection. Clients MUST NOT reconnect to the server to try 133 alternative nicknames. 135 Should the client run out of alternative nicknames to try, but the 136 server is willing to accept another attempt, the client MAY either 137 disconnect from the server and show the user an error message, or 138 prompt the user for another nickname to try. 140 The use of passwords is not recommended, as they present a 141 significant security problem. They are allowed purely for 142 convenience. Users of the password field must be aware of the 143 security issues discussed in Section 6 of this document. 145 2.3. Server Ports 147 Special consideration must be given to URLs without ports specified. 148 Almost all IRC servers are contactable on a variety of standard ports 149 as allocated by the IANA. Should an IRC URL be specified without a 150 port, a client SHOULD try a number of standard ports: 152 - For the "irc" URI, it is RECOMMENDED that the server is attempts 153 connection to the ports 194, 6665, 6666, 6667, 6668 and 6669. 155 - For the "ircs" URI, it is RECOMMENDED that the default port used 156 is 994. User-space ports (those above port 1023) may have 157 questionable authenticity, and SHOULD NOT be used unless 158 explicitly specified. 160 Port numbers shown here are in decimal, and have been assigned by the 161 IANA. 163 2.4. Channels 165 For compatibility with older implementations, and to allow 166 simplification of the specification, channels MAY be specified 167 without the use of the "channel" option detailed in Section 2.5.1. 169 Only one channel can be specified, and this facility has the same 170 functionality as the "channel" option. See Section 3 of this 171 document for examples of the equivalence between this and the 172 "channel" option in Section 2.5.1. 174 2.5. Additional Options 176 Additional options may be added to control what action the client 177 software MAY take following connection to the IRC server. 178 Unsupported options should simply be ignored. 180 These options listed here may be expanded on at a later date by 181 updated RFC's. 183 2.5.1. The "channel" Option 185 This instructs the client to join the specified channel, allowing the 186 user to participate in discussions within the channel. 188 The value given with the channel option is a channel name, and 189 optionally a "key" (see Section 4.2.10 of [RFC2811]). Its value can 190 be defined in [ABNF] as follows: 192 optvalue = name [ "," key ] 194 See Section 2.1 of this document for information on acceptable 195 characters. The "," character is not allowed in either the channel 196 name, or key, unless it is escaped ("%x2C"). 198 The number of channels which can be joined at once is normally 199 restricted by the server, but no hard-limit is given by this 200 specification as this is a matter of individual server policy. As 201 such, multiple "channel" options may be given. 203 An automated message MUST NOT be sent to the channel upon joining it. 205 It is NOT RECOMMENDED to use the channel key feature. Please see 206 Section 6 of this document. If a key is required to join a channel, 207 and one is not given, the IRC client MAY wish to prompt the user for 208 the key. 210 2.5.2. The "query" Option 212 For each "query" option, the client is requested to open some 213 interface where by users may type a message to the given query 214 target. For example, the client may open up a window where messages 215 may be typed to, and received from the target. 217 Some clients may not have the ability to open up a specific window or 218 dialogue box. These clients MAY prompt the user for a message to be 219 sent to the target, or otherwise this option MAY be ignored and hence 220 unsupported. 222 The option value is the same as the message target value specified in 223 Section 3.3.1 of [RFC2812], except that the client MUST only accept 224 one target. Multiple targets per "query" option MUST NOT be 225 accepted, and the entire query MUST be considered invalid and 226 ignored. 228 A message MUST NOT be automatically sent to the target, simply an 229 interface created to allow the user to send a message to the target. 231 The IRC client software MAY wish to check the availability of the 232 target prior to opening the interface if inclined to do so, however 233 any method of testing the availability MUST NOT generate any 234 automatic message being sent to the target. 236 Multiple targets MAY be referenced with multiple query options, 237 however in order to reduce the potential for abuse, it is RECOMMENDED 238 that additional query options are ignored. There are valid reasons 239 for having multiple targets, and abuse is minimal as no messages are 240 sent to the targets. 242 3. Examples 244 While examples of every situation cannot be shown here because of 245 space considerations, the following examples provide a rough overview 246 of how the IRC URL can be used. 248 250 In its simplest form, the above complete URL can be used to direct a 251 client to a specific IRC server, which in this case is 252 "irc.undernet.org". The client should presume to use default port 253 settings. 255 257 The above URL specifies that the IRC client should try to connect to 258 "irc.efnet.org" on the port 6667, rather than use whatever is 259 considered the default. It also tells the IRC client it should try 260 to use a nickname of "pickle", if it is available. 262 264 This shows a properly [UTF-8] encoded URL, specifying the nickname 265 Idil (with the first character being a Turkish Latin capital letter 266 "I" with a dot above it, [Unicode] codepoint U+0130). Failing that, 267 the second nickname, "idil", may be used if the first one is 268 rejected, perhaps by an older IRC server. 270 272 The above URL will instruct the IRC client to connect to a server 273 with the address 172.16.0.12, which is an IRC server that is 274 presumably password protected. The client should request to use the 275 nickname "pickle", with the password "secret" to authenticate the 276 session to the remote server. This URL also enforces the standard IRC 277 port, 194, and will stop IRC clients from hunting for ports. 279 280 281 283 All three of these URLs connects to the IRCnet network, and will join 284 the client to the channel "#worldchat" upon connection. 286 288 This will connect to the server "irc.alien.net.au" and will provoke 289 the client to open up a window (or similar) associated with sending 290 messages to the nickname 'pickle'. It will also join the channel 291 "+private" using the channel key "foo". 293 295 This will connect to AUSTnet and join two channels, "#melbourne" and 296 "#sydney". 298 300 This will open a dialogue box prepared to send a message to 301 "pickle%butcher.id.au". Please refer to Section 3.3.1 of [RFC2812] 302 for more details. 304 4. Internationalisation Considerations 306 With the inevitable adoption of [Unicode] on IRC, and indeed the 307 Internet as a whole, URLs MUST be encoded using the [UTF-8] character 308 set, with potentially unsafe octets encoded using %HH notation (where 309 HH is a hexadecimal value), as per Section 2.2.5 of [RFC-2718]. 311 For example, the word for "alias" in Japanese, using Unicode code- 312 points, is U+5225 U+540D. Correctly encoded, this would appear in 313 the URL as: "%E5%88%A5%E5%90%8D". An example of this use in action 314 can be found in Section 3. 316 5. Interoperability Considerations 318 Many existing implementations fail to acknowledge the correct use of 319 the generic URL syntax defined in [RFC2396], but continue to use the 320 format regardless. 322 Some implementations do not take into consideration the use of prefix 323 characters on channels names, as defined by [RFC2811], and therefore 324 cannot correctly reference channels appropriately. Software SHOULD 325 NOT guess the channel type, or hence the channel's prefix character, 326 unless the probability of an accurate guess is 100% (for example, the 327 server only supports one type of channel). 329 Some current implementations will need slight modification to accept 330 the extended format defined in this specification, however most 331 implementations which parse the URL in a standard form will continue 332 to work. 334 The majority of incongruities are simply caused by the problem of 335 developers ignoring RFC-2396. 337 The use of the channel name without specifying the channel option is 338 to both maintain compatibility with the existing implementations, 339 whilst providing an abbreviated form, similar to the design of the 340 "mailto:" scheme defined by [RFC2368]. 342 6. Security Considerations 344 Security problems arise only when the authentication portion of the 345 URL is used, or channel keys are given. While the use of the 346 password/key extensions is considered to be rare, they have been 347 included for completeness. 349 As the passwords and channel keys are unfortunately in clear-text, 350 any user using the IRC URL should be aware of obvious insecurities. 352 Furthermore, it is RECOMMENDED that user software does not 353 automatically initiate the connection specified by the URL without 354 the knowledge and consent of the user. To do so would open the 355 implementation up to a variety of malicious activities including, but 356 not limited to, the purposes of direct advertising or channel 357 advertising (also known as "spam") by way of pop-ups. 359 When connecting using a secure connection ("ircs://"), user-space 360 ports (those above port 1023) SHOULD NOT be used automatically, as 361 their authority is questionable. If a secure connection cannot be 362 established, the client MUST either give up, or prompt the user 363 before attempting an insecure ("irc://") connection. 365 Beyond this, there are security concerns with regards with associated 366 protocols, including IRC and TLS, which MUST be taken into 367 consideration, but are beyond the scope of this document. 369 7. Acknowledgments 371 Thanks must go to Khaled Mardam-Bey for his early implementation in 372 his software, "mIRC", which provided the inspiration to clarify the 373 specification. 375 I would also like to acknowledge the members of the IRC development 376 community who encouraged me to publish this draft, after more than 18 377 months of pretermission. 379 8. References 381 [ABNF] Crocker, D., and Overell, P., "Augmented BNF for Syntax 382 Specifications: ABNF", RFC 2234, November 1997. 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC2368] Hoffman, P., Masinter, L., Zawinski, J., "The mailto URL 388 scheme", RFC 2368, July 1998. 390 [RFC2396] Berners-Lee, T, Fielding, T., Masinter, L., "Uniform 391 Resource Identifiers (URI): Generic Syntax", RFC 2396, 392 August 1998. 394 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., 395 "Guidelines for new URL Schemes", RFC 2718, November 1999. 397 [RFC2811] Kalt, C., "Internet Relay Chat: Channel Management", RFC 398 2811, April 2000. 400 [RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2819, 401 April 2000. 403 [SSL] Hickman, K., "The SSL Protocol", Netscape Communications 404 Corp., February 9, 1995. 406 [TLS] Dierks, T. and Allen, C., "The TLS Protocol Version 1.0", 407 RFC 2246, January 1999. 409 [Unicode] The Unicode Consortium. The Unicode Standard, Version 410 4.0.0, (Reading, MA, Addison-Wesley, 2003. ISBN 411 0-321-18578-1). 413 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 414 RFC 2279, January 1998. 416 9. Author's Address 418 Simon Butcher 419 Alien Internet Services 421 PO Box 7041 422 Croydon South 423 VIC 3136 424 Australia 426 Phone: +61-3-9879-8052 427 Fax: +61-3-9893-2793 428 Email: simonb@alien.net.au 430 Document Expiration and Filename 432 Please note that this is a draft document and it shall expire April 433 2004. Its filename is draft-butcher-irc-url-00.txt