idnits 2.17.1 draft-hardy-irc-isupport-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 783. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 796. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 9 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 2005) is 7040 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: '6' is defined on line 704, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 1459 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2812 (ref. '3') ** Obsolete normative reference: RFC 2234 (ref. '4') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 2811 (ref. '5') ** Obsolete normative reference: RFC 3667 (ref. '6') (Obsoleted by RFC 3978) Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Hardy 2 Internet-Draft E. Brocklesby 3 Expires: July 2, 2005 ircd-ratbox 4 K. Mitchell 5 Undernet IRC Network 6 January 2005 8 IRC RPL_ISUPPORT Numeric Definition 9 draft-hardy-irc-isupport-00 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 2, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 IRC (Internet Relay Chat) is a long-standing protocol for real-time 45 chatting. Servers often provide features that are backward 46 compatible with older clients, but do not provide a reliable method 47 for making clients aware of what extensions exist. This memo 48 presents a method for servers to advertise such extensions to 49 clients. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 55 "OPTIONAL" in this document are to be interpreted as described in RFC 56 2119 [1]. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Problems to be Solved . . . . . . . . . . . . . . . . . . . 5 64 3. The RPL_ISUPPORT numeric . . . . . . . . . . . . . . . . . . 6 66 4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1 CASEMAPPING . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2 CHANLIMIT . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.3 CHANMODES . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.4 CHANNELLEN . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.5 CHANTYPES . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.6 CNOTICE . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.7 CPRIVMSG . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.8 ELIST . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.9 EXCEPTS . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.10 INVEX . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.11 MAXLIST . . . . . . . . . . . . . . . . . . . . . . . . 12 78 4.12 MODES . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.13 NETWORK . . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.14 NICKLEN . . . . . . . . . . . . . . . . . . . . . . . . 13 81 4.15 PREFIX . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 4.16 SAFELIST . . . . . . . . . . . . . . . . . . . . . . . . 14 83 4.17 SILENCE . . . . . . . . . . . . . . . . . . . . . . . . 14 84 4.18 STATUSMSG . . . . . . . . . . . . . . . . . . . . . . . 14 85 4.19 TARGMAX . . . . . . . . . . . . . . . . . . . . . . . . 15 86 4.20 TOPICLEN . . . . . . . . . . . . . . . . . . . . . . . . 15 87 4.21 WATCH . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 5. Differences to existing implementations . . . . . . . . . . 17 90 5.1 Conflicts with RFC2812 . . . . . . . . . . . . . . . . . . 17 91 5.2 Traditional EXCEPTS/INVEX usage . . . . . . . . . . . . . 17 92 5.3 MAXBANS . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 5.4 MAXCHANNELS . . . . . . . . . . . . . . . . . . . . . . . 17 94 5.5 MAXTARGETS . . . . . . . . . . . . . . . . . . . . . . . . 17 95 5.6 WALLCHOPS . . . . . . . . . . . . . . . . . . . . . . . . 18 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 99 7. Security Considerations . . . . . . . . . . . . . . . . . . 20 101 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 107 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 B. ABNF Description of Capabilities . . . . . . . . . . . . . . 24 111 C. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . 25 113 Intellectual Property and Copyright Statements . . . . . . . 26 115 1. Introduction 117 The IRC protocol, as originally documented by RFC 1459 [2] and 118 updated by RFC 2812 [3], is a simple, text-based conferencing 119 protocol, involving a number of users spread across a number of 120 interconnected servers. These users may chat with other individual 121 users, or may chat with groups of users on "channels"--what other 122 chat systems refer to as "rooms" or "chat rooms". These channels 123 have various "modes" which can alter the behaviour of the channel. 125 Over the years, various modifications to the basic IRC protocol have 126 been made by IRC server programmers. These modifications may amongst 127 other things, introduce features available to users and remove some 128 features that were available to users. Due to the wildly varying 129 nature between IRC servers of what features are supported and how the 130 protocol differs from RFC 1459 [2] and RFC 2119 [1], it is 131 problematic for clients to determine just how a server differs from 132 these specifications. 134 A de facto standard emerged in the community, originally implemented 135 by the Undernet's IRC server software based on the 005 numeric from 136 DALnet's IRC server. This standard allows the server to advertise to 137 the client upon connection which extensions to the protocol are 138 supported. This reply, termed RPL_ISUPPORT, uses the non-standard 139 numeric 005. 141 Unfortunately, whilst the numeric itself has become a de-facto 142 standard, differences have emerged between the meaning of extensions 143 advertised. This memo attempts to standardise the format of the 144 RPL_ISUPPORT numeric, as well as standardising the definition of 145 extensions given within this numeric. 147 2. Problems to be Solved 149 The IRC protocol is no longer standardised in many aspects. This 150 means that various IRC daemons support features others do not, and 151 clients need a reliable method of determining which features a server 152 supports. The de-facto standard that emerged to counter this has 153 itself suffered from a lack of standards. 155 The solution to these problems is to formally define a method for 156 servers to advertise to clients the features it supports, and to 157 formally define the features advertised. The client may then rely on 158 this method for reliably determining what features a server supports. 160 3. The RPL_ISUPPORT numeric 162 The extension for informing clients about available features is 163 implemented by the addition of one numeric, RPL_ISUPPORT, which 164 contains a list of features supported by the server. Clients SHOULD 165 NOT assume a server supports a feature unless it has been advertised 166 in RPL_ISUPPORT. 168 In ABNF [4] notation: 170 isupport = [ ":" servername SP ] "005" SP nick SP 171 1*13( token SP ) ":are supported by this server" 173 token = *1"-" parameter / parameter *1( "=" value ) 174 parameter = 1*20letter 175 value = *letpun 176 letter = ALPHA / DIGIT 177 punct = %d33-47 / %d58-64 / %d91-96 / %d123-126 178 letpun = letter / punct 180 where SP is as designated in Appendix A of RFC 2234 [4], and 181 servername and nick are as designated in section 2.3.1 of RFC 1459 182 [2]. As with other local numerics, when RPL_ISUPPORT is delivered 183 remotely, it MUST be converted into a "105" numeric before delivery 184 to the client. 186 A token is of the form "-PARAMETER", "PARAMETER" or 187 "PARAMETER=VALUE". A server MAY send an empty value field and a 188 parameter MAY have a default value. A server MUST send the parameter 189 in upper-case text. Unless otherwise stated, when a parameter 190 contains a value, the value MUST be treated as being case sensitive. 191 The value MAY contain multiple fields, if this is the case the fields 192 MUST be delimited with a comma character (','). 194 Due to the increasingly modular nature of IRC server software, it is 195 possible that the status of features previously advertised to clients 196 in RPL_ISUPPORT can change. When this happens, a server SHOULD 197 reissue the RPL_ISUPPORT numeric with the relevant parameters that 198 have changed. If a feature becomes unavailable, the server MUST 199 prefix the parameter with the dash character ('-') when issuing the 200 updated RPL_ISUPPORT. 202 As RFC 1459 [2] limits the maximum parameters of any reply to 15, the 203 maximum amount of extensions that may be advertised is 13. To 204 counter this, a server MAY issue multiple RPL_ISUPPORT numerics. A 205 server MUST issue the RPL_ISUPPORT numeric after client registration 206 has completed. It MUST be issued after the RPL_WELCOME (XXX - 207 reference?) welcome and MUST be issued before any further commands 208 from the client are processed. 210 4. Parameters 212 Servers MAY send parameters that are not covered in this 213 specification. 215 4.1 CASEMAPPING 217 CASEMAPPING=string 219 The CASEMAPPING parameter is used to indicate what method is used by 220 the server to compare equality of case-insensitive strings. Possible 221 values are: 222 o "ascii": The ASCII characters 97 to 122 (decimal) are defined as 223 the lower-case characters of ASCII 65 to 90 (decimal). No other 224 character equivalency is defined. 226 o "rfc1459": The ASCII characters 97 to 126 (decimal) are defined as 227 the lower-case characters of ASCII 65 to 94 (decimal). No other 228 character equivalency is defined. 230 o "strict-rfc1459": The ASCII characters 97 to 125 (decimal) are 231 defined as the lower-case characters of ASCII 65 to 93 (decimal). 232 no other character equivalency is defined. 234 The value MUST be specified. Whilst RFC 1459 [2] defines character 235 equivalency in terms of "strict-rfc1459" encoding, this is believed 236 to be a mistake as the majority of IRC server implementations treat 237 character equivalency in terms of "rfc1459" encoding with the tilde 238 character ('~') and caret character ('^') being equivalent. 240 An example CASEMAPPING token: 241 CASEMAPPING=rfc1459 243 4.2 CHANLIMIT 245 CHANLIMIT=prefix:number[,prefix:number[,...]] 247 The CHANLIMIT parameter is used to indicate the maximum amount of 248 channels that a client may join. The value is a series of 249 "prefix:number" pairs, where "prefix" refers to one or more prefix 250 characters defined in the PREFIX (Section 4.15) token, and "number" 251 indicates how many channels of the given type combined may be joined. 252 The number parameter MAY be omitted if no limit is placed on the 253 number of channels. 255 A client SHOULD NOT make any assumptions about how many channels 256 other clients may join based on the CHANLIMIT parameter. 258 An example CHANLIMIT token: 259 CHANLIMIT=#+:25,&: 260 Indicates that a client may join up to 25 channels with the prefix 261 '#' and '+', and an unlimited amount of channels with the '&' prefix. 263 4.3 CHANMODES 265 CHANMODES=A,B,C,D 267 The CHANMODES parameter is used to indicate the channel modes 268 available and the arguments they take. There are four categories of 269 modes, defined as follows: 270 o Type A: Modes that add or remove an address to or from a list. 271 These modes MUST always have a parameter when sent from the server 272 to a client. A client MAY issue the mode without an argument to 273 obtain the current contents of the list. 275 o Type B: Modes that change a setting on a channel. These modes 276 MUST always have a parameter. 278 o Type C: Modes that change a setting on a channel. These modes 279 MUST have a parameter when being set, and MUST NOT have a 280 parameter when being unset. 282 o Type D: Modes that change a setting on a channel. These modes 283 MUST NOT have a parameter. 285 To allow for future extensions, a server MAY send additional types, 286 delimeted by the comma character (','). The behaviour of any 287 additional types is undefined. 289 The IRC server MUST NOT list modes in the CHANMODES parameter that 290 are contained within the PREFIX (Section 4.15) parameter. However, 291 for completeness, modes within the PREFIX (Section 4.15) parameter 292 may be treated as type B modes. 294 An example CHANMODES token: 295 CHANMODES=b,k,l,imnpst 297 4.4 CHANNELLEN 299 CHANNELLEN=number 301 The CHANNELLEN parameter specifies the maximum length of a channel 302 name that a client may join. A client elsewhere on the network MAY 303 join a channel with a name length of higher value. The value MUST be 304 specified and MUST be numeric. 306 An example CHANNELLEN token: 307 CHANNELLEN=50 308 Limits the length of a channel name that a user may join to 50 309 characters. 311 4.5 CHANTYPES 313 CHANTYPES=[string] 315 Special characters used as prefixes are reserved to differentiate 316 channels from other namespaces within the IRC protocol. The 317 CHANTYPES parameter specifies these characters. 319 The value is OPTIONAL and when is not specified indicates that no 320 channel types are supported. 322 An example CHANTYPES token: 323 CHANTYPES=&# 324 Denotes the ampersand ('&') and hash ('#') characters as channel 325 prefixes. 327 4.6 CNOTICE 329 CNOTICE 331 The CNOTICE parameter indicates that the server supports the 332 "CNOTICE" command. An extension for the NOTICE command, as defined 333 in RFC 1459 [2] section 4.4.2, it allows users with a specific status 334 in a channel to issue a NOTICE command to a user within that channel, 335 free of certain restrictions a server MAY apply to NOTICE. 337 The CNOTICE parameter MUST NOT be specified with a value. 339 An example CNOTICE token: 340 CNOTICE 342 4.7 CPRIVMSG 344 CPRIVMSG 346 The CPRIVMSG parameter indicates that the server supports the 347 "CPRIVMSG" command. An extension for the PRIVMSG command, as defined 348 in RFC 1459 [2] section 4.4.1, it allows users with a specific status 349 in a channel to issue a PRIVMSG command to a user within that 350 channel, free of certain restrictions a server MAY apply to PRIVMSG. 352 The CPRIVMSG parameter MUST NOT be specified with a value. 354 An example CPRIVMSG token: 355 CPRIVMSG 357 4.8 ELIST 359 ELIST=string 361 The ELIST parameter indicates that the server supports search 362 extensions to the LIST command. The value is required, and is a 363 non-delimited set of letters which each denote an extension. The 364 following extensions, which a client MUST treat as being case 365 insensitive are defined: 366 o C: Searching based on creation time, via the "Cval" 367 modifiers to search for a channel creation time that is lower or 368 higher than val respectively. 370 o M: Searching based on mask. 372 o N: Searching based on !mask. 374 o P: To explain 376 o T: Searching based on topic time, via the "Tval" 377 modifiers to search for a topic time that is lower or higher than 378 val respectively. 380 o U: Searching based on user count within the channel, via the 381 "val" modifiers to search for a channel that has less 382 than or more than val users respectively. 384 An example ELIST token: 385 ELIST=CMNTU 387 4.9 EXCEPTS 389 EXCEPTS[=letter] 391 The EXCEPTS parameter indicates that the server supports "ban 392 exceptions", as defined in RFC 2811 [5] section 4.3.1. The value is 393 OPTIONAL and when is not specified indicates that that the letter 'e' 394 is used as the channel mode for ban exceptions. When the value is 395 specified, it indicates the letter which is used for ban exceptions. 397 An example EXCEPTS token: 398 EXCEPTS 400 4.10 INVEX 402 INVEX[=letter] 404 The INVEX parameter indicates that the server supports "invite 405 exceptions", as defined in RFC 2811 [5] section 4.3.2. The value is 406 OPTIONAL and when is not specified indicates that the letter 'I' is 407 used as the channel mode for invite exceptions. When the value is 408 specified, it indicates the letter which is used for invite 409 exceptions. 411 An example INVEX token: 412 INVEX 414 4.11 MAXLIST 416 MAXLIST=mode:number[,mode:number[,...]] 418 The MAXLIST parameter limits how many "variable" modes of type A that 419 have been defined in the CHANMODES (Section 4.3) token a client may 420 set in total on a channel. The value MUST be specified and is a set 421 of "mode:number" pairs, where "mode" refers to a type A mode defined 422 in the CHANMODES (Section 4.3) token and "number" indicates how many 423 of the given modes combined a client may issue on a channel. 425 A client MUST NOT make any assumptions about how many of the given 426 modes may actually exist on the channel. The limit applies only to 427 the client setting new modes of the given types. 429 Example MAXLIST tokens: 430 MAXLIST=beI:25 431 Indicates that a client may set up to a total of 25 of a combination 432 of "+b", "+e" and "+I" modes. 433 MAXLIST=b:25,eI:50 434 Indicates that a client may set up to a total of 25 "+b" modes and up 435 to a total of 50 of a combination of "+e" and "+I" modes. 437 4.12 MODES 439 MODES=[number] 441 The MODES parameter limits how many "variable" modes may be set on a 442 channel by a single MODE command from a client. A "variable" mode is 443 defined as being type A, B and C as defined for the CHANMODES 444 (Section 4.3) parameter, and the channel modes specified in the 445 PREFIX (Section 4.15) parameter. 447 A client SHOULD NOT issue more "variable" modes than this in a single 448 MODE command. A server MAY however issue more "variable" modes than 449 this value in a single MODE command. The value is OPTIONAL and when 450 is not specified indicates that no limit is placed upon "variable" 451 modes. The value, if specified, MUST be numeric. 453 An example MODES token: 454 MODES=3 455 Limits the number of "variable" modes from a client to the server to 456 3 per MODE command. 458 4.13 NETWORK 460 NETWORK=string 462 The NETWORK parameter is for informational purposes only and defines 463 the name of the IRC network that the client is connected to. The 464 value MUST be specified. A client SHOULD NOT use the value to make 465 assumptions about supported features on the server. 467 An example NETWORK token: 468 NETWORK=EFnet 469 Indicates the client is connected to the EFnet IRC network. 471 4.14 NICKLEN 473 NICKLEN=number 475 The NICKLEN parameter specifies the maximum length of a nickname that 476 a client can use. A client elsewhere on the network MAY use a nick 477 length of higher value. The value MUST be specified and MUST be 478 numeric. 480 An example NICKLEN token: 481 NICKLEN=9 482 Limits the length of a nickname to 9 characters 484 4.15 PREFIX 486 PREFIX=[(modes)prefixes] 488 Within channels, clients can have various different statuses, denoted 489 by single character "prefixes". The PREFIX parameter specifies these 490 prefixes and the channel mode character that it is mapped to. There 491 is a one-to-one mapping between prefixes and channel modes. The 492 prefixes are in descending order, from the prefix that gives the most 493 privileges to the prefix that gives the least. 495 The value is OPTIONAL and when it is not specified indicates that no 496 prefixes are supported. 498 An example PREFIX token: 499 PREFIX=(ov)@+ 500 Denotes the at character ('@') as mapping to the channel mode denoted 501 by the letter 'o', and the plus character ('+') as mapping to the 502 channel mode denoted by the letter 'v'. 504 4.16 SAFELIST 506 SAFELIST 508 The SAFELIST parameter indicates that the client may request a "LIST" 509 command from the server, without being disconnected by the large 510 volume of data the LIST command generates. The SAFELIST parameter 511 MUST NOT be specified with a value. 513 An example SAFELIST token: 514 SAFELIST 516 4.17 SILENCE 518 SILENCE=number 520 The SILENCE parameter indicates the maximum number of entries a user 521 may have in their silence list. The value is OPTIONAL and if it is 522 not specified indicates SILENCE support is not available. 524 Whilst a formal definition of the SILENCE command is outside the 525 scope of this document, it is generally a list of masks of equivalent 526 form to those defined as type A in the CHANMODES (Section 4.3) 527 parameter. Any messages, as defined in RFC 2812 [3] section 3.3, 528 that originate from another client matching the given mask, with a 529 destination of the client itself will be dropped by the server. 531 An example SILENCE token: 532 SILENCE=15 533 Indicates a client may have upto 15 masks in their silence list. 535 4.18 STATUSMSG 537 STATUSMSG=string 539 The STATUSMSG parameter indicates that the server supports a method 540 for the client to send a message via the NOTICE command to those 541 people on a channel with the specified status. 543 The value MUST be specified and MUST be a non-delimited list of 544 prefixes that have been defined in the PREFIX (Section 4.15) 545 parameter. The server MUST NOT advertise a character in STATUSMSG 546 which is also present in CHANTYPES (Section 4.5). 548 An example STATUSMSG token: 549 STATUSMSG=@+ 550 Presuming the hash character ('#') is defined within the CHANTYPES 551 (Section 4.5) parameter, allows the client to send a NOTICE command 552 to "@#channel" and "+#channel". 554 4.19 TARGMAX 556 TARGMAX=[cmd:number,cmd:number,...] 558 Certain commands from a client MAY contain multiple targets, 559 delimited by a comma character (','). The TARGMAX parameter defines 560 the maximum number of targets allowed for commands which accept 561 multiple targets. The value is OPTIONAL and is a set of "cmd:number" 562 pairs, where "cmd" refers to a command the client MAY send to the 563 server, and "number" refers to the maximum targets for this command. 564 A client MUST treat the "cmd" field as case insensitive. 566 If the number is not specified for a particular command, then the 567 command does not have a limit on the number of targets. The server 568 MUST specify all commands available to the user which support 569 multiple targets. 571 If the TARGMAX parameter is not advertised, or a value is not sent 572 then a client SHOULD assume that no commands except the "JOIN" and 573 "PART" commands accept multiple parameters. 575 An example TARGMAX token: 576 TARGMAX=PRIVMSG:3,WHOIS:1,JOIN: 577 Indicates that a client could issue 3 targets to a PRIVMSG command, 1 578 target to a WHOIS command and an unlimited amount of targets to a 579 JOIN command. 581 4.20 TOPICLEN 583 TOPICLEN=number 585 The TOPICLEN parameter specifies the maximum length of a topic, 586 defined in RFC 1459 [2] section 4.2.4 that a client may set on a 587 channel. A channel on the network MAY have a topic with a longer 588 length. The value MUST be specified and MUST be numeric. 590 An example TOPICLEN token: 591 TOPICLEN=120 592 Limits the length of a topic to 120 characters. 594 4.21 WATCH 596 WATCH=number 598 The WATCH parameter indicates the maximum number of nicknames a user 599 may have in their watch list. The value MUST be specified. 601 Whilst a formal definition of the WATCH command is outside the scope 602 of this document, it is generally used a method for clients to have 603 the server notify them when a given nickname joins or leaves the 604 network. It is designed to replace repetitive use by clients of the 605 ISON command, as defined in RFC 1459 [2] section 5.8. 607 An example WATCH token: 608 WATCH=100 609 Indicates that a client may have upto 100 nicks in their watch list. 611 5. Differences to existing implementations 613 A number of differences exist between this specification and existing 614 implementations in current IRC server software. 616 5.1 Conflicts with RFC2812 618 RFC 2812 [3] section 5.1, defines a numeric reply "RPL_BOUNCE" with 619 the associated numeric "005". This conflicts with the numeric 620 defined within this document for RPL_ISUPPORT. As RFC 2812 [3] is an 621 Informational RFC and 005 has been widely adopted as the de-facto 622 standard numeric for RPL_ISUPPORT, this is not seen as problematic. 623 Moreover, the only server implementation known to implement RFC 2812 624 [3] moved the RPL_BOUNCE numeric to 010 and adopted the RPL_ISUPPORT 625 numeric as 005. 627 5.2 Traditional EXCEPTS/INVEX usage 629 The EXCEPTS (Section 4.9) and INVEX (Section 4.10) parameters 630 traditionally take no argument. Whilst they indicate the presence of 631 these features on the server, they rely on these features using the 632 +e and +I channel modes respectively. The argument value described 633 provides extra flexibility whilst retaining backwards compatibility. 635 5.3 MAXBANS 637 The MAXBANS parameter was replaced by the MAXLIST (Section 4.11) 638 parameter. MAXBANS was considered non-useful, because of its 639 ambiguous meaning; two of the largest IRC networks for example could 640 not agree whether "MAXBANS=n" was equivalent to "MAXLIST=beI:n" or 641 "MAXLIST=b:n,e:n,I:n". MAXLIST is also considered considerably more 642 flexible and can more accurately define the servers behaviour. 644 5.4 MAXCHANNELS 646 The MAXCHANNELS parameter was replaced by the CHANLIMIT (Section 4.2) 647 parameter. Some IRC server implementations did not apply any limits 648 to server-local "&" channels, the MAXCHANNELS parameter did not 649 reflect this and so the CHANLIMIT (Section 4.2) parameter was 650 introduced to replace MAXCHANNELS, as it can more accurately define 651 the server implementation. 653 5.5 MAXTARGETS 655 The MAXTARGETS parameter was replaced by the TARGMAX (Section 4.19) 656 parameter. As which commands MAXTARGETS applied to is unclear and 657 different target limits can often apply to different commands, it was 658 believed the TARGMAX parameter could more accurately define which 659 commands may contain multiple targets. 661 5.6 WALLCHOPS 663 The WALLCHOPS parameter was replaced by the STATUSMSG (Section 4.18) 664 parameter. It is believed the STATUSMSG (Section 4.18) parameter is 665 more flexible. Some IRC server implementations also implemented a 666 "WALLCHOPS" command, and it was unclear whether the parameter 667 indicated support for this command or not. This behaviour is still 668 unclear. 670 6. IANA Considerations 672 This memo does not raise any IANA considerations. 674 7. Security Considerations 676 This memo does not raise any security considerations. 678 8. Acknowledgments 680 The authors gratefully acknowledges the contributions of Bill Fenner 681 ("fenestro"), Perry Lorier ("Isomer"), Kurt Roeckx ("Q") and John 682 Midgley ("CrazyEddy") in the preparation of this document. 684 This document is heavily based on a previous document entitled "The 685 005 numeric". 687 9 References 689 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 690 Levels", BCP 14, RFC 2119, March 1997. 692 [2] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 693 1459, May 1993. 695 [3] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, 696 April 2000. 698 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 699 Specifications: ABNF", RFC 2234, November 1997. 701 [5] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, 702 April 2000. 704 [6] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, 705 February 2004. 707 Authors' Addresses 709 Lee Hardy 710 ircd-ratbox development team 712 EMail: lee@leeh.co.uk 713 URI: http://www.leeh.co.uk 715 Edward Brocklesby 716 ircd-ratbox development team 717 57 Williamson Way 718 Oxford OX4 4TU 719 UK 720 Kevin L. Mitchell 721 Undernet IRC Network 722 38 Eighth St., Apt. 7 723 Cambridge, Massachusetts 02141 724 US 726 Phone: +1-617-230-1021 727 EMail: klmitch@mit.edu 728 URI: http://www.mit.edu/~klmitch/ 730 Appendix A. Examples 732 The following examples show various RPL_ISUPPORT messages from 733 various IRC server software. 735 Example network 737 :server 005 nickname foo 739 Appendix B. ABNF Description of Capabilities 741 This section summarizes the ABNF [4] description of the RPL_ISUPPORT 742 extension. 744 Appendix C. ChangeLog 746 Note to RFC Editor: This section may be removed on publication as an 747 RFC. 749 Here is a log of changes to this document: 751 2005-01-28 LH Initial draft written, borrowing heavily from the old 752 i-d by Edward Brocklesby. 753 2005-01-29 LH 754 * Fleshed out information on CPRIVMSG, CNOTICE, WATCH and SILENCE 755 tokens. 756 * Added CHANNELLEN token. 757 * Added TOPICLEN token. 758 * Added TARGMAX token. 760 2005-02-02 LH 761 * Documented differences to traditional EXCEPTS/INVEX usage. 762 * Added the old WALLCHOPS token under differences. 763 * Added the old MAXBANS token under differences. 764 * Added the old MAXTARGETS token under differences. 765 * Added the old MAXCHANNELS token under differences. 767 2005-02-03 LH 768 * "Add r remote" to "Add or remove" in CHANMODES. 769 * Make SILENCE= indicate its unsupported. 770 * Remove some stuff from STATUSMSG thats beyond the scope of this 771 document. 772 * Clarify ETRACE modifiers. 774 Intellectual Property Statement 776 The IETF takes no position regarding the validity or scope of any 777 Intellectual Property Rights or other rights that might be claimed to 778 pertain to the implementation or use of the technology described in 779 this document or the extent to which any license under such rights 780 might or might not be available; nor does it represent that it has 781 made any independent effort to identify any such rights. Information 782 on the procedures with respect to rights in RFC documents can be 783 found in BCP 78 and BCP 79. 785 Copies of IPR disclosures made to the IETF Secretariat and any 786 assurances of licenses to be made available, or the result of an 787 attempt made to obtain a general license or permission for the use of 788 such proprietary rights by implementers or users of this 789 specification can be obtained from the IETF on-line IPR repository at 790 http://www.ietf.org/ipr. 792 The IETF invites any interested party to bring to its attention any 793 copyrights, patents or patent applications, or other proprietary 794 rights that may cover technology that may be required to implement 795 this standard. Please address the information to the IETF at 796 ietf-ipr@ietf.org. 798 Disclaimer of Validity 800 This document and the information contained herein are provided on an 801 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 802 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 803 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 804 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 805 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 806 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 808 Copyright Statement 810 Copyright (C) The Internet Society (2005). This document is subject 811 to the rights, licenses and restrictions contained in BCP 78, and 812 except as set forth therein, the authors retain all their rights. 814 Acknowledgment 816 Funding for the RFC Editor function is currently provided by the 817 Internet Society.