idnits 2.17.1 draft-pfenning-irc-extensions-04.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 40 longer pages, the longest (page 2) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 40 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Abstract' ) ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 10. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 53 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 435 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 34 has weird spacing: '...actions are d...' == Line 36 has weird spacing: '...support for ...' == Line 37 has weird spacing: '...tilayer secur...' == Line 39 has weird spacing: '...th full contr...' == Line 43 has weird spacing: '...ed such that...' == (48 more instances...) -- 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 (June 1998) is 9444 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) -- Missing reference section? '1' on line 2097 looks like a reference -- Missing reference section? '2' on line 2100 looks like a reference -- Missing reference section? '4' on line 2106 looks like a reference -- Missing reference section? '6' on line 2114 looks like a reference -- Missing reference section? '5' on line 2110 looks like a reference -- Missing reference section? '3' on line 2103 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Dalen Abraham 3 Expires: December 16, 1998 Microsoft Corporation 4 June 1998 6 Extensions to the Internet Relay Chat Protocol (IRCX) 7 draft-pfenning-irc-extensions-04.txt 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are 12 working documents of the Internet Engineering Task Force 13 (IETF), its areas, and its working groups. Note that other 14 groups may also distribute working documents as Internet 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 To view the entire list of current Internet-Drafts, please 24 check the "1id-abstracts.txt" listing contained in the 25 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 26 ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern 27 Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 28 Coast), or ftp.isi.edu (US West Coast). 30 2. Abstract 32 This document describes IRCX, a set of extensions to the 33 Internet Relay Chat (IRC) protocol defined in RFC 1459[1]. 34 Only client-server interactions are defined. The added 35 functionality includes user authentication for multiple 36 security providers, support for UNICODE[2] characters, 37 multilayer security, and a unified property mechanism. 38 Chat server implementations can support channel or server 39 services with full control over all messages and events. 40 These services communicate with the core server over an 41 extended IRC connection. 43 All changes to the IRC protocol are designed such that 44 existing clients will continue to work against servers 45 implementing the extensions. Support for the extended protocol 46 can be queried by clients to take advantage of the added 47 functionality or to conform to the basic protocol as defined 48 in RFC1459. 50 2.1. Contents 52 1. Status of this Memo.......................................1 53 2. Abstract..................................................1 54 2.1. Contents.............................................2 55 3. Modified UTF8 Encoding of UNICODE characters..............5 56 4. Terms and Definitions.....................................5 57 4.1. User Access Levels...................................6 58 4.2. Prefixes.............................................6 59 5. IRCX Client Messages......................................7 60 5.1. ACCESS command (new IRCX command)....................8 61 5.1.1. Parameters.......................................8 62 5.1.2. Results..........................................8 63 5.1.3. Possible Errors..................................9 64 5.1.4. Remarks..........................................9 65 5.1.5. Examples.........................................9 66 5.2. AUTH Command (new IRCX command).....................10 67 5.2.1. Parameters......................................10 68 5.2.2. Results.........................................10 69 5.2.3. Possible Errors.................................10 70 5.2.4. Remarks:........................................11 71 5.2.5. Example:........................................11 72 5.3. CREATE (new IRCX command)...........................11 73 5.3.1. Parameters......................................11 74 5.3.2. Results.........................................11 75 5.3.3. Possible Errors.................................11 76 5.3.4. Remarks.........................................12 77 5.3.5. Examples........................................12 78 5.4. DATA / REQUEST / REPLY (new IRCX command)...........12 79 5.4.1. Parameters......................................12 80 5.4.2. Results.........................................13 81 5.4.3. Possible Errors.................................13 82 5.4.4. Remarks.........................................13 83 5.4.5. Example.........................................13 84 5.5. EVENT (new IRCX command)............................13 85 5.5.1. Parameters......................................13 86 5.5.2. Results.........................................14 87 5.5.3. Possible Errors.................................14 88 5.5.4. Remarks.........................................14 89 5.5.5. Examples:.......................................14 90 5.6. IRCX (new IRCX command).............................15 91 5.6.1. Parameters......................................15 92 5.6.2. Results.........................................15 93 5.6.3. Example.........................................15 94 5.7. ISIRCX (new IRCX command)...........................15 95 5.7.1. Results.........................................15 96 5.8. LISTX (new IRCX command)............................15 97 5.8.1. Parameters......................................16 98 5.8.2. Results.........................................16 99 5.8.3. Remarks.........................................17 100 5.9. MODE (extension to RFC1459 command).................17 101 5.9.1. Results.........................................17 102 5.9.2. Remarks.........................................17 103 5.10. NOTICE (extension to RFC1459 command)...............18 104 5.10.1.Results.........................................18 105 5.11. PRIVMSG (extension to RFC1459 command)..............18 106 5.11.1.Results.........................................18 107 5.12. PROP (new IRCX command).............................18 108 5.12.1.Results.........................................18 109 5.12.2.Possible Errors.................................19 110 5.12.3.Remarks.........................................19 111 5.12.4.Examples........................................19 112 5.13. WHISPER (new IRCX command)..........................19 113 5.13.1.Results.........................................19 114 5.13.2.Possible Errors.................................19 115 5.13.3.Remarks.........................................20 116 6. IRCX Server Messages.....................................20 117 6.1. AUTH (new IRCX message).............................20 118 6.1.1. Parameters......................................20 119 6.1.2. Remarks.........................................21 120 6.2. CLONE (new IRCX message)............................21 121 6.2.1. Parameters......................................21 122 6.2.2. Remarks.........................................21 123 6.2.3. Example.........................................21 124 6.3. CREATE (new IRCX message)...........................21 125 6.3.1. Parameters......................................21 126 6.3.2. Remarks.........................................22 127 6.3.3. Example.........................................22 128 6.4. DATA / REQUEST / REPLY (new IRCX messages)..........22 129 6.4.1. Parameters......................................22 130 6.4.2. Remarks.........................................22 131 6.5. EVENT (new IRCX message)............................23 132 6.5.1. Parameters......................................23 133 6.5.2. Example.........................................23 134 6.6. KNOCK (new IRCX message)............................23 135 6.6.1. Parameters......................................24 136 6.6.2. Remarks.........................................24 137 6.7. REDIRECT (new IRCX message).........................24 138 6.7.1. Parameters......................................24 139 6.7.2. Remarks.........................................24 140 6.7.3. Example.........................................24 141 6.8. WHISPER (new IRCX message)..........................24 142 6.8.1. Parameters......................................24 143 6.8.2. Remarks.........................................25 144 6.8.3. Example.........................................25 145 7. User Modes and Properties................................25 146 7.1. OWNER (IRCX +q).....................................25 147 7.2. GAG (IRCX +z).......................................25 148 8. Channel Modes and Properties.............................26 149 8.1. Modes...............................................26 150 8.1.1. PUBLIC (RFC1459 default)........................26 151 8.1.2. PRIVATE (RFC1459 +p)............................26 152 8.1.3. HIDDEN (IRCX +h)................................26 153 8.1.4. SECRET (RFC1459 +s).............................26 154 8.1.5. MODERATED (RFC1459 +m)..........................27 155 8.1.6. NOEXTERN (RFC1459 +n)...........................27 156 8.1.7. TOPICOP (RFC1459 +t)............................27 157 8.1.8. INVITE (RFC1459 +i).............................27 158 8.1.9. KNOCK (IRCX +u).................................27 159 8.1.10.NOFORMAT (IRCX +f)..............................27 160 8.1.11.NOWHISPER (IRCX +w).............................28 161 8.1.12.AUDITORIUM (IRCX +x)............................28 162 8.1.13.REGISTERED (IRCX +r)............................28 163 8.1.14.SERVICE (IRCX +z)...............................28 164 8.1.15.AUTHONLY (IRCX +a)..............................29 165 8.1.16.CLONEABLE (IRCX +d).............................29 166 8.1.17.CLONE (IRCX +e).................................29 167 8.2. Properties..........................................30 168 8.2.1. OID (R/O).......................................30 169 8.2.2. NAME (R/O)......................................30 170 8.2.3. CREATION (R/O)..................................30 171 8.2.4. LANGUAGE........................................30 172 8.2.5. OWNERKEY........................................30 173 8.2.6. HOSTKEY.........................................31 174 8.2.7. MEMBERKEY.......................................31 175 8.2.8. PICS............................................31 176 8.2.9. TOPIC...........................................31 177 8.2.10.SUBJECT.........................................31 178 8.2.11.CLIENT..........................................31 179 8.2.12.ONJOIN..........................................32 180 8.2.13.ONPART..........................................32 181 8.2.14.LAG.............................................32 182 8.2.15.ACCOUNT.........................................32 183 8.2.16.CLIENTGUID......................................32 184 8.2.17.SERVICEPATH.....................................33 185 9. IRCX Command Responses...................................33 186 9.1. Command Replies.....................................33 187 9.2. IRCX Error Replies..................................36 188 10. Security Considerations..................................39 189 11. Acknowledgements.........................................40 190 12. References...............................................40 191 13. Authors' Addresses.......................................40 193 3. Modified UTF8 Encoding of UNICODE characters 195 Allowing UNICODE characters for all user visible strings 196 introduces a set of compatibility problems if the protocol 197 must be backward compatible. UTF8 encoding is used to convert 198 wide UNICODE characters into a string compatible with existing 199 IRC servers and clients. 201 To permit the full range of UNICODE characters, we must 202 introduce an additional post-processing step on the result of 203 an UTF8 translation. 205 Any string beginning with a '%' character (i.e. "reason" 206 strings within a REDIRECT command) will be interpreted as 207 UTF8-encoded UNICODE strings. 209 UNICODE characters encoded in UTF8 may use more bytes than an 210 ASCII character. To ensure compatibility, UNICODE strings 211 such as nicknames and channel names must fit within the 212 standard length measured in bytes, not in characters. 214 The quoting character for the post-processing step is the '\' 215 character. All mappings are listed in the table below. 217 Table 1 - Character Quoting in UTF8 219 \b " " (blank) 221 \c "," 223 \\ "\" 225 \r CR 227 \n LF 229 \t TAB 231 IRCX clients view UTF8-encoded UNICODE strings in their native 232 form. So non-IRCX clients can inter-operate with UNICODE 233 nicks, UNICODE nicks are translated by the server into a 234 usable form before being sent to the non-IRCX client. This 235 usable format is a simple hex format preceded by a '^' 236 character. Non-IRCX clients can use this hex format nickname 237 to specify the IRCX/UNICODE user. 239 4. Terms and Definitions 241 Throughout this document we will use certain terms which are 242 defined in the following pages. 244 String lengths are indicated in "characters", referring to 245 ASCII characters, because even UNICODE strings must be encoded 246 in ASCII for the IRC protocol. 248 Table 2 - Definition of Terms 250 Chat Network A Chat Network is comprised of one or more 251 servers linked together. 253 Server A server is a single machine. 255 Channel A channel (sometimes called a room or 256 conference) is a conversation between one or 257 more users. 259 Member A member is a user that is part of a 260 conversation in a channel. 262 User A user is a client that makes a connection to 263 the server. 265 Objects An object is a general term for channels, 266 users, members (users in a channel), and 267 servers. The type of object can be determined 268 from the first character of the object's name. 270 4.1. User Access Levels 272 There are six user levels that define the ability of the user 273 to perform operations. Some levels are determined on the 274 context of the operation to be performed. 276 Table 3 - Definition of Client Levels 278 Sysop Manager A Sysop Manager has full access to online 279 commands. 281 Sysop A Chat Sysop oversees and controls the chat 282 network. 284 Channel Owner A Channel Owner manages a channel and the 285 channel hosts. 287 Channel Host A Channel Host manages a channel. Also 288 referred to as a channel operator. 290 Channel Member A Channel Member is a member of a channel. 292 Chat User A Chat User is a client connected to the 293 server. 295 4.2. Prefixes 297 Each object contains a unique prefix that identifies the type 298 of object. By tagging UNICODE objects with a special prefix, 299 a client can easily decide whether to use standard ASCII or 300 UNICODE when sending a message to a user or channel. The IRCX 301 client is responsible, when sending a UNICODE string, for 302 prefixing it with a '%' character so that other IRCX clients 303 can interpret it as UNICODE. 305 Table 4 - Object identifiers 307 # The '#' prefix identifies a RFC1459 global channel. 309 & The '&' prefix identifies a RFC1459 local channel. 311 %# The "%#" prefix identifies an extended global channel 312 name (a modified UTF8-encoded UNICODE string). 314 %& The "%&" prefix identifies an extended local channel 315 name (a modified UTF8-encoded UNICODE string). 317 % The '%' character followed by a space or comma can 318 identify the last channel that this client 319 specified and is a member of. Its function is to 320 optimize server processing of multiple messages from 321 a client to a channel. 323 A to } The 'A' through '}' prefix identifies a standard 324 RFC1459 nickname. 326 ' The ''' prefix identifies an extended IRCX nickname 327 which consists of a modified UTF8-encoded UNICODE 328 string. The ''' character followed by a space or 329 comma is used to represent the local client 330 connection. The characters following ''' can be '0' 331 through '9', '-', and any character above 'A'. 333 ^ The '^' prefix identifies a nickname which was 334 translated from UTF8 into hex characters so that the 335 nickname can be viewed by non-IRCX clients. The 336 characters following '^' can be any standard RFC1459 337 nickname characters. 339 0 The '0' prefix identifies an internal object 340 identifier (OID). The OID consists of the '0' 341 prefix and eight hexadecimal characters. If not 342 supported by the server, then OID must be returned as 343 '0'. 345 $ The '$' prefix identifies a server on the network. 346 The '$' character followed by a space or comma may 347 be used to represent the local server the client is 348 connected to. 350 5. IRCX Client Messages 352 This section details commands which have been added and 353 commands which have been changed from RFC1459. Responses from 354 the server are discussed in greater detail in later sections. 356 5.1. ACCESS command (new IRCX command) 358 Create an "access entry" for an object to grant or deny access 359 to an object, including a channel, a user, or the server. 360 ACCESS LIST is used to list all access entries for an object 361 and CLEAR is used to clear all entries or all entries of the 362 same level. 364 Syntax 1: ACCESS LIST 366 Syntax 2: ACCESS ADD|DELETE 367 [ [:]] 369 Syntax 3: ACCESS CLEAR [] 371 5.1.1. Parameters 373 The object to which access is being granted or 374 limited. Can be a channel name, nickname, $ or *. 376 The level of access being given or taken away. Can 377 be: 379 DENY Disallow access to an object that is accessible 381 GRANT Allow access to an object that is inaccessible 383 HOST Channel host access to specified channel 385 OWNER Channel owner access to specified channel 387 VOICE Voice access to specified channel 389 Mask to identify user by nickname, userid, host or 390 server characteristics. Supports wildcards * and ?. 392 Minutes until the access entry is removed. A value 393 of 0 indicates unlimited duration. 395 Text reason shown when users are denied access due 396 to the access entry. 398 5.1.2. Results 400 IRCRPL_ACCESSADD 402 IRCRPL_ACCESSDELETE 404 IRCRPL_ACCESSSTART 406 IRCRPL_ACCESSLIST 408 IRCRPL_ACCESSEND 410 5.1.3. Possible Errors 412 In this specification possible error messages are listed. 414 IRCERR_BADLEVEL 416 IRCERR_DUPACCESS 418 IRCERR_MISACCESS 420 IRCERR_TOOMANYACCESSES 422 IRCERR_TOOMANYARGUMENTS 424 IRCERR_BADCOMMAND 426 IRCERR_NOTSUPPORTED 428 IRCERR_NOACCESS 430 5.1.4. Remarks 432 An object with GRANT access entries but no DENY entries is 433 assumed to be off-limits to those users not covered by the 434 GRANT entries. If there are multiple entries in the access 435 list, the list is processed in the following order: OWNER, 436 HOST, VOICE, GRANT, DENY. 438 Hosts and Owners may add and delete access entries for their 439 channel. Hosts may not remove access entries added by owners. 440 Any user may add and delete access entries for themselves. 441 Sysops and sysop managers on a server may add and delete 442 access entries for that server or the entire network. 444 A user who has blocked another user does not get any messages 445 from the blocked user, including invites. 447 5.1.5. Examples 449 To make a user, "piper", a channel host when they join the 450 channel, "#mychan": 452 ACCESS #mychan ADD HOST piper 454 To grant normal access to the network to a few people but deny 455 access to all others: 457 ACCESS * ADD DENY * :closed for private party 459 ACCESS * ADD GRANT *.company.com :these people can get on 461 To delete the DENY access record on the network that denies 462 access to '*' (note that this doesn't delete other DENY access 463 records such as '*.com'): 465 ACCESS * DELETE DENY * 467 To clear all DENY-level entries on the local server: 469 ACCESS $ CLEAR DENY 471 To clear all access entries of any level for a channel: 473 ACCESS #mychan CLEAR 475 5.2. AUTH Command (new IRCX command) 477 Authenticate the client using an SASL[4] authentication 478 mechanism. 480 Syntax 1: AUTH [:] 482 5.2.1. Parameters 484 The name of the SASL mechanism to use for 485 authentication. 487 The sequence is a value of 'I' or 'S'. The 'I' value 488 is specified for the initial AUTH message and the 'S' value is 489 specified for all subsequent AUTH messages. If the 490 client specifies '*' for the sequence, the server will abort 491 the authentication sequence and return 492 IRCERR_AUTHENTICATIONFAILED. 494 This is optional data sent as an argument with 495 the AUTH messages. The content depends on the authentication 496 mechanism being used. All content must use standard escaping 497 formats (e.g. \r for carriage return) to comply with IRC 498 message format restrictions. 500 5.2.2. Results 502 AUTH message 504 5.2.3. Possible Errors 506 ERR_NEEDMOREPARAMS 508 IRCERR_ALREADYAUTHENTICATED 510 IRCERR_ALREADYREGISTERED 512 IRCERR_AUTHENTICATIONFAILED 514 IRCERR_AUTHENTICATIONSUSPENDED 516 IRCERR_BADCOMMAND 518 IRCERR_UNKNOWNPACKAGE 520 5.2.4. Remarks 522 If the server is known to support IRCX with specific SASL 523 mechanism(s), then the first message from an IRCX-compliant 524 client must be the AUTH command (if authentication is to be 525 used), before the USER and NICK commands. Use MODE ISIRCX to 526 determine if the server supports IRCX. 528 5.2.5. Example 530 Client: AUTH NTLM I : 532 Server: AUTH NTLM S : 534 Client: AUTH NTLM S : 536 Server: AUTH NTLM * userid@domain 03FA4534C 538 5.3. CREATE (new IRCX command) 540 Create a new channel and/or join an existing channel. 542 Syntax: CREATE [ []] 544 5.3.1. Parameters 546 The name of the channel. 548 Initial channel modes, not separated by spaces (like 549 MODE command). Includes mode 'e' to force a clone of a 550 clonable channel. 552 Optional mode arguments, separated by spaces, in 553 the same order as the modes. For the mode 'l' the mode 554 argument is the maximum number of members in the channel. 555 For the mode 'k' the mode argument is the channel 556 keyword. These are the only modes that require mode 557 arguments. 559 5.3.2. Results 561 CREATE message 563 JOIN message 565 RPL_TOPIC 567 RPL_NAMEPLY 569 RPL_ENDOFNAMES 571 5.3.3. Possible Errors 573 IRCERR_CHANNELEXIST 574 IRCERR_ALREADYONCHANNEL 576 ERR_NEEDMOREPARAMS 578 ERR_INVITEONLYCHAN 580 ERR_CHANNELISFULL 582 ERR_BANNEDFROMCHAN 584 ERR_BADCHANNELKEY 586 ERR_TOOMANYCHANNELS 588 ERR_UNKNOWNCOMMAND 590 5.3.4. Remarks 592 The CREATE command provides a method to specify channel 593 properties at creation time, and also provides a method (flag 594 'c') to create and join a channel only if it does not already 595 exist. If user is not in IRCX mode, server returns 596 ERR_UNKNOWNCOMMAND. 598 5.3.5. Examples 600 This example shows the creation of a moderated (m) channel 601 with the following properties and modes: its topic can only 602 be changed by an owner or host (t = TOPICOP), messages from 603 outside the channel are blocked (n = NOEXTERN), it is limited 604 to 50 members (l 50), it has a member key which is 'password' 605 (k password), and it will be created only if it doesn't 606 already exist (c = CREATE) 608 Client: CREATE #MyChannel tnmlkc 50 password 610 Server: CREATE #MyChannel 048532944 612 5.4. DATA / REQUEST / REPLY (new IRCX command) 614 Used to send tagged data, requests or replies. The syntax for 615 each is the same, but clients can use REQUEST to indicate that 616 a REPLY is desired, and use REPLY to indicate that a REQUEST 617 was issued. If user is not in IRCX mode, server returns 618 ERR_UNKNOWNCOMMAND. 620 Syntax 1: DATA : 622 5.4.1. Parameters 624 The target for the data. Target can be a nick, list 625 of nicks, channel, list of channels, or channel followed 626 by a list of some members of the channel. This 627 definition for will be used throughout this 628 document. 630 Text field that clients use to know how to interpret 631 the data. Valid characters are [A..z], [0..9] and 632 period (.). The first character must be one of [A..z]. 633 Maximum 15 characters. If the tag begins with ADM, SYS, 634 OWN or HST then the originator must have appropriate 635 privileges (Sysop Manager, Sysop, Channel Owner or 636 Channel Host. Channel Owner & Host apply to the channel 637 the message is being sent to.) The server itself can 638 send tags beginning with these reserved strings. 640 Payload or data for the message, ending with a 641 newline. Any newlines or other control characters within 642 the body of the message must be escaped. 644 5.4.2. Results 646 DATA message 648 5.4.3. Possible Errors 650 ERR_UNKNOWNCOMMAND 652 5.4.4. Remarks 654 REPLY and REQUEST may be used to replace "DATA". IRCX servers 655 should not send DATA commands to clients that have not 656 indicated that they support IRCX. Clients should only process 657 DATA messages if they know and support the tag used. 659 Prefixes should indicate the organization that specified them, 660 when appropriate. For example: MYORG.AVATAR could be a tag 661 used by MyOrg, as would be all MYORG.* tags. 663 5.4.5. Example 665 Sending ad banners from server sysop to channel, "#Channel": 667 DATA #Channel SYS.AD.SMALL : 669 5.5. EVENT (new IRCX command) 671 Add/Change/Delete event logging to the client connection. The 672 list of event types and the way masks are applied is not 673 specified here. 675 Syntax 1: EVENT [ADD | DELETE] [] 677 Syntax 2: EVENT LIST [] 679 5.5.1. Parameters 680 Type of event, such as CHANNEL, MEMBER, SERVER, 681 CONNECTION, SOCKET or USER. 683 Optional mask for applying a selection criteria per 684 event. 686 5.5.2. Results 688 IRCRPL_EVENTADD 690 IRCRPL_EVENTDEL 692 IRCRPL_EVENTSTART 694 IRCRPL_EVENTLIST 696 IRCRPL_EVENTEND 698 5.5.3. Possible Errors 700 ERR_NEEDMOREPARAMS 702 ERR_NOPRIVILEGES 704 IRCERR_BADFUNCTION 706 IRCERR_EVENTDUP 708 IRCERR_EVENTMIS 710 IRCERR_NOSUCHEVENT 712 IRCERR_TOOMANYEVENTS 714 5.5.4. Remarks 716 The EVENT command can be used by other server implementations 717 to define the events that a sysop manager or sysop of the 718 server wishes to be notified of. Only sysop managers and/or 719 sysops are allowed to receive event messages. 721 5.5.5. Examples 723 Add channel events. 725 Client: EVENT ADD CHANNEL 727 Server: : 806 CHANNEL *!*@*$* 729 Add a list event with no active events returned. 731 Client: EVENT LIST 733 Server: : 808 :Start of events 734 : 809 CHANNEL *!*@*$* 736 : 810 :End of events 738 5.6. IRCX (new IRCX command) 740 Enables IRCX mode and displays IRCX status. Use MODE ISIRCX 741 first to see if the server supports IRCX. 743 Syntax: IRCX 745 5.6.1. Parameters 747 None. 749 5.6.2. Results 751 IRCRPL_IRCX 753 5.6.3. Example 755 This example includes a server that supports IRCX and three 756 authentication packages. 758 Client: IRCX 760 Server: : 800 1 0 NTLM,DPA,ANON 512 * 762 5.7. ISIRCX (new IRCX command) 764 Queries whether or not the server supports the Extended 765 RFC1459 protocol (IRCX). Server response is same as for IRCX 766 message. 768 Use ISIRCX after logging into the server. 770 Syntax: ISIRCX 772 5.7.1. Results 774 IRCRPL_IRCX 776 5.8. LISTX (new IRCX command) 778 Extended version of the LIST command that returns additional 779 channel properties. Channels with extended names will be 780 returned, even to non-IRCX clients. Some channel modes and 781 the PICS rating string are included with the result. Only the 782 channel modes that do not define an additional argument 783 (TOPICOP, NOEXTERN, etc.) are included in the field. 784 Clients should use the query limit to avoid overloading the 785 client or having the connection dropped by the server. 787 Syntax 1: LISTX [] 788 Syntax 2: LISTX [] 790 5.8.1. Parameters 792 A list of channels may be specified in order 793 to find the PICS ratings or modes of those channels. If 794 no channels are specified, the server will send the 795 entire matching list of channels. 797 One or more query terms separated by spaces or 798 commas. 800 Table 5 - Query terms for LIST command 802 <# Select channels with less than # members. 804 ># Select channels with more than # members. 806 C<# Select channels created less than # minutes 807 ago. 809 C># Select channels created greater than # minutes 810 ago. 812 L= Select channels with language property 813 matching the mask string. 815 N= Select channels with name matching the mask 816 string. 818 R=0 Select unregistered channels. 820 R=1 Select registered channels. 822 S= Select channels with subject matching the mask 823 string. 825 T<# Select channels with a topic changed less than 826 # minutes ago. 828 T># Select channels with a topic changed greater 829 than # minutes ago. 831 T= Select channels that topic matches the mask 832 string. 834 Maximum number of channels to be returned. 836 Sequence of characters that is used to select 837 a matching channel name or topic. The 838 character * and ? are used for wildcard 839 searches. 841 5.8.2. Results 842 IRCRPL_LISTXSTART 844 IRCRPL_LISTXLIST 846 IRCRPL_LISTXPICS 848 IRCRPL_LISTXTRUNC 850 IRCRPL_LISTXEND 852 5.8.3. Remarks 854 To compose a mask, use this character escaping scheme. 856 Table 6 - Character escaping in mask-string 858 \b for " " blank 860 \c for "," 862 \\ for "\" 864 \* for * 866 \? for ? 868 The PICS property is only returned if not null. 870 A record limit of '0' (zero) or blank will be interpreted as 871 unlimited. 873 5.9. MODE (extension to RFC1459 command) 875 MODE command can now be used for new user or channel modes 876 (see later sections). In addition, the special syntax "MODE 877 ISIRCX" can be used to help clients find out whether a server 878 supports IRCX prior to logging into the server. 880 Syntax: MODE ISIRCX 882 5.9.1. Results 884 MODE message 886 IRCRPL_IRCX 888 5.9.2. Remarks 890 The ISIRCX mode (must be in capital letters) is only 891 functional before the user has registered with the server. 892 IRCX servers respond with IRCRPL_IRCX and non-IRCX servers 893 should return an error code. This allows unregistered users 894 to query whether the server supports IRCX. 896 See RFC1459 for more details on the original MODE command and 897 its parameters. 899 5.10. NOTICE (extension to RFC1459 command) 901 Sends a notice to a channel or user. In RFC1459 a notice 902 could only be sent to a channel or a list of users. Now a 903 notice can be sent to a list of users within the context of a 904 channel. As before, users will not get the list of users that 905 received the notice. 907 Syntax: NOTICE : 909 5.10.1. Results 911 Same as defined in RFC1459, but with the additional 912 functionality of sending to a list of nicknames within the 913 context of a channel. 915 5.11. PRIVMSG (extension to RFC1459 command) 917 Sends a message to a channel or user. PRIVMSG is extended in 918 the same way as NOTICE. 920 Syntax: PRIVMSG : 922 5.11.1. Results 924 Same as defined in RFC1459, but with the additional 925 functionality of sending to a list of nicknames within the 926 context of a channel. 928 5.12. PROP (new IRCX command) 930 Add, change or delete a channel data property. 932 To query a property: 934 Syntax 1: PROP [,] 936 To set or change a property: 938 Syntax 2: PROP : 940 To delete a property: 942 Syntax 3: PROP : 944 5.12.1. Results 946 PROP message 948 IRCRPL_PROPLIST 949 IRCRPL_PROPEND 951 5.12.2. Possible Errors 953 IRCERR_BADCOMMAND 955 IRCERR_BADPROPERTY 957 IRCERR_SECURITY 959 IRCERR_NOSUCHOBJECT 961 IRCERR_TOOMANYARGUMENTS 963 IRCERR_BADVALUE 965 5.12.3. Remarks 967 The PROP command provides a new method for manipulating string 968 and numeric properties of channels. If an optional channel 969 property is not supported on the server, the server should 970 return IRCERR_BADPROPERTY. 972 See section 8.2 for definitions of channel properties. 974 5.12.4. Examples 976 Client: PROP #MyChan TOPIC,ONJOIN 978 Server: : 818 #MyChan TOPIC :This is the topic of 979 my channel 981 Server: : 818 #MyChan ONJOIN :Welcome to my 982 channel! 984 Server: : 819 #MyChan :End of properties 986 Client: PROP #MyChannel TOPIC :Change my channel topic 988 Server: PROP #MyChannel TOPIC :Change my channel topic 990 5.13. WHISPER (new IRCX command) 992 Whisper to member(s) in a channel. 994 Syntax: WHISPER : 996 5.13.1. Results 998 WHISPER message 1000 5.13.2. Possible Errors 1001 ERR_UNKNOWNCOMMAND 1003 ERR_CANNOTSENDTOCHAN 1005 ERR_USERNOTINCHANNEL 1007 ERR_NEEDMOREPARAMS 1009 IRCERR_NOTONCHANNEL 1011 IRCERR_TOOMANYTARGETS 1013 IRCERR_NOSUCHNICK 1015 IRCERR_NOSUCHCHANNEL 1017 IRCERR_NOWHISPER 1019 5.13.3. Remarks 1021 The purpose of the WHISPER command is to whisper to one or 1022 more members in a channel within the context of that channel. 1023 The sender and all recipients must be in the channel 1024 specified. A whisper is different from a privmsg in that it 1025 includes both a user list and a channel name, indicating that 1026 the message is private but has a context. 1028 IRCX clients should display the WHISPER message within the 1029 context (possibly a window) of the specified channel. Non- 1030 IRCX clients receive a PRIVMSG with the content of the whisper 1031 (losing the context of the whisper). Only one whisper will be 1032 sent per nick. A user may whisper to themselves. 1034 The channel mode 'w' will disable whispers between ordinary 1035 members of the channel (but not whispers from or to channel 1036 operators). 1038 6. IRCX Server Messages 1040 This section summarizes new extended messages which can be 1041 sent from the server. 1043 6.1. AUTH (new IRCX message) 1045 Negotiates authentication with client or informs client that 1046 authorization was successful. 1048 Syntax 1 (negotiating authorization): AUTH S 1049 [:] 1051 Syntax 2 (authorization successful): AUTH * 1052 1054 6.1.1. Parameters 1055 The name of the SASL mechanism to use for 1056 authentication. 1058 The ident is the userid@domain of the authenticated 1059 client account. It is returned on the final response from the 1060 server (Syntax 2) when authentication is successful. 1062 The OID is the internal object identifier assigned to 1063 the client connection. If not supported by the server, then 1064 OID must be returned as '0'. 1066 This is optional data sent as an argument with 1067 the AUTH messages. 1069 6.1.2. Remarks 1071 The server will send the syntax 2 form when the authentication 1072 process is complete or a numeric error reply. 1074 6.2. CLONE (new IRCX message) 1076 Informs the hosts and owners in a CLONEABLE channel that a 1077 new CLONE channel was created. 1079 Syntax: CLONE 1081 6.2.1. Parameters 1083 The name of the created CLONE channel. 1085 The object identifier for this new CLONE channel. The 1086 value is implementation-dependent and must equal 0 if not 1087 supported. 1089 6.2.2. Remarks 1091 The CLONE message can be sent at anytime to the hosts/owners 1092 of a CLONEABLE channel to inform them that a new CLONE channel 1093 was created. This message is intended to be used by a custom 1094 application to automatically join the new CLONE channel. A 1095 non-IRCX client will not get this message. 1097 6.2.3. Example 1099 Server: CLONE #MyChat1 034F8FF32 1101 6.3. CREATE (new IRCX message) 1103 Informs the client that a new channel was created. Response 1104 to the CREATE command. 1106 Syntax: CREATE 1108 6.3.1. Parameters 1109 The name of the created channel. 1111 The object identifier for this new channel. The value 1112 is implementation- dependent and must equal 0 if not 1113 supported. 1115 6.3.2. Remarks 1117 The CREATE message is sent in response to a CREATE command 1118 sent by the client application if the channel specified did 1119 not previously exist and was created by the server. 1121 6.3.3. Example 1123 Server: CREATE #MyChat1 034F8FF32 1125 6.4. DATA / REQUEST / REPLY (new IRCX messages) 1127 The DATA message (could be REQUEST or REPLY also) is 1128 forwarded from another user or sent by the server. The 1129 payload or message should be interpreted according to the tag. 1130 If the tag is unknown, the message may be discarded. 1132 Syntax 1: :DATA : 1134 :REQUEST : 1136 :REPLY : 1138 If the DATA, REQUEST or REPLY message is sent to a number of 1139 members within a channel, the receiving user will see the 1140 channel name and their own nick in the message as follows: 1142 Syntax 2: :DATA : 1144 6.4.1. Parameters 1146 May be a user or a server. 1148 Channel and/or nick list as defined above. 1150 Identifying tag. 1152 Payload. 1154 6.4.2. Remarks 1156 The tag indicates what to do with the message. Tag types may 1157 be specified by administrators, client developers, server 1158 developers etc. 1160 A tag beginning with SYS can only be from a sysop, sysop 1161 manager or the server. A tag beginning with ADM can only be 1162 from a sysop manager or the server. 1164 DATA message functionality is different from client-to-client 1165 messaging in several respects. First, we encourage groups to 1166 define their own tags and data formats for special purposes, 1167 for example to indicate details for a user's avatar in 1168 graphical chats, or to indicate that an ad banner or image 1169 should be downloaded. Second, the DATA message is more 1170 appropriate for content that may go to several users, for 1171 example all users in a channel. Third, the DATA message may 1172 come from the server. Fourth, the SYS and ADM prefixes are 1173 specified so that important tags may be reserved for sysops, 1174 sysop managers and the server itself, with the server 1175 responsible for verifying the sender before forwarding the 1176 DATA message. 1178 6.5. EVENT (new IRCX message) 1180 Notifies the client of an event. These events are intended 1181 for sysops and sysop managers, and are sent in addition to IRC 1182 events. 1184 Syntax: EVENT 1186 6.5.1. Parameters 1188 The number of elapsed seconds from midnight 1189 (00:00:00) January 1, 1970 (coordinated universal time) until 1190 the time that the event occurred on the server. 1192 Objects can be Channel, Member, User, Connection, 1193 Socket or Server. 1195 Event type varies depending on the object. For 1196 example, events for channels can be Create, Destroy, Topic 1197 change, Mode change, Collision. 1199 Vary depending on event type. 1201 6.5.2. Example 1203 This example is the event generated when a user logs onto 1204 server, "chat1" with the nickname, "john", showing the user's 1205 info including IP address and port. 1207 EVENT chat1 946080000 USER LOGON john!jsmith@uw.edu 1208 192.29.93.93:1111 1210 6.6. KNOCK (new IRCX message) 1212 Informs the owners and hosts of a channel that a user has 1213 tried to enter the channel and could not (could be because of 1214 a full channel, keyword wrong, user ban, or other reasons). 1215 This message is only sent to the IRCX owners and hosts of the 1216 channel. 1218 Syntax: KNOCK 1220 6.6.1. Parameters 1222 User field is of the format nick!userid@host. 1224 Name of the channel that the user tried to enter. 1226 Reason that the user received when they tried to 1227 join the channel. 1229 6.6.2. Remarks 1231 A KNOCK message will not be sent to a non-IRCX client. 1233 6.7. REDIRECT (new IRCX message) 1235 Informs the client that they need to connect to another 1236 server. 1238 Syntax: REDIRECT : 1240 6.7.1. Parameters 1242 The server list is a comma separated list of 1243 host:port pairs. The server list can be specified either as 1244 a fully-qualified domain name or by the IP address in quad- 1245 dotted notation. 1247 The redirect reason is an implementation-dependent 1248 string which can optionally be displayed to the client. 1250 6.7.2. Remarks 1252 The REDIRECT message can be sent to the client at any time to 1253 request that the client disconnect and reconnect to another 1254 server specified in the list. The REDIRECT message is 1255 generally sent when a server is to be shutdown. 1257 A REDIRECT message will not be sent to a non-IRCX client. 1259 6.7.3. Example 1261 Server: REDIRECT chat.corp.net:6667,134.9.3.3:6667 :Server 1262 full. 1264 6.8. WHISPER (new IRCX message) 1266 A whisper from another channel member. 1268 Syntax: WHISPER : 1270 6.8.1. Parameters 1271 The nick-name of the person that sent the whisper. 1273 The channel that the message is sent to. 1275 The list of nicknames of channel members that will 1276 receive the whisper. 1278 The content of the whisper. 1280 6.8.2. Remarks 1282 The server may transform a WHISPER into a PRIVMSG for clients 1283 that do not support IRCX. 1285 6.8.3. Example 1287 Server: Joe WHISPER #test Jill :Test whisper. 1289 7. User Modes and Properties 1291 These are new user modes and properties that have been added. 1292 The MODE command as defined in RFC1459 is used to add or 1293 remove modes. 1295 7.1. OWNER (IRCX +q) 1297 The OWNER mode indicates that the user is an owner of a 1298 channel. Only a channel owner can give OWNER mode to another 1299 member of that channel, but any owner may remove OWNER mode 1300 from themselves. 1302 Clients in IRCX mode see owner nicknames with a '.' prefix 1303 and continue to see hosts with a '@' prefix (in results 1304 from NAMES, WHO, WHOIS and other commands which list 1305 nicknames). 1307 Note that HOST mode uses +o, which was "operator" mode in 1308 RFC1459. Syntax for these modes is the same as "operator" 1309 mode: 1311 MODE { + | - }q 1313 7.2. GAG (IRCX +z) 1315 The GAG mode is applied by a sysop or sysop manager on a user 1316 and may not be removed except by a sysop or sysop manager. 1317 The user may not be notified when this mode is applied because 1318 the mode can be a more effective tool for keeping order if the 1319 user doesn't know exactly when it is applied. 1321 The server will discard all messages from a user with GAG mode 1322 to any other user or to any channel. 1324 MODE { + | - }z 1326 8. Channel Modes and Properties 1328 New modes and properties have been added to channels. 1330 Channels support four mutually exclusive states of visibility: 1331 public, private, hidden, and secret. The visibility of a 1332 channel affects which modes and properties are available to a 1333 client. 1335 8.1. Modes 1337 Each channel object contains a number of binary mode settings 1338 that can be queried and optionally updated via the RFC1459 1339 MODE command. 1341 8.1.1. PUBLIC (RFC1459 default) 1343 The channel is public and all information about the channel 1344 (except for text messages) can be queried by non-members. 1345 PUBLIC mode is mutually exclusive with the PRIVATE, HIDDEN and 1346 SECRET modes. 1348 This mode may be set and queried by sysop managers, owners and 1349 hosts of the channel. It may be queried by sysops, members of 1350 the channel, and users. 1352 8.1.2. PRIVATE (RFC1459 +p) 1354 The channel is private and only the name, number of members 1355 and PICS property can be queried by non-members. PRIVATE 1356 mode is mutually exclusive with the PUBLIC, HIDDEN and SECRET 1357 modes. 1359 This mode may be set by sysop managers, owners and hosts of 1360 the channel. It may be not be queried by sysops or users. 1362 8.1.3. HIDDEN (IRCX +h) 1364 The channel is hidden and cannot be located by enumeration 1365 queries from non-members. HIDDEN mode is mutually exclusive 1366 with the PUBLIC, PRIVATE, and SECRET modes. The purpose of 1367 the new HIDDEN channel mode is to permit the existence of 1368 channels that cannot be found using the standard LIST 1369 command, but whose properties can be queried if the exact 1370 channel name is known. Thus a HIDDEN channel is the same as 1371 a PUBLIC channel except that it cannot be enumerated by using 1372 a LIST or LISTX command. 1374 This mode may be set and queried like PUBLIC mode. 1376 8.1.4. SECRET (RFC1459 +s) 1377 The channel is secret and cannot by located by any query from 1378 non-members. SECRET mode is mutually exclusive with the 1379 PUBLIC, PRIVATE, and HIDDEN modes. 1381 This mode may be set and queried like PRIVATE mode. 1383 8.1.5. MODERATED (RFC1459 +m) 1385 Normally, new channel members may speak. In MODERATED mode 1386 however, new channel members may not speak by default. This 1387 is achieved by giving all new members the '-v' mode (no voice) 1388 for that channel. Usually -v mode has no effect, but in a 1389 MODERATED channel it does. 1391 This mode may be set and queried by sysop managers, owners and 1392 hosts of the channel. It may be queried by sysops and members 1393 of the channel. Users may query this mode if the channel is 1394 PUBLIC or HIDDEN. 1396 8.1.6. NOEXTERN (RFC1459 +n) 1398 NOEXTERN mode blocks messages from non-members to the 1399 channel. A sysop manager can still send a message to the 1400 channel. 1402 This mode may be set and queried like MODERATED mode. 1404 8.1.7. TOPICOP (RFC1459 +t) 1406 TOPICOP mode permits only channel owners and hosts to change 1407 the channel topic property. 1409 This mode may be set and queried like MODERATED mode. 1411 8.1.8. INVITE (RFC1459 +i) 1413 INVITE mode permits only invited users to enter the channel. 1414 Only owners and hosts can issue an invitation when this mode 1415 is on. 1417 This mode may be set and queried like MODERATED mode. 1419 8.1.9. KNOCK (IRCX +u) 1421 The KNOCK extended mode causes a KNOCK message to be sent to 1422 owners and hosts of the channel if a user attempts to join a 1423 channel and the server denies entrance. 1425 This mode may be set and queried like MODERATED mode. 1427 8.1.10. NOFORMAT (IRCX +f) 1429 The NOFORMAT channel mode is an indication to the client 1430 application not to format text received from the channel. 1432 Normally clients will prefix text messages with "x said y" or 1433 "x whispers to y and x", if the NOFORMAT mode is set then 1434 just the raw text should be displayed moving to the next line 1435 at the end of the message. The client should not echo text 1436 sent by the client. This is to permit custom applications to 1437 control the formatting to clients. Clients may want to inform 1438 users that messages can be spoofed with this mode. 1440 This mode can only be set by sysop managers. It can be read 1441 by sysop managers, sysops, owners, hosts and members of the 1442 channel. It can be read by users if the channel is PUBLIC or 1443 HIDDEN. 1445 8.1.11. NOWHISPER (IRCX +w) 1447 The NOWHISPER channel mode will prevent all messages sent to 1448 specific nicknames within the context of that channel. 1450 This channel mode may be set and read by sysop managers and 1451 owners. It can be read by sysops, hosts and members of the 1452 channel. It can be read by other users if the channel is 1453 PUBLIC or HIDDEN. 1455 8.1.12. AUDITORIUM (IRCX +x) 1457 The AUDITORIUM channel mode restricts visibility and messaging 1458 within a channel. Members will only see themselves and the 1459 hosts/owners in the channel. Any message sent by a member 1460 will only be received by the hosts and owners. Hosts and 1461 owners will see all members in the channel and messages from a 1462 host or owner are seen by all channel members. Ordinary 1463 members will not receive JOIN/PART messages from other 1464 members. This mode is designed for channels with so many 1465 members that they do not want to see each other. Note that 1466 auditorium mode may only be set at channel creation time using 1467 the CREATE command. 1469 This mode may be set and read by sysop managers, sysops, and 1470 owners. It may be read by hosts and members of the channel. 1471 It can be read by other users if the channel is PUBLIC or 1472 HIDDEN. 1474 8.1.13. REGISTERED (IRCX +r) 1476 The channel is registered by the administrator of the chat 1477 network. The registration procedure is not defined here. Only 1478 the server or server administrator can set this mode. 1480 It can be read by sysop managers, sysops, owners, hosts, and 1481 members of the channel. It can be read by users if the 1482 channel is PUBLIC or HIDDEN. 1484 8.1.14. SERVICE (IRCX +z) 1485 A service is monitoring/controlling the channel. This is an 1486 indication to the client that message traffic sent to the 1487 channel is being monitored by a Chat Service which does not 1488 appear as a member in the channel. 1490 This mode can only be set by the Chat Server. It can be read 1491 by sysop managers, sysops, owners, hosts and members of the 1492 channel. It can be read by users if the channel is PUBLIC or 1493 HIDDEN. 1495 8.1.15. AUTHONLY (IRCX +a) 1497 The AUTHONLY channel mode permits channel access only to users 1498 who have been authenticated by the server. Note that an 1499 authenticated user is any user that was successfully 1500 authenticated with the PASS command or the AUTH command. 1502 This mode can be set and read by sysop managers or owners of 1503 the channel. It can be read by sysops, hosts and members of 1504 the channel. It can be read by users if the channel is PUBLIC 1505 or HIDDEN. 1507 8.1.16. CLONEABLE (IRCX +d) 1509 The CLONEABLE channel mode defines a channel that creates new 1510 clone channels if the parent channel is full. A clone channel 1511 is created with the same name as the parent cloneable channel 1512 with a numeric suffix starting at 1, ranging to 99. It is not 1513 valid to set the CLONEABLE channel mode of a parent channel 1514 that ends with a numeric character. The clone channel 1515 inherits modes and properties from the parent channel when it 1516 is set up. When a clone channel is created, any channel that 1517 has the same name is removed. This prevents channel takeover 1518 of a clone channel. 1520 It is advised that only sysop be allowed to set cloneable mode 1521 on a channel. The mode may be read by sysops, owners, hosts 1522 and members of the channel. It may be read by users if the 1523 channel is PUBLIC or HIDDEN. 1525 8.1.17. CLONE (IRCX +e) 1527 The CLONE channel mode defines a channel that was created by 1528 the server when a parent CLONEABLE channel becomes full. 1529 Users should usually join the parent channel, although a user 1530 may join a clone channel that is not full. A sysop manager 1531 can set up a clone channel but only when the channel is being 1532 created. 1534 This mode can be set by the sysop manager and read like the 1535 SERVICE mode. 1537 8.2. Properties 1539 Each channel object contains a number of properties that can 1540 be queried and optionally updated via the IRCX PROP command. 1541 Owners and hosts may update a property for their own channel. 1542 Sysop Managers and Sysops can use the PROP command on a 1543 channel only by becoming host/owner of that channel. Users 1544 and members can read properties only. 1546 8.2.1. OID (R/O) 1548 The OID channel property is the internal object identifier for 1549 the channel. As a shortcut, the OID can be optionally used 1550 in place of the full string name of a channel. If the OID 1551 is set to "0", then this feature is not supported on the 1552 server. 1554 This property may be read by all users, except by ordinary 1555 users when the channel is SECRET or PRIVATE. 1557 8.2.2. NAME (R/O) 1559 The NAME channel property is the name of the channel (limited 1560 to 63 characters, including 1 or 2 characters for channel 1561 prefix). Valid characters are as defined in RFC1459. 1563 This property may be set and read like the OID property. 1565 8.2.3. CREATION (R/O) 1567 The CREATION channel property is the time that the channel 1568 was created, in number of seconds elapsed since midnight 1569 (00:00:00), January 1, 1970, (coordinated universal time). 1571 This property may be set and read like the OID property. 1573 8.2.4. LANGUAGE 1575 The LANGUAGE channel property is the preferred language type. 1576 The LANGUAGE property is a string limited to 31 characters. 1577 We recommend following the guidelines of RFC1766[6] to form 1578 well-understood language-defining strings. 1580 This property may be set and read by sysop managers, owners 1581 and hosts of the channel. It may be read by sysop managers, 1582 sysops and members. It may be read by users if the channel is 1583 PUBLIC or HIDDEN. 1585 8.2.5. OWNERKEY 1587 The OWNERKEY channel property is the owner keyword that will 1588 provide owner access when entering the channel. The OWNERKEY 1589 property is limited to 31 characters. 1591 This property may be set by the sysop manager or channel 1592 owner. It may never be read. 1594 8.2.6. HOSTKEY 1596 The HOSTKEY channel property is the host keyword that will 1597 provide host (channel op) access when entering the channel. 1598 The HOSTKEY property is limited to 31 characters. 1600 This property may be set and read like the OWNERKEY property. 1602 8.2.7. MEMBERKEY 1604 The MEMBERKEY channel property is the keyword required to 1605 enter the channel. The MEMBERKEY property is limited to 31 1606 characters. This is backwards-compatible with RFC1459 because 1607 users can still use the MODE command as an alternative way to 1608 set this property. 1610 This property may be set and read like the OWNERKEY property. 1612 8.2.8. PICS 1614 The PICS channel property is the current PICS rating of the 1615 channel. Chat clients that are PICS enabled can use this 1616 property to determine if the channel is appropriate for the 1617 user. The PICS property is limited to 255 characters. The 1618 format for this field is defined by PICS (see 1619 http://www.w3.org). 1621 This property may be set by sysop managers and read by all. 1622 It may not be read by ordinary users if the channel is SECRET. 1624 8.2.9. TOPIC 1626 The TOPIC channel property is the current topic of the 1627 channel. The TOPIC property is limited to 160 characters. 1629 This property may be set and read by sysop managers, owners 1630 and hosts of the channel. It may be read by sysops and 1631 members of the channel. It may be read by users if the 1632 channel is PUBLIC or HIDDEN. 1634 8.2.10. SUBJECT 1636 The SUBJECT channel property is a string that can contain 1637 subject keywords for search engines. The SUBJECT property is 1638 limited to 31 characters. 1640 This property may be set and read like the TOPIC property. 1642 8.2.11. CLIENT 1643 The CLIENT channel property contains client-specified 1644 information. The format is not defined by the server. The 1645 CLIENT property is limited to 255 characters. 1647 This property may be set and read like the TOPIC property. 1649 8.2.12. ONJOIN 1651 The ONJOIN channel property contains a string to be sent (via 1652 PRIVMSG) to a user after the user has joined the channel. The 1653 channel name is displayed as the sender of the message. Only 1654 the user joining the channel will see this message. Multiple 1655 lines can be generated by embedding '\n' in the string. The 1656 ONJOIN property is limited to 255 characters. 1658 This property may be set and read by sysop managers, owners 1659 and hosts of the channel. It may additionally be read by 1660 sysops. 1662 8.2.13. ONPART 1664 The ONPART channel property contains a string that is sent 1665 (via NOTICE) to a user after they have parted from the 1666 channel. The channel name is displayed as the sender of the 1667 message. Only the user parting the channel will see this 1668 message. Multiple lines can be generated by embedding '\n' 1669 in the string. The ONPART property is limited to 255 1670 characters. 1672 This property may be set and read like the ONJOIN property. 1674 8.2.14. LAG 1676 The LAG channel property contains a numeric value between 0 to 1677 2 seconds. The server will add an artificial delay of that 1678 length between subsequent messages from the same member. All 1679 messages to the channel are affected. 1681 This property may be set and read by sysop managers and 1682 owners. It can additionally be read by sysops, hosts, and 1683 members of the channel. It can be read by users if the 1684 channel is PUBLIC or HIDDEN. 1686 8.2.15. ACCOUNT 1688 The ACCOUNT channel property contains an implementation- 1689 dependent string for attaching a security account. This 1690 controls access to the channel using the native OS security 1691 system. The ACCOUNT property is limited to 31 characters. 1693 This property may be set by sysop managers. It can only be 1694 read by sysop managers, sysops and owners of the channel. 1696 8.2.16. CLIENTGUID 1697 The CLIENTGUID channel property contains a GUID that defines 1698 the client protocol to be used within the channel. 1700 This property may be set and read like the LAG property. 1702 8.2.17. SERVICEPATH 1704 The SERVICEPATH channel property contains the path of a server 1705 side extension that is used to control the channel operation. 1706 Details are implementation-dependent. 1708 This property may be set and read like the LAG property. 1710 9. IRCX Command Responses 1712 The new extended IRCX numeric replies follow the same 1713 convention as IRC replies, with a specific range for command 1714 responses and another range for error results. The IRCX 1715 command responses are in the range of 800 to 899 and 900 to 1716 999 for the error results. 1718 9.1. Command Replies 1720 800 - IRCRPL_IRCX 1722 1724 The response to the IRCX and ISIRCX commands. The 1725 indicates if the client has IRCX mode enabled (0 for disabled, 1726 1 for enabled). The is the version of the IRCX 1727 protocol starting at 0. The contains a list 1728 of authentication packages supported by the server. The 1729 package name of "ANON" is reserved to indicate that anonymous 1730 connections are permitted. The defines the maximum 1731 message size permitted, with the standard being 512. The 1732 contains a list of options supported by the 1733 server; these are implementation-dependent. If no options are 1734 available, the '*' character is used. 1736 801 - IRCRPL_ACCESSADD 1738 : 1740 Response to a successful ACCESS ADD command. The is 1741 the name of the object to which the access restrictions apply 1742 (i.e. channel name or user name). The is the level of 1743 access being added (i.e. GRANT, DENY). The is the 1744 selection mask. If no mask is provided in the ACCESS command, 1745 then the default mask of *!*@*$* is used. The is 1746 the amount of time this access entry will last. The is 1747 the one who added the new ACCESS record. The is the 1748 reason supplied in the ACCESS ADD command. 1750 802 - IRCRPL_ACCESSDELETE 1751 1753 Response to a successful ACCESS DELETE command. See reply 1754 801 for explanation of the fields. 1756 803 - IRCRPL_ACCESSSTART 1758 :Start of access entries 1760 Beginning of a list of access entries. is the object 1761 to which the access restrictions apply (i.e. channel name or 1762 user name). The next message will be an IRCRPL_ACCESSLIST or 1763 IRCRPL_ACCESSEND reply. 1765 804 - IRCRPL_ACCESSLIST 1767 : 1769 One entry in a list of access entries. See reply 801 for 1770 explanation of the fields. 1772 805 - IRCRPL_ACCESSEND 1774 :End of access entries 1776 End of a list of access entries. See reply 803 for explanation 1777 of the field. This reply will always follow an 1778 IRCRPL_ACCESSSTART or IRCRPL_ACCESSLIST reply. 1780 806 - IRCRPL_EVENTADD 1782 1784 The acknowledgment response to the EVENT ADD command. The 1785 contains the name of the event added. The is 1786 the selection mask. If no mask is provided in the EVENT 1787 command, then the default mask of *!*@*$* is used. 1789 807 - IRCRPL_EVENTDEL 1791 1793 The acknowledgment response to the EVENT DELETE command. The 1794 contains the name of the deleted event. The is 1795 the selection mask. If no mask is provided in the EVENT 1796 command, then the default mask of *!*@*$* is used. 1798 808 - IRCRPL_EVENTSTART 1800 :Start of events 1802 Response to the EVENT LIST message that indicates the 1803 start of the event list. 1805 809 - IRCRPL_EVENTLIST 1807 1809 Response to the EVENT LIST message that displays a 1810 list of current events that the client is interested in. 1812 810 - IRCRPL_EVENTEND 1814 :End of events 1816 Response to the EVENT LIST message that indicates the 1817 end of the event list. 1819 811 - IRCRPL_LISTXSTART 1821 :Start of ListX 1823 First reply to a LISTX (extended list) command. Will always 1824 be followed by a reply of type 812, 816 or 817. 1826 812 - IRCRPL_LISTXLIST 1828 : 1830 Single list item in an extended list of channels. The 1831 is the name of the channel in the list. The 1832 specify the current modes set on the channel. lists 1833 the members currently in the channel. returns 1834 the member limit of the channel. returns the topic of 1835 the channel. 1837 813 - IRCRPL_LISTXPICS 1839 : 1841 PICS rating string for the last channel listed (follows an 812 1842 message). 1844 816 - IRCRPL_LISTXTRUNC 1846 :Truncation of ListX 1848 Last reply to a LISTX command, either because the user asked 1849 for a limited list of channels or because the server truncated 1850 the list to prevent output flooding. Always follows a reply 1851 of type 811, 812 or 813. 1853 817 - IRCRPL_LISTXEND 1855 :End of ListX 1857 Last reply to a LISTX command, indicating that the list has 1858 ended. Always follows a reply of type 811, 812 or 813. 1860 818 - IRCRPL_PROPLIST 1862 : 1864 A value in a property list. The is the name of the 1865 object (i.e., channel name). The is the property 1866 in the list. The is the value of the property listed. 1868 819 - IRCRPL_PROPEND 1870 :End of properties 1872 Last message in a property list. 1874 9.2. IRCX Error Replies. 1876 900 - IRCERR_BADCOMMAND 1878 :Bad command 1880 Response to an incorrectly formatted command. 1882 901 - IRCERR_TOOMANYARGUMENTS 1884 :Too many arguments 1886 Response to too many arguments being provided for a command. 1888 902 - IRCERR_BADFUNCTION 1890 :Bad function 1892 Response to a command that supports functions, with invalid 1893 function sent by the user. For example, the EVENT command 1894 supports functions. 1896 903 - IRCERR_BADLEVEL 1898 :Bad level 1900 Response to an ACCESS command with a bad level specified (i.e. 1901 not GRANT, DENY...) 1903 904 - IRCERR_BADTAG 1905 :Bad message tag. 1907 Response to a DATA/REQUEST/REPLY with an incorrect message 1908 tag. 1910 905 - IRCERR_BADPROPERTY 1912 :Bad property specified 1913 Response to a channel property command with a bad property 1914 specified. 1916 906 - IRCERR_BADVALUE 1918 :Bad value specified 1920 Response to an attempt to set an integer property to a string 1921 value (PROP command). 1923 907 - IRCERR_RESOURCE 1925 :Not enough resources 1927 Server does not have enough resources to perform command. 1929 908 - IRCERR_SECURITY 1931 :No permissions to perform command 1933 For security reasons, the command/function/operation is not 1934 permitted for this level of client. 1936 909 - IRCERR_ALREADYAUTHENTICATED 1938 :Already authenticated 1940 The client is already authenticated with the server. 1942 910 - IRCERR_AUTHENTICATIONFAILED 1944 :Authentication failed 1946 The authentication failed due to a bad userid/password or 1947 server/network failure. 1949 911 - IRCERR_AUTHENTICATIONSUSPENDED 1951 :Authentication suspended for this IP 1953 Authentication has been temporary disabled due to too many 1954 authentication failures from this IP. 1956 912 - IRCERR_UNKNOWNPACKAGE 1958 :Unsupported authentication package 1960 The authentication package specified is not known to the 1961 server. ISIRCX command will return a list of supported 1962 authentication packages. 1964 913 - IRCERR_NOACCESS 1966 :No access 1967 Response to a user trying to change the ACCESS list for an 1968 object the user does not have sufficient privileges to alter. 1970 914 - IRCERR_DUPACCESS 1972 :Duplicate access entry 1974 An access entry already exists for the specified user mask. 1976 915 - IRCERR_MISACCESS 1978 :Unknown access entry 1980 Response to ACCESS DELETE command when server does not 1981 recognize the entry to be removed. 1983 916 - IRCERR_TOOMANYACCESSES 1985 :Too many access entries 1987 Response to ACCESS ADD command when maximum number of access 1988 entries has been reached. 1990 918 - IRCERR_EVENTDUP 1992 :Duplicate event entry 1994 The user has asked for an event that is already being sent. 1996 919 - IRCERR_EVENTMIS 1998 :Unknown event entry 2000 Response to event remove command when user is not already 2001 receiving the event specified. 2003 920 - IRCERR_NOSUCHEVENT 2005 :No such event type 2007 Response to event add command when server does not recognize 2008 the event specified. 2010 921 - IRCERR_TOOMANYEVENTS 2012 :Too many events specified 2014 Response to event add command when user may not add another 2015 event to monitor. 2017 923 - IRCERR_NOWHISPER 2019 :Does not permit whispers 2020 Response to whisper command when channel does not permit 2021 whispers. 2023 924 - IRCERR_NOSUCHOBJECT 2025 :No such object found 2027 Response to an attempt to define a property for an object 2028 which can't be found (PROP command). 2030 925 - IRCERR_NOTSUPPORTED 2032 :Command not supported by object 2034 Response to PROP and ACCESS commands when a bad object was 2035 specified in the command. 2037 926 - IRCERR_CHANNELEXIST 2039 :Channel already exists. 2041 The channel name in the CREATE command already exists on the 2042 server and the +c mode was specified. 2044 927 - IRCERR_ALREADYONCHANNEL 2046 :Already in the channel. 2048 Response to join command when user is already in the channel. 2050 999 - IRCERR_UNKNOWNERROR 2052 :Unknown error code 2054 The internal error generated doesn't map to a valid IRCX error 2055 reply. The error code is implementation-dependent. 2057 10. Security Considerations 2059 Security issues are also discussed in the authentication 2060 section. 2062 The IRCX and ISIRCX commands return a set of authentication 2063 mechanisms supported by the server. This method is open to a 2064 middle man attack whereby an attacker modifies the list of 2065 returned authentication methods and only offers a clear-text 2066 password transaction. In order to avoid this type of 2067 attack, only authentication methods with a challenge response 2068 mechanism should be used. 2070 Since all administration commands for RFC1459 and IRCX are 2071 sent in clear text, a stream layer encryption mechanism like 2072 SSL[5] or IPSEC is required to protect the integrity and 2073 confidentiality of the transactions. The mechanisms for 2074 establishing these connection are outside the scope of this 2075 document. 2077 11. Acknowledgements 2079 Specific acknowledgments must be extended to the following 2080 people as the editors of the previous versions: 2082 Kent Cedola, Lisa Dusseault, and Thomas Pfenning 2084 In addition it has benefited from many rounds of review and 2085 comments. As so, any list of contributors is bound to be 2086 incomplete; please regard the following as only a selection 2087 from the group of people who have contributed to make this 2088 document what it is today. 2090 In alphabetical order: 2092 Josh Cohen, Alex Hoppman, David Kurlander, Robert Uttecht, and 2093 Teoman Smith 2095 12. References 2097 [1] "Internet Relay Chat Protocol", Network Working Group RFC 2098 1459, J. Oikarinen, D. Reed, May 1993 2100 [2] The Unicode Consortium, "The Unicode Standard Version 2101 2.0", Addison Wesley Developers Press, July 1996 2103 [3] "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", 2104 Network Working Group RFC 2060, M. Crispin, December 1996 2106 [4] "Simple Authentication and Security Layer (SASL)", Work 2107 in Progress, draft-myers-auth-sasl-07.txt, J. Myers, December 2108 1996 2110 [5] "The SSL Protocol Version 3.0", Work in Progress, draft- 2111 ietf-tls-ssl-version3-00.txt, Alan O. Freier, Philip Karlton, 2112 Paul C. Kocher, November 1996 2114 [6] "Tags for the Identification of Languages", Network 2115 Working Group RFC 1766, H. Alvestrand, March 1995 2117 13. Authors' Addresses 2119 Dalen Abraham 2121 Microsoft Corporation 2123 One Microsoft Way 2125 Redmond, WA 98052 2127 EMail: dalena@microsoft.com