idnits 2.17.1 draft-butcher-irc-url-01.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 52 instances of lines with control characters in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 321, but not defined ** Obsolete undefined reference: RFC 2718 (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'PICS' ** Obsolete normative reference: RFC 2368 (Obsoleted by RFC 6068) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2717 (Obsoleted by RFC 4395) ** 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: 12 errors (**), 0 flaws (~~), 4 warnings (==), 6 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 Internet- 19 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 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document specifies two URL (Uniform Resource Locator) schemes, 39 using the URI (Uniform Resource Indicator) names "irc" and "ircs", 40 for the location of IRC (Internet Relay Chat) servers. These URLs 41 allow for easy location of an IRC server, optionally also specifying 42 an IRC channel to join or person to contact upon connection. 44 1. Introduction 46 Since its introduction, Internet Relay Chat (IRC) has become widely 47 known and used within the Internet Community as a real-time chat 48 medium. IRC networks are steadily growing larger, not only with 49 regards to the number of regular uses, but also the number of 50 channels and servers required to support the demand. 52 Due to the nature of IRC as a simple real-time chat service, it has 53 been known to be used for a wide variety of uses such as software 54 support, job interviews, and of course just for a casual chat. 56 While IRC is progressing, the need for an appropriate Uniform 57 Resource Locator (URL) scheme has become apparent. Applications for 58 such a scheme would range quite widely, including IRC network server 59 lists on a website, software support contact details, or even a 60 meeting location with an e-mail including a specific IRC channel. 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 In this document, the term "client" is defined as the IRC client 67 software, and the term "user" is the end-user of that software. 69 2. URL Definition 71 An IRC URL begins with either the Uniform Resource Identifiers (URIs) 72 "irc" or "ircs", denoting normal and secured connections 73 respectively. Normal sessions are via the existing transport, as 74 defined in [RFC2812], and secured sessions are the same, only via a 75 secure transport layer such as [TLS] (or [SSL], the predecessor to 76 TLS). 78 The URL scheme for IRC follows the Generic URL Syntax, defined in 79 [RFC2396]. 81 The action the URL is to instigate is to open a connection to the 82 specified IRC server using whatever protocol necessary. Currently 83 only one protocol is defined to do this, as per RFC 2812. 85 2.1. ABNF Syntax 87 The following is the definition for an IRC URL in [ABNF] grammar: 89 ircURL = type "://" location "/" [ channel ] [ options ] 91 type = "irc" / "ircs" 93 location = [ authinfo "@" ] hostport 94 ; See Section 3.2.2 of [RFC2396] for 95 ; the definition of 'hostport'. 97 authinfo = [ nickname *2( "," nickname ) ] [ ":" password ] 99 nickname = *( escaped / unreserved ) 100 ; Further restrictions may apply upon 101 ; connection, depending on the server. 102 ; Some common nickname characters must be 103 ; encoded, as per recommendations in Section 104 ; 2.4.3 in [RFC2396]. 106 password = *( escaped / unreserved ) 108 channel = *( escaped / unreserved / safe / "=" ) 110 options = "?" option *( "&" option ) 112 option = optname [ "=" optvalue ] 114 optname = *( ALPHA ) 116 optvalue = optparam *( "," optparam ) 117 ; Only some options have multiple parameters. 119 optparam = *( escaped / unreserved / safe / "?" ) 120 ; Other characters (such as [Unicode] 121 ; characters in [UTF-8]) must be escaped 122 ; as per rules in Section 2.2.5 of [RFC2718]. 123 ; See also Section 4 of this document. 125 safe = "#" / "$" / "&" / "+" / "@" / ";" / ":" 127 The definition of "escaped" and "unreserved" is in sections 2.4.1 and 128 2.3 of [RFC2396] respectively. 130 The use of spaces, escaped (%20) or otherwise, SHOULD NOT be allowed 131 for channel names or nicknames, as they are currently unsupported by 132 existing IRC protocols. 134 2.2. Authentication 136 Multiple nicknames MAY be specified, and pending any error or lack of 137 availability, the IRC client software MAY request the next nickname 138 in the list. 140 Clients MUST NOT accept any more than three (3) nicknames, and any 141 more nicknames specified MUST be ignored to curtail potential abuse. 143 Clients may only attempt to use alternative nicknames given during 144 the one connection. Clients MUST NOT reconnect to the server to try 145 alternative nicknames. 147 Should the client run out of alternative nicknames to try, but the 148 server is willing to accept another attempt, the client MAY either 149 disconnect from the server and show the user an error message, or 150 prompt the user for another nickname to try. 152 The use of passwords is not recommended, as they present a 153 significant security problem. They are allowed purely for 154 convenience. Users of the password field must be aware of the 155 security issues discussed in Section 6 of this document. 157 2.3. Server Ports 159 Special consideration must be given to URLs without ports specified. 160 Almost all IRC servers are contactable on a variety of standard ports 161 as allocated by the IANA. Should an IRC URL be specified without a 162 port, a client SHOULD try a number of standard ports: 164 - For the "irc" URI, it is RECOMMENDED that the server is attempts 165 connection to the ports 194, 6665, 6666, 6667, 6668 and 6669. 167 - For the "ircs" URI, it is RECOMMENDED that the default port used 168 is 994. User-space ports (those above port 1023) may have 169 questionable authenticity, and SHOULD NOT be used unless 170 explicitly specified. 172 Port numbers shown here are in decimal, and have been assigned by the 173 IANA. 175 2.4. Channels 177 For compatibility with older implementations, and to allow 178 simplification of the specification, channels MAY be specified 179 without the use of the "channel" option detailed in Section 2.5.1. 181 Only one channel can be specified, and this facility has the same 182 functionality as the "channel" option. See Section 3 of this 183 document for examples of the equivalence between this and the 184 "channel" option in Section 2.5.1. 186 2.5. Additional Options 188 Additional options may be added to control what action the client 189 software MAY take following connection to the IRC server. 190 Unsupported options should simply be ignored. 192 These options listed here may be expanded on at a later date by 193 updated RFC's. 195 2.5.1. The "channel" Option 197 This instructs the client to join the specified channel, allowing the 198 user to participate in discussions within the channel. 200 The value given with the channel option is a channel name, and 201 optionally a "key" (see Section 4.2.10 of [RFC2811]). Its value can 202 be defined in [ABNF] as follows: 204 value = name [ "," key ] 206 See Section 2.1 of this document for information on acceptable 207 characters. The "," character is not allowed in either the channel 208 name, or key, unless it is escaped ("%x2C"). 210 The number of channels which can be joined at once is normally 211 restricted by the server, but no hard-limit is given by this 212 specification as this is a matter of individual server policy. As 213 such, multiple "channel" options may be given. 215 An automated message MUST NOT be sent to the channel upon joining it. 217 It is NOT RECOMMENDED to use the channel key feature. Please see 218 Section 6 of this document. If a key is required to join a channel, 219 and one is not given, the IRC client MAY wish to prompt the user for 220 the key. 222 2.5.2. The "query" Option 224 For each "query" option, the client is requested to open some 225 interface where by users may type a message to the given query 226 target. For example, the client may open up a window where messages 227 may be typed to, and received from the target. 229 Some clients may not have the ability to open up a specific window or 230 dialogue box. These clients MAY prompt the user for a message to be 231 sent to the target, or otherwise this option MAY be ignored and hence 232 unsupported. 234 The option value is the same as the message target value specified in 235 Section 3.3.1 of [RFC2812], except that the client MUST only accept 236 one target. Multiple targets per "query" option MUST NOT be 237 accepted, and the entire query MUST be considered invalid and 238 ignored. 240 A message MUST NOT be automatically sent to the target, simply an 241 interface created to allow the user to send a message to the target. 243 The IRC client software MAY wish to check the availability of the 244 target prior to opening the interface if inclined to do so, however 245 any method of testing the availability MUST NOT generate any 246 automatic message being sent to the target. 248 Multiple targets MAY be referenced with multiple query options, 249 however in order to reduce the potential for abuse, it is RECOMMENDED 250 that additional query options are ignored. There are valid reasons 251 for having multiple targets, and abuse is minimal as no messages are 252 sent to the targets. 254 3. Examples 256 While examples of every situation cannot be shown here because of 257 space considerations, the following examples provide a rough overview 258 of how the IRC URL can be used. 260 262 In its simplest form, the above complete URL can be used to direct a 263 client to a specific IRC server, which in this case is 264 "irc.undernet.org". The client should presume to use default port 265 settings. 267 269 The above URL specifies that the IRC client should try to connect to 270 "irc.efnet.org" on the port 6667, rather than use whatever is 271 considered the default. It also tells the IRC client it should try 272 to use a nickname of "pickle", if it is available. 274 276 This shows a properly [UTF-8] encoded URL, specifying the nickname 277 Idil (with the first character being a Turkish Latin capital letter 278 "I" with a dot above it, [Unicode] code point U+0130). Failing that, 279 the second nickname, "idil", may be used if the first one is 280 rejected, perhaps by an older IRC server. 282 284 The above URL will instruct the IRC client to connect to a server 285 with the address 192.0.2.1, which is an IRC server that is presumably 286 password protected. The client should request to use the nickname 287 "pickle", with the password "secret" to authenticate the session to 288 the remote server. This URL also enforces the standard IRC port, 194, 289 and will stop IRC clients from hunting for ports. 291 292 293 295 All three of these URLs connects to the IRCnet network, and will join 296 the client to the channel "#worldchat" upon connection. 298 300 This will connect to the server "irc.alien.net.au" and will provoke 301 the client to open up a window (or similar) associated with sending 302 messages to the nickname 'pickle'. It will also join the channel 303 "+private" using the channel key "foo". 305 307 This will connect to AUSTnet and join two channels, "#melbourne" and 308 "#sydney". 310 312 This will open a dialogue box prepared to send a message to 313 "pickle%butcher.id.au". Please refer to Section 3.3.1 of [RFC2812] 314 for more details. 316 4. Internationalisation Considerations 318 With the inevitable adoption of [Unicode] on IRC, and indeed the 319 Internet as a whole, URLs MUST be encoded using the [UTF-8] character 320 set, with potentially unsafe octets encoded using %HH notation (where 321 HH is a hexadecimal value), as per Section 2.2.5 of [RFC-2718]. 323 For example, the word for "alias" in Japanese, using Unicode code- 324 points, is U+5225 U+540D. Correctly encoded, this would appear in 325 the URL as: "%E5%88%A5%E5%90%8D". An example of this use in action 326 can be found in Section 3. 328 5. Interoperability Considerations 330 Many existing implementations fail to acknowledge the correct use of 331 the generic URL syntax defined in [RFC2396], but continue to use the 332 format regardless. This implementation flaw is likely to be due to 333 the first documentation of the irc: URI scheme by the W3C's [PICS] 334 recommendation. This implementation has never adequately considered 335 the needs of IRC, nor even the implementation of IRC at the time. 337 Some implementations do not take into consideration the use of prefix 338 characters on channels names, as defined by [RFC2811], and therefore 339 cannot correctly reference channels appropriately. Software SHOULD 340 NOT guess the channel type, or hence the channel's prefix character, 341 unless the probability of an accurate guess is 100% (for example, the 342 server only supports one type of channel). 344 Some current implementations will need slight modification to accept 345 the extended format defined in this specification, however most 346 implementations which parse the URL in a standard form will continue 347 to work. 349 The majority of incongruities are simply caused by the problem of 350 developers ignoring RFC-2396. 352 The use of the channel name without specifying the channel option is 353 to both maintain compatibility with the existing implementations, 354 whilst providing an abbreviated form, similar to the design of the 355 "mailto:" scheme defined by [RFC2368]. 357 Some fields have been extended to allow additional characters outside 358 of those normally needing to be encoded to allow for interoperability 359 with existing implementations. 361 6. Security Considerations 363 Security problems arise only when the authentication portion of the 364 URL is used, or channel keys are given. While the use of the 365 password/key extensions is considered to be rare, they have been 366 included for completeness. 368 As the passwords and channel keys are unfortunately in clear-text, 369 any user using the IRC URL should be aware of obvious insecurities. 371 Furthermore, it is recommended that user software does not 372 automatically initiate the connection specified by the URL without 373 the knowledge and consent of the user. To do so would open the 374 implementation up to a variety of malicious activities including, but 375 not limited to, the purposes of direct advertising or channel 376 advertising (also known as "spam") by way of pop-ups. 378 When connecting using a secure connection ("ircs://"), user-space 379 ports (those above port 1023) should not be used automatically, as 380 their authority is questionable. If a secure connection cannot be 381 established, the client MUST either give up, or prompt the user 382 before attempting an insecure ("irc://") connection. 384 Automated messages MUST NOT be sent to channels or other users upon 385 connection to an IRC server as a direct action of this URL. Services 386 MAY be contacted. The facility to send automated messages to other 387 users has been explicitly avoided in this document to avoid abuse, 388 common with IRC services. 390 Beyond this, there are security concerns with regards with associated 391 protocols, including IRC and TLS, which must be taken into 392 consideration, but are beyond the scope of this document. 394 7. IANA Considerations 396 The following is registration for the URL schemes as per [RFC2717]: 397 URL scheme name: "irc" and "ircs". 399 URL scheme syntax: See Section 2.1. 401 Character encoding considerations: Characters must be encoded in 402 UTF-8 and escaped. See Section 4. 404 Intended usage: The scheme initiates connection to an IRC server, 405 normally through the execution of IRC Client software. 407 Interoperability considerations: See Section 5. 409 Security considerations: See Section 6. 411 Relevant publications: The IRC protocol is defined by [RFC2812]. 412 Either [SSL] or [TLS] may be used for the "ircs" scheme, depending on 413 client and server configuration. 415 Person & email address to contact for further information: The 416 Author; See Section 10 for details. 418 Author/Change controller: The IETF is to maintain change control. 420 8. Acknowledgments 422 Thanks must go to Khaled Mardam-Bey for his early implementation in 423 his software, "mIRC", which provided the inspiration to clarify the 424 specification. 426 I acknowledge the previous work of Mandar Mirashi who originally 427 wrote an Internet-Draft to similar effect, but of which this document 428 has no derivation. 430 I would also like to acknowledge the members of the IRC development 431 community who encouraged me to publish this draft, after more than 18 432 months of pretermission. 434 9. References 436 [ABNF] Crocker, D., and Overell, P., "Augmented BNF for Syntax 437 Specifications: ABNF", RFC 2234, November 1997. 439 [PICS] Miller, J., Resnick, P., Singer, D., "Rating Services and 440 Rating Systems (and Their Machine Readable Descriptions)", 441 Version 1.1, , 442 October 1996. 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, March 1997. 447 [RFC2368] Hoffman, P., Masinter, L., Zawinski, J., "The mailto URL 448 scheme", RFC 2368, July 1998. 450 [RFC2396] Berners-Lee, T, Fielding, T., Masinter, L., "Uniform 451 Resource Identifiers (URI): Generic Syntax", RFC 2396, 452 August 1998. 454 [RFC2717] Petke, R., King, I., "Registration Procedures for URL 455 Scheme Names", RFC 2717, November 1999. 457 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., 458 "Guidelines for new URL Schemes", RFC 2718, November 1999. 460 [RFC2811] Kalt, C., "Internet Relay Chat: Channel Management", RFC 461 2811, April 2000. 463 [RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2819, 464 April 2000. 466 [SSL] Hickman, K., "The SSL Protocol", Netscape Communications 467 Corp., February 9, 1995. 469 [TLS] Dierks, T. and Allen, C., "The TLS Protocol Version 1.0", 470 RFC 2246, January 1999. 472 [Unicode] The Unicode Consortium. The Unicode Standard, Version 473 4.0.0, (Reading, MA, Addison-Wesley, 2003. ISBN 474 0-321-18578-1). 476 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 477 RFC 2279, January 1998. 479 10. Author's Address 481 Simon Butcher 482 Alien Internet Services 484 PO Box 7041 485 Croydon South 486 VIC 3136 487 Australia 489 Phone: +61-3-9879-8052 490 Fax: +61-3-9893-2793 491 Email: simonb@alien.net.au 492 simon@butcher.id.au 494 Intellectual Property Rights Notice 496 The IETF takes no position regarding the validity or scope of any 497 intellectual property or other rights that might be claimed to 498 pertain to the implementation or use of the technology described in 499 this document or the extent to which any license under such rights 500 might or might not be available; neither does it represent that it 501 has made any effort to identify any such rights. Information on the 502 IETF's procedures with respect to rights in standards-track and 503 standards-related documentation can be found in BCP-11. Copies of 504 claims of rights made available for publication and any assurances of 505 licenses to be made available, or the result of an attempt made to 506 obtain a general license or permission for the use of such 507 proprietary rights by implementers or users of this specification can 508 be obtained from the IETF Secretariat. 510 The IETF invites any interested party to bring to its attention any 511 copyrights, patents or patent applications, or other proprietary 512 rights which may cover technology that may be required to practice 513 this standard. Please address the information to the IETF Executive 514 Director. 516 Full Copyright Notice 518 Copyright (C) The Internet Society (2003). All Rights Reserved. 520 This document and translations of it may be copied and furnished to 521 others, and derivative works that comment on or otherwise explain it 522 or assist in its implementation may be prepared, copied, published 523 and distributed, in whole or in part, without restriction of any 524 kind, provided that the above copyright notice and this paragraph are 525 included on all such copies and derivative works. However, this 526 document itself may not be modified in any way, such as by removing 527 the copyright notice or references to the Internet Society or other 528 Internet organizations, except as needed for the purpose of 529 developing Internet standards in which case the procedures for 530 copyrights defined in the Internet Standards process must be 531 followed, or as required to translate it into languages other than 532 English. 534 The limited permissions granted above are perpetual and will not be 535 revoked by the Internet Society or its successors or assigns. 537 This document and the information contained herein is provided on an 538 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 539 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 540 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 541 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 542 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 544 Document Expiration and Filename 546 Please note that this is a draft document and it shall expire April 547 2004. Its filename is draft-butcher-irc-url-01.txt