idnits 2.17.1 draft-pfenning-irc-extensions-02.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-25) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 39 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 39 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 326 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 547 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...), its areas...' == Line 13 has weird spacing: '... its worki...' == Line 17 has weird spacing: '... and may ...' == Line 18 has weird spacing: '...afts as refer...' == Line 21 has weird spacing: '... To learn...' == (321 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 1850 looks like a reference -- Missing reference section? '2' on line 1853 looks like a reference -- Missing reference section? '4' on line 1859 looks like a reference -- Missing reference section? '5' on line 1862 looks like a reference -- Missing reference section? '3' on line 1856 looks like a reference Summary: 17 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kent Cedola 3 File: Lisa Dusseault 4 20 August 1997 Thomas Pfenning 5 Microsoft Corporation 7 Extensions to the Internet Relay Chat Protocol (IRCX) 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 The distribution of this memo is unlimited. It is filed as , and expires February 25, 1998. 28 Please send comments to the authors. 30 2. Abstract 32 This document describes extensions to the Internet Relay Chat (IRC) 33 protocol defined in RFC 1459[1]. Only client-server interactions are 34 defined. The added functionality includes optional user authentication 35 for multiple security providers, support for UNICODE[2] characters, 36 multilayer security, and a unified property mechanism. Chat server 37 implementations can optionally support channel or server services with 38 full control over all messages and events. These services communicate 39 with the core server over an extended IRC connection. 41 All changes to the IRC protocol are designed in a way that existing 42 clients will continue to work against servers implementing the exten- 43 sions. Support for the extended protocol can be queried by clients to 44 take advantage of the added functionality or to conform to the basic 45 protocol as defined in RFC1459. 47 3. Modified UTF8 Encoding of UNICODE characters 49 Allowing UNICODE characters for all user visible strings introduces a 50 set of compatibility problems if the protocol must be backward compat- 51 ible. UTF8 encoding is used to convert wide UNICODE characters into a 52 string compatible with existing IRC servers and clients. 54 To permit the full range of UNICODE characters, we must introduce an 55 additional postprocessing step on the result of an UTF8 translation. 57 Any string beginning with a '%' character (i.e. "reason" strings 58 within a REDIRECT command) may be interpreted as UTF8-encoded UNICODE 59 strings. 61 UNICODE characters encoded in UTF8 may use more bytes than an ASCII 62 character. To ensure compatibility, UNICODE strings such as nicknames 63 and channel names must fit within the standard length measured in 64 bytes, not in characters. 66 The quoting character for the postprocessing step is the '\' charac- 67 ter. All mappings are listed in the table below. 69 +------------------------------------+ 70 |Table 1 - Character Quoting in UTF8 | 71 +----------------+-------------------+ 72 | \b | for " " blank | 73 | \c | for "," | 74 | \\ | for "\" | 75 | \r | for CR | 76 | \n | for LF | 77 | \t | for TAB | 78 +----------------+-------------------+ 80 IRCX clients will view UNICODE strings in their native form. So that 81 non-IRCX clients can interoperate with UNICODE nicks, UNICODE nicks 82 are translated by the server into a usable form before being sent to 83 the non-IRCX client. Usable format is a simple hex format preceded by 84 a '^' character. Non-IRCX clients can use this hex format nickname to 85 specify the IRCX/UNICODE user. The server may prevent duplicate nicks 86 by preventing users from setting their nick to a valid hex translation 87 (a '^' character followed by an even number of hex characters). 89 4. Terms and Definitions 91 Throughout this document we will use certain terms which are defined 92 in the following pages. 94 String lengths are indicated in "characters", referring to ASCII char- 95 acters, because even UNICODE strings must be encoded in ASCII for the 96 IRC protocol. 98 +------------------------------------------------------------------+ 99 | Table 2 - Definition of Terms | 100 +---------------+--------------------------------------------------+ 101 | Chat Network | A Chat Network is comprised of one or more | 102 | | servers linked together. | 103 | Server | A server is a single machine. | 104 | Channel | A channel (sometimes called a room or confer- | 105 | | ence) is a conversation between one or more | 106 | | users. | 107 | Member | A member is a user that is part of a conversa- | 108 | | tion in a channel. | 109 | User | A user is a client that makes a connection to | 110 | | the server. | 111 | Objects | An object is a general term for channels, | 112 | | users, members (users in a channel), and | 113 | | servers. The type of object can be determined | 114 | | from the first character of the object's name. | 115 +---------------+--------------------------------------------------+ 117 4.1. User Access Levels 119 There are six user levels that define the ability of the user to per- 120 form operations. Some levels are determined on the context of the 121 operation to be performed. 123 +------------------------------------------------------------------+ 124 | Table 3 - Definition of Client Levels | 125 +---------------------+--------------------------------------------+ 126 | Chat Administrator | A Chat Administrator has full access to | 127 | | the server. | 128 | Chat Sysop | A Chat Sysop oversees and controls the | 129 | | chat network. | 130 | Channel Owner | A Channel Owner manages a channel and | 131 | | the channel hosts. | 132 | Channel Host | A Channel Host manages a channel. Also | 133 | | referred to as a channel operator. | 134 | Channel Member | A Channel Member is a member of a chan- | 135 | | nel. | 136 | Chat User | A Chat User is a client connected to the | 137 | | server. | 138 +---------------------+--------------------------------------------+ 140 4.2. Prefixes 142 Each object contains a unique prefix that identifies the type of 143 object. By tagging UNICODE objects with a special prefix, a client 144 can easily decide whether to use standard ASCII or UNICODE when send- 145 ing a message to a user or channel. The IRCX client is responsible, 146 when sending a UNICODE string, for prefixing it with a '%' character 147 so that other IRCX clients can interpret it as UNICODE. 149 +-----------------------------------------------------------------+ 150 | Table 4 - Object identifiers | 151 +---------+-------------------------------------------------------+ 152 | # | The '#' prefix identifies a RFC1459 global channel. | 153 | & | The '&' prefix identifies a RFC1459 local channel. | 154 | %# | The "%#" prefix identifies an extended global chan- | 155 | | nel name (a modified UTF8-encoded UNICODE string). | 156 | %& | The "%&" prefix identifies an extended local chan- | 157 | | nel name (a modified UTF8-encoded UNICODE string). | 158 | % | The '%' character followed by a space or comma can | 159 | | identify the last channel that this client speci- | 160 | | fied and is a member of. Its function is to opti- | 161 | | mize server processing of multiple messages from a | 162 | | client to a channel. Support for this feature is | 163 | | optional. | 164 | A to } | The 'A' through '}' prefix identifies a standard | 165 | | RFC1459 nickname. | 166 | ' | The ''' prefix identifies an extended IRCX nickname | 167 | | which consists of a modified UTF8-encoded UNICODE | 168 | | string. The ''' character followed by a space or | 169 | | comma may be used to represent the local client | 170 | | connection (support for this feature is optional). | 171 | | The characters following ''' can be '0' through | 172 | | '9', '-', and any character above 'A'. | 173 | ^ | The '^' prefix identifies a nickname which was | 174 | | translated from UTF8 into hex characters so that | 175 | | the nickname can be viewed by non-IRCX clients. | 176 | | The characters following '^' can be any standard | 177 | | RFC1459 nickname characters. | 178 | 0 | The '0' prefix identifies an internal object iden- | 179 | | tifier (OID). The OID consists of the '0' prefix | 180 | | and eight hexadecimal characters. Use of the OID | 181 | | is implementation dependent. | 182 | $ | The '$' prefix identifies a server on the network. | 183 | | The '$' character followed by a space or comma may | 184 | | be used to represent the local server the client is | 185 | | connected to (support for this feature is | 186 | | optional). | 187 +---------+-------------------------------------------------------+ 189 5. IRCX Client Messages 191 This section details commands which have been added and commands which 192 have changed from RFC1459. Responses from the server are discussed in 193 greater detail in later sections. 195 5.1. ACCESS command (new IRCX command) 197 Create an "access entry" for an object to grant or deny access to an 198 object, including a channel, a user, or the server. ACCESS LIST is 199 used to list all access entries for an object and CLEAR is used to 200 clear all entries or all entries of the same level. 202 Syntax 1: ACCESS LIST 203 Syntax 2: ACCESS ADD|DELETE [] 204 [:] 206 Syntax 3: ACCESS CLEAR [] 208 5.1.1. Parameters 210 The object to which access is being granted or limited. Can 211 be: 213 Channel 214 Nickname 215 $ Chat server to which the command is sent 216 * All chat servers on the network 218 The level of access being given or taken away. Can be: 220 DENY Disallow access to an object that is accessible 221 GRANT Allow access to an object that is inaccessible 222 HOST Channel host access to specified channel 223 OWNER Channel owner access to specified channel 224 VOICE Voice access to specified channel 226 Mask to identify user by nickname, userid, host or server 227 characteristics. Supports wildcards * and ?. 229 Minutes until the access entry is removed. A value of 0 230 indicates unlimited duration. 232 Text reason shown when users are denied access due to the 233 access entry. 235 5.1.2. Results 237 IRCRPL_ACCESSADD 238 IRCRPL_ACCESSDELETE 239 IRCRPL_ACCESSSTART 240 IRCRPL_ACCESSLIST 241 IRCRPL_ACCESSEND 243 5.1.3. Possible Errors 245 In this specification possible error messages are listed. Which error 246 messages are used is dependent on the server implementation. 248 IRCERR_BADLEVEL 249 IRCERR_DUPACCESS 250 IRCERR_MISACCESS 251 IRCERR_TOOMANYACCESSES 252 IRCERR_TOOMANYARGUMENTS 253 IRCERR_BADCOMMAND 254 IRCERR_SECURITY 256 5.1.4. Remarks 258 An object with GRANT access entries but no DENY entries is assumed to 259 be off-limits to those users not covered by the GRANT entries. If 260 there are multiple entries in the access list, the list is processed 261 in the following order: OWNER, HOST, VOICE, GRANT, DENY. 263 Hosts and Owners may add and delete access entries for their channel. 264 Hosts may not remove access entries added by owners. Any user may add 265 and delete access entries for themselves. Sysops and admins on a 266 server may add and delete access entries for that server or the entire 267 network. 269 A user who has blocked another user should not get any messages from 270 the blocked user, including invites. 272 5.1.5. Example: 274 To make a user a channel host when they join the channel: 276 ACCESS #mychan ADD HOST piper 278 To grant normal access to the network to a few people but deny access 279 to all others: 281 ACCESS * ADD DENY * :closed for private party 282 ACCESS * ADD GRANT *.company.com :these are the people that can get 283 on 285 To delete the DENY access record on the network that denies access to 286 '*' (note that this doesn't delete other DENY access records such as 287 '*.com'): 289 ACCESS * DELETE DENY * 291 To clear all DENY-level entries on the local server: 293 ACCESS $ CLEAR DENY 295 To clear all access entries of any level for a channel: 297 ACCESS #mychan CLEAR 299 5.2. AUTH Command (new IRCX command) 301 Authenticate the client using an SASL[4] authentication mechanism. The 302 details of the authentication mechanisms are specified in a profile 303 that should be registered with the IANA. 305 Syntax 1: AUTH : [] 307 5.2.1. Parameters 309 The name of the SASL mechanism to use for authentication. The 310 specific SASL mechanisms supported are implementation-dependent. 312 The sequence is a value of 'I' or 'S'. The 'I' value is speci- 313 fied for the initial AUTH message and the 'S' value is specified for 314 all subsequent AUTH messages. If the client specifies '*' for the 315 sequence, the server will abort the authentication sequence and return 316 IRCERR_AUTHENTICATIONFAILED. 318 This is optional data sent as an argument with the AUTH 319 messages. The content depends on the authentication mechanism being 320 used. All content must use standard escaping formats (eg. \r for car- 321 riage return) to comply with IRC message format restrictions. 323 5.2.2. Results 325 AUTH message 327 5.2.3. Possible Errors 329 IRCERR_ALREADYAUTHENTICATED 330 IRCERR_ALREADYREGISTERED 331 IRCERR_AUTHENTICATIONFAILED 332 IRCERR_AUTHENTICATIONSUSPENDED 333 IRCERR_BADCOMMAND 334 IRCERR_NEEDMOREPARAMS 335 IRCERR_UNKNOWNPACKAGE 337 5.2.4. Remarks: 339 If the server is known to support IRCX with specific SASL mecha- 340 nism(s), then the first message must be the AUTH command (if authenti- 341 cation is to be used), before the USER and NICK commands. Use MODE 342 ISIRCX to determine if the server supports IRCX. 344 5.2.5. Example: 346 Client: AUTH NTLM I: 347 Server: AUTH NTLM S: 348 Client: AUTH NTLM S: 349 Server: AUTH NTLM * userid@domain 03FA4534C 351 5.3. CREATE (new IRCX command) 353 Create a new channel and/or join an existing channel. 355 Syntax: CREATE [] 357 5.3.1. Parameters 359 The name of the channel. 361 Initial channel modes, not separated by spaces (like MODE 362 command). Includes mode 'e' to force a clone of a clonable channel. 364 Optional mode arguments, separated by spaces, in the same 365 order as the modes. For the mode 'l' the mode argument is the maximum 366 number of members in the channel. For the mode 'k' the mode argument 367 is the channel keyword. These are the only modes that require mode 368 arguments. 370 5.3.2. Results 372 CREATE message 373 JOIN message. 374 RPL_TOPIC 375 RPL_NAMEPLY 376 RPL_ENDOFNAMES 378 5.3.3. Possible Errors 380 IRCERR_CHANNELEXIST 381 IRCERR_ALREADYONCHANNEL 382 ERR_NEEDMOREPARAMS 383 ERR_INVITEONLYCHAN 384 ERR_CHANNELISFULL 385 ERR_BANNEDFROMCHAN 386 ERR_BADCHANNELKEY 387 ERR_TOOMANYCHANNELS 388 ERR_UNKNOWNCOMMAND 390 5.3.4. Remarks 392 The CREATE command provides a method to specify channel properties at 393 creation time, and also provides a method (flag 'c') to create and 394 join a channel only if it does not already exist. If user is not in 395 IRCX mode, server returns ERR_UNKNOWNCOMMAND. 397 5.3.5. Examples 399 This example shows the creation of a moderated (m) channel with the 400 following properties and modes: its topic can only be changed by an 401 owner or host (t = TOPICOP), messages from outside the channel are 402 blocked (n = NOEXTERN), it is limited to 50 members (l 50), it has a 403 member key which is 'password' (k password), and it will be created 404 only if it doesn't already exist (c = CREATE) 406 Client: CREATE #MyChannel tnmlkc 50 password 407 Server: CREATE #MyChannel 048532944 409 5.4. DATA / REQUEST / REPLY 411 Used to send tagged data, requests or replies. The syntax for each is 412 the same, but clients can use REQUEST to indicate that a REPLY is 413 desired, and use REPLY to indicate that a REQUEST was issued. If user 414 is not in IRCX mode, server returns ERR_UNKNOWNCOMMAND. 416 Syntax 1: DATA : 418 5.4.1. Parameters 420 The target for the data. Target can be a nick, list of 421 nicks, channel, list of channels, or channel followed by a list of 422 some members of the channel. This definition for will be 423 used throughout this document. 425 Text field that clients use to know how to interpret the data. 426 Valid characters are [A..z], [0..9] and period (.). The first charac- 427 ter must be one of [A..z]. Maximum 15 characters. If the tag begins 428 with SYS or ADM then the originator must have sysop or admin privi- 429 leges. The server itself can send tags beginning with SYS or ADM. 431 Payload or data for the message, ending with a newline. 432 Any newlines or other control characters within the body of the mes- 433 sage must be escaped. 435 5.4.2. Results 437 DATA message 439 5.4.3. Possible Errors 441 ERR_UNKNOWNCOMMAND 442 5.4.4. Remarks 444 REPLY and REQUEST may be used to replace "DATA". IRCX servers should 445 not send DATA commands to clients that have not indicated that they 446 support IRCX. Clients should only process DATA messages if they know 447 and support the tag used. 449 Prefixes should indicate the organization that specified them, when 450 appropriate. For example: MYORG.AVATAR could be a tag used by MyOrg, 451 as would be all MYORG.* tags. 453 5.4.5. Example 455 Sending ad banners from server admin to channel 457 DATA #Channel SYS.AD.SMALL : 459 5.5. EVENT (new IRCX command) 461 Add/Change/Delete event logging to the client connection. The list of 462 event types and the way masks are applied may vary depending on the 463 server implementation. 465 Syntax 1: EVENT [ADD | DELETE] [] 467 Syntax 2: EVENT LIST [] 469 5.5.1. Parameters 471 Type of event, such as CHANNEL, MEMBER, SERVER, CONNECTION, 472 SOCKET or USER. 474 Optional mask for applying a selection criteria per event. 476 5.5.2. Results 478 IRCRPL_EVENTADD 479 IRCRPL_EVENTDEL 480 IRCRPL_EVENTSTART 481 IRCRPL_EVENTLIST 482 IRCRPL_EVENTEND 484 5.5.3. Possible Errors 486 IRCERR_NEEDMOREPARAMS 487 IRCERR_BADFUNCTION 488 IRCERR_EVENTDUP 489 IRCERR_EVENTMIS 490 IRCERR_NOSUCHEVENT 491 IRCERR_TOOMANYEVENTS 492 ERR_NOPRIVILEGES 494 5.5.4. Remarks 496 Use the EVENT command to define the events that an admin or sysop 497 wishes to be notified of. The format above is the recommended format 498 for this optional command. It is advised that only admins and/or 499 sysops be allowed to receive event messages. 501 5.5.5. Examples: 503 Add channel events. 505 Client: EVENT ADD CHANNEL 506 Server: : 806 CHANNEL *!*@*$* 508 Add a list event with no active events returned. 510 Client: EVENT LIST 511 Server: : 808 :Start of events 512 : 809 CHANNEL *!*@*$* 513 : 810 :End of events. 515 5.6. IRCX (new IRCX command) 517 Enables IRCX mode and displays IRCX status. Use MODE ISIRCX first to 518 see if the server supports IRCX. 520 Syntax: IRCX 522 5.6.1. Parameters 524 None. 526 5.6.2. Results 528 IRCRPL_IRCX 530 5.6.3. Example 532 This example includes a server that supports IRCX and three authenti- 533 cation packages. 535 Client: IRCX 536 Server: : 800 1 0 NTLM,DPA,ANON 512 * 538 5.7. ISIRCX (new IRCX command) 540 Queries whether or not the server supports the Extended RFC1459 proto- 541 col (IRCX). Server response is same as for IRCX message. 543 Syntax: ISIRCX 544 5.7.1. Results 546 IRCRPL_IRCX 548 5.8. LISTX (new IRCX command) 550 Extended version of the LIST command that returns additional channel 551 properties. Channels with extended names will be returned, even to 552 non-IRCX clients. Some channel modes and the PICS rating string are 553 included with the result. Only the channel modes that do not define 554 an additional argument (TOPICOP, NOEXTERN, etc.) are included in the 555 field. Clients should use the query limit to avoid overloading 556 the client or having the connection dropped by the server. 558 Syntax 1: LISTX [] 560 Syntax 2: LISTX [] 562 5.8.1. Parameters 564 A list of channels may be specified in order to find 565 the PICS ratings or modes of those channels. If no channels are spec- 566 ified, the server will send the entire matching list of channels. 568 One or more query terms separated by spaces or commas. 570 +--------------------------------------------------------------------+ 571 | Table 5 - Query terms for LIST command | 572 +-----------+--------------------------------------------------------+ 573 | <# | Select channels with less than # members | 574 | ># | Select channels with more than # members | 575 | C<# | Select channels created less than # minutes ago | 576 | C># | Select channels created greater than # minutes ago | 577 | L= | Select channels with language property matching the | 578 | | mask string | 579 | N= | Select channels with name matching the mask string | 580 | R=0 | Select unregistered channels | 581 | R=1 | Select registered channels | 582 | S= | Select channels with subject matching the mask | 583 | | string | 584 | T<# | Select channels with a topic changed less than # | 585 | | minutes ago | 586 | T># | Select channels with a topic changed greater than # | 587 | | minutes ago | 588 | T= | Select channels that topic matches the mask string | 589 +-----------+--------------------------------------------------------+ 591 Maximum number of channels to be returned. 593 Sequence of characters that is used to select a matching chan- 594 nel name or topic. The character * and ? are used for wildcard 595 searches. 597 5.8.2. Results 599 IRCRPL_LISTXSTART 600 IRCRPL_LISTXLIST 601 IRCRPL_LISTXPICS 602 IRCRPL_LISTXTRUNC 603 IRCRPL_LISTXEND 605 5.8.3. Remarks 607 To compose a mask, use this character escaping scheme. 609 +--------------------------------------------+ 610 |Table 6 - Character escaping in mask-string | 611 +--------------------+-----------------------+ 612 | \b | for " " blank | 613 | \c | for "," | 614 | \\ | for "\" | 615 | \* | for * | 616 | \? | for ? | 617 +--------------------+-----------------------+ 618 The PICS property is only returned if not null. 620 A record limit of '0' (zero) or blank will be interpreted as unlim- 621 ited. 623 5.9. MODE (extension to RFC1459 command) 625 MODE command can now be used for new user or channel modes (see later 626 sections). In addition, the special syntax "MODE ISIRCX" can be used 627 to help clients find out whether a server supports IRCX. 629 Syntax: MODE ISIRCX 631 5.9.1. Results 633 MODE message 634 IRCRPL_IRCX 636 5.9.2. Remarks 638 The ISIRCX mode (must be in capital letters) is only functional before 639 the user has registered with the server. IRCX servers respond with 640 IRCRPL_IRCX and non-IRCX servers should return an error code. This 641 allows unregistered users to query whether the server supports IRCX. 643 See RFC1459 for more details on the original MODE command and its 644 parameters. 646 5.10. NOTICE (extension to RFC1459 command) 648 Sends a notice to a channel or user. In RFC1459 a notice could only 649 be sent to a channel or a list of users. Now a notice can be sent to 650 a list of users within the context of a channel. As before, users 651 will not get the list of users that received the notice. 653 Syntax: NOTICE : 655 5.10.1. Results 657 Same as defined in RFC1459, but with the additional functionality of 658 sending to a list of nicknames within the context of a channel. 660 5.11. PRIVMSG (extension to RFC1459 command) 662 Sends a message to a channel or user. PRIVMSG is extended in the same 663 way as NOTICE. 665 Syntax: PRIVMSG : 667 5.11.1. Results 669 Same as defined in RFC1459, but with the additional functionality of 670 sending to a list of nicknames within the context of a channel. 672 5.12. PROP (new IRCX command) 674 Add, change or delete a channel data property. 676 To query a property: 678 Syntax 1: PROP [,] 680 To set or change a property: 682 Syntax 2: PROP : 684 To delete a property: 686 Syntax 3: PROP : 688 5.12.1. Results 690 PROP message 691 IRCRPL_PROPLIST 692 IRCRPL_PROPEND 694 5.12.2. Possible Errors 696 IRCERR_BADCOMMAND 697 IRCERR_BADPROPERTY 698 IRCERR_SECURITY 699 IRCERR_NOSUCHOBJECT 700 IRCERR_TOOMANYARGUMENTS 701 IRCERR_BADVALUE 703 5.12.3. Remarks 705 The PROP command provides a new method for manipulating string and 706 numeric properties of channels. If an optional channel property is 707 not supported on the server, the server should return IRCERR_BADPROP- 708 ERTY. 710 See section 8.2 for definitions of channel properties. 712 5.12.4. Examples 714 Client: PROP #MyChan TOPIC,ONJOIN 715 Server: : 818 #MyChan TOPIC :This is the topic of my channel 716 Server: : 818 #MyChan ONJOIN :Welcome to my channel! 717 Server: : 819 #MyChan :End of properties 719 Client: PROP #MyChannel TOPIC :Change my channel topic to something 720 Server: PROP #MyChannel TOPIC :Change my channel topic to something 722 5.13. WHISPER (new IRCX command) 724 Whisper to member(s) in a channel. 726 Syntax: WHISPER : 728 5.13.1. Results 730 WHISPER message 732 5.13.2. Possible Errors 734 ERR_UNKNOWNCOMMAND 735 IRCERR_NEEDMOREPARAMS 736 IRCERR_NOTONCHANNEL 737 IRCERR_CANNOTSENDTOCHANNEL 738 IRCERR_TOOMANYTARGETS 739 IRCERR_NOSUCHNICK 740 IRCERR_NOSUCHCHANNEL 741 IRCERR_NOWHISPER 742 ERR_USERNOTINCHANNEL 744 5.13.3. Remarks 746 The purpose of the WHISPER command is to whisper to one or more mem- 747 bers in a channel within the context of that channel. The sender and 748 all recipients must be in the channel specified. 750 IRCX clients should display the WHISPER message within the context 751 (window) of the specified channel. Non-IRCX clients may receive a 752 PRIVMSG with the content of the whisper. Only one whisper will be 753 sent per nick. A user may whisper to themselves. 755 The channel mode 'w' will disable whispers between ordinary members of 756 the channel (but not whispers from or to channel operators). 758 6. IRCX Server Messages 760 This section summarizes new extended messages which can be sent from 761 the server. 763 6.1. AUTH (new IRCX message) 765 Negotiates authentication with client or informs client that autho- 766 rization was successful. 768 Syntax 1 (negotiating authorization): AUTH S: [] 770 Syntax 2 (authorization successful): AUTH * 772 6.1.1. Parameters 774 The name of the SASL mechanism to use for authentication. The 775 specific SASL mechanisms supported are implementation-dependent. 777 The ident is the userid@domain of the authenticated client 778 account. It is returned on the final response from the server (Syntax 779 2) when authentication is successful. 781 The OID is the internal object identifier assigned to the 782 client connection. If not supported by the server, then '0' must be 783 returned. 785 This is optional data sent as an argument with the AUTH 786 messages. The content depends on the authentication mechanism being 787 used. 789 6.1.2. Remarks 791 The server will send the syntax 2 form when the authentication process 792 is complete or a numeric error reply. 794 6.2. CLONE (new IRCX message) 796 Informs the hosts and owners in a CLONEABLE channel that a new CLONE 797 channel was created. 799 Syntax: CLONE 801 6.2.1. Parameters 803 The name of the created CLONE channel. 805 The object identifier for this new CLONE channel. The value is 806 implementation- dependent and must equal 0 if not supported. 808 6.2.2. Remarks 810 The CLONE message can be sent at anytime to the hosts/owners of a 811 CLONEABLE channel to inform them that a new CLONE channel was created. 812 This message is intended to be used by a custom application to auto- 813 matically join the new CLONE channel. A non-IRCX client will not get 814 this message. 816 6.2.3. Example: 818 Server: CLONE #MyChat1 034F8FF32 820 6.3. CREATE (new IRCX message) 822 Informs the client that a new channel was created. Response to the 823 CREATE command. 825 Syntax: CREATE 827 6.3.1. Parameters 829 The name of the created channel. 831 The object identifier for this new channel. The value is imple- 832 mentation- dependent and must equal 0 if not supported. 834 6.3.2. Remarks 836 The CREATE message is sent in response to a CREATE command sent by the 837 client application if the channel specified did not previously exist 838 and was created by the server. 840 6.3.3. Example: 842 Server: CREATE #MyChat1 034F8FF32 844 6.4. DATA / REQUEST / REPLY (new IRCX messages) 846 The DATA message (could be REQUEST or REPLY also) is forwarded from 847 another user or sent by the server. The payload or message should be 848 interpreted according to the tag. If the tag is unknown, the message 849 may be discarded. 851 Syntax 1: :DATA : 852 :REQUEST : 853 :REPLY : 855 If the DATA, REQUEST or REPLY message is sent to a number of members 856 within a channel, the receiving user will see the channel name and 857 their own nick in the message as follows: 859 Syntax 2: :DATA : 861 6.4.1. Parameters 863 May be a user or a server. 865 Channel and/or nick list as defined above. 867 Identifying tag. 869 Payload. 871 6.4.2. Remarks 873 The tag indicates what to do with the message. Tag types may be spec- 874 ified by administrators, client developers, server developers etc. 876 A tag beginning with SYS can only be from a sysop, admin or the 877 server. A tag beginning with ADM can only be from an admin or the 878 server. 880 DATA message functionality is different from a simple client-to-client 881 message in several respects. First, we encourage groups to define 882 their own tags and data formats for special purposes, for example to 883 indicate details for a user's avatar in graphical chats, or to indi- 884 cate that an ad banner or image should be downloaded. Second, the 885 DATA message is more appropriate for content that may go to several 886 users, for example all users in a channel. Third, the DATA message 887 may come from the server. Fourth, the SYS and ADM prefixes are speci- 888 fied so that important tags may be reserved for sysops, admins and the 889 server itself, with the server responsible for verifying the sender 890 before forwarding the DATA message. 892 6.5. EVENT (new optional IRCX message) 894 Notifies the client of an event. These events are intended for sysops 895 and admins, and are sent in addition to IRC events. Specific event 896 messages and message types are implementation-dependent. 898 Syntax: EVENT 900 6.5.1. Parameters 902 The number of elapsed seconds from midnight (00:00:00) 903 January 1, 1970 (coordinated universal time) until the time that the 904 event occurred on the server. 906 Objects can be Channel, Member, User, Connection, Socket or 907 Server. 909 Event type varies depending on the object. For example, 910 events for channels can be Create, Destroy, Topic change, Mode change, 911 Collision. 913 Vary depending on event type. 915 6.5.2. Example 917 This example is the event generated when a user logs onto server chat1 918 with the nickname john, showing the user's info including IP address 919 and port. 921 EVENT chat1 946080000 USER LOGON john!jsmith@uw.edu 192.29.93.93:1111 923 6.6. KNOCK (new IRCX message) 925 Informs the owners and hosts of a channel that a user has tried to 926 enter the channel and could not (could be because of a full channel, 927 keyword set, user ban, or other reasons). This message is only sent 928 to the owners and hosts of the channel in IRCX mode. 930 Syntax: KNOCK 932 6.6.1. Parameters 934 User field is of the format nick!userid@host. 936 Name of the channel that the user tried to enter. 938 Reason that the user received when they tried to join the 939 channel. 941 6.6.2. Remarks 943 A KNOCK message will not be sent to a non-IRCX client. 945 6.7. REDIRECT (new IRCX message) 947 Informs the client that they need to connect to another server. 949 Syntax: REDIRECT : 951 6.7.1. Parameters 953 The server list is a comma seperated list of host:port 954 pairs. The server list can be specified either as a fully-qualified 955 domain name or by the IP address in quad-dotted notation. 957 The redirect reason is an implementation-dependent string 958 which can optionally be displayed to the client. 960 6.7.2. Remarks 962 The REDIRECT message can be sent to the client at any time to request 963 that the client disconnect and reconnect to another server specified 964 in the list. The REDIRECT message is generally sent when a server is 965 to be shutdown. 967 A REDIRECT message will not be sent to a non-IRCX client. 969 6.7.3. Example 971 Server: REDIRECT chat.corp.net:6667,134.9.3.3:6667 :Server full. 973 6.8. WHISPER (new IRCX message) 975 A whisper from another channel member. 977 Syntax: WHISPER : 979 6.8.1. Parameters 981 The nick-name of the person that sent the whisper. 983 The channel that the message is sent to. 985 The list of nicknames of channel members that will receive 986 the whisper. 988 The content of the whisper. 990 6.8.2. Remarks 992 The server may transform a WHISPER into a PRIVMSG for clients that do 993 not support IRCX. 995 6.8.3. Example 997 Server: Joe WHISPER #test :Test whisper. 999 7. User Modes and Properties 1001 These are new user modes and properties that have been added. The 1002 MODE command as defined in RFC1459 is used to add or remove modes. 1004 7.1. OWNER (IRCX +q) 1006 The OWNER mode indicates that the user is an owner of a channel. Only 1007 a channel owner can give OWNER mode to another member of that channel, 1008 but any owner may remove OWNER mode from themself. 1010 Clients in IRCX mode see owner nicknames with a '.' prefix and con- 1011 tinue to see hosts with a '@' prefix (in results from NAMES, WHO, 1012 WHOIS and other commands which list nicknames). 1014 Note that HOST mode uses +o, which was "operator" mode in RFC1459. 1015 Syntax for these modes is the same as "operator" mode: 1017 MODE { + | - }q 1019 7.2. GAG (IRCX +z) 1021 The GAG mode is applied by a sysop or admin on a user and may not be 1022 removed except by a sysop or admin. The user may not be notified when 1023 this mode is applied because the mode can be a more effective tool for 1024 keeping order if the user doesn't know exactly when it is applied. 1026 The server will discard all messages from a user with GAG mode to any 1027 other user or to any channel. 1029 MODE { + | - }z 1031 8. Channel Modes and Properties 1033 New modes and properties have been added to channels. Some of these 1034 are optional and are marked as such. 1036 Channels support four mutually exclusive states of visibility: public, 1037 private, hidden, and secret. The visibility of a channel affects 1038 which modes and properties are available to a client. Each mode/prop- 1039 erty is followed by a table that consists of a matrix of the channel's 1040 visibility state and each type of client. R/W is for Read/Write 1041 access, WO for Write Only access, RO for Read Only access, "-" for no 1042 access (can't be queried), "*" for special access explained in the 1043 mode description, and N/A for does not apply. These access rights are 1044 listed for the different access levels. 1046 8.1. Modes 1048 Each channel object contains a number of binary mode settings that can 1049 be queried and optionally updated via the RFC1459 MODE command. 1051 8.1.1. PUBLIC (RFC1459 default) 1053 The channel is public and all information about the channel (except 1054 for text messages) can be queried by non-members. PUBLIC mode is 1055 mutually exclusive with the PRIVATE, HIDDEN and SECRET modes. 1057 Admin Sysop Owner Host Member User 1058 Public R/W RO R/W R/W RO RO 1059 Private N/A N/A N/A N/A N/A N/A 1060 Hidden N/A N/A N/A N/A N/A N/A 1061 Secret N/A N/A N/A N/A N/A N/A 1063 8.1.2. PRIVATE (RFC1459 +p) 1065 The channel is private and only the name, number of members and PICS 1066 property can be queried by non-members. PRIVATE mode is mutually 1067 exclusive with the PUBLIC, HIDDEN and SECRET modes. 1069 Admin Sysop Owner Host Member User 1070 Public N/A N/A N/A N/A N/A N/A 1071 Private R/W RO R/W R/W RO - 1072 Hidden N/A N/A N/A N/A N/A N/A 1073 Secret N/A N/A N/A N/A N/A N/A 1075 8.1.3. HIDDEN (IRCX +h) 1077 The channel is hidden and cannot be located by enumeration queries 1078 from non-members. HIDDEN mode is mutually exclusive with the PUBLIC, 1079 PRIVATE, and SECRET modes. The purpose of the new HIDDEN channel mode 1080 is to permit the existence of channels that cannot be found using the 1081 standard LIST command, but whose properties can be queried if the 1082 exact channel name is known. Thus a HIDDEN channel is the same as a 1083 PUBLIC channel except that it cannot be enumerated by using a LIST or 1084 LISTX command. 1086 Admin Sysop Owner Host Member User 1087 Public N/A N/A N/A N/A N/A N/A 1088 Private N/A N/A N/A N/A N/A N/A 1089 Hidden R/W RO R/W R/W RO RO 1090 Secret N/A N/A N/A N/A N/A N/A 1092 8.1.4. SECRET (RFC1459 +s) 1094 The channel is secret and cannot by located by any query from non-mem- 1095 bers. SECRET mode is mutually exclusive with the PUBLIC, PRIVATE, and 1096 HIDDEN modes. 1098 Admin Sysop Owner Host Member User 1099 Public N/A N/A N/A N/A N/A N/A 1100 Private N/A N/A N/A N/A N/A N/A 1101 Hidden N/A N/A N/A N/A N/A N/A 1102 Secret R/W RO R/W R/W RO - 1104 8.1.5. MODERATED (RFC1459 +m) 1106 Normally, new channel members may speak. In MODERATED mode however, 1107 new channel members may not speak by default. This is achieved by 1108 giving all new members the '-v' mode (no voice) for that channel. 1109 Usually -v mode has no effect, but in a MODERATED channel it does. 1111 Admin Sysop Owner Host Member User 1112 Public R/W RO R/W R/W RO RO 1113 Private R/W RO R/W R/W RO - 1114 Hidden R/W RO R/W R/W RO RO 1115 Secret R/W RO R/W R/W RO - 1117 8.1.6. NOEXTERN (RFC1459 +n) 1119 NOEXTERN mode blocks messages from non-members to the channel. An 1120 administrator can still send a message to the channel. 1122 Admin Sysop Owner Host Member User 1123 Public R/W RO R/W R/W RO RO 1124 Private R/W RO R/W R/W RO - 1125 Hidden R/W RO R/W R/W RO RO 1126 Secret R/W RO R/W R/W RO - 1128 8.1.7. TOPICOP (RFC1459 +t) 1130 TOPICOP mode permits only channel owners and hosts to change the chan- 1131 nel topic property. 1133 Admin Sysop Owner Host Member User 1134 Public R/W RO R/W R/W RO RO 1135 Private R/W RO R/W R/W RO - 1136 Hidden R/W RO R/W R/W RO RO 1137 Secret R/W RO R/W R/W RO - 1139 8.1.8. INVITE (RFC1459 +i) 1141 INVITE mode permits only invited users to enter the channel. Only 1142 owners and hosts can issue an invitation when this mode is on. 1144 Admin Sysop Owner Host Member User 1145 Public R/W RO R/W R/W RO RO 1146 Private R/W RO R/W R/W RO - 1147 Hidden R/W RO R/W R/W RO RO 1148 Secret R/W RO R/W R/W RO - 1150 8.1.9. KNOCK (IRCX +u) 1152 The KNOCK extended mode causes a KNOCK message to be sent to owners 1153 and hosts of the channel if user attempts to join a channel and the 1154 server denies entrance. 1156 Admin Sysop Owner Host Member User 1157 Public R/W RO R/W R/W RO RO 1158 Private R/W RO R/W R/W RO - 1159 Hidden R/W RO R/W R/W RO RO 1160 Secret R/W RO R/W R/W RO - 1162 8.1.10. NOFORMAT (IRCX +f) 1164 The NOFORMAT channel mode is an indication to the client application 1165 not to format text received from the channel. Normally clients will 1166 prefix text messages with "x said y" or "x whispers to y and x", if 1167 the NOFORMAT mode is set then just the raw text should be dis- 1168 played moving to the next line at the end of the message. The client 1169 should not echo text sent by the client. This is to permit custom 1170 applications to control the formatting to clients. Clients may want 1171 to inform users that messages can be spoofed with this mode. 1173 Admin Sysop Owner Host Member User 1174 Public R/W RO RO RO RO RO 1175 Private R/W RO RO RO RO - 1176 Hidden R/W RO RO RO RO RO 1177 Secret R/W RO RO RO RO - 1179 8.1.11. NOWHISPER (IRCX +w) 1181 The NOWHISPER channel mode will prevent all messages sent to specific 1182 nicknames within the context of that channel. 1184 Admin Sysop Owner Host Member User 1185 Public R/W RO R/W RO RO RO 1186 Private R/W RO R/W RO RO - 1187 Hidden R/W RO R/W RO RO RO 1188 Secret R/W RO R/W RO RO - 1190 8.1.12. AUDITORIUM (IRCX +x) 1192 The AUDITORIUM channel mode restricts visibility and messaging within 1193 a channel. Members will only see themselves and the hosts/owners in 1194 the channel. Any message sent by a member will only be received by 1195 the hosts and owners. Hosts and owners will see all members in the 1196 channel and messages from a host or owner are seen by all channel mem- 1197 bers. Ordinary members will not receive JOIN/PART messages from other 1198 members. This mode is designed for channels with so many members that 1199 they do not want to see each other. Note that auditorium mode may 1200 only be set at channel creation time using the CREATE command. 1202 Admin Sysop Owner Host Member User 1203 Public R/W R/W R/W RO RO RO 1204 Private R/W R/W R/W RO RO - 1205 Hidden R/W R/W R/W RO RO RO 1206 Secret R/W R/W R/W RO RO - 1208 8.1.13. REGISTERED (IRCX +r) 1210 The channel is registered by the administrator of the chat network. 1211 The registration procedure is not defined here and is implementation- 1212 dependent. Only the server or admin can set this mode. 1214 Admin Sysop Owner Host Member User 1215 Public R/W RO RO RO RO RO 1216 Private R/W RO RO RO RO - 1217 Hidden R/W RO RO RO RO RO 1218 Secret R/W RO RO RO RO - 1220 8.1.14. SERVICE (IRCX +z) 1222 A service is monitoring/controlling the channel. This is an indica- 1223 tion to the client that message traffic sent to the channel is being 1224 monitored by a Chat Service which does not appear as a member in the 1225 channel. The SERVICE flag can only be set by the Chat Server. 1227 Admin Sysop Owner Host Member User 1228 Public RO RO RO RO RO RO 1229 Private RO RO RO RO RO - 1230 Hidden RO RO RO RO RO RO 1231 Secret RO RO RO RO RO - 1233 8.1.15. AUTHONLY (IRCX +a) 1235 The AUTHONLY channel mode permits channel access only to users who 1236 have been authenticated by the server. Note that an authenticated 1237 user is any user that was successfully authenticated with the PASS 1238 command or the AUTH command. 1240 Admin Sysop Owner Host Member User 1241 Public R/W RO R/W RO RO RO 1242 Private R/W RO R/W RO RO - 1243 Hidden R/W RO R/W RO RO RO 1244 Secret R/W RO R/W RO RO - 1246 8.1.16. CLONEABLE (IRCX +d) 1248 The CLONEABLE channel mode defines a channel that creates new clone 1249 channels if the parent channel is full. A clone channel is created 1250 with the same name as the parent cloneable channel with a numeric suf- 1251 fix starting at 1, ranging to 99. It is not valid to set the CLONE- 1252 ABLE channel mode of a parent channel that ends with a numeric charac- 1253 ter. The clone channel inherits modes and properties from the parent 1254 channel when it is set up. When a clone channel is created, any chan- 1255 nel that has the same name is removed. This prevents channel take 1256 over of a clone channel. It is advised that only administrators be 1257 allowed to set cloneable mode on a channel. 1259 Admin Sysop Owner Host Member User 1260 Public R/W RO RO RO RO RO 1261 Private R/W RO RO RO RO - 1262 Hidden R/W RO RO RO RO RO 1263 Secret R/W RO RO RO RO - 1265 8.1.17. CLONE (IRCX +e) 1267 The CLONE channel mode defines a channel that was created by the 1268 server when a parent CLONEABLE channel becomes full. Users should 1269 usually join the parent channel, although a user may join a clone 1270 channel that is not full. An admin can set up a clone channel but 1271 only when the channel is being created. 1273 Admin Sysop Owner Host Member User 1274 Public * RO RO RO RO RO 1275 Private * RO RO RO RO - 1276 Hidden * RO RO RO RO RO 1277 Secret * RO RO RO RO - 1279 8.2. Properties 1281 Each channel object contains a number of properties that can be 1282 queried and optionally updated via the IRCX PROP command. Owners and 1283 hosts may update a property for their own channel. Admins and Sysops 1284 can use the PROP command on a channel only by becoming host/owner of 1285 that channel. Users and members can read properties only. 1287 8.2.1. OID (R/O) 1289 The OID channel property is the internal object identifier for the 1290 channel. As a shortcut, the OID can be optionally used in place of 1291 the full string name of a channel. If the OID is set to "0", then 1292 this feature is not supported on the server. 1294 Admin Sysop Owner Host Member User 1295 Public RO RO RO RO RO RO 1296 Private RO RO RO RO RO - 1297 Hidden RO RO RO RO RO RO 1298 Secret RO RO RO RO RO - 1300 8.2.2. NAME (R/O) 1302 The NAME channel property is the name of the channel (limited to 63 1303 characters, including 1 or 2 characters for channel prefix). Valid 1304 characters are as defined in RFC1459. 1306 Admin Sysop Owner Host Member User 1307 Public RO RO RO RO RO RO 1308 Private RO RO RO RO RO - 1309 Hidden RO RO RO RO RO RO 1310 Secret RO RO RO RO RO - 1312 8.2.3. CREATION (R/O) 1314 The CREATION channel property is the time that the channel was cre- 1315 ated, in number of seconds elapsed since midnight (00:00:00), January 1316 1, 1970, (coordinated universal time). 1318 Admin Sysop Owner Host Member User 1319 Public RO RO RO RO RO RO 1320 Private RO RO RO RO RO - 1321 Hidden RO RO RO RO RO RO 1322 Secret RO RO RO RO RO - 1324 8.2.4. LANGUAGE 1326 The LANGUAGE channel property is the perferred language type. The 1327 LANGUAGE property is a string limited to 31 characters. We recommend 1328 following the guidelines of RFC1766 to form well-understood language- 1329 defining strings. 1331 Admin Sysop Owner Host Member User 1332 Public R/W RO R/W R/W RO RO 1333 Private R/W RO R/W R/W RO - 1334 Hidden R/W RO R/W R/W RO RO 1335 Secret R/W RO R/W R/W RO - 1337 8.2.5. OWNERKEY 1339 The OWNERKEY channel property is the owner keyword that will provide 1340 owner access when entering the channel. The OWNERKEY property is 1341 limited to 31 characters. 1343 Admin Sysop Owner Host Member User 1344 Public WO - WO - - - 1345 Private WO - WO - - - 1346 Hidden WO - WO - - - 1347 Secret WO - WO - - - 1349 8.2.6. HOSTKEY 1351 The HOSTKEY channel property is the host keyword that will provide 1352 host (channel op) access when entering the channel. The HOSTKEY prop- 1353 erty is limited to 31 characters. 1355 Admin Sysop Owner Host Member User 1356 Public WO - WO - - - 1357 Private WO - WO - - - 1358 Hidden WO - WO - - - 1359 Secret WO - WO - - - 1361 8.2.7. MEMBERKEY 1363 The MEMBERKEY channel property is the keyword required to enter the 1364 channel. The MEMBERKEY property is limited to 31 characters. This is 1365 backwards-compatible with RFC1459 because users can still use the MODE 1366 command as an alternative way to set this property. 1368 Admin Sysop Owner Host Member User 1369 Public WO - WO - - - 1370 Private WO - WO - - - 1371 Hidden WO - WO - - - 1372 Secret WO - WO - - - 1374 8.2.8. PICS (Optional) 1376 The PICS channel property is the current PICS rating of the channel. 1377 Chat clients that are PICS enabled can use this property to determine 1378 if the channel is appropriate for the user. The PICS property is lim- 1379 ited to 255 characters. The format for this field is defined by PICS 1380 (see http://www.w3.org). 1382 Admin Sysop Owner Host Member User 1383 Public R/W RO RO RO RO RO 1384 Private R/W RO RO RO RO RO 1385 Hidden R/W RO RO RO RO RO 1386 Secret R/W RO RO RO RO - 1388 8.2.9. TOPIC 1390 The TOPIC channel property is the current topic of the channel. The 1391 TOPIC property is limited to 160 characters. 1393 Admin Sysop Owner Host Member User 1394 Public R/W RO R/W R/W RO RO 1395 Private R/W RO R/W R/W RO - 1396 Hidden R/W RO R/W R/W RO RO 1397 Secret R/W RO R/W R/W RO - 1399 8.2.10. SUBJECT 1401 The SUBJECT channel property is a string that can contain subject key- 1402 words. The SUBJECT property is limited to 31 characters. 1404 Admin Sysop Owner Host Member User 1405 Public R/W RO R/W R/W RO RO 1406 Private R/W RO R/W R/W RO - 1407 Hidden R/W RO R/W R/W RO RO 1408 Secret R/W RO R/W R/W RO - 1410 8.2.11. CLIENT (Optional) 1412 The CLIENT channel property contains client specified information. 1413 The format is not defined by the server. The CLIENT property is lim- 1414 ited to 255 characters. 1416 Admin Sysop Owner Host Member User 1417 Public R/W RO R/W RO RO RO 1418 Private R/W RO R/W RO RO - 1419 Hidden R/W RO R/W RO RO RO 1420 Secret R/W RO R/W RO RO - 1422 8.2.12. ONJOIN (Optional) 1424 The ONJOIN channel property contains a string to be sent (via PRIVMSG) 1425 to a user after the user has joined the channel. The channel name is 1426 displayed as the sender of the message. Only the user joining the 1427 channel will see this message. Multiple lines can be generated by 1428 embedding '\n' in the string. The ONJOIN property is limited to 255 1429 characters. 1431 Admin Sysop Owner Host Member User 1432 Public R/W RO R/W R/W - - 1433 Private R/W RO R/W R/W - - 1434 Hidden R/W RO R/W R/W - - 1435 Secret R/W RO R/W R/W - - 1437 8.2.13. ONPART (Optional) 1439 The ONPART channel property contains a string that is sent (via 1440 NOTICE) to a user after they have parted from the channel. The chan- 1441 nel name is displayed as the sender of the message. Only the user 1442 parting the channel will see this message. Multiple lines can be gen- 1443 erated by embedding '\n' in the string. The ONPART property is lim- 1444 ited to 255 characters. 1446 Admin Sysop Owner Host Member User 1447 Public R/W RO R/W R/W - - 1448 Private R/W RO R/W R/W - - 1449 Hidden R/W RO R/W R/W - - 1450 Secret R/W RO R/W R/W - - 1452 8.2.14. LAG (Optional) 1454 The LAG channel property contains a numeric value between 0 to 2 sec- 1455 onds. The server will add an artificial delay of that length between 1456 subsequent messages from the same member. All messages to the channel 1457 are affected. 1459 Admin Sysop Owner Host Member User 1460 Public R/W RO R/W RO RO RO 1461 Private R/W RO R/W RO RO - 1462 Hidden R/W RO R/W RO RO RO 1463 Secret R/W RO R/W RO RO - 1465 8.2.15. ACCOUNT (Optional) 1467 The ACCOUNT channel property contains an implementation-dependent 1468 string for attaching a security account. This controls access to the 1469 channel using the native OS security system. The ACCOUNT property is 1470 limited to 31 characters. 1472 Admin Sysop Owner Host Member User 1473 Public R/W RO RO - - - 1474 Private R/W RO RO - - - 1475 Hidden R/W RO RO - - - 1476 Secret R/W RO RO - - - 1478 8.2.16. CLIENTGUID (Optional) 1480 The CLIENTGUID channel property contains a GUID that defines the 1481 client protocol to be used within the channel. 1483 Admin Sysop Owner Host Member User 1484 Public R/W RO R/W RO RO RO 1485 Private R/W RO R/W RO RO - 1486 Hidden R/W RO R/W RO RO RO 1487 Secret R/W RO R/W RO RO - 1489 8.2.17. SERVICEPATH (Optional) 1491 The SERVICEPATH channel property contains the path of a server side 1492 extension that is used to control the channel operation. Details are 1493 implementation-dependent. 1495 Admin Sysop Owner Host Member User 1496 Public R/W RO RO RO - - 1497 Private R/W RO RO RO - - 1498 Hidden R/W RO RO RO - - 1499 Secret R/W RO RO RO - - 1501 9. IRCX Command Responses 1503 The new extended IRCX numeric replies follow the same convention as 1504 IRC replies, with a specific range for command responses and another 1505 range for error results. The IRCX command responses are in the range 1506 of 800 to 899 and 900 to 999 for the error results. The prefix field 1507 is optional if the server generating the error is the server that the 1508 client is connected to. 1510 9.1. Command Replies 1512 800 - IRCRPL_IRCX 1514 1516 The response to the IRCX and ISIRCX commands. The indicates 1517 if the client has IRCX mode enabled (0 for disabled, 1 for enabled). 1518 The is the version of the IRCX protocol starting at 0. The 1519 contains a list of authentication packages supported by 1520 the server. The package name of "ANON" is reserved to indicate that 1521 anonymous connections are permitted. The defines the maximum 1522 message size permitted, with the standard being 512. The 1523 contains a list of options supported by the server; these are imple- 1524 mentation-dependent. If no options are available, the '*' character 1525 is used. 1527 801 - IRCRPL_ACCESSADD 1528 : 1530 Response to a successful ACCESS ADD command. The is the name 1531 of the object to which the access restrictions apply (i.e. channel 1532 name or user name). The is the level of access being added 1533 (i.e. GRANT, DENY). The is the selection mask. If no mask is 1534 provided in the ACCESS command, then the default mask of *!*@*$* is 1535 used. The is the amount of time this access entry will 1536 last. The is the one who added the new ACCESS record. The 1537 is the reason supplied in the ACCESS ADD command. 1539 802 - IRCRPL_ACCESSDELETE 1541 1543 Response to a successful ACCESS DELETE command. See reply 801 for 1544 explanation of the fields. 1546 803 - IRCRPL_ACCESSSTART 1548 :Start of access entries 1550 Beginning of a list of access entries. is the object to 1551 which the access restrictions apply (i.e. channel name or user name). 1552 The next message will be an IRCRPL_ACCESSLIST or IRCRPL_ACCESSEND 1553 reply. 1555 804 - IRCRPL_ACCESSLIST 1557 : 1559 One entry in a list of access entries. See reply 801 for explanation 1560 of the fields. 1562 805 - IRCRPL_ACCESSEND 1564 :End of access entries 1566 End of a list of access entries. See reply 803 for explanation of the 1567 field. This reply will always follow an IRCRPL_ACCESSSTART or 1568 IRCRPL_ACCESSLIST reply. 1570 806 - IRCRPL_EVENTADD 1572 1574 The acknowledgment response to the EVENT ADD command. The 1575 contains the name of the event added. The is the selection 1576 mask. If no mask is provided in the EVENT command, then the default 1577 mask of *!*@*$* is used. 1579 807 - IRCRPL_EVENTDEL 1581 1583 The acknowledgment response to the EVENT DEL command. The 1584 contains the name of the deleted event. The is the selection 1585 mask. If no mask is provided in the EVENT command, then the default 1586 mask of *!*@*$* is used. 1588 808 - IRCRPL_EVENTSTART 1590 :Start of events 1592 Response to the EVENT LIST message that indicates the start of 1593 the event list. 1595 809 - IRCRPL_EVENTLIST 1597 1599 Response to the EVENT LIST message that displays a list of 1600 current events that the client is interested in. 1602 810 - IRCRPL_EVENTEND 1604 :End of events 1606 Response to the EVENT LIST message that indicates the end of 1607 the event list. 1609 811 - IRCRPL_LISTXSTART 1611 :Start of ListX 1613 First reply to a LISTX (extended list) command. Will always be fol- 1614 lowed by a reply of type 812, 816 or 817. 1616 812 - IRCRPL_LISTXLIST 1618 : 1620 Single list item in an extended list of channels. 1622 813 - IRCRPL_LISTXPICS 1623 : 1625 PICS rating string for the last channel listed (follows an 812 mes- 1626 sage). 1628 816 - IRCRPL_LISTXTRUNC 1630 :Truncation of ListX 1632 Last reply to a LISTX command, either because the user asked for a 1633 limited list of channels or because the server truncated the list to 1634 prevent output flooding. Always follows a reply of type 811, 812 or 1635 813. 1637 817 - IRCRPL_LISTXEND 1639 :End of ListX 1641 Last reply to a LISTX command, indicating that the list has ended. 1642 Always follows a reply of type 811, 812 or 813. 1644 818 - IRCRPL_PROPLIST 1646 : 1648 A value in a property list. 1650 819 - IRCRPL_PROPEND 1652 :End of properties 1654 Last message in a property list. 1656 9.2. IRCX Error Replies. 1658 900 - IRCERR_BADCOMMAND 1660 :Bad command 1662 Response to an incorrectly formatted command. 1664 901 - IRCERR_TOOMANYARGUMENTS 1666 :Too many arguments 1668 Response to too many arguments being provided for a command. 1670 902 - IRCERR_BADFUNCTION 1672 :Bad function 1674 Response to a command that supports functions, with invalid function 1675 sent by the user. For example, the EVENT command supports functions. 1677 903 - IRCERR_BADLEVEL 1679 :Bad level 1681 Response to an ACCESS command with a bad level specified (i.e. not 1682 GRANT, DENY...) 1684 904 - IRCERR_BADTAG 1686 :Bad message tag. 1688 The message tag format is incorrect. 1690 905 - IRCERR_BADPROPERTY 1692 :Bad property specified 1694 Response to a channel property command with a bad property specified. 1696 906 - IRCERR_BADVALUE 1698 :Bad value specified 1700 Response to an attempt to set an integer property to a string value 1701 (PROP command). 1703 907 - IRCERR_RESOURCE 1705 :Not enough resources 1707 Server does not have enough resources to perform command. 1709 908 - IRCERR_SECURITY 1711 :No permissions to perform command 1713 For security reasons, the command/function/operation is not permitted 1714 for this level of client. 1716 909 - IRCERR_ALREADYAUTHENTICATED 1718 :Already authenticated 1720 The client is already authenticated with the server. 1722 910 - IRCERR_AUTHENTICATIONFAILED 1724 :Authentication failed 1726 The authentication failed due to a bad userid/password or server/net- 1727 work failure. 1729 911 - IRCERR_AUTHENTICATIONSUSPENDED 1731 :Authentication suspended for this IP 1733 Authentication has been temporary disabled due to too many authentica- 1734 tion failures from this IP. 1736 912 - IRCERR_UNKNOWNPACKAGE 1738 :Unsupported authentication package 1740 The authentication package specified is not known to the server. 1741 ISIRCX command will return a list of supported authentication pack- 1742 ages. 1744 913 - IRCERR_NOACCESS 1746 :No access 1748 Response to a user trying to change the ACCESS list for an object the 1749 user does not have sufficient privileges to alter. 1751 914 - IRCERR_DUPACCESS 1753 :Duplicate access entry 1755 An access entry already exists for the specified user mask. 1757 915 - IRCERR_MISACCESS 1759 :Unknown access entry 1761 Response to ACCESS DELETE command when server does not recognize the 1762 entry to be removed. 1764 916 - IRCERR_TOOMANYACCESSES 1766 :Too many access entries 1768 Response to ACCESS ADD command when maximum number of access entries 1769 has been reached. 1771 918 - IRCERR_EVENTDUP 1773 :Duplicate event entry 1775 The user has asked for an event that is already being sent. 1777 919 - IRCERR_EVENTMIS 1779 :Unknown event entry 1781 Response to event remove command when user is not already receiving 1782 the event specified. 1784 920 - IRCERR_NOSUCHEVENT 1786 :No such event type 1788 Response to event add command when server does not recognize the event 1789 specified. 1791 921 - IRCERR_TOOMANYEVENTS 1793 :Too many events specifed 1795 Response to event add command when user may not add another event to 1796 monitor. 1798 923 - IRCERR_NOWHISPER 1800 :Does not permit whispers 1802 Response to whisper command when channel does not permit whispers. 1804 924 - IRCERR_NOSUCHOBJECT 1806 :No such object found 1808 Response to an attempt to define a property for an object which can't 1809 be found (PROP command). 1811 926 - IRCERR_CHANNELEXIST 1813 :Channel already exists. 1815 The channel name in the CREATE command already exist on the server and 1816 the +c mode was specified. 1818 927 - IRCERR_ALREADYONCHANNEL 1820 :Already in the channel. 1822 Response to join command when user is already in the channel. 1824 999 - IRCERR_UNKNOWNERROR 1826 :Unknown error code 1828 The internal error generated doesn't map to a valid IRCX error reply. 1829 The error code is implementation-dependent. 1831 10. Security Considerations 1833 Security issues are discussed in the authentication section. 1835 The IRCX and ISIRCX commands return a set of authentication mechanisms 1836 supported by the server. This method is open to a middle man attack 1837 whereby an attacker modifies the list of returned authentication meth- 1838 ods and only offers a cleartext password transaction. In order to 1839 avoid this type of attack, only authentication methods with a chal- 1840 lenge response mechanism should be used. 1842 Since all administration commands for RFC1459 and IRCX are sent in 1843 clear text, a stream layer encryption mechanism like SSL[5] or IPSEC 1844 is required to protect the integrity and confidentiality of the trans- 1845 actions. The mechanisms for establishing these connection are outside 1846 the scope of this document. 1848 11. References 1850 [1] "Internet Relay Chat Protocol", Network Working Group RFC 1459, J. 1851 Oikarinen, D. Reed, May 1993 1853 [2] The Unicode Consortium, "The Unicode Standard Version 2.0", Addi- 1854 son Wesley Developers Press, July 1996 1856 [3] "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", Network Work- 1857 ing Group RFC 2060, M. Crispin, December 1996 1859 [4] "Simple Authentication and Security Layer (SASL)", Work in 1860 Progress, draft-myers-auth-sasl-07.txt, J. Myers, December 1996 1862 [5] "The SSL Protocol Version 3.0", Work in Progress, draft-ietf-tls- 1863 ssl-version3-00.txt, Alan O. Freier, Philip Karlton, Paul C. Kocher, 1864 November 1996 1866 12. Authors' Addresses 1868 Kent Cedola 1869 Microsoft Corporation 1870 One Microsoft Way 1871 Redmond, WA 98052 1873 EMail: kentce@microsoft.com 1875 Lisa Dusseault 1876 Microsoft Corporation 1877 One Microsoft Way 1878 Redmond, WA 98052 1880 EMail: lisadu@microsoft.com 1882 Thomas Pfenning 1883 Microsoft Corporation 1884 One Microsoft Way 1885 Redmond, WA 98052 1887 EMail: thomaspf@microsoft.com