idnits 2.17.1 draft-brocklesby-irc-isupport-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the server has not advertised a CHARSET parameter, it MUST not use such sequences with a value outside those permitted by the above ABNF grammar, with the exception of "\x20"; if it has advertised CHARSET, then it may in addition send any printable character defined in that encoding. Characters in multibyte encodings such as UTF-8 should be sent as a series of \x sequences. -- 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 5, 2004) is 7416 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 816, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 2811 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2812 (ref. '4') ** Downref: Normative reference to an Experimental RFC: RFC 1459 (ref. '5') Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Brocklesby 3 Internet-Draft January 5, 2004 4 Expires: July 5, 2004 6 IRC RPL_ISUPPORT Numeric Definition 7 draft-brocklesby-irc-isupport-03 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on July 5, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This memo presents a way for the server to unobtrusively advertise 38 the ways in which it differs from the Internet Relay Chat (IRC) 39 specification defined in RFC1459. It is a primary goal to implement 40 this in a way which is completely backwards-compatible with the 41 original protocol, and as much as possible with current non-standard 42 implementations of the ISUPPORT numeric. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.2 Changes to previous version . . . . . . . . . . . . . . . . 3 49 1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.4 Notes on examples . . . . . . . . . . . . . . . . . . . . . 4 51 2. Protocol outline . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Currently defined parameters . . . . . . . . . . . . . . . . 7 53 3.1 CASEMAPPING . . . . . . . . . . . . . . . . . . . . . . . . 7 54 3.2 CHANLIMIT . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.3 CHANMODES . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 3.4 CHANNELLEN . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 3.5 CHANTYPES . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 3.6 EXCEPTS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 3.7 IDCHAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 3.8 INVEX . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 3.9 KICKLEN . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 3.10 MAXLIST . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 3.11 MODES . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.12 NETWORK . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.13 NICKLEN . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 3.14 PREFIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 3.15 SAFELIST . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 3.16 STATUSMSG . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 3.17 STD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 3.18 TARGMAX . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 3.19 TOPICLEN . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 4. Differences to existing implementations . . . . . . . . . . 16 73 4.1 PREFIX parameter without value . . . . . . . . . . . . . . . 16 74 4.2 EXCEPTS and INVEX value argument . . . . . . . . . . . . . . 16 75 4.3 STATUSMSG / WALLCHOPS . . . . . . . . . . . . . . . . . . . 16 76 4.4 Conflicts with RFC 2812 . . . . . . . . . . . . . . . . . . 16 77 4.5 Default value for CASEMAPPING . . . . . . . . . . . . . . . 17 78 4.6 CHANLIMIT / MAXCHANNELS . . . . . . . . . . . . . . . . . . 17 79 4.7 MAXLIST / MAXBANS . . . . . . . . . . . . . . . . . . . . . 17 80 4.8 CHARSET . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 4.9 TARGMAX / MAXTARGETS . . . . . . . . . . . . . . . . . . . . 17 82 5. Security Considerations . . . . . . . . . . . . . . . . . . 18 83 Normative References . . . . . . . . . . . . . . . . . . . . 18 84 Informative references . . . . . . . . . . . . . . . . . . . 18 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 86 A. Default ISUPPORT values . . . . . . . . . . . . . . . . . . 18 87 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 88 Intellectual Property and Copyright Statements . . . . . . . 20 90 1. Introduction 92 1.1 Terminology 94 o Original IRC protocol: The original IRC protocol as described in 95 RFC 1459 [5]. 96 o The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 97 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in 99 RFC 2119 [1]. 100 o The ABNF syntax used in this document is defined in RFC 2234 [2] 101 o The term "character" is this document is used to mean an octet, as 102 defined in RFC 1459 [5], section 2.2. 104 1.2 Changes to previous version 106 [Note: To be removed by the RFC editor prior to publication.] 108 The follow significant changes were made from version 02 to version 109 03 of this document: 111 o The semantics of MAXCHANNELS were changed and it was renamed to 112 CHANLIMIT. 113 o The semantics of CHIDLEN were changed and it was renamed to 114 IDCHAN. 115 o The description of the protocol was clarified significantly, as 116 were several parameter definitions. Several recommendations of 117 what the client should do when faced with protocol violations by 118 the server were also removed. 119 o Several implications or recommendations of client or server 120 behaviour were changed into requirements or removed entirely. 121 o In particular, the server is now required to send STD as the first 122 parameter upon client registration, followed by all defined 123 parameters which have no default value. 124 o The specification of a parameter's value was changed to allow 125 "\xHH" sequences, to represent spaces and other characters. This 126 feature is considered experimental and comments are particular 127 appreciated. 128 o Delivery of 005 numerics from remote servers is now explicitly 129 prohibited. 130 o The CHARSET parameter was found to be unworkable and has been 131 entirely removed. 132 o The TARGMAX parameter was added. 133 o "X" and "X=" were made identical. 135 1.3 Motivation 137 Since the publication of RFC 1459 [5] in 1993, a number of changes 138 and extensions have been made to the IRC protocol. This has led to a 139 problem whereby clients are unable to correctly interpret some server 140 replies, because the reply, channel mode, and so on may have 141 different meanings on different implementations of the IRC server. 142 It is also difficult for the client to ascertain which protocol 143 extensions may be available on a specific server. 145 A de facto standard has emerged in the community, originally 146 implemented by the Undernet's IRC server software based on the 005 147 numeric from DALnet's IRC server, which allows the server to 148 advertise to the client upon connection which protocol extensions it 149 supports. This reply, termed RPL_ISUPPORT, uses the non-standard 150 numeric 005. 152 Unfortunately, since there is no standard document describing the 153 ISUPPORT numeric, differences have emerged between implementations in 154 IRC server software; it is believed that this reduces the potential 155 usefulness of the feature. This memo attempts to standardise the 156 format and content of the ISUPPORT numeric in an extensible way, such 157 that IRC clients can use the information provided to the maximum 158 extent. 160 1.4 Notes on examples 162 Several examples of protocol replies are given throughout this 163 document. These are intended only for clarification of the protocol; 164 in the case of a discrepancy between the example and the formal 165 specification, the specification is always preferred. 167 2. Protocol outline 169 The ISUPPORT numeric consists of a series of parameters, each of 170 which maps to a protocol extension supported by the IRC server. A 171 parameter may have an associated value, typically a numeric or string 172 value, which provides additional information on the extension. 174 The format of the ISUPPORT numeric is the same as other server 175 numeric replies currently used. A client which does not understand 176 the numeric may ignore it; however, it is recommended that IRC 177 clients understand ISUPPORT, in order to allow users the full benefit 178 of features implemented by the IRC server. 180 The ABNF grammar for the numeric is as follows: 182 isupport = ":" servername SP "005" SP nickname SP 183 1*13( token SP ) ":are supported by this server" 185 token = *1"-" parameter / parameter *1( "=" value ) 186 parameter = 1*20letter 187 value = *letpun 188 letter = ALPHA / DIGIT 189 punct = %d33-47 / %d58-64 / %d91-96 / %d123-126 190 letpun = letter / punct 192 The format of the postfix descriptive text is not fixed, and may be 193 any string subject to the requirements of RFC 1459 [5] regarding 194 numeric replies. Servername and nickname are as defined in RFC 1459 195 [5]. 197 The "servername" MUST be the name of the server to which the client 198 is connected; the 005 numeric is never sent remotely across the 199 network. As with other local numerics, when delivered remotely it 200 MUST be converted into a 105 numeric before delivery to the client. 202 A token is of the form "PARAMETER[=VALUE]" or "-PARAMETER". The forms 203 "X" and "X=" are identical; they both define that the parameter is 204 present but has no value. The server SHOULD send "X", not "X="; this 205 is the normalised form. 207 The server MUST send the parameter in upper-case text; unless 208 otherwise stated, the parameter's value is case sensitive. 210 The parameter's value may contain sequences of the form "\xHH", where 211 HH is a two-digit hexadecimal number. Each such sequence is 212 considered identical to the equivalent octet after parsing of the 213 reply into separate tokens has occurred. 215 [Example: X=A\x20B defines one token, "X", with the value "A B", 216 rather than two tokens "X" and "B".] 217 [Note: The literal string "\x" must therefore be encoded as 218 "\x5Cx".] 220 If the server has not advertised a CHARSET parameter, it MUST not use 221 such sequences with a value outside those permitted by the above ABNF 222 grammar, with the exception of "\x20"; if it has advertised CHARSET, 223 then it may in addition send any printable character defined in that 224 encoding. Characters in multibyte encodings such as UTF-8 should be 225 sent as a series of \x sequences. 227 RFC 1459 [5] defines a maximum of 15 parameters to any reply, 228 including the nickname and the text; therefore, only 13 capabilities 229 are possible per reply. 231 In order to allow flexibility in the protocol, and future expansion, 232 the server may send more than one ISUPPORT reply per connection. It 233 is RECOMMENDED that consecutive ISUPPORT replies are sent adjacent to 234 each other. The client MUST support receiving multiple ISUPPORT 235 replies, and merge them to produce the final list of supported 236 protocol extensions. It is RECOMMENDED that the server attempt to 237 send 13 tokens per line before sending multiple replies. 239 On connection to the server, all parameters are assumed to be equal 240 to their default values, if any. Unless later changed by the server, 241 this default value persists throughout the connection. Except as 242 explicitly stated in its definition, a parameter SHOULD NOT be sent 243 unless it changes this default value. The server MUST send an 005 244 reply after client registration but before any further client 245 commands are processed in order to resolve any ambiguities in 246 parameters with no default value. 248 The form "-PARAMETER" is used to negate a previously specified 249 parameter; that is, revert to the behaviour that would occur if the 250 parameter had not been specified. This is intended to allow servers 251 to change their capabilities without disconnecting clients. Both 252 parameters with and without a value argument may be negated; however, 253 the value argument is not supplied. It is not required to negate a 254 parameter in order to change its value, the server should merely 255 re-advertise the parameter with the new value. 257 The server may negate tokens which have not been previously 258 advertised to the client; in this case, the client should ignore the 259 negation. 261 The server may not advertise and negate the same parameter, nor 262 advertise the same parameter with different value specifiers, in the 263 same ISUPPORT numeric reply. However, the server is free to 264 advertise or negate the same parameters in separate replies. 266 The server MUST NOT negate a parameter which does not have a 267 meaningful default value. 269 [Note: Implementations often change the value of a particular 270 parameter upon certain events, such as a successful OPER command 271 from a client. It is important that any relevant parameters be 272 (re)advertised when this occurs.] 274 3. Currently defined parameters 276 A number of parameters are currently used in the IRC community, and 277 it is believed to be beneficial to standardise these. They are 278 listed below, with relevant information. 280 [Note: It is intended and expected that future documents will 281 update and extend the set of defined parameters; this is not meant 282 to be an exhaustive list.] 284 3.1 CASEMAPPING 286 o CASEMAPPING=string 288 The CASEMAPPING parameter allows the server to specify which method 289 it uses to compare equality of case-insensitive strings. Possible 290 values are: 292 o "ascii": The ASCII characters 97 to 122 (decimal) are defined as 293 the lower-case characters of ASCII 65 to 90 (decimal). No other 294 character equivalency is defined. 295 o "rfc1459": The ASCII characters 97 to 126 (decimal) are defined as 296 the lower-case characters of ASCII 65 to 94 (decimal). No other 297 character equivalency is defined. 298 o "strict-rfc1459": The ASCII characters 97 to 125 (decimal) are 299 defined as the lower-case characters of ASCII 65 to 93 (decimal). 300 No other character equivalency is defined. 302 [Note: The only difference between "rfc1459" and "strict-rfc1459" 303 is that the characters "~" and "^" are not considered equivalent 304 in the "strict-rfc1459" encoding. This is believed to be an 305 mistake in the specification of character equivalency in RFC 1459 306 [5]; the majority of IRC server implementations known to the 307 author treat these characters as equivalent (however, see Section 308 4.5).] 310 The CASEMAPPING token requires a value. 312 The default value for CASEMAPPING is "rfc1459". While this differs 313 from the historical definition in RFC 1459 [5], it is believed to 314 reflect current IRC server implementations, and is as such more 315 useful. 317 3.2 CHANLIMIT 319 o CHANLIMIT=pfx:num[,pfx:num,...] 321 This parameter specifies the maximum number of channels that a client 322 may join. The value is a series of "pfx:num" pairs, where 'pfx' 323 refers to one or more channel prefix characters (as specified in 324 CHANTYPES), and 'num' indicates how many of these types of channel 325 the client may join in total. If there is no limit to the number of 326 certain channel type(s) a client may join, the limit should be 327 specified as the empty string, for example "#:". 329 [Example: CHANLIMIT=#+:10,&: indicates that a client may join up to 330 10 '#' and '+' channels (for example, 7 '#' channels and 3 '+' 331 channels), and any number of '&' channels.] 333 Clients on either this server or a remote server may be on more than 334 this number of channels; this parameter is only intended for 335 information on how many channels the client it is advertised to may 336 join. 338 There is no default value for the CHANLIMIT token. 340 The CHANLIMIT token requires a value. 342 3.3 CHANMODES 344 o CHANMODES=A,B,C,D 346 The CHANMODES token specifies the modes that may be set on a channel. 347 These modes are split into four categories, as follows: 349 o Type A: Modes that add or remove an address to or from a list. 350 These modes always take a parameter when sent by the server to a 351 client; when sent by a client, they may be specified without a 352 parameter, which requests the server to display the current 353 contents of the corresponding list on the channel to the client. 354 o Type B: Modes that change a setting on the channel. These modes 355 always take a parameter. 356 o Type C: Modes that change a setting on the channel. These modes 357 take a parameter only when set; the parameter is absent when the 358 mode is removed both in the client's and server's MODE command. 359 o Type D: Modes that change a setting on the channel. These modes 360 never take a parameter. 362 If the server sends any additional types after these 4, the client 363 MUST ignore them; this is intended to allow future extension of this 364 token. 366 The IRC server MUST NOT list modes in CHANMODES which are also 367 present in the PREFIX parameter; however, for completeness, modes 368 described in PREFIX may be treated as type B modes. 370 If the server does not support any modes corresponding to a 371 particular type, it should advertise that type as the empty string. 373 [Example: A server supporting no channel modes would advertise 374 "CHANMODES=,,,".] 375 [Example: CHANMODES=b,k,l,imnpst] 377 The CHANMODES token requires a value. 379 There is no default value for the CHANMODES token. 381 3.4 CHANNELLEN 383 o CHANNELLEN=number 385 The CHANNELLEN parameter specifies the maximum length of the name of 386 a channel that may be created by a client. The server may make known 387 to the client a channel with a name longer than that specified in 388 this value -- that is, the client must not depend on a channel's name 389 never being longer than this. 391 The CHANNELLEN token does not require a value; if none is given, 392 channel names are not limited in length. If a value is given, it 393 must be numeric. 395 The default value for CHANNELLEN is 200; this corresponds to RFC 1459 396 [5]. 398 3.5 CHANTYPES 400 o CHANTYPES=chars 402 The CHANTYPES parameter specifies the valid characters to begin a 403 channel name. 405 [Example: CHANTYPES=+#& defines that channels names may begin with 406 either +, #, or &; for example, #mychannel.] 408 The default value for CHANTYPES is "CHANTYPES=#&", which corresponds 409 to RFC 1459 [5]. It SHOULD NOT be specified if the server supports 410 exactly these channel types. 412 The CHANMODES parameter does not require a value; if none is given, 413 the server does not support any channel types. 415 3.6 EXCEPTS 416 o EXCEPTS[=modechar] 418 The EXCEPTS parameter indicates that the server supports "ban 419 exceptions" (channel mode +e), as defined in RFC 2811 [3], section 420 4.3.1. The optional value argument to EXCEPTS indicates which channel 421 mode is used for ban exceptions. If the token is specified with no 422 value, it is assumed that mode +e is used. 424 The default value for EXCEPTS is that channel exceptions are not 425 supported. 427 3.7 IDCHAN 429 o IDCHAN=pfx:num[,pfx:num,...] 431 The IDCHAN parameter indicates the existence of "safe" channels as 432 described in RFC 2811 [3], and the length of the "id" portion of 433 those channel names. 435 Each mode:num pair indicates one or more channel name prefixes which 436 corresponds to a "safe" channel, and the length of the ID portion of 437 those channels' name. 439 [Example: IDCHAN=!:5 means the client should expect IDs which are 5 440 characters in length on "!" channels; for example "!JNB4Sircd", 441 where "JNB4S" is the ID and "ircd" is the channel's short name.] 443 The IDCHAN token requires a value. 445 The default value for IDCHAN is no value; that is, there are no 446 "safe" channel types. 448 3.8 INVEX 450 o INVEX[=modechar] 452 The INVEX parameter indicates that the server supports "invite 453 exceptions", as defined in RFC 2811 [3], section 4.3.2. The optional 454 value argument to INVEX indicates which channel mode is used for 455 invite exceptions. If the token is specified with no value, it is 456 assumed that mode +I is used. 458 The default value for INVEX is that channel invite exceptions are not 459 available. 461 3.9 KICKLEN 462 o KICKLEN=number 464 The KICKLEN parameter specifies the maximum length of a KICK message 465 that a client may use. Note that it only specifies the length the 466 client should send to the server -- the server may send KICK messages 467 with a length longer than this value. 469 The KICKLEN token does not require a value; if none is given, KICK 470 messages are not limited in length. If a value is given, it must be 471 numeric. 473 There is no default value for the KICKLEN token. 475 3.10 MAXLIST 477 o MAXLIST=mode:num[,mode:num,...] 479 This parameter specifies the maximum numbers of 'list modes' (type A 480 modes in CHANMODES) that a client may set on a channel at one time. 481 Note that this MUST only be interpreted as applying to new modes 482 which are set by clients -- it should not be used to infer the 483 maximum length of any mode lists returned by the server. 485 The parameter is a series of mode-number pairs, each of which 486 specifies one or more type A modes, along with the maximum size of 487 the associated list for those modes. Modes which are specified in 488 the same pair share the same maximum size. 490 [Example: Given "b:25,eI:50", it would be possible to set up to 25 491 "+b" modes, and up to 50 of a combination of "+e" and "+I" modes, 492 e.g. 30 "+e" and 20 "+I" modes, making up a total of 50.] 493 [Example: MAXLIST=b:25 indicates that 25 bans may be set on a 494 channel at one time.] 496 The MAXLIST token requires a value. 498 There is no default value for the MAXLIST token. 500 3.11 MODES 502 o MODES=number 504 This parameter specifies the maximum number of "variable" modes which 505 may by set on a channel by a single MODE command from a client. A 506 "variable" mode is defined as being type A, B and C modes as defined 507 for CHANMODES, and channel modes specified in the PREFIX parameter. 509 [Example: MODES=3 indicates that 3 modes may be set with a MODE 510 command.] 512 The value of MODES does not limit the number of modes in a MODE 513 command which is sent from the server to the client; the client MUST 514 NOT rely on this being the case. 516 The default value for the MODES parameter is 3, which corresponds to 517 RFC 1459 [5]. 519 The MODES token does not require a value; if none is given, the 520 number of modes which may be set in one command is not limited. If a 521 value is given, it must be numeric. 523 3.12 NETWORK 525 o NETWORK=name 527 The NETWORK parameter defines the name of the IRC network that the 528 client is connected to. 530 [Example: NETWORK=EFnet indicates that the client is connected to 531 the EFnet IRC network.] 533 Note that this parameter is intended only for user display purposes; 534 the client SHOULD NOT assume further capabilities or features of the 535 IRC server based on the value of the NETWORK parameter. 537 The NETWORK token requires a value. 539 The default value of the NETWORK token is no value; that is, the 540 network does not have a name specified. 542 3.13 NICKLEN 544 o NICKLEN=number 546 This parameter specifies the maximum nickname length that the client 547 may use in a nickname. 549 [Example: NICKLEN=9 indicates that clients may have nicknames up to 550 9 characters in length.] 552 This parameter does not restrict the length of any nicknames other 553 clients on the network may use. 555 The NICKLEN token requires a numeric value. 557 The default value for NICKLEN is 9, which corresponds to RFC 1459 558 [5]. 560 3.14 PREFIX 562 o PREFIX=[(modes)prefixes] 564 The PREFIX parameter specifies a list of channel status flags (the 565 "modes" section) that clients may have on channels, followed by a 566 mapping to the equivalent channel status flags ("prefixes"), which 567 are used in NAMES and WHO replies. There is a one to one mapping 568 between each mode and prefix. 570 The order of the modes is from that which gives most privileges on 571 the channel, to that which gives the least. 573 [Example: (ab)&* maps the channel mode 'a' to the channel status 574 flag '&', and channel mode 'b' to the channel status flag '*'.] 576 [Example: PREFIX=(ohv)@%+ maps channel mode 'o' to status '@', 'h' 577 to status '%', and 'v' to status +. 579 The default value for PREFIX is "PREFIX=(ov)@+", which corresponds to 580 RFC 1459 [5]. It SHOULD NOT be specified if the server provides only 581 these modes. If a server provides ANY additional status flags, it 582 MUST also provide (ov)@+ (assuming they are applicable to the 583 server). The PREFIX parameter may be advertised with a null value 584 specifier; this indicates that no prefixes are supported by the IRC 585 server. 587 Note that PREFIX does NOT specify whether or not the server sends 588 multiple prefix characters for a user in NAMES replies. 590 3.15 SAFELIST 592 o SAFELIST 594 The SAFELIST parameter indicates that the client may request a "LIST" 595 command from the server, without being disconnected due to the large 596 amount of data generated by the command. 598 The SAFELIST token must not be specified with a value. 600 The default value for the SAFELIST token is none; that is, the 601 client may not safely request a LIST command. 603 3.16 STATUSMSG 605 o STATUSMSG=string 607 The server supports a method of sending a NOTICE message to only 608 those people on a channel with the specified status. This is done 609 via a NOTICE command, with the channel prefixed by the desired status 610 flag as the target. 612 [Example: NOTICE @#channel :Hi there] 614 The server should deliver the message to all users on the specified 615 channel with equal or higher status on the channel as the status flag 616 indicates. 618 [Example: STATUSMSG=@+ indicates that "@#channel" and "+#channel" 619 would be valid targets. A message to "+#channel" would deliver the 620 message to all users with voice and channel operator privileges on 621 #channel, assuming that the server supported the PREFIX value 622 (ov)@+.] 624 The required value argument to STATUSMSG indicates which prefixes 625 (from the PREFIX parameter) are valid status values for use in NOTICE 626 commands. 628 The server MUST NOT advertise a character in STATUSMSG which is also 629 present in CHANTYPES. 631 The STATUSMSG token requires a value. 633 The default value of the STATUSMSG token is none; that is, the 634 server does not support this form of messaging. 636 3.17 STD 638 o STD=version[,version[,...]] 640 The STD parameter indicates which form(s) of the ISUPPORT numeric are 641 used by the server. Currently, one only possible value is defined; 642 that is "rfcnnnn", which refers to this document. 644 [Note: To be changed by the RFC Editor before publication.] 646 The STD parameter is intended to be extensible, so that if later 647 standards emerge which update this document, the server may be able 648 to advertise this. The "version" string is free-form subject to the 649 requirements in section ABNF, however, protocol updates defined in 650 RFCs should be named "rfcxxxx", where "xxxx" is the relevant RFC 651 number. 653 A server may support any number of STD versions. However, new version 654 strings MUST NOT be added unless there is an ambiguity between two 655 tokens defined with different meanings in two different standards. It 656 is expected that most new features may be advertised simply by 657 additional parameters, in which case a new version string is not 658 required. 660 The STD token MUST be the first token advertised by the server upon 661 connection. 663 The STD token requires a value. 665 The default value for the STD parameter is none; that is, no 666 standardised ISUPPORT is available. 668 3.18 TARGMAX 670 o TARGMAX=[cmd:lim,cmd:lim...] 672 The TARGMAX parameter specifies the maximum number of targets 673 allowable for commands which accept multiple targets. It consists of 674 a series of cmd:lim pairs, where each command 'cmd' allows up to 675 'lim' targets (generally either channels or nicks). In the case of 676 the KICK command, the limit indicates the maximum number of (user, 677 channel) pairs which may be specified in any one KICK command. 679 [Example: TARGMAX=PRIVMSG:4,NOTICE:3 would allow "PRIVMSG A,B,C,D 680 :message" and "NOTICE A,B,C :message", but not "PRIVMSG A,B,C,D,E 681 :message" or "NOTICE A,B,C,D :message".] 683 If no argument is given for a particular command (e.g. "WHOIS:"), 684 that command does not have a limit on the number of targets. 686 The server MUST specify all commands available to the user which 687 support multiple targets. 689 The default value of TARGMAX is that no commands allow multiple 690 targets. If this is the case, the server SHOULD NOT specify 691 "TARGMAX=". 693 3.19 TOPICLEN 695 o TOPICLEN=number 697 The TOPICLEN parameter specifies the maximum length of the topic 698 specified in the TOPIC command for a channel. Note that it only 699 specifies the length of topic that may be set -- the server is free 700 to return topics longer than this length to the client. 702 The TOPICLEN token does not require a value; if none is given, the 703 length of channel topics is not limited. 705 The TOPICLEN token requires a numeric value. 707 4. Differences to existing implementations 709 A number of differences exist between the ISUPPORT defined in this 710 document and traditional implementations of the ISUPPORT numeric. 712 4.1 PREFIX parameter without value 714 The PREFIX parameter is traditionally not sent without a value 715 parameter; indeed, the author is not aware of any IRC server 716 implementations where this would be appropriate. However, it is 717 believed that this support is desired to allow extra flexibility, 718 while retaining compatibility with traditional PREFIX 719 implementations. 721 4.2 EXCEPTS and INVEX value argument 723 EXCEPTS and INVEX traditionally take no argument -- while they 724 indicate presence of these features on the server, they do not 725 specify the channel mode which is associated with these features. It 726 is believed that the argument value described here provides extra 727 flexibility while retaining backwards compatibility. 729 4.3 STATUSMSG / WALLCHOPS 731 The STATUSMSG parameter replaces the traditional WALLCHOPS parameter 732 used by some current implementations. It is believed that the name 733 STATUSMSG better reflects the functionality; since the argument to 734 STATUSMSG is not optional, it would break backwards compatibility to 735 use the name WALLCHOPS. It was not considered beneficial to allow a 736 STATUSMSG flag without a value. 738 4.4 Conflicts with RFC 2812 740 RFC 2812 [4], section 5.1, defines a numeric reply "RPL_BOUNCE", with 741 the associated number "005". While this conflicts with the ISUPPORT 742 numeric, it is considered that ISUPPORT has received much more 743 widespread support, and is the de facto standard for use of the 005 744 numeric. The only server implementation known to use this numeric 745 has now changed it to 010. 747 RFC2812 is an Informational RFC and does not not specify an Internet 748 standard. 750 4.5 Default value for CASEMAPPING 752 The default value for CASEMAPPING ("rfc1459") was chosen because it 753 reflects the prevailing implementations of the IRC server software 754 currently in use. While some IRC servers have moved to the "ascii" 755 case mapping, those known to the author indicate this via 756 CASEMAPPING=ascii; therefore this is not believed to introduce any 757 compatibility problems. 759 4.6 CHANLIMIT / MAXCHANNELS 761 CHANLIMIT replaces the traditional MAXCHANNELS parameter. MAXCHANNELS 762 did not specify which types of channel(s) the limit applied to; many 763 server implementation did not apply the limit to server-local "&" 764 channels, for example. The token was renamed from MAXCHANNELS to 765 CHANLIMIT to prevent confusion. 767 4.7 MAXLIST / MAXBANS 769 MAXLIST replaces the traditional MAXBANS token. MAXBANS was 770 considered non-useful, because of its ambiguous meaning; two of the 771 largest IRC networks, for example, could not agree whether 772 "MAXBANS=x" was equivalent to "MAXLIST=beI:x" or 773 "MAXLIST=b:x,e:x,I:x". MAXLIST is also considerably more flexible; 774 to standardise either of the described behaviours for MAXBANS would 775 leave some IRC servers unable to accurately describe their 776 capabilities. 778 4.8 CHARSET 780 The traditional CHARSET parameter has been entirely removed. It was 781 found to be unworkable; a correct specification could not be devised 782 to represent its meaning across implementations. Several other 783 methods to implement the same functionality are under discussion but 784 are outside the scope of this document. 786 4.9 TARGMAX / MAXTARGETS 788 Traditional implementations use MAXTARGETS instead of TARGMAX. 789 However, TARGMAX allowed several commands to be specified (such as 790 WHOIS and KICK) whereas MAXTARGETS only applies to channels. TARGMAX 791 is also more extendable to cope with future changes. 793 5. Security Considerations 795 This memo does not raise any security considerations. 797 Normative References 799 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 800 Levels", RFC 2119, March 1997. 802 [2] Crocker, D. and P. Overell, "Augumented BNF for Syntax 803 Specifications: ABNF", RFC 2234, November 1997. 805 [3] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, 806 April 2000. 808 [4] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, 809 April 2000. 811 [5] Reed, D. and J. Oikarinen, "Internet Relay Chat Protocol", RFC 812 1459, May 1993. 814 Informative references 816 [6] Roeckx, K., "The 005 numeric", September 2002. 818 Author's Address 820 Edward Brocklesby 821 57 Williamson Way 822 Oxford, Oxon OX4 4TU 823 GB 825 EMail: ejb@goth.net 827 Appendix A. Default ISUPPORT values 829 As an aid to implementation, a standard ISUPPORT reply with all 830 values which may be assumed to be at their defaults upon connection 831 is supplied here (lines broken due to formatting requirements). 833 :irc.example.com 005 nickname :CASEMAPPING=rfc1459 CHANNELLEN=200 834 CHANTYPES=#& MODES=3 NICKLEN=9 PREFIX=(ov)@+ TARGMAX 836 In addition, the server must provide values for the following 837 parameters: CHANLIMIT, CHANMODES, KICKLEN, MAXLIST, STD, TOPICLEN. 839 Appendix B. Acknowledgements 841 The author gratefully acknowledges the contributions of Bill Fenner 842 ("fenestro"), Perry Lorier ("Isomer"), Kurt Roeckx ("Q") and John 843 Midgley ("CrazyEddy") in the preparation of this document. 845 This document is heavily based on a previous document entitled "The 846 005 numeric". 848 Intellectual Property Statement 850 The IETF takes no position regarding the validity or scope of any 851 intellectual property or other rights that might be claimed to 852 pertain to the implementation or use of the technology described in 853 this document or the extent to which any license under such rights 854 might or might not be available; neither does it represent that it 855 has made any effort to identify any such rights. Information on the 856 IETF's procedures with respect to rights in standards-track and 857 standards-related documentation can be found in BCP-11. Copies of 858 claims of rights made available for publication and any assurances of 859 licenses to be made available, or the result of an attempt made to 860 obtain a general license or permission for the use of such 861 proprietary rights by implementors or users of this specification can 862 be obtained from the IETF Secretariat. 864 The IETF invites any interested party to bring to its attention any 865 copyrights, patents or patent applications, or other proprietary 866 rights which may cover technology that may be required to practice 867 this standard. Please address the information to the IETF Executive 868 Director. 870 Full Copyright Statement 872 Copyright (C) The Internet Society (2004). All Rights Reserved. 874 This document and translations of it may be copied and furnished to 875 others, and derivative works that comment on or otherwise explain it 876 or assist in its implementation may be prepared, copied, published 877 and distributed, in whole or in part, without restriction of any 878 kind, provided that the above copyright notice and this paragraph are 879 included on all such copies and derivative works. However, this 880 document itself may not be modified in any way, such as by removing 881 the copyright notice or references to the Internet Society or other 882 Internet organizations, except as needed for the purpose of 883 developing Internet standards in which case the procedures for 884 copyrights defined in the Internet Standards process must be 885 followed, or as required to translate it into languages other than 886 English. 888 The limited permissions granted above are perpetual and will not be 889 revoked by the Internet Society or its successors or assignees. 891 This document and the information contained herein is provided on an 892 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 893 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 894 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 895 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 896 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 898 Acknowledgment 900 Funding for the RFC Editor function is currently provided by the 901 Internet Society.