idnits 2.17.1 draft-butcher-irc-url-04.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 61 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 2003) is 7772 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 363, but not defined ** Obsolete undefined reference: RFC 2718 (Obsoleted by RFC 4395) == Unused Reference: 'PICS' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC2368' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC2718' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'RFC2811' is defined on line 527, but no explicit reference was found in the text ** 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 ** Downref: Normative reference to an Informational RFC: RFC 2812 -- 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: 13 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Simon Butcher 3 Expires July 2004 Alien Internet Services 4 January 2003 6 Uniform Resource Locator Schemes for 7 Internet Relay Chat Entities 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 "irc-url" mailing list, 15 specified at the end of this document. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document specifies two URL (Uniform Resource Locator) schemes, 40 using the URI (Uniform Resource Indicator) names "irc" and "ircs", 41 for the location of IRC (Internet Relay Chat) servers. These URLs 42 allow for easy location of an IRC server, optionally also specifying 43 an IRC channel to join, or a person's nickname to contact upon 44 connection. 46 1. Introduction 48 Since its introduction, Internet Relay Chat (IRC) has become widely 49 known and used within the Internet Community as a real-time chat 50 medium. IRC networks are steadily growing larger, not only with 51 regards to the number of regular users, but also the number of 52 channels and servers required to support the diverse demand. 54 Due to the nature of IRC as a real-time chat service, it has been 55 known to be used for a wide variety of uses such as software support, 56 job interviews, and of course just for a casual conversation. 58 For years now, the need for an appropriate Uniform Resource Locator 59 (URL) scheme has been apparent. Applications for such a scheme range 60 quite widely, including IRC network's server lists on their website, 61 technical support contact details, or even a meeting location within 62 an e-mail, giving a specific IRC channel or nickname to contact. 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 In this document, the term "client" is defined as the IRC client 69 software, and the term "user" is the end-user of that software. The 70 term "entity" refers to an addressable IRC entity, such as a user, 71 service, or channel. 73 2. URL Definition 75 An IRC URL begins with either the Uniform Resource Identifiers (URIs) 76 "irc", or "ircs", denoting normal and secured connections 77 respectively. Normal sessions are via existing transport (such as 78 that in [RFC2812]) and is to be considered insecure. Secured 79 sessions are much the same, only secured via a "blanket security" 80 method such as [SSL], or negotiating a [TLS] session. 82 The URL scheme for IRC follows the Generic URL Syntax ([RFC2396]). 84 The action the URL instigates is to open a connection to the 85 specified IRC server using whatever protocol necessary, and make 86 contact with the given user, service or channel, if also requested. 88 There is no requirement for IRC client software implementing the 89 "irc" scheme to also implement the "ircs" scheme, or vice-versa. It 90 is, however, RECOMMENDED that clients implementing the "ircs" scheme 91 are also capable of handling a normal connection via the "irc" 92 scheme. 94 2.1. ABNF Syntax 96 Below is the definition for the IRC URL scheme in [ABNF] grammar: 98 ircURL = ircURI "://" location "/" [ entity ] [ flags ] [ options ] 100 ircURI = "irc" / "ircs" 101 ; See Section 2, above, for details. 103 location = [ authinfo "@" ] hostport 104 ; See Section 3.2.2 of [RFC2396] for the definition 105 ; of 'hostport'. 107 authinfo = [ username ] [ ":" password ] 108 ; See Section 2.2 of this document for details. 110 username = *( escaped / unreserved ) 112 password = *( escaped / unreserved ) [ ";" passtype ] 114 passtype = *( escaped / unreserved ) 116 entity = [ "#" ] *( escaped / unreserved ) 117 ; Note the prefix, "#", may be used for channel names 118 ; without escapes. Please see Section 2.5.1. 120 flags = ( [ "," enttype ] [ "," hosttype ] ) 121 /= ( [ "," hosttype ] [ "," enttype ] ) 123 enttype = "," ( "isuser" / "ischannel" ) 125 hosttype = "," ( "isserver" / "isnetwork" ) 127 options = "?" option *( "&" option ) 129 option = optname [ "=" optvalue ] 131 optname = *( ALPHA / "-" ) 132 ; Option names are case-insensitive. 134 optvalue = optparam *( "," optparam ) 136 optparam = *( escaped / unreserved ) 138 The definition of "escaped" and "unreserved" is in sections 139 2.4.1 and 2.3 of [RFC2396] respectively. Clients MUST be 140 aware of protocol limitations. For example, using "IRC-2" 141 (RFC2812), it's impossible to use codepoint U+0020 in names. 143 2.2. Authentication 145 To allow for complete authentication of a session, a username MAY be 146 provided with the password. The username MUST NOT be passed to the 147 server as a nickname. For example, while registering a connection 148 using the "IRC-2" protocol, the username would be passed as the first 149 parameter of the "USER" command (See Section 3.1.3 of [RFC2812]). 151 The characters available for use in a username may be restricted by 152 the protocol used, and the IRC server software used. 154 The use of the password field is not recommended, as it presents a 155 significant security problem. Authors of IRC URLs using the 156 authentication field, including a password, should make themselves 157 aware of the security issues discussed in Section 6 of this document. 159 See Section 3 for examples of username/password pair authentication, 160 and traditional server password only authentication. 162 2.3. Server Names 164 Servers can be named with either their hostname, or address, like 165 other URL schemes, but also with an IRC Network's name. The 166 difference can be explicitly specified using the "isserver" and 167 "isnetwork" keywords in the "hosttype" section (see Section 3 for 168 examples). 170 As many modern IRC clients maintain lists of major IRC networks and 171 their respective servers, determination of a server to connect to 172 from a given network name should be a trivial task. 174 If the host name used is not a raw address (such as an IPv4, IPv6, or 175 other network address), the name cannot be resolved (through DNS or 176 other means), and does not contain a period character (U+002E), the 177 client MAY consider the given host name as a network name to find an 178 appropriate IRC server. 180 If the IRC client does not contain IRC Network name lists, and 181 "isnetwork" has been specified, the client MUST NOT attempt to 182 resolve the network name as a hostname. 184 2.4. Server Ports 186 Special consideration must be given to URLs without ports specified. 187 Almost all IRC servers are contactable on a variety of standard ports 188 as allocated by the IANA. Should an IRC URL be specified without a 189 port, a client MAY try a number of standard ports: 191 - For the "irc" URI, the client SHOULD attempt connection to the 192 port 6667, and MAY attempt connection to the ports 194, 6665, 193 6666, 6668 and 6669, in that order. Port 194 is likely to be a 194 more "authentic" server, however at this time the majority of 195 IRC servers are available on port 6667, at least. 197 - For the "ircs" URI, the default port used is 994. User-space 198 ports (those above port 1023) may have questionable 199 authenticity, and SHOULD NOT be used unless explicitly 200 specified. 202 Port numbers shown are in decimal, and have been assigned by the 203 IANA. Section 3.2.2 of [RFC2396] suggests only one port may be used 204 as a default port, and does not state a preference for or against 205 port hunting. The act of port hunting for the "irc" scheme when no 206 port is specified is therefore left up to the discretion of client 207 authors. 209 For URL equivalency, clients SHOULD consider default ports without 210 considering port-hunting. For example, and 211 should be considered equivalent, as should 212 and . 214 Note that the port 194 is officially the "standard" port for IRC 215 servers, the current practise is to use port 6667. This document may 216 be updated in the future if and when port 194 obtains an increased 217 prevailance. 219 2.5. Entity Names 221 Only one entity can be named per URL. The named entity SHOULD be 222 presumed to be a channel name, unless the "enttype" section (see 223 Section 2.1) of the URL is provided to determine the entity type. 225 An automated message MUST NOT be sent to the addressed entity. 227 2.5.1. Channel Names 229 When "enttype" contains "ischannel", or "enttype" is omitted 230 completely, the entity name provided is a channel name. 232 While it is discouraged, channel names prefixed with the "#" (U+0023) 233 character may be specified without encoding the character (as "%23") 234 in the URL. Implementers MAY accept this, despite it being an 235 exception to Section 2.4.3 of [RFC2396], because channels of this 236 type are currently very common, and will remain so in the foreseeable 237 future. 239 Clients SHOULD attempt to determine valid channel name prefix 240 characters from the server it has connected to, such as via an 241 "RPL_ISUPPORT" reply. If the client is unable to determine valid 242 prefix characters for the server it is connected to, the client 243 SHOULD attempt to join the channel without modifying its name. If 244 joining the channel failed, the prefix character "#" may be used. 246 If the client discovers the channel name given is considered to be 247 invalid because it is missing a valid prefix character, the client 248 SHOULD prepend a default prefix character to the name. 250 Since default prefix characters for channels may differ between IRC 251 servers, the client SHOULD try to determine the default channel 252 prefix for the server it is connected to, such as the first prefix 253 character given by "CHANTYPES" in "RPL_ISUPPORT". If the client is 254 still unable to determine a prefix character, a prefix character of 255 '#' (U+0023) MAY be presumed. 257 2.5.2. Nicknames 259 When "enttype" contains "isuser", the entity given refers to a user. 260 The given entity name may simply be a nickname, or it may contain 261 more specific information such as the user's hostname, username, or a 262 server they use. 264 A user entity is referred to using the following syntax (in [ABNF] 265 grammar): 267 userent = nickname [ "%21" username ] [ "%40" hostname ] 269 The definitions of "nickname", "username", and "hostname" are all 270 identical to the definition of "entname", as defined in Section 2.1 271 of this document. 273 It's RECOMMENDED that the client parse this name, as most servers 274 will not accept this syntax directly. For example, the client may 275 wish to make use of the IRC-2 "WHO" command to discover if the entity 276 is valid and available. 278 2.6. Additional Options 280 Additional options may be used to provide additional information 281 about the entity you're addressing. 283 These options listed here may be expanded on at a later date by 284 future documents. Unsupported options MUST be ignored by the client. 285 The client author is not obligated to utilise the "options" section 286 (see Section 2.1) of the URL, but it is RECOMMENDED to do so. 288 2.6.1. The "key" Option 290 This option is only valid if the entity name given is a channel name. 291 If the entity name is not a channel name, then this option MUST 292 simply be ignored. 294 The option's value provides a "key" to be given to the server when 295 joining the given channel name, and is used for channels which 296 require a "key" to join them. If a channel key is found to be 297 required and one is not provided with this option, the IRC client may 298 wish to prompt the user for the key. 300 Please see Section 6 of this document. 302 3. Examples 304 While examples of every situation cannot be shown here because of 305 space considerations, the following examples provide a rough overview 306 of how the IRC URL can be used. 308 310 In its simplest form, the above complete URL can be used to direct a 311 client to a specific IRC server, which in this case is 312 "irc.undernet.org". The client should presume to use default port 313 settings. 315 316 317 318 320 All four of these URLs connects to the IRCnet network, and will join 321 the client to the channel "#worldchat" upon connection. All of these 322 URLs are considered identical. 324 326 This will connect to the server "irc.alien.net.au" and will provoke 327 the client to open up a window (or similar) associated with sending 328 messages to the nickname 'pickle'. 330 332 This will connect to AUSTnet and join the channel "#foobar", using 333 the channel key "bazqux". 335 337 This will open a dialogue box prepared to send a message to "pickle" 338 with the server name "butcher.id.au". This URL will connect to the 339 network named as "undernet". For this to work correctly, the client 340 must be configured appropriately to know of at least one server's 341 address associated with this name. 343 345 The above URL specifies that the IRC client should try to connect to 346 "irc.efnet.org" on the port 194, rather than use the default port(s). 347 It also tells the IRC client it should try to connect to the server 348 using the server password "pass". 350 352 This shows a properly [UTF-8] encoded URL, specifying the username 353 "Idil" (with the first character being a Turkish Latin capital letter 354 "I" with a dot above it, [Unicode] codepoint U+0130) and the password 355 "guzel" (with a diaeresis on the u, codepoint U+00FC). 357 4. Internationalisation Considerations 359 With the inevitable adoption of [Unicode] on IRC, and indeed the 360 Internet as a whole, URLs MUST be encoded using the [UTF-8] character 361 set, with (potentially) unsafe octets encoded using %HH notation 362 (where HH is a hexadecimal value), as per Section 2.2.5 of 363 [RFC-2718]. An example of this in action can be found in Section 3. 365 Some IRC servers use such character sets as US-ASCII and KOI-8. It 366 is left up to the client and the server to negotiate an appropriate 367 character set for communication between the two, as more servers are 368 now implementing specific character-set preferences. It is also left 369 up to the client to convert entity names from UTF-8 into the 370 appropriate character set. 372 At the time of writing, [UTF-8] is set to become the popular choice 373 (announced via RPL_ISUPPORT) as it's easy to implement with very 374 minimal changes to existing server software. Other IRC servers are 375 opting to announce a preferred character set, but allow the client to 376 switch character sets on the fly, using CAP/CAPAB negotiation, oft 377 implemented using the UNIX98 iconv() function (or something similar). 379 5. Interoperability Considerations 381 Many existing implementations fail to acknowledge the correct use of 382 the generic URL syntax defined in [RFC2396], but act like they use 383 the format. 385 Some current implementations will need slight modification to accept 386 the extended format defined in this specification, however most 387 implementations which parse the URL in a standard form will continue 388 to work for most IRC URLs. 390 The presumption of a channel name without explicitly specifying the 391 entity type is designed to maintain compatibility with the existing 392 implementations. The practise of omitting the channel prefix 393 character, or not encoding it, is also for compatibility, but is 394 STRONGLY DISCOURAGED. 396 There are interoperability issues with existing IRC servers as a 397 result of the restricted characters available for channel names and 398 nicknames. The restriction of acceptable characters has been left up 399 to the IRC server authors and not the URL scheme, as not to hinder 400 advances in IRC protocols and servers. 402 Some existing IRC servers will accept nickname/password pairs, 403 however at the time of writing these servers do not use this for 404 actually authenticating the session, but instead identifying 405 nicknames to nickname registration services. The use of 406 username/password pairs is used for actual authentication, and has 407 been included. 409 6. Security Considerations 411 Security problems naturally arise when a server password and/or a 412 channel key is specified (using the "key" option). While the use of 413 the password and channel key sections is considered to be rare, and 414 they have been included for uses such as for shortcut/bookmark lists, 415 or to be used as a user command. 417 As the passwords and channel keys are unfortunately passed as clear 418 text, any user using the IRC URL should be aware of obvious 419 insecurities. It is strongly discouraged to use these fields in a 420 public sense, such as on a website. 422 Furthermore, it is recommended that client software does not 423 automatically initiate the connection specified by the URL without 424 the knowledge and consent of the user. To do so would open the 425 implementation up to a variety of malicious activities including, but 426 not limited to, the purposes of direct advertising or channel 427 advertising (known as "spam") via "pop-ups" or other means. 429 When connecting using a secure connection ("ircs://"), user-space 430 ports (those above port 1023) should be treated with suspicion, as 431 their authority could be questionable. If a secure connection cannot 432 be established, the client MUST NOT automatically default to an 433 insecure ("irc://") connection. To do so would denigrate the "ircs" 434 scheme and restrict its usefulness. 436 Automated messages MUST NOT be sent to any entity upon connection to 437 an IRC server as a direct result of execution of an IRC URL. Sending 438 messages to channels and other users should be left up to the user, 439 not the URL author or the client software. The facility to send 440 automated messages to other users has been explicitly avoided in this 441 document to avoid abuse, common with IRC. 443 Clients MUST be aware of protocol limitations, especially when 444 dealing with entity names, as the probability for exploitation is 445 high. For example, a URL with a nickname including "%0D%0A" could be 446 used to exploit a client using using the "IRC-2" protocol, 447 potentially allowing a malicious URL author to execute any command 448 they wish. 450 Beyond this, there are security concerns with regards with associated 451 protocols, including the IRC server-to-user protocols themselves, 452 [TLS] and [UTF-8], which must be taken into consideration, but are 453 beyond the scope of this document. 455 7. IANA Considerations 457 The following is registration for the URL schemes as per [RFC2717]: 459 URL scheme name: Two URI's are described herein: "irc" and "ircs". 461 URL scheme syntax: See Section 2.1, and indeed Section 2 as a 462 whole. 464 Character encoding considerations: Characters must be encoded in 465 UTF-8 and escaped. See Section 4. 467 Intended usage: The scheme initiates connection to an IRC server, 468 normally through the execution of IRC Client software. Further- 469 more, the scheme may then initiate further commands, such as 470 joining channels, as outlined above. 472 Interoperability considerations: See Section 5. 474 Security considerations: See Section 6. 476 Relevant publications: The IRC protocol is defined by [RFC2812]. 477 Either [SSL] or [TLS] may be used for the "ircs" scheme, depending 478 on client and server configuration. 480 Person & email address to contact for further information: The 481 Author; See Section 10 for details. 483 Author/Change controller: The Author's details are contained 484 within Section 10. The IETF is to maintain change control. 486 8. Acknowledgments 488 I acknowledge the previous work of Mandar Mirashi who originally 489 wrote an Internet-Draft to similar effect. 491 The input of Petr Baudis, Robert Ginda, Piotr Kucharski, Perry 492 Lorier, Khaled Mardam-Bey, Dominick Meglio, James Ross, and Samuel 493 Sieb, was greatly appreciated, and this draft would not exist without 494 their valued participation. I also thank them for their patience 495 while I was travelling overseas. 497 I would also like to acknowledge those members of the IRC development 498 community who encouraged me to publish this document, after more than 499 18 months of pretermission. 501 9. References 503 [ABNF] Crocker, D., and Overell, P., "Augmented BNF for Syntax 504 Specifications: ABNF", RFC 2234, November 1997. 506 [PICS] Miller, J., Resnick, P., Singer, D., "Rating Services and 507 Rating Systems (and Their Machine Readable Descriptions)", 508 Version 1.1, , 509 October 1996. 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, March 1997. 514 [RFC2368] Hoffman, P., Masinter, L., Zawinski, J., "The mailto URL 515 scheme", RFC 2368, July 1998. 517 [RFC2396] Berners-Lee, T, Fielding, T., Masinter, L., "Uniform 518 Resource Identifiers (URI): Generic Syntax", RFC 2396, 519 August 1998. 521 [RFC2717] Petke, R., King, I., "Registration Procedures for URL 522 Scheme Names", RFC 2717, November 1999. 524 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., 525 "Guidelines for new URL Schemes", RFC 2718, November 1999. 527 [RFC2811] Kalt, C., "Internet Relay Chat: Channel Management", RFC 528 2811, April 2000. 530 [RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, 531 April 2000. 533 [SSL] Hickman, K., "The SSL Protocol", Netscape Communications 534 Corp., February 9, 1995. 536 [TLS] Dierks, T. and Allen, C., "The TLS Protocol Version 1.0", 537 RFC 2246, January 1999. 539 [Unicode] The Unicode Consortium. The Unicode Standard, Version 540 4.0.0, (Reading, MA, Addison-Wesley, 2003. ISBN 541 0-321-18578-1). 543 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 544 RFC 2279, January 1998. 546 10. Author's Address 548 Simon Butcher 549 Alien Internet Services 551 PO Box 7041 552 Croydon South 553 VIC 3136 554 Australia 556 Phone: +61-3-9879-8052 557 Fax: +61-3-9893-2793 558 Email: simonb@alien.net.au 559 simon@butcher.name 560 simon@butcher.id.au 562 11. Intellectual Property Rights Notice 564 The IETF takes no position regarding the validity or scope of any 565 intellectual property or other rights that might be claimed to 566 pertain to the implementation or use of the technology described in 567 this document or the extent to which any license under such rights 568 might or might not be available; neither does it represent that it 569 has made any effort to identify any such rights. Information on the 570 IETF's procedures with respect to rights in standards-track and 571 standards-related documentation can be found in BCP-11. Copies of 572 claims of rights made available for publication and any assurances of 573 licenses to be made available, or the result of an attempt made to 574 obtain a general license or permission for the use of such 575 proprietary rights by implementers or users of this specification can 576 be obtained from the IETF Secretariat. 578 The IETF invites any interested party to bring to its attention any 579 copyrights, patents or patent applications, or other proprietary 580 rights which may cover technology that may be required to practice 581 this standard. Please address the information to the IETF Executive 582 Director. 584 12. Full Copyright Notice 586 Copyright (C) The Internet Society (2003). All Rights Reserved. 588 This document and translations of it may be copied and furnished to 589 others, and derivative works that comment on or otherwise explain it 590 or assist in its implementation may be prepared, copied, published 591 and distributed, in whole or in part, without restriction of any 592 kind, provided that the above copyright notice and this paragraph are 593 included on all such copies and derivative works. However, this 594 document itself may not be modified in any way, such as by removing 595 the copyright notice or references to the Internet Society or other 596 Internet organizations, except as needed for the purpose of 597 developing Internet standards in which case the procedures for 598 copyrights defined in the Internet Standards process must be 599 followed, or as required to translate it into languages other than 600 English. 602 The limited permissions granted above are perpetual and will not be 603 revoked by the Internet Society or its successors or assigns. 605 This document and the information contained herein is provided on an 606 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 607 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 608 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 609 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 610 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 612 Document Discussion Forum 614 Discussion for this document is currently taking place using the 615 "irc-url@alien.net.au" mailing list in order to keep discussion open 616 and archived appropriately. Those interested in this document are 617 strongly encouraged to join in on the discussion. 619 To subscribe to the mailing list, see: 620 622 Archives of the mailing list are available at: 623 625 Document Expiration and Filename 627 Please note that this is a draft document and it shall expire July 628 2004. Its filename is .