idnits 2.17.1 draft-pfenning-irc-extensions-01.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-03-28) 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 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 27 longer pages, the longest (page 22) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 187 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...), its areas...' == Line 12 has weird spacing: '...its working g...' == Line 16 has weird spacing: '...and may be u...' == Line 17 has weird spacing: '...afts as refer...' == Line 20 has weird spacing: '...To learn the...' == (182 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) ** Downref: Normative reference to an Experimental RFC: RFC 1459 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2060 (ref. '3') (Obsoleted by RFC 3501) == Outdated reference: A later version (-12) exists of draft-myers-auth-sasl-07 -- Possible downref: Normative reference to a draft: ref. '5' Summary: 15 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Kent Cedola 2 File: Microsoft Corporation 3 13 February 1997 Thomas Pfenning 4 Microsoft Corporation 6 Extensions to the Internet Relay Chat Protocol (IRCX) 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working docu- 11 ments of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute work- 13 ing documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference mate- 18 rial or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 The distribution of this memo is unlimited. It is filed as , and expires July 13, 1997. Please 27 send comments to the authors. 29 2. Abstract 31 This document describes extensions to the Internet Relay Chat protocol 32 defined in RFC 1459[1]. The added functionality includes optional user 33 authentication for multiple security providers, support for UNICODE[2] 34 characters, multilayer security, and a unified property mechanism. 35 Chat server implementations can optionally support channel or server 36 services with full control over all messages and events. These ser- 37 vices communicate with the core server over an extended IRC connec- 38 tion. 40 All changes to the IRC protocol are designed in a way that existing 41 clients will continue to work against servers implementing the exten- 42 sions. Support for the extended protocol can be queried by clients to 43 take advantage of the added functionality or to conform to the basic 44 protocol as defined in RFC 1459. 46 3. Modified UTF7 Encoding of UNICODE characters 48 Allowing UNICODE characters for all user visible strings introduces a 49 set of compatibility problems if the protocol must be backwards com- 50 patible. While UTF7 encoding[1] maintains readability for pure ASCII 51 strings, the BASE64 encoding of extended characters can contain char- 52 acters which have a special meaning to the parser. In order to provide 53 backwards compatibility with exisiting IRC clients and to allow new 54 client to use a subset of UNICODE features on existing IRC server we 55 introduce an additional postprocessing step on the result of an UTF7 56 translation. 58 The quoting character for the postprocessing step is ''. All mappings 59 are listed in the table below. 61 +------------------------------------+ 62 |Table 1 - Character Quoting in UTF7 | 63 +----------------+-------------------+ 64 | \b | for " " blank | 65 | \c | for "," | 66 | \\ | for "\" | 67 | \r | for CR | 68 | \n | for LF | 69 +----------------+-------------------+ 71 This mechanism is a first proposal and subject to change if we dicover 72 a more general solution to this problem. Since a similar problem was 73 discovered in the context of the IMAP protocol[3] it might be worth- 74 while to define a new safe encoding of UNICODE which translates to 75 alphanumeric characters only. It seems, that every special character 76 has a special meaning in one or the other protocol. 78 4. Terms and Definitions 80 Throughout the document we will use certain terms which are defined in 81 this section. 83 +------------------------------------------------------------------+ 84 | Table 2 - Definition of Terms | 85 +---------------+--------------------------------------------------+ 86 | Chat Network | Chat Network is comprised of one or more | 87 | | servers linked together. | 88 | Server | A server is a single machine. | 89 | Channel | A channel (sometimes called a room or confer- | 90 | | ence) is conversation between one or more | 91 | | users. | 92 | Member | A member is a user that is part of a conversa- | 93 | | tion in a channel. | 94 | User | A user is a client that makes a connection to | 95 | | the server. | 96 | Objects | An object is a general term for channels, | 97 | | users, members (users in a channel), and | 98 | | servers. The type of object can be determined | 99 | | from the first character of the object's name. | 100 +---------------+--------------------------------------------------+ 102 4.1. User Access Levels 104 Each client falls into one of eight level that define the ability to 105 perform operations. Some levels are determined on the context of the 106 operation to be performed. 108 +------------------------------------------------------------------+ 109 | Table 3 - Definition of Client Levels | 110 +---------------------+--------------------------------------------+ 111 | Chat Administrator | A Chat Administrator has full access to | 112 | | all aspect of the server. | 113 | Chat Service | A Chat Service is defined for external | 114 | | application to provide extended services | 115 | | to the chat network. Also refered to as | 116 | | bots. | 117 | A Chat Manager | A Chat Manager is a senior sysop access | 118 | | level that is permitted a wider range of | 119 | | opertions than a Chat Sysop. | 120 | A Chat Sysop | A Chat Sysop is a user that is ability | 121 | | to oversee and control the chat network. | 122 | A Chat Owner | A Chat Owner is a owner of a channel | 123 | | that has the ability to manage channel | 124 | | hosts. | 125 | A Chat Host | A Chat Host is a member of a channel | 126 | | with the ability to manage a channel. | 127 | | Also refered to as a channel operator. | 128 | A Chat Member | An Chat Member is a member of a channel. | 129 | A Chat User | An Chat User is a client connected to | 130 | | the server. | 131 +---------------------+--------------------------------------------+ 133 4.2. Prefixes 135 Each object contains a unique prefix that identifies the type of 136 object. By tagging UNICODE objects with a special prefix a client can 137 easily decide whether to use standard ASCII or UNICODE when sending a 138 message to a user or channel. 140 +-----------------------------------------------------------------+ 141 | Table 4 - Object identifiers | 142 +---------+-------------------------------------------------------+ 143 | # | The '#' prefix identifies an IRC2 global channel. | 144 | & | The '&' prefix identifies an IRC2 local channel. | 145 | + | The '+' prefix identifies an IRC2 modeless channel. | 146 | %# | The "%#" prefix identifies an extended global chan- | 147 | | nel name which consist of a modified UTF7 encoded | 148 | | Unicode string. | 149 | %& | The "%&" prefix identifies an extended local chan- | 150 | | nel name which consist of a modified UTF7 encoded | 151 | | Unicode string. | 152 | %+ | The "%+" prefix identifies an extended modeless | 153 | | channel name which consist of a modified UTF7 | 154 | | encoded Unicode string. | 155 | % | The '%' character identifies the last channel that | 156 | | this client specified and is a member of. The '%' | 157 | | character must be followed by a space or comma. It | 158 | | is used to optimize server processing of multiple | 159 | | messages from a client to a channel. | 160 | A to } | The 'A' through '}' prefix identifies a standard | 161 | | IRC2 nick name. | 162 | ' | The ''' prefix identifies an extended IRCX nick | 163 | | name which consist of a modified UTF7 encoded Uni- | 164 | | code string. The ''' character followed by a space | 165 | | or comma represents the local client connection. | 166 | 0 | The '0' prefix identifies an internal object iden- | 167 | | tifier (OID). The OID consists of the '0' prefix | 168 | | and 8 hexadecimal characters. The use of OID is | 169 | | implementation dependent. | 170 | $ | The '$' prefix identifies a server on the network. | 171 | | Just '$' represents the local server the client is | 172 | | connected to. | 173 +---------+-------------------------------------------------------+ 175 5. Channels 177 Channels support four mutually exclusive states of visibility; public, 178 private, hidden and secret. The visibility of a channel effects which 179 modes and properties are available to a client. Each mode/property is 180 followed by a table that consists of a matrix of the channel's visi- 181 bility state and each type of client. R/W is for Read/Write access, 182 WO for Write Only access, RO for Read Only access, "-" for no access 183 (can't be queried) and N/A for does not apply. These access rights are 184 listed for the different adminstrative levels. 186 5.1. Modes 188 Each channel object contains a number of binary mode settings that can 189 be queried and optionally updated via the IRC2 MODE and/or the IRCX 190 MODEX command. The IRC2 mode, if available, is presented with the 191 + format after the name of the mode. 193 5.1.1. PUBLIC (IRC2 default) 195 The channel is public and all information about the channel (except 196 for text messages) can be queried by non-members. The PUBLIC mode is 197 mutually exclusive with the PRIVATE, HIDDEN and SECRET modes. 199 Admin Service Manager Sysop Owner Host Member User 200 Public R/W R/W RO RO R/W R/W RO RO 201 Private N/A N/A N/A N/A N/A N/A N/A N/A 202 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 203 Secret N/A N/A N/A N/A N/A N/A N/A N/A 205 5.1.2. PRIVATE (IRC2 +P) 207 The channel is private and only the name and number of members can be 208 queried by non-members. The PRIVATE mode is mutually exclusive with 209 the PUBLIC, HIDDEN and SECRET modes. 211 Admin Service Manager Sysop Owner Host Member User 212 Public N/A N/A N/A N/A N/A N/A N/A N/A 213 Private R/W R/W RO RO R/W R/W RO RO 214 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 215 Secret N/A N/A N/A N/A N/A N/A N/A N/A 217 5.1.3. HIDDEN (IRCX +Q) 219 The channel is hidden and can not by located by enumeration queries. 220 The HIDDEN mode is mutually exclusive with the PUBLIC, PRIVATE, and 221 SECRET modes. The purpose of the new HIDDEN channel mode is to permit 222 channels that can not be found using the standard LIST command, but 223 properties can be queried if the exact name is known. Thus a HIDDEN 224 channel is the same as a PUBLIC channel except that it can not be enu- 225 merated by using the LIST command. 227 Admin Service Manager Sysop Owner Host Member User 228 Public N/A N/A N/A N/A N/A N/A N/A N/A 229 Private N/A N/A N/A N/A N/A N/A N/A N/A 230 Hidden R/W R/W RO RO R/W R/W RO RO 231 Secret N/A N/A N/A N/A N/A N/A N/A N/A 233 5.1.4. SECRET (IRC2 +S) 235 The channel is secret and can not by located by any query. The SECRET 236 mode is mutually exclusive with the PUBLIC, PRIVATE, and HIDDEN modes. 238 Admin Service Manager Sysop Owner Host Member User 239 Public N/A N/A N/A N/A N/A N/A N/A N/A 240 Private N/A N/A N/A N/A N/A N/A N/A N/A 241 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 242 Secret R/W R/W RO RO R/W R/W RO RO 244 5.1.5. MODERATED (IRC2 +M) The MODERATED mode changes the default 245 speaker setting for new members to off. 247 Admin Service Manager Sysop Owner Host Member User 248 Public R/W R/W RO RO R/W R/W RO RO 249 Private R/W R/W RO RO R/W R/W RO - 250 Hidden R/W R/W RO RO R/W R/W RO RO 251 Secret R/W R/W RO RO R/W R/W RO - 253 5.1.6. NOEXTERN (IRC2 +N) 255 The NOEXTERN mode blocks messages from non-members to the channel. 257 Admin Service Manager Sysop Owner Host Member User 258 Public R/W R/W RO RO R/W R/W RO RO 259 Private R/W R/W RO RO R/W R/W RO - 260 Hidden R/W R/W RO RO R/W R/W RO RO 261 Secret R/W R/W RO RO R/W R/W RO - 263 5.1.7. TOPICOP (IRC2 +T) 265 The TOPICOP mode only permits channel hosts the ability to change the 266 channel topic property. 268 Admin Service Manager Sysop Owner Host Member User 269 Public R/W R/W RO RO R/W R/W RO RO 270 Private R/W R/W RO RO R/W R/W RO - 271 Hidden R/W R/W RO RO R/W R/W RO RO 272 Secret R/W R/W RO RO R/W R/W RO - 274 5.1.8. INVITE (IRC2 +I) 276 The INVITE mode only permits invited users to enter the channel. 278 Admin Service Manager Sysop Owner Host Member User 279 Public R/W R/W RO RO R/W R/W RO RO 280 Private R/W R/W RO RO R/W R/W RO - 281 Hidden R/W R/W RO RO R/W R/W RO RO 282 Secret R/W R/W RO RO R/W R/W RO - 284 5.1.9. KNOCK (IRCX +J) 286 The KNOCK extended mode causes a KNOCK message to be sent to all chan- 287 nel hosts if an uninvited user attempts to join an invite only chan- 288 nel. Useful for clients that wish to use custom access control of a 289 channel and will automatically issue an invite to a select group of 290 users. 292 Admin Service Manager Sysop Owner Host Member User 293 Public R/W R/W RO RO R/W RO RO RO 294 Private R/W R/W RO RO R/W RO RO - 295 Hidden R/W R/W RO RO R/W RO RO RO 296 Secret R/W R/W RO RO R/W RO RO - 298 5.1.10. NODATA (IRCX +D) The NODATA channel mode will disable CTCP 299 messages from being sent to a channel. A CTCP message is defined as a 300 message that contains Control-A as the first character of the message 301 text. 303 Admin Service Manager Sysop Owner Host Member User 304 Public R/W R/W RO RO R/W RO RO RO 305 Private R/W R/W RO RO R/W RO RO - 306 Hidden R/W R/W RO RO R/W RO RO RO 307 Secret R/W R/W RO RO R/W RO RO - 309 5.1.11. NOFORMAT (IRCX +F) The NOFORMAT channel mode is an indication 310 to the client application not to format text received from the chan- 311 nel. Normally clients will prefix text messages with "x said y" or "x 312 whispers to y and x", if the NOFORMAT mode is set then just the raw 313 text should be displayed moving to the next line at the end of the 314 message. The client should not echo text sent by the client. This is 315 to permit custom applications to control the formatting to clients. 317 Admin Service Manager Sysop Owner Host Member User 318 Public R/W R/W RO RO R/W RO RO RO 319 Private R/W R/W RO RO R/W RO RO - 320 Hidden R/W R/W RO RO R/W RO RO RO 321 Secret R/W R/W RO RO R/W RO RO - 323 5.1.12. NOWHISPER (IRCX +W) 325 The NOWHISPER channel mode will disable WHISPER messages from being 326 sent to a channel. 328 Admin Service Manager Sysop Owner Host Member User 329 Public R/W R/W RO RO R/W RO RO RO 330 Private R/W R/W RO RO R/W RO RO - 331 Hidden R/W R/W RO RO R/W RO RO RO 332 Secret R/W R/W RO RO R/W RO RO - 334 5.1.13. BROADCAST (IRCX +E) 336 The BROADCAST channel mode is a special mode used for channels that 337 will send information one way from channel hosts to channel members. 338 Each member in a channel will only see themself in the channel. 339 Client applications should expect messages from host members that do 340 not appear in the channel member list via the WHO or NAMES commands. 342 Admin Service Manager Sysop Owner Host Member User 343 Public R/W R/W RO RO RO RO RO RO 344 Private R/W R/W RO RO RO RO RO - 345 Hidden R/W R/W RO RO RO RO RO RO 346 Secret R/W R/W RO RO RO RO RO - 348 5.1.14. EXTERNAL (IRCX +X) 350 The EXTERNAL channel mode restricts the visibility and messaging 351 within a channel. Members will only see themself and other hosts in 352 the channel. Any message sent by a member will only be received by 353 the host members. Hosts will see all members in the channel and mes- 354 sages from a host are seen by all members. 356 Admin Service Manager Sysop Owner Host Member User 357 Public R/W R/W RO RO R/W RO RO RO 358 Private R/W R/W RO RO R/W RO RO - 359 Hidden R/W R/W RO RO R/W RO RO RO 360 Secret R/W R/W RO RO R/W RO RO - 362 5.1.15. REGISTERED (IRCX +R) 364 The channel has been registered via a chat service. 366 Admin Service Manager Sysop Owner Host Member User 367 Public R/W R/W RO RO RO RO RO RO 368 Private R/W R/W RO RO RO RO RO - 369 Hidden R/W R/W RO RO RO RO RO RO 370 Secret R/W R/W RO RO RO RO RO - 372 5.1.16. SERVICE (IRCX +Z) 374 A service is monitoring/controlling the channel. This is an indica- 375 tion to the client that message traffic sent to the channel is being 376 monitored by a Chat Service which does not appear as a member in the 377 channel. The SERVICE flag is only set by the Chat Server. 379 Admin Service Manager Sysop Owner Host Member User 380 Public RO RO RO RO RO RO RO RO 381 Private RO RO RO RO RO RO RO - 382 Hidden RO RO RO RO RO RO RO RO 383 Secret RO RO RO RO RO RO RO - 385 5.1.17. AUTHONLY 387 The AUTHONLY channel mode restricts access to the channel to only 388 users that have been authenticated by the server. 390 Admin Service Manager Sysop Owner Host Member User 391 Public R/W R/W RO RO R/W RO RO RO 392 Private R/W R/W RO RO R/W RO RO - 393 Hidden R/W R/W RO RO R/W RO RO RO 394 Secret R/W R/W RO RO R/W RO RO - 396 5.1.18. CLONEABLE 398 The CLONEABLE channel mode defines a channel that will create new 399 clone channels if the parent channel is full. A clone channel is cre- 400 ated with the same name as the parent cloneable channel with a numeric 401 suffix starting at 1, ranging to 99. It is not valid to set the 402 CLONEABLE channel mode of a channel that ends with a numeric charac- 403 ter. When a clone channel is created, any channel that has the same 404 name will be removed. This is to prevent channel take over of a clone 405 channel. 407 Admin Service Manager Sysop Owner Host Member User 408 Public R/W R/W RO RO RO RO RO RO 409 Private R/W R/W RO RO RO RO RO - 410 Hidden R/W R/W RO RO RO RO RO RO 411 Secret R/W R/W RO RO RO RO RO - 413 5.1.19. CLONE 415 The CLONE channel mode defines a channel that was created by the 416 server when a parent CLONEABLE channel was full. 418 Admin Service Manager Sysop Owner Host Member User 419 Public R/W R/W RO RO (1) RO RO RO 420 Private R/W R/W RO RO (1) RO RO - 421 Hidden R/W R/W RO RO (1) RO RO RO 422 Secret R/W R/W RO RO (1) RO RO - 424 1. The CLONE channel mode can only be set on a channel that has the 425 same base name as a CLONEABLE channel the user is also an owner of. 426 This is to permit a channel owner to pre-create clone channels. 428 5.2. Properties 430 Each channel object contains a number of properties that can be 431 queried and optionally updated via the IRCX PROP command. 433 5.2.1. OID (R/O) 435 The OID channel property is the internal object identifier for the 436 channel. The OID can be optionally used in place of the full string 437 name of a channel as a short cut. If the OID is "0", then this fea- 438 ture is not supported on the server. 440 Admin Service Manager Sysop Owner Host Member User 441 Public RO RO RO RO RO RO RO RO 442 Private RO RO RO RO RO RO RO - 443 Hidden RO RO RO RO RO RO RO RO 444 Secret RO RO RO RO RO RO RO - 446 5.2.2. NAME (R/O) 448 The NAME channel property is the name of the channel. 450 Admin Service Manager Sysop Owner Host Member User 451 Public RO RO RO RO RO RO RO RO 452 Private RO RO RO RO RO RO RO - 453 Hidden RO RO RO RO RO RO RO RO 454 Secret RO RO RO RO RO RO RO - 456 5.2.3. KEYWORD The KEYWORD channel property is the keyword required 457 to enter the channel. 459 Admin Service Manager Sysop Owner Host Member User 460 Public R/W R/W - - R/W R/W RO RO 461 Private R/W R/W - - R/W R/W RO - 462 Hidden R/W R/W - - R/W R/W RO RO 463 Secret R/W R/W - - R/W R/W RO - 465 5.2.4. HOSTKEY 467 The HOSTKEY channel property is the host keyword that will provide 468 host (channel op) access when entering the channel. 470 Admin Service Manager Sysop Owner Host Member User 471 Public R/W R/W WO - R/W RO - - 472 Private R/W R/W WO - R/W RO - - 473 Hidden R/W R/W WO - R/W RO - - 474 Secret R/W R/W WO - R/W RO - - 476 5.2.5. OWNERKEY 478 The OWNERKEY channel property is the owner keyword that will provide 479 owner access when entering the channel. 481 Admin Service Manager Sysop Owner Host Member User 482 Public R/W R/W - - R/W - - - 483 Private R/W R/W - - R/W - - - 484 Hidden R/W R/W - - R/W - - - 485 Secret R/W R/W - - R/W - - - 487 5.2.6. TOPIC 489 The TOPIC channel property is the current topic of the channel. 491 Admin Service Manager Sysop Owner Host Member User 492 Public R/W R/W RO RO R/W R/W (1) RO 493 Private R/W R/W RO RO R/W R/W (1) - 494 Hidden R/W R/W RO RO R/W R/W (1) RO 495 Secret R/W R/W RO RO R/W R/W (1) - 497 1. The TOPIC property can only be set by members if the TOPICOP chan- 498 nel mode is not set. 500 5.2.7. PICS 502 The PICS channel property is the current PICS rating of the channel. 503 Chat clients that are PICS enabled can use this property to determine 504 if the channel is appropriate for the user. 505 .LP 506 Admin Service Manager Sysop Owner Host Member User 507 Public R/W R/W R/W RO RO RO RO RO 508 Private R/W R/W R/W RO RO RO RO RO 509 Hidden R/W R/W R/W RO RO RO RO RO 510 Secret R/W R/W R/W RO RO RO RO - 512 6. IRCX Server Messages 514 This section summarizes all extended messages which can be send unso- 515 licited from the server. 517 6.1. CLONE (new IRCX message) 519 Informs the hosts in a CLONEABLE channel of the creation of a new 520 CLONE channel. 522 Syntax: CLONE 524 6.1.1. Parameters 526 The name of the created CLONE channel. 528 The object identifier for this new CLONE channel. The value is 529 implementation dependent and must be 0 if not supported. 531 6.1.2. Remarks 533 The CLONE message can be sent at anytime to the hosts of a CLONEABLE 534 channel of the creation of a CLONE channel. Normally used by custom 535 application to automatically join the new CLONE channel. 537 6.1.3. Example 539 Server: CLONE #MyChat1 034F8FF32 541 6.2. EVENT (new IRCX message) 543 Notification to the client of an event. 545 Syntax 1: EVENT CHANNEL CREATE 547 Syntax 2: EVENT CHANNEL DELETE 549 Syntax 3: EVENT CHANNEL KILL : 551 Syntax 4: EVENT MEMBER JOIN 552 Syntax 5: EVENT MEMBER PART : 554 Syntax 6: EVENT MEMBER KICK : 556 Syntax 7: EVENT USER REGISTER 557 559 Syntax 8: EVENT USER QUIT : 561 Syntax 9: EVENT USER KILL : 563 6.2.1. Parameters 565 The number of seconds elapsed since midnight (00:00:00), 566 January 1, 1970, coordinated universal time when the event occured on 567 the server. 569 The user's nick, userid, host and server in 570 nick!user@host$server format that triggered the event. 572 {same as for REDIRECT} 574 The local server IP address and port number of the 575 . 577 The remote client IP address and port number of the 578 . 580 6.2.2. Remarks 582 The EVENT command is to use to define the events that the client is 583 interested in. 585 6.3. REDIRECT (new IRCX message) 587 Informs the client to connect to another server. 589 Syntax: REDIRECT : 591 6.3.1. Parameters 593 The server list is a comma seperated list of host:port 594 pairs. That can be specified either as a FQDN or by the IP address in 595 quuad dotted notation. 597 The redirect reason is an implementation dependent string 598 which can optionally be displayed at the client. If the string starts 599 with a '%' character is is handled as modified UTF7 according to sec- 600 tion 4. 602 6.3.2. Remarks 604 The REDIRECT message can be sent to the client at anytime to request 605 the client to disconnect and reconnect to another server specified in 606 the list. The REDIRECT message is generally sent when a server is to 607 be shutdown. 609 6.3.3. Example 611 Server: REDIRECT chat.corp.net:6667,134.9.3.3:6667 :Server full. 613 7. IRCX Client Messages 615 All messages sent from the client to an IRCX server can optionally be 616 tagged with a message prefix. This implies that the client has veri- 617 fied, that the server it is talking to supports the extended IRC pro- 618 tocol. A tag is a string enclosed in square brackets. Only the charac- 619 ters [a-z,A-Z,0-9] are valid in a tag. The string can contain a mini- 620 mum of 1 and a maxminum of 16 charcters. An empty string is not 621 allowed. 623 All replies from the server to a client message prefixed with a tag 624 will have the same tag prepended. This feature allows the matching of 625 replies to multiple outstandig messages and easy dispatch of messages 626 to multithreaded clients. The tag will not be sent to other clients. 627 Tagged data messages can be used for indicating a certain payload to 628 other clients. 630 Syntax [alphanumeric string] 632 Parameters 634 This argument is any valid client message according to 635 the IRC or IRCX specification. 637 7.1. AUTH Command (new IRCX command) 639 Authenticate the client using an SASL[4] authentication mechanism. The 640 details of the authentication mechanisms is specified in a profile 641 that should be registered with the IANA. 643 Syntax 1: AUTH : [] 645 Syntax 2 (from server to client only): AUTH OK 646 7.1.1. Parameters 648 The name of the SASL mechanism to use for authentication. The 649 specific SASL mechanisms supported are implementation dependent. 651 The sequence is a value of 'I' or 'S'. The 'I' value is speci- 652 fied for the initial AUTH message and 'S' for all subsequence AUTH 653 messages. If the client specifies '*' for the sequence the server 654 will abort the authentication sequence and return IRCERR_AUTHENTICA- 655 TIONFAILED. 657 This is optional data send as an argument with the AUTH 658 messages. The content is depends on the autentication mechanism being 659 used. 661 The ident is the userid@domain of the authenticated client 662 account. It is returned on the final response from the server (Syn- 663 tax2) when authentication is successful. 665 The uid is the internal object identifier assigned to the 666 client connection. If not supported by the server then '0' must be 667 returned. 669 7.1.2. Results: 671 AUTH message 672 IRCERR_ALREADYAUTHENTICATED 673 IRCERR_ALREADYREGISTERED 674 IRCERR_AUTHENTICATIONFAILED 675 IRCERR_AUTHENTICATIONSUSPENDED 676 IRCERR_BADCOMMAND 677 IRCERR_BADPREFIX 678 IRCERR_NEEDMOREPARAMS 679 IRCERR_UNKNOWNPACKAGE 681 7.1.3. Remarks: 683 If the server is known to support IRCX with specific SASL mechanism(s) 684 then the first message must be the AUTH command (if authentication is 685 to be used). If the server state is unknown, send the message 686 "ISIRCX\r\nPING\r\n" and non IRCX servers will return the PONG reply 687 without the IRCX message (or an error message and then the PONG), IRCX 688 servers will return the IRCRPL_IRCX message (see IRCX command for more 689 info) and then the PONG reply. 691 The server will send the syntax 2 form when the authentication process 692 is complete or a numeric error reply. 694 7.1.4. Example: 696 Client: AUTH NTLM I: <-quoted blob data> 697 Server: AUTH NTLM S: <-quoted blob data> 698 Client: AUTH NTLM S: <-quoted blob data> 699 Server: AUTH NTLM OK userid@domain 03FA4534C 701 7.2. EVENT (new IRCX command) 703 Add/Change/Delete event logging to the client connection. 705 Syntax 1: EVENT [ADD | DEL] [] 707 Syntax 2: EVENT LIST [] 709 7.2.1. Parameters 711 Type of event, CHANNEL, MEMBER and USER. 713 Option mask for apply a selection critical per event. 715 7.2.2. Results 717 IRCRPL_EVENTADD 718 IRCRPL_EVENTDELETE 719 IRCRPL_EVENTLIST 720 IRCRPL_EVENTEND 721 IRCERR_NEEDMOREPARAMS 722 IRCERR_BADFUNCTION 723 IRCERR_EVENTDUP 724 IRCERR_EVENTMIS 725 IRCERR_NOSUCHEVENT 726 IRCERR_TOOMANYEVENTS 728 7.2.3. Events 730 See the EVENT section for IRCX Server Messages for more detail of gen- 731 erated events. 733 7.2.4. Remarks 735 The EVENT command is a sysop only function to select which events the 736 client is interested in. 738 7.2.5. Examples 740 Add channel events 741 Client: EVENT ADD CHANNEL 742 Server: 801 CHANNEL *!*@*$* 744 Add list event with no active events returned 746 Client: EVENT LIST 747 Server: 803 CHANNEL *!*@*$* 748 804 * :End of events. 750 7.3. IRCX (new IRCX command) 752 Enables IRCX mode and displays IRCX status. 754 Syntax: IRCX 756 7.3.1. Parameters 758 None. 760 7.3.2. Results 762 IRCRPL_IRCX 764 7.3.3. Remarks 766 Before a client is registered with a non-IRCX server, sending the 767 ISIRCX command will result in no response from the server. Recommend 768 sending the ISIRCX command followed by the PING command, and if a PONG 769 is just returned then the server doesn't support IRCX. 771 7.3.4. Example 773 Client: IRCX 774 Server: : 800 1 0 NTLM,DPA,ANON * 775 ://http:chat.mysite.net 777 7.4. ISIRCX (new IRCX command) 779 Queries if the server supports the Extended IRC2 protocol (RCX). 781 Syntax: ISIRCX 782 7.4.1. Results 784 IRCRPL_IRCX 786 7.4.2. Remarks 788 Before a client is registered with a non-IRCX server, sending the 789 ISIRCX command will result in no response from the server. Recommend 790 sending the ISIRCX command followed by the PING command, and if a PONG 791 is just returned then the server doesn't support IRCX. 793 7.4.3. Example 795 Client: ISIRCX 796 Server: : 800 1 0 NTLM,DPA,ANON * 797 ://http:chat.mysite.net 799 7.5. LIST (extension to IRC2 command) 801 List channels with extended filters. 803 Syntax 1: LIST [channel-list] 805 Syntax 2: LIST [query-list] [query-list ...] 807 7.5.1. Parameters 809 One or more 811 This parameter allows the specification of certain fil- 812 ters for the search operation. 814 +------------------------------------------------------------------+ 815 | Table 5 - Search filters for LIST command | 816 +---------+--------------------------------------------------------+ 817 | <# | Select channels with less than # members | 818 | ># | Select channels with more than # members | 819 | C<# | Select channels created less than # minutes ago | 820 | C># | Select channels created greater than # minutes ago | 821 | T<# | Select channels with a topic changed less than # | 822 | | minutes ago | 823 | T># | Select channels with a topic changed greater than # | 824 | | minutes ago | 825 +---------+--------------------------------------------------------+ 827 7.5.2. Results 829 Same as defined in RFC 1459. 831 7.5.3. Remarks 833 The LIST extension was first implemented for the Undernet version of 834 the standard IRC2 server. 836 7.6. MODE (extension to IRC2 command) 838 Enumerates, adds or changes modes of a channel or user. 840 Syntax 1: MODE 842 Syntax 2: MODE {+ | - } { o } 844 7.6.1. Parameters 846 The nick name of a user. 848 7.6.2. Results 850 MODE message 851 IRCERR_NOPRIVILEGES 853 7.6.3. Remarks 855 Client that have authenticated as a sysop can enable or disable their 856 sysop access via the +/- o mode parameter. 858 7.6.4. Example 860 Client: MODE MyNick -o 861 Server: MODE MyNick -o 863 7.7. MODEX (new IRCX command) 865 Enumerates, adds or changes extended modes of a channel or user. 867 Syntax 1: MODEX 869 Syntax 2: MODEX {+ | -} [...] 870 7.7.1. Parameters 872 The name of a user, channel, member or server. 874 An extended mode (see MODEX under the specific object type). 876 7.7.2. Results 878 MODEX message 879 IRCRPL_MODELIST 880 IRCRPL_MODELIST2 881 IRCRPL_MODEEND 882 IRCRPL_BADMODE 883 IRCERR_NOPRIVILEGES 884 IRCERR_CHANOPRIVSNEEDED 885 IRCERR_CHANOWNPRIVSNEEDED 887 7.7.3. Remarks 889 The MODEX command is a replacement to the standard IRC2 MODE command, 890 but unlike the single character letter used by MODE, MODEX supports 891 named mode settings. The MODEX command only effects binary (on or 892 off) modes of an object. 894 To issue a MODEX command on a channel member, the field con- 895 sists of the channel name, followed by a comma and then the nick of 896 the member. For example, "MODEX #MyChannel,Nick" to list the modes of 897 the user Nick member information in the channel #MyChannel. 899 The IRCRPL_MODELIST (805) message contains the channel modes settable 900 by client connections, the IRCRPL_MODELIST2 (806) message contains the 901 channel flags that are only settable by the server or a chat service. 903 If an error occurs, no modes are updated. 905 7.7.4. Examples 907 Client: MODEX #MyChannel 908 Server: 805 #MyChannel PUBLIC TOPICOP NOEXTERN 909 806 #MyChannel PERSISTENT 910 807 #MyChannel :End of modes 912 Longer transaction with query and setting of particular modes. 914 Client: MODEX #MyChannel 915 Server: 805 #MyChannel PUBLIC TOPICOP NOEXTERN 916 807 #MyChannel :End of modes 918 Client: MODEX #MyChannel +PRIVATE -TOPICOP +NODATA +NOWHISPER 919 Server: MODEX #MyChannel +PRIVATE +NOEXTERN +NODATA +NOWHISPER 921 Client: MODEX #MyChannel 922 Server: 805 #MyChannel PRIVATE NOEXTERN NODATA NOWHISPER 923 807 #MyChannel :End of modes 925 7.8. NOTICE (extension to IRC2 command) 927 Send a notice to a channel or user. 929 Syntax 1: NOTICE : 931 Syntax 2: NOTICE : 933 7.8.1. Results 935 Same as defined in RFC 1459. 937 7.9. 938 PRIVMSG (extension to IRC2 command) 940 Send a message to a channel or user. 942 Syntax 1: PRIVMSG : 944 Sybtax 2: PRIVMSG : 946 7.9.1. Results 948 Same as defined in RFC 1459. 950 7.10. PROP (new IRCX command) 952 Add/Changes/Deletes a channel data property. 954 Syntax 1: PROP 956 Syntax 2: PROP * 957 Syntax 3: PROP [,] 959 Syntax 4: PROP : 961 7.10.1. Results 963 PROP message 964 IRCRPL_PROPLIST 965 IRCRPL_PROPEND 966 IRCRPL_PROPVALUE 967 IRCERR_BADPROPERTY 968 IRCERR_NOPRIVILEGES 969 IRCERR_CHANOPRIVSNEEDED 970 IRCERR_CHANOWNPRIVSNEEDED 972 7.10.2. Remarks 974 The PROP command provides a new method for manipulating string and 975 number properties of server, user, channel and member objects based of 976 a label name. Members of channels are defined by specifying the name 977 of the member's channel, a comma delimited, followed by the user's 978 nick. 980 7.10.3. Examples 982 Client: PROP #MyChannel 983 Server: 808 #MyChannel TOPIC HOSTKEY PICS 984 809 #MyChannel :End of properties 986 Client: PROP #MyChannel TOPIC 987 Server: 810 #MyChannel TOPIC :This is the topic of my channel 988 Client: PROP #MyChannel TOPIC :Change my channel topic to 989 something 990 Server: PROP #MyChannel TOPIC :Change my channel topic to 991 something 993 7.11. WHISPER (new IRCX command) 995 Whisper to member(s) in a channel. 997 Syntax: WHISPER : 999 7.11.1. Results 1000 WHISPER message 1001 IRCERR_NEEDMOREPARAMS 1002 IRCERR_NORECIPIENT 1003 IRCERR_NOTEXTTOSEND 1004 IRCERR_NOTONCHANNEL 1005 IRCERR_CANNOTSENDTOCHANNEL 1006 IRCERR_TOOMANYTARGETS 1007 IRCERR_NOSUCHNICK 1008 IRCERR_NOSUCHCHANNEL 1010 7.11.2. Remarks 1012 The purpose of the WHISPER command is to whisper to one or more mem- 1013 bers in a channel within the context of that channel. IRCX clients 1014 must display the WHISPER message within the context (window) of the 1015 channel specified. 1017 8. IRCX Command Responses 1019 The new extended IRCX numeric replies follow the same convention as 1020 with IRC with a specific range for command responses and another range 1021 for error results. The IRCX command responses are in the ranage of 1022 800 to 899 and 900 to 999 for the error results. The prefix field is 1023 optional if the host generating the error is the same as the host the 1024 client is connected to. 1026 8.1. Command Replies 1028 800 - IRCRPL_IRCX 1030 : 1032 The response to the IRCX command. The indicates if the has 1033 IRCX mode enabled (0 for disabled, 1 for enabled). The is 1034 the version of the IRCX protocol starting at 0. The 1035 contains a list of authentication packages supported by the server. 1036 The package name of "ANON" is reserved to indicate anonymous connec- 1037 tions are permitted. The contains a list of options 1038 supported by the server; theses are implementation dependent. If no 1039 options are available, the '*' character should be used. The field contains an administrator defined URL. 1042 801 - IRCRPL_EVENTADD 1044 1046 The acknowledgment response to the EVENT ADD command. The 1047 contains the name of the event added. The is the selection 1048 mask. If no mask was provided in the EVENT command, then the default 1049 mask of *!*@*$* is used. 1051 802 - IRCRPL_EVENTDEL 1053 1055 The acknowledgment response to the EVENT DEL command. The 1056 contains the name of the event deleted. The is the selection 1057 mask. If no mask was provided in the EVENT command, then the default 1058 mask of *!*@*$* is used. 1060 803 - IRCRPL_EVENTLIST 1062 1064 Response to the EVENT LIST message to display a list of cur- 1065 rent events the client is interested in. 1067 804 - IRCRPL_EVENTEND 1069 :End of events 1071 Response to the EVENT LIST message to indicate the end of the 1072 event list. 1074 805 - IRCRPL_MODELIST 1076 1078 Response to the MODEX command of extended modes. 1080 806 - IRCRPL_MODELIST2 1082 1084 Response to the MODEX command of extended flags that are only set by 1085 the server. 1087 807 - IRCRPL_MODEEND 1089 :End of modes 1091 Last message in an extended mode list. 1093 808 - IRCRPL_PROPLIST 1094 1096 Response to the PROP command to list properties of an object. Multi- 1097 ple IRCRPL_PROPLIST messages can be generated per list. 1099 809 - IRCRPL_PROPEND 1101 :End of properties 1103 Last message in a property list. 1105 810 - IRCRPL_PROPVALUE 1107 : 1109 Response to a PROP query of a specific property. 1111 8.2. IRCX Error Replies. 1113 900 - IRCERR_BADCOMMAND 1115 :Bad command 1117 In response to an incorrectly formatted command. 1119 901 - IRCERR_BADPREFIX 1121 :Bad command prefix specified 1123 A message prefix is not supported for this command. 1125 902 - IRCERR_BADTAG 1127 :Bad property specified 1129 The message tag is incorrect. 1131 903 - IRCERR_ALREADYAUTHENTICATED 1133 :Already authentication 1135 The client has already authenticated with the server. 1137 904 - IRCERR_AUTHENTICATIONFAILED 1138 :Authentication failed 1140 The authentication failed due to a bad userid/password or server/net- 1141 work failure. 1143 905 - IRCERR_AUTHENTICATIONSUSPENDED 1145 :Authentication suspended for this IP 1147 Authentication has been temporary disabled due to too many authentica- 1148 tion failures from this IP. 1150 906 - IRCERR_UNKNOWNPACKAGE 1152 :Unsupported authentication package 1154 The authentication package specified is not known to the server. 1155 ISIRCX command will return a list of supported authentication pack- 1156 ages. 1158 907 - IRCERR_EVENTDUP 1160 :Duplicate event entry 1162 908 - IRCERR_EVENTMIS 1164 :Unknown event entry 1166 909 - IRCERR_NOSUCHEVENT 1168 :No such event type 1170 10 - IRCERR_TOOMANYEVENTS 1172 :Too many events specifed 1174 911 - IRCERR_UNKNOWNFUNCTION 1176 :Unknown function 1178 A unknown command function was specified. 1180 912 - IRCERR_UNKNOWNMODE 1182 :Unknown mode 1184 913 - IRCERR_UNKNOWNPROPERTY 1186 :Unknown property 1188 914 - IRCERR_NODATA 1190 :Does not permit data messages 1192 915 - IRCERR_NOWHISPER 1194 :Does not permit whisper messages 1196 916 - IRCERR_NOREMOTE 1198 :Does not remote clients to join this channel 1200 917 - IRCERR_RESTRICTED 1202 :Restricted by the administrator 1204 The command/function/operation was not executed due to an administra- 1205 tor restriction on this client connection. 1207 918 - IRCERR_SECURITY 1209 :Security failure 1211 The command/function/operation is not permited for this level of 1212 client due to security. 1214 999 - IRCERR_INTERNALERROR 1216 :Internal error code 1218 Internal error generated that doesn't map to a valid IRCX error reply. 1219 The error code is implementation dependent. 1221 9. Security Considerations 1223 Security issues are discussed in the authentication section. 1225 The IRCX command returns a set of authentication mechanisms supported 1226 by the server. This method is open to a middle man attack whereby an 1227 attacker modifies the list of returned authentication method and only 1228 offer a cleartext password transaction. In order to avoid this type of 1229 attack only authentication methods with a challenge response mechanism 1230 should be used whenever security is a concern. 1232 Since all administration commands for IRC and IRCX are send in cleart- 1233 ext a stream layer encryption mechanism like SSL[5] or IPSEC is 1234 required to protect the integrity and confidentiality of the transac- 1235 tions. The mechanisms for establishing these connection are outside 1236 the scope of this document. 1238 10. References 1240 [1] "Internet Relay Chat Protocol", Network Working Group RFC 1459, J. 1241 Oikarinen, D. Reed, May 1993 1243 [2] The Unicode Consortium, "The Unicode Standard Version 2.0", Addi- 1244 son Wesley Developers Press, July 1996 1246 [3] "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", Network Work- 1247 ing Group RFC 2060, M. Crispin, December 1996 1249 [4] "Simple Authentication and Security Layer (SASL)", Work in 1250 Progress, draft-myers-auth-sasl-07.txt, J. Myers, December 1996 1252 [5] "The SSL Protocol Version 3.0", Work in Progress, draft-ietf-tls- 1253 ssl-version3-00.txt, Alan O. Freier, Philip Karlton, Paul C. Kocher, 1254 November 1996 1256 11. Authors' Addresses 1258 Kent Cedola 1259 Microsoft Corporation 1260 One Microsoft Way 1261 Redmond, WA 98052 1263 EMail: kentce@microsoft.com 1265 Thomas Pfenning 1266 Microsoft Corporation 1267 One Microsoft Way 1268 Redmond, WA 98052 1270 EMail: thomaspf@microsoft.com