idnits 2.17.1 draft-mirashi-url-irc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 77 has weird spacing: '...encoded by a ...' == Line 215 has weird spacing: '...e world wide ...' == Line 232 has weird spacing: '...ver and updat...' == Line 264 has weird spacing: '.... They may a...' == Line 285 has weird spacing: '... issues are t...' -- 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 (August 29, 1996) is 10099 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) == Unused Reference: 'RFC1738' is defined on line 326, but no explicit reference was found in the text == Unused Reference: 'RFC 1459' is defined on line 330, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Downref: Normative reference to an Experimental RFC: RFC 1459 Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Mandar Mirashi 2 draft-mirashi-url-irc-01.txt mandar@wildstar.net 3 Expires: February 28, 1997 August 29, 1996 5 "irc: URL scheme" 7 Status of This Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its 11 areas, and its working groups. Note that other groups may also 12 distribute working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet- 17 Drafts as reference material or to cite them other than as 18 ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check 21 the ``1id-abstracts.txt'' listing contained in the Internet- 22 Drafts Shadow Directories on ftp.is.co.za (Africa), 23 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 24 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 26 Abstract 28 A new URL scheme "irc:" is defined. The irc URL scheme is used to 29 refer to either IRC (Internet Relay Chat) servers or individual 30 entities (channels or people) on IRC servers. 32 Description 34 With the advent of "plugins", and realtime support via CGI and Java, 35 web developers have come up with different means to integrate IRC 36 support into their products. This document attempts to define a URL 37 scheme ("irc:") which would make this process easier. 39 An irc URL takes the form: 41 irc:[ //[ [:] ]/[] [,needpass] ] 43 where, 45 46 The IRC server host to connect to. See RFC 1034 [Sec 3.5] and 47 RFC 1123 [Sec 2.1] for details on allowed Internet hostname 48 formats. If omitted, the client must connect to a prespecified 49 default IRC server. irc: URL scheme implementors are recommended 50 to provide a preconfigured list of IRC servers/networks to choose 51 from, and must have the ability to let the user designate a 52 default IRC server host. 54 55 The port number to connect to. If : is omitted, the 56 default IANA assigned IRC port 194 is used. Clients may use port 57 6667 as an alternate port in case connection to the default 58 port fails. Clients should also maintain a default port number, 59 as well as associations of port numbers with specific hosts. 61 62 If a target is referred to, it takes the form: 64 ::= | 65 ::= | 66 ::= ',needkey' 68 The target can be either an IRC channel or a person on IRC 69 (identified by his/her nickname and other associated information) 70 RFC 1459 (sec 2.3) defines an IRC channel as: 72 ::= ('#' | '&' | '+') 73 ::= 76 In the irc: URL scheme, "unsafe" characters (RFC 1738, Sec 2.2) in 77 or must be encoded by a character triplet 78 consisting of the character "%" followed by the two hexadecimal 79 digits (from "0123456789ABCDEF") which form the hexadecimal value 80 of the octet. (The characters "abcdef" may also be used in 81 hexadecimal encodings.) 83 Since most IRC channels begin with the '#' character which is 84 unsafe in a URL, it must be encoded. To avoid the cumbersome 85 % encoding for most references, this draft omits the specific 86 mention of a channel prefix in a of type . 87 irc: URL scheme implementors must maintain a prefix variable (by 88 default, '#', with '&' and '+' as other allowable values) to form 89 channel names in accordance with RFC 1459. Further, the characters 90 '!', ',', ':' and '@' are reserved in the irc: URL scheme and must 91 also be encoded. 93 [,needkey] 94 IRC channels can require a keyword (RFC 1459, Sec 4.2.1) before 95 entrance to the channel is granted. This parameter indicates to 96 the irc: URL scheme implementor that the user should be prompted 97 for the channel key, before an attempt to dereference the URL 98 is made. This parameter should be ignored for modeless + channels. 100 is described by (also see RFC1459, Sec 2.3): 102 ::= ',isnick' 103 ::= | | 104 ::= '!' '@' 105 ::= '@' 106 ::= { | | } 107 ::= { } 108 ::= 'a' ... 'z' | 'A' ... 'Z' 109 ::= '0' ... '9' 110 ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}' 111 ::= 113 ::= 114 ::= 116 Characters deemed unsafe (RFC 1738, Sec. 2.2) in (and 117 thus in ) must be encoded as usual. The irc: URL scheme 118 implementor may choose to initiate a DCC (direct client to client) 119 chat connection to the user when is specified. Many 120 IRC clients currently support DCC functionality and a rough draft 121 appears at ftp://ftp.undernet.org/irc/docs/technical/DCC.doc. 122 Alternatively, they may choose to stick to exchanging messages 123 via IRC, or offer the user a choice between the two. 125 [,needpass] 126 IRC servers can require a password (RFC 1459, Sec 7) before a 127 connection to the server is granted. This parameter indicates to 128 the irc: URL scheme implementor that the user should be prompted 129 for the server password, before an attempt to dereference the URL 130 is made. 132 Client issues 134 irc: URL scheme implementors must have the following user 135 configurable fields or variables in their clients (also see RFC 136 1459): 138 * Default IRC server host to connect to (alternate servers if 139 the connection to the default server fails, may also be listed). 140 A list of IRC servers/networks to choose from is also suggested 141 for inclusion. 143 * Default port to connect on (alternate ports if the connection 144 to the default port fails may also be listed) 146 * Default channelname prefix (usually '#', but can also take the 147 values '&' and '+') 149 * Default nickname to connect under (alternate nicknames should be 150 specified since the specified nickname may already be in use) 152 * Real name (also known as the IRCNAME variable) of the person. 154 The USER command passed to an IRC server requires a 155 parameter. Since it is easy for a client to lie about its username 156 by relying solely on the USER message, the availability of this 157 as a user configurable field should be avoided. This field may 158 be automatically obtained on Unix systems via the getpwuid() (or 159 a similar) system call. On other systems, the identity section of 160 mail programs on the system frequently contains a "reply-to" or 161 an "e-mail" field, often in a user@host format. The user portion 162 of this may be used for the parameter. Only if these 163 methods fail, should the user be prompted for a . 165 As discussed earlier, the client must be able to prompt the user 166 for a channel key or server password, based on the irc: URL 167 specified. It may also offer the user a choice of a DCC chat 168 connection when a nickname is dereferenced. 170 Examples 172 The URL's: 174 irc: irc:// irc:/// 176 reference the default/local IRC server. The URL: 178 irc:///,needpass 180 references the default IRC server and prompts the user for a 181 password, before connecting to it. 183 The URL 185 irc:///help 187 references IRC channel help (this could be #help, &help or +help, 188 depending on the channel prefix set) on the default IRC server. 190 The URL 192 irc:///Mmmm!mandar@*uoknor.edu,isnick 194 references a person with nickname Mmmm, and user@host matching 195 mandar@*uoknor.edu on the default IRC server. 197 The URL, 198 irc://foobar.org/Mmmm,isnick,needpass 200 references a person with nickname Mmmm on server foobar.org. The 201 connection to foobar.org takes place over the default port, and the 202 user is prompted for a server password. 204 The URL 206 irc://foobar.org:6665/secret,needkey 208 references the IRC channel secret on server foobar.org. The 209 connection takes place over port 6665, and the user is prompted 210 for a channel key in order to reference the channel. 212 Current Implementations 214 Despite the lack of a common URL scheme, many integration efforts 215 between IRC and the world wide web have been successful. These 216 can be roughly categorised into: 218 IRC plugins: 219 These are IRC clients distributed separately and designed to work 220 in close conjunction with the browser. Current plugins include: 221 http://home.netscape.com/comprod/chat.html 222 (Netscape Chat - Netscape Corp) 223 http://www.globalchat.com 224 (Global Chat - Quarterdeck Corp) 225 http://www.ichat.com/client.htm 226 (iChat - iChat Inc) 227 They often include proprietary protocol implementations, in 228 addition to IRC support. 230 Java gateways: 231 These take the form of a Java capable Web browser that interacts 232 with an IRC server and updates "live content" web pages. The 233 foll. URL's which illustrate these, were functional at the time of 234 writing: 235 http://polaris.ibm.com/~gong/irc_room.html 236 http://www.blackdown.org/~kbs/irctst/demo.html 237 http://irc.webmaster.com 238 http://virtual.itribe.net/jirc/ 239 http://www.dimensionx.com/products/cafe/index.html 240 http://www.hdmdigital.com/~cknight/dotcom/zirc/ 241 These gateways take up resources on the machine hosting the web 242 server, and are also slower than IRC clients which open a direct 243 connection to the IRC server. A variation of the Java gateway is a 244 CGI gateway, which is based on CGI scripts instead of Java, but 245 quickly fading from existence due to CGI's limited realtime 246 functionality. 248 IRC client - Web browser communication: 249 Recent IRC clients often communicate with the Web browser via 250 mechanisms such as API calls or DDE, and pass back a URL to be 251 opened via the browser. Some of these can also be set up as 252 "plugins" or "helper applications". Clients that implement this 253 include: 254 http://apollo3.com/~acable/virc.html (Visual IRC) 255 http://www.mirc.co.uk/ (mIRC) 256 http://www.bcpl.lib.md.us/~frappa/pirch.html (Pirch) 257 http://www.vapor.com/support/amirc/ (AmIRC) 258 http://catless.ncl.ac.uk/Programs/Zircon/ (Zircon) 259 http://xirc.bitgate.com/ (XIRC) 261 It is anticipated that the irc: URL scheme would allow Web 262 browsers to open a local dynamic "live content" page as 263 demonstrated by the gateways (thus eliminating the need to go via a 264 gateway). They may also choose to open a plugin IRC client. The 265 choice is left to the individual irc: URL scheme implementor. 267 History 269 IRC as a protocol first appeared in 1988 and thus predates the world 270 wide web by several years. A formal specification of the protocol 271 was drawn up in 1993 (RFC 1459). Today, there are thousands of 272 simultaneous users on various IRC networks. Integration efforts with 273 the World Wide Web continue (as outlined above). The irc: URL 274 scheme first appeared in the Rating Services and Rating Systems 275 document published by the PICS (Platform for Internet Content 276 Selection) technical subcommitee of the World Wide Web 277 Consortium: 278 http://www.w3.org/pub/WWW/PICS/services.html 279 However, the original definition lacked RFC 1459 conformance. This 280 draft attempts to add RFC 1459 conformance to the scheme, besides 281 other features previously lacking. 283 Security Considerations 285 Security issues are tackled in RFC 1738 and RFC 1459. Character 286 encoding rules must be followed for unsafe and reserved characters. 287 Clients should take care that attempts to connect to ports other 288 than 194 in the well known port range 1-1024, are disregarded. IRC 289 servers often use the non-registered port 6667 (or ports in the 290 range 6000-7000) for clients to connect to. Since the URL 291 dereference would always result in client to server messages 292 prefixed by NICK, or USER, or JOIN or MSG, chances of a dangerous 293 URL resolution are minimized. 295 Nicknames on IRC are not constant - different people may use the 296 same nickname at different times (although not simultaneously on 297 the same IRC server or network). This feature/anomaly is inherent 298 to the definition of the current IRC protocol (RFC 1459). It is 299 highly recommended that irc: URL scheme implementors warn the 300 user when dereferencing a instead of . A WHOIS 301 IRC lookup is also suggested. 303 Scheme summary 305 The irc: URL scheme is unique in its own way. It does borrow 306 concepts from other URL schemes (RFC 1738) however. Like the nntp: 307 URL scheme, it allows the specification of a for a unique 308 resource location. However, many IRC servers often limit 309 connections from outside domains. Thus, like the news: and mailto: 310 URL schemes, it allows for the resolution of this information at 311 the client level, and like the file: URL scheme, allows 312 to be an empty string. Like the telnet: URL scheme, it does not 313 designate a data object, but rather an interactive service. 315 The draft defines the irc: URL scheme and "must be configured" 316 fields. This scheme is extremely useful given the shortcomings of 317 current implementations. There's only one operation defined on this 318 UR*, and it is not very GET like (the IRC protocol is outlined in 319 RFC 1459). It can be proxied into HTTP/HTML, but this does have 320 severe limitations as mentioned earlier. Security considerations 321 have been outlined. It does not follow the relative URL (RFC 1808) 322 model. 324 References 326 [RFC1738] RFC 1738. Uniform Resource Locators (URL). 327 T. Berners-Lee, L. Masinter & M. McCahill. 328 December 1994. 330 [RFC 1459] RFC 1459. Internet Relay Chat (IRC) Protocol 331 J. Oikarinen, D. Reed. May 1993. 333 Acknowledgements 335 A sincere thanks to various IRC server and client coders, HTML/WWW 336 developers, the PICS technical subcommittee, W3 members, and former 337 URI working group members, who offered help, advice and suggestions 338 at all stages of the draft. People who offered help/advice/reviews/ 339 new suggestions (in no particular order): 340 Dan Connolly, Harald T. Alvestran, Larry Masinter, Darren Reed, 341 Matthew Green, Bjorn Borud, Carl von Loesch, Dennis Holmes, Niels 342 Bakker, James Egelhof, Arthur Liu, Robert Ullman, Klaus Wissmann. 344 Those of you whom I inadvertently missed, you know who you are. 346 Author's contact information: 348 Name: Mandar Mirashi 349 Address: 35B, Hudson Harbour Drive, 350 Poughkeepsie, NY 12601. 351 Phone#: 914-485-6264 352 Email: mandar@wildstar.net, 353 Mmmm@alias.undernet.org 354 IRC Nick: Mmmm