idnits 2.17.1 draft-pfenning-irc-extensions-00.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-26) 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 26 longer pages, the longest (page 4) being 85 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 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 159 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...' == (154 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 31 January 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 31, 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, a unified property mechanism, and 35 support for tagged data messages. Chat server implementations can 36 optionally support channel or server services with full control over 37 all messages and events. These services communicate with the core 38 server over an extended IRC connection. 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 Domain | A Chat Domain is comprised of one or more net- | 87 | | works linked together. | 88 | Chat Network | Chat Network is comprised of one or more | 89 | | servers linked together. | 90 | Server | A server is a single machine. | 91 | Channel | A channel (sometimes called a room or confer- | 92 | | ence) is conversation between one or more | 93 | | users. | 94 | Member | A member is a user that is part of a conversa- | 95 | | tion in a channel. | 96 | User | A user is a client that makes a connection to | 97 | | the server. | 98 | Objects | An object is a general term for channels, | 99 | | users, members (users in a channel), and | 100 | | servers. The type of object can be determined | 101 | | from the first character of the object's name. | 102 +---------------+--------------------------------------------------+ 104 4.1. User Access Levels 106 Each client falls into one of eight level that define the ability to 107 perform operations. Some levels are determined on the context of the 108 operation to be performed. 110 +------------------------------------------------------------------+ 111 | Table 3 - Definition of Client Levels | 112 +---------------------+--------------------------------------------+ 113 | Chat Administrator | A Chat Administrator has full access to | 114 | | all aspect of the server. | 115 | Chat Service | A Chat Service is defined for external | 116 | | application to provide extended services | 117 | | to the chat network. Also refered to as | 118 | | bots. | 119 | A Chat Manager | A Chat Manager is a senior sysop access | 120 | | level that is permitted a wider range of | 121 | | opertions than a Chat Sysop. | 122 | A Chat Sysop | A Chat Sysop is a user that is ability | 123 | | to oversee and control the chat network. | 124 | A Chat Owner | A Chat Owner is a owner of a channel | 125 | | that has the ability to manage channel | 126 | | hosts. | 127 | A Chat Host | A Chat Host is a member of a channel | 128 | | with the ability to manage a channel. | 129 | | Also refered to as a channel operator. | 130 | A Chat Member | An Chat Member is a member of a channel. | 131 | A Chat User | An Chat User is a client connected to | 132 | | the server. | 133 +---------------------+--------------------------------------------+ 135 4.2. Prefixes 137 Each object contains a unique prefix that identifies the type of 138 object. By tagging UNICODE objects with a special prefix a client can 139 easily decide whether to use standard ASCII or UNICODE when sending a 140 message to a user or channel. 142 +----------------------------------------------------------------------- 143 + 144 | Table 4 - Object identifiers 145 | 146 +---------+------------------------------------------------------------- 147 + 148 | # | The '#' prefix identifies a standard IRC2 global channel. 149 | 150 | & | The '&' prefix identifies a standard IRC2 local channel. 151 | 152 | + | The '+' prefix identifies an extended channel name which 153 | 154 | | consist of a modified UTF7 encoded Unicode string. 155 | 156 | A to } | The 'A' through '}' prefix identifies a standard IRC2 157 | 158 | | nick name. 159 | 160 | % | The '%' prefix identifies an extended IRCX nick name 161 | 162 | | which consist of a modified Unicode string. Just '%' 163 | 164 | | represents the local client connection. 165 | 166 | 0 | The '0' prefix identifies an internal object identifier 167 | 168 | | (OID). The OID consists of the '0' prefix and 8 hexadec- 169 | 170 | | imal characters. 171 | 172 | $ | The '$' prefix identifies a server on the network. Just 173 | 174 | | '$' represents the local server the client is connected 175 | 176 | | to. 177 | 178 +---------+------------------------------------------------------------- 179 + 181 5. Channels 183 Channels support four mutually exclusive states of visibility; public, 184 private, hidden and secret. The visibility of a channel effects which 185 modes and properties are available to a client. Each mode/property is 186 followed by a table that consists of a matrix of the channel's visi- 187 bility state and each type of client. R/W is for Read/Write access, 188 R/O for Read Only access, "-" for no access (can't be queried) and N/A 189 for does not apply. These access rights are listed for the different 190 adminstrative levels. 192 5.1. Modes 194 Each channel object contains a number of binary mode settings that can 195 be queried and optionally updated via the IRC2 MODE and/or the IRCX 196 MODEX command. The IRC2 mode, if available, is presented with the 197 + format after the name of the mode. 199 5.1.1. PUBLIC (IRC2 default) 201 The channel is public and all information about the channel (except 202 for text/data messages) can be queried by non-members. The PUBLIC 203 mode is mutually exclusive with the PRIVATE, HIDDEN and SECRET modes. 205 Admin Service Manager Sysop Owner Host Member User 206 Public R/W R/W R/W R/W R/W R/W RO RO 207 Private N/A N/A N/A N/A N/A N/A N/A N/A 208 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 209 Secret N/A N/A N/A N/A N/A N/A N/A N/A 211 5.1.2. PRIVATE (IRC2 +P) 213 The channel is private and only the name and number of members can be 214 queried by non-members. The PRIVATE mode is mutually exclusive with 215 the PUBLIC, HIDDEN and SECRET modes. 217 Admin Service Manager Sysop Owner Host Member User 218 Public N/A N/A N/A N/A N/A N/A N/A N/A 219 Private R/W R/W R/W R/W R/W R/W RO RO 220 Hidden N/A N/A N/A N/A N/A N/A N/O N/A 221 Secret N/A N/A N/A N/A N/A N/A N/A N/A 223 5.1.3. HIDDEN 225 The channel is secret and can not by located by any query. The SECRET 226 mode is mutually exclusive with the PUBLIC, PRIVATE, and HIDDEN modes. 228 Admin Service Manager Sysop Owner Host Member User 229 Public R/W R/W R/W R/W R/W R/W RO RO 230 Private N/A N/A N/A N/A N/A N/A N/A N/A 231 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 232 Secret N/A N/A N/A N/A N/A N/A N/A N/A 234 5.1.4. SECRET (IRC2 +S) 236 The channel is secret and can not by located by any query. The SECRET 237 mode is mutually exclusive with the PUBLIC, PRIVATE, and HIDDEN modes. 239 Admin Service Manager Sysop Owner Host Member User 240 Public R/W R/W R/W R/W R/W R/W RO RO 241 Private N/A N/A N/A N/A N/A N/A N/A N/A 242 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 243 Secret N/A N/A N/A N/A N/A N/A N/A N/A 245 5.1.5. MODERATED (IRC2 +M) The MODERATED mode changes the default 246 speaker setting for new members to off. 248 Admin Service Manager Sysop Owner Host Member User 249 Public R/W R/W R/W R/W R/W R/W RO RO 250 Private N/A N/A N/A N/A N/A N/A N/A N/A 251 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 252 Secret N/A N/A N/A N/A N/A N/A N/A N/A 254 5.1.6. NOEXTERN (IRC2 +N) 256 The NOEXTERN mode blocks messages from non-members to the channel. 258 Admin Service Manager Sysop Owner Host Member User 259 Public R/W R/W R/W R/W R/W R/W RO RO 260 Private N/A N/A N/A N/A N/A N/A N/A N/A 261 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 262 Secret N/A N/A N/A N/A N/A N/A N/A N/A 264 5.1.7. TOPICOP (IRC2 +T) 266 The TOPICOP mode only permits channel hosts the ability to change the 267 channel topic property. 269 Admin Service Manager Sysop Owner Host Member User 270 Public R/W R/W R/W R/W R/W R/W RO RO 271 Private N/A N/A N/A N/A N/A N/A N/A N/A 272 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 273 Secret N/A N/A N/A N/A N/A N/A N/A N/A 275 5.1.8. INVITE (IRC2 +I) 277 The INVITE mode only permits invited users to enter the channel. 279 Admin Service Manager Sysop Owner Host Member User 280 Public R/W R/W R/W R/W R/W R/W RO RO 281 Private N/A N/A N/A N/A N/A N/A N/N N/A 282 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 283 Secret N/A N/A N/A N/A N/A N/A N/A N/A 285 5.1.9. KNOCK 287 The KNOCK extended mode causes a KNOCK message to be sent to all chan- 288 nel hosts if an uninvited user attempts to join an invite only chan- 289 nel. Useful for clients that wish to use custom access control of a 290 channel and will automatically issue an invite to a select group of 291 users. 293 Admin Service Manager Sysop Owner Host Member User 294 Public R/W R/W R/W R/W R/W R/W RO RO 295 Private N/A N/A N/A N/A N/A N/A N/A N/A 296 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 297 Secret N/A N/A N/A N/A N/A N/A N/A N/A 299 5.1.10. NODATA The NODATA channel mode will disable DATA messages 300 from being sent to a channel. 302 Admin Service Manager Sysop Owner Host Member User 303 Public R/W R/W R/W R/W R/W R/W RO RO 304 Private N/A N/A N/A N/A N/A N/A N/A N/A 305 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 306 Secret N/A N/A N/A N/A N/A N/A N/A N/A 308 5.1.11. NOWHISPER 310 The NOWHISPER channel mode will disable WHISPER messages from being 311 sent to a channel. 313 Admin Service Manager Sysop Owner Host Member User 314 Public R/W R/W R/W R/W R/W R/W RO RO 315 Private N/A N/A N/A N/A N/A N/A N/A N/A 316 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 317 Secret N/A N/A N/A N/A N/A N/A N/A N/A 319 5.1.12. REGISTERED 321 The channel has been registered via a chat service. 323 Admin Service Manager Sysop Owner Host Member User 324 Public R/W R/W R/W R/W R/W R/W RO RO 325 Private N/A N/A N/A N/A N/A N/A N/A N/A 326 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 327 Secret N/A N/A N/A N/A N/A N/A N/A N/A 329 5.1.13. SERVICE 331 A service is monitoring/controlling the channel. 333 Admin Service Manager Sysop Owner Host Member User 334 Public R/W R/W R/W R/W R/W R/W RO RO 335 Private N/A N/A N/A N/A N/A N/A N/A N/A 336 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 337 Secret N/A N/A N/A N/A N/A N/A N/A N/A 339 5.2. Extended Flags 341 Each channel object contains a number of binary flags that are only 342 settable by the chat server and will not change during the life span 343 of the channel. 345 5.2.1. PERSISTENT 347 The channel has been defined by the chat administrator as a persistent 348 channel. 350 Admin Service Manager Sysop Owner Host Member User 351 Public R/W R/W R/W R/W R/W R/W RO RO 352 Private N/A N/A N/A N/A N/A N/A N/A N/A 353 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 354 Secret N/A N/A N/A N/A N/A N/A N/A N/A 356 5.3. Properties 358 Each channel object contains a number of properties that can be 359 queried and optionally updated via the IRCX PROP command. 361 5.3.1. OID (R/O) 363 The OID channel property is the internal object identifier for the 364 channel. The OID can be optionally used in place of the full string 365 name of a channel as a short cut. If the OID is "0", then this fea- 366 ture is not supported on the server. 368 Admin Service Manager Sysop Owner Host Member User 369 Public R/W R/W R/W R/W R/W R/W RO RO 370 Private N/A N/A N/A N/A N/A N/A N/A N/A 371 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 372 Secret N/A N/A N/A N/A N/A N/A N/A N/A 374 5.3.2. NAME (R/O) 376 The NAME channel property is the name of the channel. 378 Admin Service Manager Sysop Owner Host Member User 379 Public R/W R/W R/W R/W R/W R/W RO RO 380 Private N/A N/A N/A N/A N/A N/A N/A N/A 381 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 382 Secret N/A N/A N/A N/A N/A N/A N/A N/A 384 5.3.3. KEYWORD The KEYWORD channel property is the keyword required 385 to enter the channel. The KEYWORD property can only be queried by 386 members of the channel and sysops. The KEYWORD property can only be 387 updated by channel hosts and sysops. 389 Admin Service Manager Sysop Owner Host Member User 390 Public R/W R/W R/W R/W R/W R/W RO RO 391 Private N/A N/A N/A N/A N/A N/A N/A N/A 392 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 393 Secret N/A N/A N/A N/A N/A N/A N/A N/A 395 5.3.4. HOSTKEY 397 The HOSTKEY channel property is the host keyword that will provide 398 host (channel op) access when entering the channel. The HOSTKEY prop- 399 erty can only be queried by channel hosts and sysops. The HOSTKEY 400 property can only be updated by channel hosts and sysops. 402 Admin Service Manager Sysop Owner Host Member User 403 Public R/W R/W R/W R/W R/W R/W RO RO 404 Private N/A N/A N/A N/A N/A N/A N/A N/A 405 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 406 Secret N/A N/A N/A N/A N/A N/A N/A N/A 408 5.3.5. TOPIC 410 The TOPIC channel property is the current topic of the channel. The 411 TOPIC property can be queried by the channel members and sysops, and 412 users can query outside the channel if is public or hidden. The TOPIC 413 property can only be updated by hosts, sysops, and members if the TOP- 414 ICOP channel mode is NOT set. 416 Admin Service Manager Sysop Owner Host Member User 417 Public R/W R/W R/W R/W R/W R/W RO RO 418 Private N/A N/A N/A N/A N/A N/A N/A N/A 419 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 420 Secret N/A N/A N/A N/A N/A N/A N/A N/A 422 5.3.6. PICS 424 The PICS channel property is the current PICS rating of the channel. 425 The PICS property can be queried by the channel members and sysops, 426 and users can query outside the channel if is public, private or hid- 427 den. The PICS property can only be updated by owners and sysops. 429 Admin Service Manager Sysop Owner Host Member User 430 Public R/W R/W R/W R/W R/W R/W RO RO 431 Private N/A N/A N/A N/A N/A N/A N/A N/A 432 Hidden N/A N/A N/A N/A N/A N/A N/A N/A 433 Secret N/A N/A N/A N/A N/A N/A N/A N/A 435 6. IRCX Server Messages 437 This section summarizes all extended messages which can be send unso- 438 licited from the server. 440 6.1. EVENT (new IRCX message) 442 Notification to the client of an event. 444 Syntax 1: EVENT CHANNEL CREATE 446 Syntax 2: EVENT CHANNEL DELETE 448 Syntax 3: EVENT CHANNEL KILL : 450 Syntax 4: EVENT MEMBER JOIN 452 Syntax 5: EVENT MEMBER PART : 454 Syntax 6: EVENT MEMBER KICK : 456 Syntax 7: EVENT USER REGISTER 457 459 Syntax 8: EVENT USER QUIT : 461 Syntax 9: EVENT USER KILL : 463 6.1.1. Parameters 465 The number of seconds elapsed since midnight (00:00:00), 466 January 1, 1970, coordinated universal time when the event occured on 467 the server. 469 The user's nick, userid, host and server in 470 nick!user@host$server format that triggered the event. 472 {same as for REDIRECT} 474 The local server IP address and port number of the 475 . 477 The remote client IP address and port number of the 478 . 480 6.1.2. Remarks 482 The EVENT command is to use to define the events that the client is 483 interested in. 485 6.2. REDIRECT (new IRCX message) 487 Informs the client to connect to another server. 489 Syntax: REDIRECT : 491 6.2.1. Parameters 493 The server list is a comma seperated list of host:port 494 pairs. Thos can be specified either as a FQDN or by the IP address in 495 quuad dotted notation. 497 The redirect reason is an implementation dependent string 498 which can optionally be displayed at the client. If the string starts 499 with a '%' character is is handled as modified UTF7 according to sec- 500 tion 4. 502 6.2.2. Remarks 504 The REDIRECT message can be sent to the client at anytime to request 505 the client to disconnect and reconnect to another server specified in 506 the list. The REDIRECT message is generally sent when a server is to 507 be shutdown. 509 6.2.3. Example 511 Server: REDIRECT chat.corp.net:6667,134.9.3.3:6667 :Server full. 513 7. IRCX Client Messages 515 All messages sent from the client to an IRCX server can optionally be 516 tagged with a message prefix. This implies that the client has veri- 517 fied, that the server it is talking to supports the extended IRC pro- 518 tocol. A tag is a string enclosed in square brackets. Only the charac- 519 ters [a-z,A-Z,0-9] are valid in a tag. The string can contain a mini- 520 mum of 1 and a maxminum of 16 charcters. An empty string is not 521 allowed. 523 All replies from the server to a client message prefixed with a tag 524 will have the same tag prepended. This feature allows the matching of 525 replies to multiple outstandig messages and easy dispatch of messages 526 to multithreaded clients. The tag will not be sent to other clients. 527 Tagged data messages can be used for indicating a certain payload to 528 other clients. 530 Syntax [alphanumeric string] 532 Parameters 534 This argument is any valid client message according to 535 the IRC or IRCX specification. 537 7.1. AUTH Command (new IRCX command) 539 Authenticate the client using an SASL[4] authentication mechanism. The 540 details of the authentication mechanisms is specified in a profile 541 that should be registered with the IANA. 543 Syntax 1: AUTH : [] 545 Syntax 2 (from server to client only): AUTH OK 547 7.1.1. Parameters 549 The name of the SASL mechanism to use for authentication. The 550 specific SASL mechanisms supported are implementation dependent. 552 The sequence is a value of 'I' or 'S'. The 'I' value is speci- 553 fied for the initial AUTH message and 'S' for all subsequence AUTH 554 messages. 556 This is optional data send as an argument with the AUTH 557 messages. The content is depends on the autentication mechanism being 558 used. 560 The ident is the userid@domain of the authenticated client 561 account. It is returned on the final response from the server (Syn- 562 tax2) when authentication is successful. 564 The uid is the internal object identifier assigned to the 565 client connection. If not supported by the server then '0' must be 566 returned. 568 7.1.2. Results: 570 AUTH message 571 IRCERR_ALREADYAUTHENTICATED 572 IRCERR_ALREADYREGISTERED 573 IRCERR_AUTHENTICATIONFAILED 574 IRCERR_AUTHENTICATIONSUSPENDED 575 IRCERR_BADCOMMAND 576 IRCERR_BADPREFIX 577 IRCERR_NEEDMOREPARAMS 578 IRCERR_UNKNOWNPACKAGE 580 7.1.3. Remarks: 582 If the server is known to support IRCX with specific SASL mechanism(s) 583 then the first message must be the AUTH command (if authentication is 584 to be used). If the server state is unknown, send the message 585 "ISIRCX\r\nPING\r\n" and non IRCX servers will return the PONG reply 586 without the IRCX message (or an error message and then the PONG), IRCX 587 servers will return the IRCRPL_IRCX message (see IRCX command for more 588 info) and then the PONG reply. 590 The server will send the syntax 2 form when the authentication process 591 is complete or a numeric error reply. 593 7.1.4. Example: 595 Client: AUTH NTLM I: <-quoted blob data> 596 Server: AUTH NTLM S: <-quoted blob data> 597 Client: AUTH NTLM S: <-quoted blob data> 598 Server: AUTH NTLM * userid@domain 03FA4534C 600 7.2. EVENT (new IRCX command) 602 Add/Change/Delete event logging to the client connection. 604 Syntax 1: EVENT [ADD | DEL] [] 606 Syntax 2: EVENT LIST [] 608 7.2.1. Parameters 610 Type of event, CHANNEL, MEMBER and USER. 612 Option mask for apply a selection critical per event. 614 7.2.2. Results 615 IRCRPL_EVENTADD 616 IRCRPL_EVENTDELETE 617 IRCRPL_EVENTLIST 618 IRCRPL_EVENTEND 619 IRCERR_NEEDMOREPARAMS 620 IRCERR_BADFUNCTION 621 IRCERR_EVENTDUP 622 IRCERR_EVENTMIS 623 IRCERR_NOSUCHEVENT 624 IRCERR_TOOMANYEVENTS 626 7.2.3. Events 628 See the EVENT section for IRCX Server Messages for more detail of gen- 629 erated events. 631 7.2.4. Remarks 633 The EVENT command is a sysop only function to select which events the 634 client is interested in. 636 7.2.5. Examples 638 Add channel events 640 Client: EVENT ADD CHANNEL 641 Server: 801 CHANNEL *!*@*$* 643 Add list event with no active events returned 645 Client: EVENT LIST 646 Server: 803 CHANNEL *!*@*$* 647 804 * :End of events. 649 7.3. DATA (new IRCX command) 651 Send a data message to an user, channel or member(s) in a channel. If 652 a client does not understand a particular tag name, the message is 653 discarded. 655 Syntax 1: DATA : 657 Syntax 2: DATA : 658 7.3.1. Parameters 660 The name of channel or user. 662 The name of a channel. 664 Client defined tag following the same restrictions as the 665 string in message prefixes, that is 1-16 alphanumeric characters. 667 A list of one or more user nicks. 669 7.3.2. Results 671 DATA message 672 IRCERR_NEEDMOREPARAMS 673 IRCERR_NORECIPIENT 674 IRCERR_NOTEXTTOSEND 675 IRCERR_NOTONCHANNEL 676 IRCERR_CANNOTSENDTOCHANNEL 677 IRCERR_TOOMANYTARGETS 678 IRCERR_NOSUCHNICK 679 IRCERR_NOSUCHCHANNEL 680 IRCERR_NODATA 682 7.3.3. Remarks 684 The DATA message is designed to send a tagged data message that can be 685 used by clients to interact with other. The server does not validate 686 the tag or message information and totally dependent on the client to 687 support. A recommendation of tag is included in the appendixes. 689 The DATA message can be disabled to a channel, member or user by set- 690 ting the MODEX +NODATA flag. 692 7.3.4. Examples 694 A client send out a data message with the URL tag. The server reacts 695 by sending the message to all users in the channel. 697 Client: DATA #MyChannel URL :\www.site.com 698 Server: DATA #MyChannel URL :\www.site.com 700 This example shows a tyocail scenario for a mutliplayer game or dun- 701 geon by specifiyng a an additional user list. 703 Client: DATA #MyChannel Nick1,Nick2 POS :34,23 704 Server: DATA #MyChannel Nick1 POS :34,23 (to Nick1) 705 DATA #MyChannel Nick2 POS :34,23 (to Nick2) 707 7.3.5. Data Tags 709 The following is a list of recommend tags to be in the DATA message 710 between clients. This list is subject to change based on more feed- 711 back. There should be a central registration point for new tags. 713 RTF: The data message contains RTF formatted text. 715 URL: A standard Internet URL pointer. The client can optionally load 716 the URL address provided. 718 VERSION: Request for the client type and version information. 720 7.4. IRCX (new IRCX command) 722 Enables IRCX mode and displays IRCX status. 724 Syntax: IRCX 726 7.4.1. Parameters 728 None. 730 7.4.2. Results 732 IRCRPL_IRCX 734 7.4.3. Remarks 736 Before a client is registered with a non-IRCX server, sending the 737 ISIRCX command will result in no response from the server. Recommend 738 sending the ISIRCX command followed by the PING command, and if a PONG 739 is just returned then the server doesn't support IRCX. 741 7.4.4. Example 743 Client: IRCX 744 Server: : 800 1 0 NTLM,DPA,ANON * 745 ://http:chat.mysite.net 747 7.5. ISIRCX (new IRCX command) 749 Queries if the server supports the Extended IRC2 protocol (RCX). 751 Syntax: ISIRCX 752 7.5.1. Results 754 IRCRPL_IRCX 756 7.5.2. Remarks 758 Before a client is registered with a non-IRCX server, sending the 759 ISIRCX command will result in no response from the server. Recommend 760 sending the ISIRCX command followed by the PING command, and if a PONG 761 is just returned then the server doesn't support IRCX. 763 7.5.3. Example 765 Client: ISIRCX 766 Server: : 800 1 0 NTLM,DPA,ANON * 767 ://http:chat.mysite.net 769 7.6. LIST (extension to IRC2 command) 771 List channels with extended filters. 773 Syntax 1: LIST [channel-list] 775 Syntax 2: LIST [query-list] [query-list ...] 777 7.6.1. Parameters 779 One or more 781 This parameter allows the specification of certain fil- 782 ters for the search operation. 784 +------------------------------------------------------------------+ 785 | Table 5 - Search filters for LIST command | 786 +---------+--------------------------------------------------------+ 787 | <# | Select channels with less than # members | 788 | ># | Select channels with more than # members | 789 | C<# | Select channels created less than # minutes ago | 790 | C># | Select channels created greater than # minutes ago | 791 | T<# | Select channels with a topic changed less than # | 792 | | minutes ago | 793 | T># | Select channels with a topic changed greater than # | 794 | | minutes ago | 795 +---------+--------------------------------------------------------+ 797 7.6.2. Results 799 Same as defined in RFC 1459. 801 7.6.3. Remarks 803 The LIST extension was first implemented for the Undernet version of 804 the standard IRC2 server. 806 7.7. MODE (extension to IRC2 command) 808 Enumerates, adds or changes modes of a channel or user. 810 Syntax 1: MODE 812 Syntax 2: MODE {+ | - } { o } 814 7.7.1. Parameters 816 The nick name of a user. 818 7.7.2. Results 820 MODE message 821 IRCERR_NOPRIVILEGES 823 7.7.3. Remarks 825 Client that have authenticated as a sysop can enable or disable their 826 sysop access via the +/- o mode parameter. 828 7.7.4. Example 830 Client: MODE MyNick -o 831 Server: MODE MyNick -o 833 7.8. MODEX (new IRCX command) 835 Enumerates, adds or changes extended modes of a channel or user. 837 Syntax 1: MODEX 839 Syntax 2: MODEX {+ | -} [...] 840 7.8.1. Parameters 842 The name of a user, channel, member or server. 844 An extended mode (see MODEX under the specific object type). 846 7.8.2. Results 848 MODEX message 849 IRCRPL_MODELIST 850 IRCRPL_MODELIST2 851 IRCRPL_MODEEND 852 IRCRPL_BADMODE 853 IRCERR_NOPRIVILEGES 854 IRCERR_CHANOPRIVSNEEDED 855 IRCERR_CHANOWNPRIVSNEEDED 857 7.8.3. Remarks 859 The MODEX command is a replacement to the standard IRC2 MODE command, 860 but unlike the single character letter used by MODE, MODEX supports 861 named mode settings. The MODEX command only effects binary (on or 862 off) modes of an object. 864 To issue a MODEX command on a channel member, the field con- 865 sists of the channel name, followed by a comma and then the nick of 866 the member. For example, "MODEX #MyChannel,Nick" to list the modes of 867 the user Nick member information in the channel #MyChannel. 869 The IRCRPL_MODELIST (805) message contains the channel modes settable 870 by client connections, the IRCRPL_MODELIST2 (806) message contains the 871 channel flags that are only settable by the server or a chat service. 873 If an error occurs, no modes are updated. 875 7.8.4. Examples 877 Client: MODEX #MyChannel 878 Server: 805 #MyChannel PUBLIC TOPICOP NOEXTERN 879 806 #MyChannel PERSISTENT 880 807 #MyChannel :End of modes 882 Longer transaction with query and setting of particular modes. 884 Client: MODEX #MyChannel 885 Server: 805 #MyChannel PUBLIC TOPICOP NOEXTERN 886 807 #MyChannel :End of modes 888 Client: MODEX #MyChannel +PRIVATE -TOPICOP +NODATA +NOWHISPER 889 Server: MODEX #MyChannel +PRIVATE +NOEXTERN +NODATA +NOWHISPER 891 Client: MODEX #MyChannel 892 Server: 805 #MyChannel PRIVATE NOEXTERN NODATA NOWHISPER 893 807 #MyChannel :End of modes 895 7.9. NOTICE (extension to IRC2 command) 897 Send a notice to a channel or user. 899 Syntax 1: NOTICE : 901 Syntax 2: NOTICE : 903 7.9.1. Results 905 Same as defined in RFC 1459. 907 7.10. 908 PRIVMSG (extension to IRC2 command) 910 Send a message to a channel or user. 912 Syntax 1: PRIVMSG : 914 Sybtax 2: PRIVMSG : 916 7.10.1. Results 918 Same as defined in RFC 1459. 920 7.11. PROP (new IRCX command) 922 Add/Changes/Deletes a channel data property. 924 Syntax 1: PROP 926 Syntax 2: PROP * 927 Syntax 3: PROP [,] 929 Syntax 4: PROP : 931 7.11.1. Results 933 PROP message 934 IRCRPL_PROPLIST 935 IRCRPL_PROPEND 936 IRCRPL_PROPVALUE 937 IRCERR_BADPROPERTY 938 IRCERR_NOPRIVILEGES 939 IRCERR_CHANOPRIVSNEEDED 940 IRCERR_CHANOWNPRIVSNEEDED 942 7.11.2. Remarks 944 The PROP command provides a new method for manipulating string and 945 number properties of server, user, channel and member objects based of 946 a label name. Members of channels are defined by specifying the name 947 of the member's channel, a comma delimited, followed by the user's 948 nick. 950 7.11.3. Examples 952 Client: PROP #MyChannel 953 Server: 808 #MyChannel TOPIC HOSTKEY PICS 954 809 #MyChannel :End of properties 956 Client: PROP #MyChannel TOPIC 957 Server: 810 #MyChannel TOPIC :This is the topic of my channel 958 Client: PROP #MyChannel TOPIC :Change my channel topic to 959 something 960 Server: PROP #MyChannel TOPIC :Change my channel topic to 961 something 963 7.12. WHISPER (new IRCX command) 965 Whisper to member(s) in a channel. 967 Syntax: WHISPER : 969 7.12.1. Results 970 WHISPER message 971 IRCERR_NEEDMOREPARAMS 972 IRCERR_NORECIPIENT 973 IRCERR_NOTEXTTOSEND 974 IRCERR_NOTONCHANNEL 975 IRCERR_CANNOTSENDTOCHANNEL 976 IRCERR_TOOMANYTARGETS 977 IRCERR_NOSUCHNICK 978 IRCERR_NOSUCHCHANNEL 980 7.12.2. Remarks 982 The purpose of the WHISPER command is to whisper to one or more mem- 983 bers in a channel within the context of that channel. IRCX clients 984 must display the WHISPER message within the context (window) of the 985 channel specified. 987 8. IRCX Command Responses 989 The new extended IRCX numeric replies follow the same convention as 990 with IRC with a specific range for command responses and another range 991 for error results. The IRCX command responses are in the ranage of 992 800 to 899 and 900 to 999 for the error results. The prefix field is 993 optional if the host generating the error is the same as the host the 994 client is connected to. 996 8.1. Command Replies 998 800 - IRCRPL_IRCX 1000 : 1002 The response to the IRCX command. The indicates if the has 1003 IRCX mode enabled (0 for disabled, 1 for enabled). The is 1004 the version of the IRCX protocol starting at 0. The 1005 contains a list of authentication packages supported by the server. 1006 The package name of "ANON" is reserved to indicate anonymous connec- 1007 tions are permitted. The contains a list of options 1008 supported by the server; theses are implementation dependent. If no 1009 options are available, the '*' character should be used. The field contains an administrator defined URL. 1012 801 - IRCRPL_EVENTADD 1014 1016 The acknowledgment response to the EVENT ADD command. The 1017 contains the name of the event added. The is the selection 1018 mask. If no mask was provided in the EVENT command, then the default 1019 mask of *!*@*$* is used. 1021 802 - IRCRPL_EVENTDEL 1023 1025 The acknowledgment response to the EVENT DEL command. The 1026 contains the name of the event deleted. The is the selection 1027 mask. If no mask was provided in the EVENT command, then the default 1028 mask of *!*@*$* is used. 1030 803 - IRCRPL_EVENTLIST 1032 1034 Response to the EVENT LIST message to display a list of cur- 1035 rent events the client is interested in. 1037 804 - IRCRPL_EVENTEND 1039 :End of events 1041 Response to the EVENT LIST message to indicate the end of the 1042 event list. 1044 805 - IRCRPL_MODELIST 1046 1048 Response to the MODEX command of extended modes. 1050 806 - IRCRPL_MODELIST2 1052 1054 Response to the MODEX command of extended flags that are only set by 1055 the server. 1057 807 - IRCRPL_MODEEND 1059 :End of modes 1061 Last message in an extended mode list. 1063 808 - IRCRPL_PROPLIST 1064 1066 Response to the PROP command to list properties of an object. Multi- 1067 ple IRCRPL_PROPLIST messages can be generated per list. 1069 809 - IRCRPL_PROPEND 1071 :End of properties 1073 Last message in a property list. 1075 810 - IRCRPL_PROPVALUE 1077 : 1079 Response to a PROP query of a specific property. 1081 8.2. IRCX Error Replies. 1083 900 - IRCERR_BADCOMMAND 1085 :Bad command 1087 In response to an incorrectly formatted command. 1089 901 - IRCERR_BADPREFIX 1091 :Bad command prefix specified 1093 A message prefix is not supported for this command. 1095 902 - IRCERR_BADTAG 1097 :Bad property specified 1099 The message tag is incorrect. 1101 903 - IRCERR_ALREADYAUTHENTICATED 1103 :Already authentication 1105 The client has already authenticated with the server. 1107 904 - IRCERR_AUTHENTICATIONFAILED 1108 :Authentication failed 1110 The authentication failed due to a bad userid/password or server/net- 1111 work failure. 1113 905 - IRCERR_AUTHENTICATIONSUSPENDED 1115 :Authentication suspended for this IP 1117 Authentication has been temporary disabled due to too many authentica- 1118 tion failures from this IP. 1120 906 - IRCERR_UNKNOWNPACKAGE 1122 :Unsupported authentication package 1124 The authentication package specified is not known to the server. 1125 ISIRCX command will return a list of supported authentication pack- 1126 ages. 1128 907 - IRCERR_EVENTDUP 1130 :Duplicate event entry 1132 908 - IRCERR_EVENTMIS 1134 :Unknown event entry 1136 909 - IRCERR_NOSUCHEVENT 1138 :No such event type 1140 910 - IRCERR_TOOMANYEVENTS 1142 :Too many events specifed 1144 911 - IRCERR_UNKNOWNFUNCTION 1146 :Unknown function 1148 A unknown command function was specified. 1150 912 - IRCERR_UNKNOWNMODE 1152 :Unknown mode 1154 913 - IRCERR_UNKNOWNPROPERTY 1156 :Unknown property 1158 914 - IRCERR_NODATA 1160 :Does not permit data messages 1162 915 - IRCERR_NODATA 1164 :Does not permit data messages 1166 916 - IRCERR_NOREMOTE 1168 :Does not permit whispers 1170 917 - IRCERR_NOWHISPER 1172 :Does not permit whispers 1174 918 - IRCERR_RESTRICTED 1176 :Restricted by the administrator 1178 The command/function/operation was not executed due to an administra- 1179 tor restriction on this client connection. 1181 919 - IRCERR_SECURITY 1183 :Security failure 1185 The command/function/operation is not permited for this level of 1186 client due to security. 1188 999 - IRCERR_INTERNALERROR 1190 :Internal error code 1192 Internal error generated that doesn't map to a valid IRCX error reply. 1193 The error code is implementation dependent. 1195 9. Security Considerations 1197 Security issues are discussed in the authentication section. 1199 The IRCX command returns a set of authentication mechanisms supported 1200 by the server. This method is open to a middle man attack whereby an 1201 attacker modifies the list of returned authentication method and only 1202 offer a cleartext password transaction. In order to avoid this type of 1203 attack only authentication methods with a challenge response mechanism 1204 should be used whenever security is a concern. 1206 Since all administration commands for IRC and IRCX are send in cleart- 1207 ext a stream layer encryption mechanism like SSL[5] or IPSEC is 1208 required to protect the integrity and confidentiality of the transac- 1209 tions. The mechanisms for establishing these connection are outside 1210 the scope of this document. 1212 10. References 1214 [1] "Internet Relay Chat Protocol", Network Working Group RFC 1459, J. 1215 Oikarinen, D. Reed, May 1993 1217 [2] The Unicode Consortium, "The Unicode Standard Version 2.0", Addi- 1218 son Wesley Developers Press, July 1996 1220 [3] "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", Network Work- 1221 ing Group RFC 2060, M. Crispin, December 1996 1223 [4] "Simple Authentication and Security Layer (SASL)", Work in 1224 Progress, draft-myers-auth-sasl-07.txt, J. Myers, December 1996 1226 [5] "The SSL Protocol Version 3.0", Work in Progress, draft-ietf-tls- 1227 ssl-version3-00.txt, Alan O. Freier, Philip Karlton, Paul C. Kocher, 1228 November 1996 1230 11. Authors' Addresses 1232 Kent Cedola 1233 Microsoft Corporation 1234 One Microsoft Way 1235 Redmond, WA 98052 1237 EMail: kentce@microsoft.com 1239 Thomas Pfenning 1240 Microsoft Corporation 1241 One Microsoft Way 1242 Redmond, WA 98052 1244 EMail: thomaspf@microsoft.com