You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

RFC2813.txt 57KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178117911801181118211831184118511861187118811891190119111921193119411951196119711981199120012011202120312041205120612071208120912101211121212131214121512161217121812191220122112221223122412251226122712281229123012311232123312341235123612371238123912401241124212431244124512461247124812491250125112521253125412551256125712581259126012611262126312641265126612671268126912701271127212731274127512761277127812791280128112821283128412851286128712881289129012911292129312941295129612971298129913001301130213031304130513061307130813091310131113121313131413151316131713181319132013211322132313241325132613271328132913301331133213331334133513361337133813391340134113421343134413451346134713481349135013511352135313541355135613571358135913601361136213631364136513661367136813691370137113721373137413751376137713781379138013811382138313841385138613871388138913901391139213931394139513961397139813991400140114021403140414051406140714081409141014111412141314141415141614171418141914201421142214231424142514261427142814291430143114321433143414351436143714381439144014411442144314441445144614471448144914501451145214531454145514561457
  1. Network Working Group C. Kalt
  2. Request for Comments: 2813 April 2000
  3. Updates: 1459
  4. Category: Informational
  5. Internet Relay Chat: Server Protocol
  6. Status of this Memo
  7. This memo provides information for the Internet community. It does
  8. not specify an Internet standard of any kind. Distribution of this
  9. memo is unlimited.
  10. Copyright Notice
  11. Copyright (C) The Internet Society (2000). All Rights Reserved.
  12. Abstract
  13. While based on the client-server model, the IRC (Internet Relay Chat)
  14. protocol allows servers to connect to each other effectively forming
  15. a network.
  16. This document defines the protocol used by servers to talk to each
  17. other. It was originally a superset of the client protocol but has
  18. evolved differently.
  19. First formally documented in May 1993 as part of RFC 1459 [IRC], most
  20. of the changes brought since then can be found in this document as
  21. development was focused on making the protocol scale better. Better
  22. scalability has allowed existing world-wide networks to keep growing
  23. and reach sizes which defy the old specification.
  24. Kalt Informational [Page 1]
  25. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  26. Table of Contents
  27. 1. Introduction ............................................... 3
  28. 2. Global database ............................................ 3
  29. 2.1 Servers ................................................ 3
  30. 2.2 Clients ................................................ 4
  31. 2.2.1 Users ............................................. 4
  32. 2.2.2 Services .......................................... 4
  33. 2.3 Channels ............................................... 4
  34. 3. The IRC Server Specification ............................... 5
  35. 3.1 Overview ............................................... 5
  36. 3.2 Character codes ........................................ 5
  37. 3.3 Messages ............................................... 5
  38. 3.3.1 Message format in Augmented BNF ................... 6
  39. 3.4 Numeric replies ........................................ 7
  40. 4. Message Details ............................................ 7
  41. 4.1 Connection Registration ................................ 8
  42. 4.1.1 Password message .................................. 8
  43. 4.1.2 Server message .................................... 9
  44. 4.1.3 Nick .............................................. 10
  45. 4.1.4 Service message ................................... 11
  46. 4.1.5 Quit .............................................. 12
  47. 4.1.6 Server quit message ............................... 13
  48. 4.2 Channel operations ..................................... 14
  49. 4.2.1 Join message ...................................... 14
  50. 4.2.2 Njoin message ..................................... 15
  51. 4.2.3 Mode message ...................................... 16
  52. 5. Implementation details .................................... 16
  53. 5.1 Connection 'Liveness' .................................. 16
  54. 5.2 Accepting a client to server connection ................ 16
  55. 5.2.1 Users ............................................. 16
  56. 5.2.2 Services .......................................... 17
  57. 5.3 Establishing a server-server connection. ............... 17
  58. 5.3.1 Link options ...................................... 17
  59. 5.3.1.1 Compressed server to server links ............ 18
  60. 5.3.1.2 Anti abuse protections ....................... 18
  61. 5.3.2 State information exchange when connecting ........ 18
  62. 5.4 Terminating server-client connections .................. 19
  63. 5.5 Terminating server-server connections .................. 19
  64. 5.6 Tracking nickname changes .............................. 19
  65. 5.7 Tracking recently used nicknames ....................... 20
  66. 5.8 Flood control of clients ............................... 20
  67. 5.9 Non-blocking lookups ................................... 21
  68. 5.9.1 Hostname (DNS) lookups ............................ 21
  69. 5.9.2 Username (Ident) lookups .......................... 21
  70. 6. Current problems ........................................... 21
  71. 6.1 Scalability ............................................ 21
  72. 6.2 Labels ................................................. 22
  73. Kalt Informational [Page 2]
  74. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  75. 6.2.1 Nicknames ......................................... 22
  76. 6.2.2 Channels .......................................... 22
  77. 6.2.3 Servers ........................................... 22
  78. 6.3 Algorithms ............................................. 22
  79. 7. Security Considerations .................................... 23
  80. 7.1 Authentication ......................................... 23
  81. 7.2 Integrity .............................................. 23
  82. 8. Current support and availability ........................... 24
  83. 9. Acknowledgements ........................................... 24
  84. 10. References ................................................ 24
  85. 11. Author's Address .......................................... 25
  86. 12. Full Copyright Statement ................................... 26
  87. 1. Introduction
  88. This document is intended for people working on implementing an IRC
  89. server but will also be useful to anyone implementing an IRC service.
  90. Servers provide the three basic services required for realtime
  91. conferencing defined by the "Internet Relay Chat: Architecture"
  92. [IRC-ARCH]: client locator (via the client protocol [IRC-CLIENT]),
  93. message relaying (via the server protocol defined in this document)
  94. and channel hosting and management (following specific rules [IRC-
  95. CHAN]).
  96. 2. Global database
  97. Although the IRC Protocol defines a fairly distributed model, each
  98. server maintains a "global state database" about the whole IRC
  99. network. This database is, in theory, identical on all servers.
  100. 2.1 Servers
  101. Servers are uniquely identified by their name which has a maximum
  102. length of sixty three (63) characters. See the protocol grammar
  103. rules (section 3.3.1) for what may and may not be used in a server
  104. name.
  105. Each server is typically known by all other servers, however it is
  106. possible to define a "hostmask" to group servers together according
  107. to their name. Inside the hostmasked area, all the servers have a
  108. name which matches the hostmask, and any other server with a name
  109. matching the hostmask SHALL NOT be connected to the IRC network
  110. outside the hostmasked area. Servers which are outside the area have
  111. no knowledge of the individual servers present inside the area,
  112. instead they are presented with a virtual server which has the
  113. hostmask for name.
  114. Kalt Informational [Page 3]
  115. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  116. 2.2 Clients
  117. For each client, all servers MUST have the following information: a
  118. netwide unique identifier (whose format depends on the type of
  119. client) and the server to which the client is connected.
  120. 2.2.1 Users
  121. Each user is distinguished from other users by a unique nickname
  122. having a maximum length of nine (9) characters. See the protocol
  123. grammar rules (section 3.3.1) for what may and may not be used in a
  124. nickname. In addition to the nickname, all servers MUST have the
  125. following information about all users: the name of the host that the
  126. user is running on, the username of the user on that host, and the
  127. server to which the client is connected.
  128. 2.2.2 Services
  129. Each service is distinguished from other services by a service name
  130. composed of a nickname and a server name. The nickname has a maximum
  131. length of nine (9) characters. See the protocol grammar rules
  132. (section 3.3.1) for what may and may not be used in a nickname. The
  133. server name used to compose the service name is the name of the
  134. server to which the service is connected. In addition to this
  135. service name all servers MUST know the service type.
  136. Services differ from users by the format of their identifier, but
  137. more importantly services and users don't have the same type of
  138. access to the server: services can request part or all of the global
  139. state information that a server maintains, but have a more restricted
  140. set of commands available to them (See "IRC Client Protocol" [IRC-
  141. CLIENT] for details on which) and are not allowed to join channels.
  142. Finally services are not usually subject to the "Flood control"
  143. mechanism described in section 5.8.
  144. 2.3 Channels
  145. Alike services, channels have a scope [IRC-CHAN] and are not
  146. necessarily known to all servers. When a channel existence is known
  147. to a server, the server MUST keep track of the channel members, as
  148. well as the channel modes.
  149. Kalt Informational [Page 4]
  150. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  151. 3. The IRC Server Specification
  152. 3.1 Overview
  153. The protocol as described herein is for use with server to server
  154. connections. For client to server connections, see the IRC Client
  155. Protocol specification.
  156. There are, however, more restrictions on client connections (which
  157. are considered to be untrustworthy) than on server connections.
  158. 3.2 Character codes
  159. No specific character set is specified. The protocol is based on a a
  160. set of codes which are composed of eight (8) bits, making up an
  161. octet. Each message may be composed of any number of these octets;
  162. however, some octet values are used for control codes which act as
  163. message delimiters.
  164. Regardless of being an 8-bit protocol, the delimiters and keywords
  165. are such that protocol is mostly usable from US-ASCII terminal and a
  166. telnet connection.
  167. Because of IRC's Scandinavian origin, the characters {}|^ are
  168. considered to be the lower case equivalents of the characters []\~,
  169. respectively. This is a critical issue when determining the
  170. equivalence of two nicknames, or channel names.
  171. 3.3 Messages
  172. Servers and clients send each other messages which may or may not
  173. generate a reply. Most communication between servers do not generate
  174. any reply, as servers mostly perform routing tasks for the clients.
  175. Each IRC message may consist of up to three main parts: the prefix
  176. (OPTIONAL), the command, and the command parameters (maximum of
  177. fifteen (15)). The prefix, command, and all parameters are separated
  178. by one ASCII space character (0x20) each.
  179. The presence of a prefix is indicated with a single leading ASCII
  180. colon character (':', 0x3b), which MUST be the first character of the
  181. message itself. There MUST be NO gap (whitespace) between the colon
  182. and the prefix. The prefix is used by servers to indicate the true
  183. origin of the message. If the prefix is missing from the message, it
  184. is assumed to have originated from the connection from which it was
  185. received. Clients SHOULD not use a prefix when sending a message
  186. from themselves; if they use one, the only valid prefix is the
  187. registered nickname associated with the client.
  188. Kalt Informational [Page 5]
  189. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  190. When a server receives a message, it MUST identify its source using
  191. the (eventually assumed) prefix. If the prefix cannot be found in
  192. the server's internal database, it MUST be discarded, and if the
  193. prefix indicates the message comes from an (unknown) server, the link
  194. from which the message was received MUST be dropped. Dropping a link
  195. in such circumstances is a little excessive but necessary to maintain
  196. the integrity of the network and to prevent future problems. Another
  197. common error condition is that the prefix found in the server's
  198. internal database identifies a different source (typically a source
  199. registered from a different link than from which the message
  200. arrived). If the message was received from a server link and the
  201. prefix identifies a client, a KILL message MUST be issued for the
  202. client and sent to all servers. In other cases, the link from which
  203. the message arrived SHOULD be dropped for clients, and MUST be
  204. dropped for servers. In all cases, the message MUST be discarded.
  205. The command MUST either be a valid IRC command or a three (3) digit
  206. number represented in ASCII text.
  207. IRC messages are always lines of characters terminated with a CR-LF
  208. (Carriage Return - Line Feed) pair, and these messages SHALL NOT
  209. exceed 512 characters in length, counting all characters including
  210. the trailing CR-LF. Thus, there are 510 characters maximum allowed
  211. for the command and its parameters. There is no provision for
  212. continuation message lines. See section 5 for more details about
  213. current implementations.
  214. 3.3.1 Message format in Augmented BNF
  215. The protocol messages must be extracted from the contiguous stream of
  216. octets. The current solution is to designate two characters, CR and
  217. LF, as message separators. Empty messages are silently ignored,
  218. which permits use of the sequence CR-LF between messages without
  219. extra problems.
  220. The extracted message is parsed into the components <prefix>,
  221. <command> and list of parameters (<params>).
  222. The Augmented BNF representation for this is found in "IRC Client
  223. Protocol" [IRC-CLIENT].
  224. The extended prefix (["!" user "@" host ]) MUST NOT be used in server
  225. to server communications and is only intended for server to client
  226. messages in order to provide clients with more useful information
  227. about who a message is from without the need for additional queries.
  228. Kalt Informational [Page 6]
  229. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  230. 3.4 Numeric replies
  231. Most of the messages sent to the server generate a reply of some
  232. sort. The most common reply is the numeric reply, used for both
  233. errors and normal replies. The numeric reply MUST be sent as one
  234. message consisting of the sender prefix, the three digit numeric, and
  235. the target of the reply. A numeric reply is not allowed to originate
  236. from a client; any such messages received by a server are silently
  237. dropped. In all other respects, a numeric reply is just like a normal
  238. message, except that the keyword is made up of 3 numeric digits
  239. rather than a string of letters. A list of different replies is
  240. supplied in "IRC Client Protocol" [IRC-CLIENT].
  241. 4. Message Details
  242. All the messages recognized by the IRC server and client are
  243. described in the IRC Client Protocol specification.
  244. Where the reply ERR_NOSUCHSERVER is returned, it means that the
  245. target of the message could not be found. The server MUST NOT send
  246. any other replies after this error for that command.
  247. The server to which a client is connected is required to parse the
  248. complete message, returning any appropriate errors. If the server
  249. encounters a fatal error while parsing a message, an error MUST be
  250. sent back to the client and the parsing terminated. A fatal error
  251. may follow from incorrect command, a destination which is otherwise
  252. unknown to the server (server, client or channel names fit this
  253. category), not enough parameters or incorrect privileges.
  254. If a full set of parameters is presented, then each MUST be checked
  255. for validity and appropriate responses sent back to the client. In
  256. the case of messages which use parameter lists using the comma as an
  257. item separator, a reply MUST be sent for each item.
  258. In the examples below, some messages appear using the full format:
  259. :Name COMMAND parameter list
  260. Such examples represent a message from "Name" in transit between
  261. servers, where it is essential to include the name of the original
  262. sender of the message so remote servers may send back a reply along
  263. the correct path.
  264. The message details for client to server communication are described
  265. in the "IRC Client Protocol" [IRC-CLIENT]. Some sections in the
  266. following pages apply to some of these messages, they are additions
  267. to the message specifications which are only relevant to server to
  268. Kalt Informational [Page 7]
  269. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  270. server communication, or to the server implementation. The messages
  271. which are introduced here are only used for server to server
  272. communication.
  273. 4.1 Connection Registration
  274. The commands described here are used to register a connection with
  275. another IRC server.
  276. 4.1.1 Password message
  277. Command: PASS
  278. Parameters: <password> <version> <flags> [<options>]
  279. The PASS command is used to set a 'connection password'. The
  280. password MUST be set before any attempt to register the connection is
  281. made. Currently this means that servers MUST send a PASS command
  282. before any SERVER command. Only one (1) PASS command SHALL be
  283. accepted from a connection.
  284. The last three (3) parameters MUST be ignored if received from a
  285. client (e.g. a user or a service). They are only relevant when
  286. received from a server.
  287. The <version> parameter is a string of at least four (4) characters,
  288. and up to fourteen (14) characters. The first four (4) characters
  289. MUST be digits and indicate the protocol version known by the server
  290. issuing the message. The protocol described by this document is
  291. version 2.10 which is encoded as "0210". The remaining OPTIONAL
  292. characters are implementation dependent and should describe the
  293. software version number.
  294. The <flags> parameter is a string of up to one hundred (100)
  295. characters. It is composed of two substrings separated by the
  296. character "|" (%x7C). If present, the first substring MUST be the
  297. name of the implementation. The reference implementation (See
  298. Section 8, "Current support and availability") uses the string "IRC".
  299. If a different implementation is written, which needs an identifier,
  300. then that identifier should be registered through publication of an
  301. RFC. The second substring is implementation dependent. Both
  302. substrings are OPTIONAL, but the character "|" is REQUIRED. The
  303. character "|" MUST NOT appear in either substring.
  304. Finally, the last parameter, <options>, is used for link options.
  305. The only options defined by the protocol are link compression (using
  306. the character "Z"), and an abuse protection flag (using the character
  307. Kalt Informational [Page 8]
  308. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  309. "P"). See sections 5.3.1.1 (Compressed server to server links) and
  310. 5.3.1.2 (Anti abuse protections) respectively for more information on
  311. these options.
  312. Numeric Replies:
  313. ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
  314. Example:
  315. PASS moresecretpassword 0210010000 IRC|aBgH$ Z
  316. 4.1.2 Server message
  317. Command: SERVER
  318. Parameters: <servername> <hopcount> <token> <info>
  319. The SERVER command is used to register a new server. A new connection
  320. introduces itself as a server to its peer. This message is also used
  321. to pass server data over whole net. When a new server is connected
  322. to net, information about it MUST be broadcasted to the whole
  323. network.
  324. The <info> parameter may contain space characters.
  325. <hopcount> is used to give all servers some internal information on
  326. how far away each server is. Local peers have a value of 0, and each
  327. passed server increments the value. With a full server list, it
  328. would be possible to construct a map of the entire server tree, but
  329. hostmasks prevent this from being done.
  330. The <token> parameter is an unsigned number used by servers as an
  331. identifier. This identifier is subsequently used to reference a
  332. server in the NICK and SERVICE messages sent between servers. Server
  333. tokens only have a meaning for the point-to-point peering they are
  334. used and MUST be unique for that connection. They are not global.
  335. The SERVER message MUST only be accepted from either (a) a connection
  336. which is yet to be registered and is attempting to register as a
  337. server, or (b) an existing connection to another server, in which
  338. case the SERVER message is introducing a new server behind that
  339. server.
  340. Most errors that occur with the receipt of a SERVER command result in
  341. the connection being terminated by the destination host (target
  342. SERVER). Because of the severity of such event, error replies are
  343. usually sent using the "ERROR" command rather than a numeric.
  344. Kalt Informational [Page 9]
  345. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  346. If a SERVER message is parsed and it attempts to introduce a server
  347. which is already known to the receiving server, the connection, from
  348. which that message arrived, MUST be closed (following the correct
  349. procedures), since a duplicate route to a server has been formed and
  350. the acyclic nature of the IRC tree breaks. In some conditions, the
  351. connection from which the already known server has registered MAY be
  352. closed instead. It should be noted that this kind of error can also
  353. be the result of a second running server, problem which cannot be
  354. fixed within the protocol and typically requires human intervention.
  355. This type of problem is particularly insidious, as it can quite
  356. easily result in part of the IRC network to be isolated, with one of
  357. the two servers connected to each partition therefore making it
  358. impossible for the two parts to unite.
  359. Numeric Replies:
  360. ERR_ALREADYREGISTRED
  361. Example:
  362. SERVER test.oulu.fi 1 1 :Experimental server ; New server
  363. test.oulu.fi introducing itself and
  364. attempting to register.
  365. :tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server
  366. tolsun.oulu.fi is our uplink for
  367. csd.bu.edu which is 5 hops away. The
  368. token "34" will be used by
  369. tolsun.oulu.fi when introducing new
  370. users or services connected to
  371. csd.bu.edu.
  372. 4.1.3 Nick
  373. Command: NICK
  374. Parameters: <nickname> <hopcount> <username> <host> <servertoken>
  375. <umode> <realname>
  376. This form of the NICK message MUST NOT be allowed from user
  377. connections. However, it MUST be used instead of the NICK/USER pair
  378. to notify other servers of new users joining the IRC network.
  379. This message is really the combination of three distinct messages:
  380. NICK, USER and MODE [IRC-CLIENT].
  381. The <hopcount> parameter is used by servers to indicate how far away
  382. a user is from its home server. A local connection has a hopcount of
  383. 0. The hopcount value is incremented by each passed server.
  384. Kalt Informational [Page 10]
  385. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  386. The <servertoken> parameter replaces the <servername> parameter of
  387. the USER (See section 4.1.2 for more information on server tokens).
  388. Examples:
  389. NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New
  390. user with nickname "syrk", username
  391. "kalt", connected from host
  392. "millennium.stealth.net" to server
  393. "34" ("csd.bu.edu" according to the
  394. previous example).
  395. :krys NICK syrk ; The other form of the NICK message,
  396. as defined in "IRC Client Protocol"
  397. [IRC-CLIENT] and used between
  398. servers: krys changed his nickname to
  399. syrk
  400. 4.1.4 Service message
  401. Command: SERVICE
  402. Parameters: <servicename> <servertoken> <distribution> <type>
  403. <hopcount> <info>
  404. The SERVICE command is used to introduce a new service. This form of
  405. the SERVICE message SHOULD NOT be allowed from client (unregistered,
  406. or registered) connections. However, it MUST be used between servers
  407. to notify other servers of new services joining the IRC network.
  408. The <servertoken> is used to identify the server to which the service
  409. is connected. (See section 4.1.2 for more information on server
  410. tokens).
  411. The <hopcount> parameter is used by servers to indicate how far away
  412. a service is from its home server. A local connection has a hopcount
  413. of 0. The hopcount value is incremented by each passed server.
  414. The <distribution> parameter is used to specify the visibility of a
  415. service. The service may only be known to servers which have a name
  416. matching the distribution. For a matching server to have knowledge
  417. of the service, the network path between that server and the server
  418. to which the service is connected MUST be composed of servers whose
  419. names all match the mask. Plain "*" is used when no restriction is
  420. wished.
  421. The <type> parameter is currently reserved for future usage.
  422. Kalt Informational [Page 11]
  423. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  424. Numeric Replies:
  425. ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
  426. ERR_ERRONEUSNICKNAME
  427. RPL_YOURESERVICE RPL_YOURHOST
  428. RPL_MYINFO
  429. Example:
  430. SERVICE dict@irc.fr 9 *.fr 0 1 :French Dictionary r" registered on
  431. server "9" is being announced to
  432. another server. This service will
  433. only be available on servers whose
  434. name matches "*.fr".
  435. 4.1.5 Quit
  436. Command: QUIT
  437. Parameters: [<Quit Message>]
  438. A client session ends with a quit message. The server MUST close the
  439. connection to a client which sends a QUIT message. If a "Quit
  440. Message" is given, this will be sent instead of the default message,
  441. the nickname or service name.
  442. When "netsplit" (See Section 4.1.6) occur, the "Quit Message" is
  443. composed of the names of two servers involved, separated by a space.
  444. The first name is that of the server which is still connected and the
  445. second name is either that of the server which has become
  446. disconnected or that of the server to which the leaving client was
  447. connected:
  448. <Quit Message> = ":" servername SPACE servername
  449. Because the "Quit Message" has a special meaning for "netsplits",
  450. servers SHOULD NOT allow a client to use a <Quit Message> in the
  451. format described above.
  452. If, for some other reason, a client connection is closed without the
  453. client issuing a QUIT command (e.g. client dies and EOF occurs on
  454. socket), the server is REQUIRED to fill in the quit message with some
  455. sort of message reflecting the nature of the event which caused it to
  456. happen. Typically, this is done by reporting a system specific
  457. error.
  458. Numeric Replies:
  459. None.
  460. Kalt Informational [Page 12]
  461. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  462. Examples:
  463. :WiZ QUIT :Gone to have lunch ; Preferred message format.
  464. 4.1.6 Server quit message
  465. Command: SQUIT
  466. Parameters: <server> <comment>
  467. The SQUIT message has two distinct uses.
  468. The first one (described in "Internet Relay Chat: Client Protocol"
  469. [IRC-CLIENT]) allows operators to break a local or remote server
  470. link. This form of the message is also eventually used by servers to
  471. break a remote server link.
  472. The second use of this message is needed to inform other servers when
  473. a "network split" (also known as "netsplit") occurs, in other words
  474. to inform other servers about quitting or dead servers. If a server
  475. wishes to break the connection to another server it MUST send a SQUIT
  476. message to the other server, using the name of the other server as
  477. the server parameter, which then closes its connection to the
  478. quitting server.
  479. The <comment> is filled in by servers which SHOULD place an error or
  480. similar message here.
  481. Both of the servers which are on either side of the connection being
  482. closed are REQUIRED to send out a SQUIT message (to all its other
  483. server connections) for all other servers which are considered to be
  484. behind that link.
  485. Similarly, a QUIT message MAY be sent to the other still connected
  486. servers on behalf of all clients behind that quitting link. In
  487. addition to this, all channel members of a channel which lost a
  488. member due to the "split" MUST be sent a QUIT message. Messages to
  489. channel members are generated by each client's local server.
  490. If a server connection is terminated prematurely (e.g., the server on
  491. the other end of the link died), the server which detects this
  492. disconnection is REQUIRED to inform the rest of the network that the
  493. connection has closed and fill in the comment field with something
  494. appropriate.
  495. When a client is removed as the result of a SQUIT message, the server
  496. SHOULD add the nickname to the list of temporarily unavailable
  497. nicknames in an attempt to prevent future nickname collisions. See
  498. Kalt Informational [Page 13]
  499. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  500. section 5.7 (Tracking recently used nicknames) for more information
  501. on this procedure.
  502. Numeric replies:
  503. ERR_NOPRIVILEGES ERR_NOSUCHSERVER
  504. ERR_NEEDMOREPARAMS
  505. Example:
  506. SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi
  507. has been terminated because of "Bad
  508. Link".
  509. :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; message
  510. from Trillian to disconnect
  511. "cm22.eng.umd.edu" from the net
  512. because "Server out of control".
  513. 4.2 Channel operations
  514. This group of messages is concerned with manipulating channels, their
  515. properties (channel modes), and their contents (typically users). In
  516. implementing these, a number of race conditions are inevitable when
  517. users at opposing ends of a network send commands which will
  518. ultimately clash. It is also REQUIRED that servers keep a nickname
  519. history to ensure that wherever a <nick> parameter is given, the
  520. server check its history in case it has recently been changed.
  521. 4.2.1 Join message
  522. Command: JOIN
  523. Parameters: <channel>[ %x7 <modes> ]
  524. *( "," <channel>[ %x7 <modes> ] )
  525. The JOIN command is used by client to start listening a specific
  526. channel. Whether or not a client is allowed to join a channel is
  527. checked only by the local server the client is connected to; all
  528. other servers automatically add the user to the channel when the
  529. command is received from other servers.
  530. Optionally, the user status (channel modes 'O', 'o', and 'v') on the
  531. channel may be appended to the channel name using a control G (^G or
  532. ASCII 7) as separator. Such data MUST be ignored if the message
  533. wasn't received from a server. This format MUST NOT be sent to
  534. clients, it can only be used between servers and SHOULD be avoided.
  535. Kalt Informational [Page 14]
  536. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  537. The JOIN command MUST be broadcast to all servers so that each server
  538. knows where to find the users who are on the channel. This allows
  539. optimal delivery of PRIVMSG and NOTICE messages to the channel.
  540. Numeric Replies:
  541. ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
  542. ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
  543. ERR_CHANNELISFULL ERR_BADCHANMASK
  544. ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
  545. ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE
  546. RPL_TOPIC
  547. Examples:
  548. :WiZ JOIN #Twilight_zone ; JOIN message from WiZ
  549. 4.2.2 Njoin message
  550. Command: NJOIN
  551. Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
  552. *( "," [ "@@" / "@" ] [ "+" ] <nickname> )
  553. The NJOIN message is used between servers only. If such a message is
  554. received from a client, it MUST be ignored. It is used when two
  555. servers connect to each other to exchange the list of channel members
  556. for each channel.
  557. Even though the same function can be performed by using a succession
  558. of JOIN, this message SHOULD be used instead as it is more efficient.
  559. The prefix "@@" indicates that the user is the "channel creator", the
  560. character "@" alone indicates a "channel operator", and the character
  561. '+' indicates that the user has the voice privilege.
  562. Numeric Replies:
  563. ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
  564. ERR_ALREADYREGISTRED
  565. Examples:
  566. :ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN
  567. message from ircd.stealth.net
  568. announcing users joining the
  569. #Twilight_zone channel: WiZ with
  570. channel operator status, syrk with
  571. voice privilege and avalon with no
  572. privilege.
  573. Kalt Informational [Page 15]
  574. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  575. 4.2.3 Mode message
  576. The MODE message is a dual-purpose command in IRC. It allows both
  577. usernames and channels to have their mode changed.
  578. When parsing MODE messages, it is RECOMMENDED that the entire message
  579. be parsed first, and then the changes which resulted passed on.
  580. It is REQUIRED that servers are able to change channel modes so that
  581. "channel creator" and "channel operators" may be created.
  582. 5. Implementation details
  583. A the time of writing, the only current implementation of this
  584. protocol is the IRC server, version 2.10. Earlier versions may
  585. implement some or all of the commands described by this document with
  586. NOTICE messages replacing many of the numeric replies. Unfortunately,
  587. due to backward compatibility requirements, the implementation of
  588. some parts of this document varies with what is laid out. One
  589. notable difference is:
  590. * recognition that any LF or CR anywhere in a message marks
  591. the end of that message (instead of requiring CR-LF);
  592. The rest of this section deals with issues that are mostly of
  593. importance to those who wish to implement a server but some parts
  594. also apply directly to clients as well.
  595. 5.1 Connection 'Liveness'
  596. To detect when a connection has died or become unresponsive, the
  597. server MUST poll each of its connections. The PING command (See "IRC
  598. Client Protocol" [IRC-CLIENT]) is used if the server doesn't get a
  599. response from its peer in a given amount of time.
  600. If a connection doesn't respond in time, its connection is closed
  601. using the appropriate procedures.
  602. 5.2 Accepting a client to server connection
  603. 5.2.1 Users
  604. When a server successfully registers a new user connection, it is
  605. REQUIRED to send to the user unambiguous messages stating: the user
  606. identifiers upon which it was registered (RPL_WELCOME), the server
  607. name and version (RPL_YOURHOST), the server birth information
  608. (RPL_CREATED), available user and channel modes (RPL_MYINFO), and it
  609. MAY send any introductory messages which may be deemed appropriate.
  610. Kalt Informational [Page 16]
  611. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  612. In particular the server SHALL send the current user/service/server
  613. count (as per the LUSER reply) and finally the MOTD (if any, as per
  614. the MOTD reply).
  615. After dealing with registration, the server MUST then send out to
  616. other servers the new user's nickname (NICK message), other
  617. information as supplied by itself (USER message) and as the server
  618. could discover (from DNS servers). The server MUST NOT send this
  619. information out with a pair of NICK and USER messages as defined in
  620. "IRC Client Protocol" [IRC-CLIENT], but MUST instead take advantage
  621. of the extended NICK message defined in section 4.1.3.
  622. 5.2.2 Services
  623. Upon successfully registering a new service connection, the server is
  624. subject to the same kind of REQUIREMENTS as for a user. Services
  625. being somewhat different, only the following replies are sent:
  626. RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO.
  627. After dealing with this, the server MUST then send out to other
  628. servers (SERVICE message) the new service's nickname and other
  629. information as supplied by the service (SERVICE message) and as the
  630. server could discover (from DNS servers).
  631. 5.3 Establishing a server-server connection.
  632. The process of establishing a server-to-server connection is fraught
  633. with danger since there are many possible areas where problems can
  634. occur - the least of which are race conditions.
  635. After a server has received a connection following by a PASS/SERVER
  636. pair which were recognized as being valid, the server SHOULD then
  637. reply with its own PASS/SERVER information for that connection as
  638. well as all of the other state information it knows about as
  639. described below.
  640. When the initiating server receives a PASS/SERVER pair, it too then
  641. checks that the server responding is authenticated properly before
  642. accepting the connection to be that server.
  643. 5.3.1 Link options
  644. Server links are based on a common protocol (defined by this
  645. document) but a particular link MAY set specific options using the
  646. PASS message (See Section 4.1.1).
  647. Kalt Informational [Page 17]
  648. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  649. 5.3.1.1 Compressed server to server links
  650. If a server wishes to establish a compressed link with its peer, it
  651. MUST set the 'Z' flag in the options parameter to the PASS message.
  652. If both servers request compression and both servers are able to
  653. initialize the two compressed streams, then the remainder of the
  654. communication is to be compressed. If any server fails to initialize
  655. the stream, it will send an uncompressed ERROR message to its peer
  656. and close the connection.
  657. The data format used for the compression is described by RFC 1950
  658. [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].
  659. 5.3.1.2 Anti abuse protections
  660. Most servers implement various kinds of protections against possible
  661. abusive behaviours from non trusted parties (typically users). On
  662. some networks, such protections are indispensable, on others they are
  663. superfluous. To require that all servers implement and enable such
  664. features on a particular network, the 'P' flag is used when two
  665. servers connect. If this flag is present, it means that the server
  666. protections are enabled, and that the server REQUIRES all its server
  667. links to enable them as well.
  668. Commonly found protections are described in sections 5.7 (Tracking
  669. recently used nicknames) and 5.8 (Flood control of clients).
  670. 5.3.2 State information exchange when connecting
  671. The order of state information being exchanged between servers is
  672. essential. The REQUIRED order is as follows:
  673. * all known servers;
  674. * all known client information;
  675. * all known channel information.
  676. Information regarding servers is sent via extra SERVER messages,
  677. client information with NICK and SERVICE messages and channels with
  678. NJOIN/MODE messages.
  679. NOTE: channel topics SHOULD NOT be exchanged here because the TOPIC
  680. command overwrites any old topic information, so at best, the two
  681. sides of the connection would exchange topics.
  682. Kalt Informational [Page 18]
  683. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  684. By passing the state information about servers first, any collisions
  685. with servers that already exist occur before nickname collisions
  686. caused by a second server introducing a particular nickname. Due to
  687. the IRC network only being able to exist as an acyclic graph, it may
  688. be possible that the network has already reconnected in another
  689. location. In this event, the place where the server collision occurs
  690. indicates where the net needs to split.
  691. 5.4 Terminating server-client connections
  692. When a client connection unexpectedly closes, a QUIT message is
  693. generated on behalf of the client by the server to which the client
  694. was connected. No other message is to be generated or used.
  695. 5.5 Terminating server-server connections
  696. If a server-server connection is closed, either via a SQUIT command
  697. or "natural" causes, the rest of the connected IRC network MUST have
  698. its information updated by the server which detected the closure.
  699. The terminating server then sends a list of SQUITs (one for each
  700. server behind that connection). (See Section 4.1.6 (SQUIT)).
  701. 5.6 Tracking nickname changes
  702. All IRC servers are REQUIRED to keep a history of recent nickname
  703. changes. This is important to allow the server to have a chance of
  704. keeping in touch of things when nick-change race conditions occur
  705. with commands manipulating them. Messages which MUST trace nick
  706. changes are:
  707. * KILL (the nick being disconnected)
  708. * MODE (+/- o,v on channels)
  709. * KICK (the nick being removed from channel)
  710. No other commands need to check nick changes.
  711. In the above cases, the server is required to first check for the
  712. existence of the nickname, then check its history to see who that
  713. nick now belongs to (if anyone!). This reduces the chances of race
  714. conditions but they can still occur with the server ending up
  715. affecting the wrong client. When performing a change trace for an
  716. above command it is RECOMMENDED that a time range be given and
  717. entries which are too old ignored.
  718. Kalt Informational [Page 19]
  719. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  720. For a reasonable history, a server SHOULD be able to keep previous
  721. nickname for every client it knows about if they all decided to
  722. change. This size is limited by other factors (such as memory, etc).
  723. 5.7 Tracking recently used nicknames
  724. This mechanism is commonly known as "Nickname Delay", it has been
  725. proven to significantly reduce the number of nickname collisions
  726. resulting from "network splits"/reconnections as well as abuse.
  727. In addition of keeping track of nickname changes, servers SHOULD keep
  728. track of nicknames which were recently used and were released as the
  729. result of a "network split" or a KILL message. These nicknames are
  730. then unavailable to the server local clients and cannot be re-used
  731. (even though they are not currently in use) for a certain period of
  732. time.
  733. The duration for which a nickname remains unavailable SHOULD be set
  734. considering many factors among which are the size (user wise) of the
  735. IRC network, and the usual duration of "network splits". It SHOULD
  736. be uniform on all servers for a given IRC network.
  737. 5.8 Flood control of clients
  738. With a large network of interconnected IRC servers, it is quite easy
  739. for any single client attached to the network to supply a continuous
  740. stream of messages that result in not only flooding the network, but
  741. also degrading the level of service provided to others. Rather than
  742. require every 'victim' to provide their own protection, flood
  743. protection was written into the server and is applied to all clients
  744. except services. The current algorithm is as follows:
  745. * check to see if client's `message timer' is less than current time
  746. (set to be equal if it is);
  747. * read any data present from the client;
  748. * while the timer is less than ten (10) seconds ahead of the current
  749. time, parse any present messages and penalize the client by two (2)
  750. seconds for each message;
  751. * additional penalties MAY be used for specific commands which
  752. generate a lot of traffic across the network.
  753. This in essence means that the client may send one (1) message every
  754. two (2) seconds without being adversely affected. Services MAY also
  755. be subject to this mechanism.
  756. Kalt Informational [Page 20]
  757. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  758. 5.9 Non-blocking lookups
  759. In a real-time environment, it is essential that a server process
  760. does as little waiting as possible so that all the clients are
  761. serviced fairly. Obviously this requires non-blocking IO on all
  762. network read/write operations. For normal server connections, this
  763. was not difficult, but there are other support operations that may
  764. cause the server to block (such as disk reads). Where possible, such
  765. activity SHOULD be performed with a short timeout.
  766. 5.9.1 Hostname (DNS) lookups
  767. Using the standard resolver libraries from Berkeley and others has
  768. meant large delays in some cases where replies have timed out. To
  769. avoid this, a separate set of DNS routines were written for the
  770. current implementation. Routines were setup for non-blocking IO
  771. operations with local cache, and then polled from within the main
  772. server IO loop.
  773. 5.9.2 Username (Ident) lookups
  774. Although there are numerous ident libraries (implementing the
  775. "Identification Protocol" [IDENT]) for use and inclusion into other
  776. programs, these caused problems since they operated in a synchronous
  777. manner and resulted in frequent delays. Again the solution was to
  778. write a set of routines which would cooperate with the rest of the
  779. server and work using non-blocking IO.
  780. 6. Current problems
  781. There are a number of recognized problems with this protocol, all of
  782. which are hoped to be solved sometime in the near future during its
  783. rewrite. Currently, work is underway to find working solutions to
  784. these problems.
  785. 6.1 Scalability
  786. It is widely recognized that this protocol does not scale
  787. sufficiently well when used in a large arena. The main problem comes
  788. from the requirement that all servers know about all other servers
  789. and clients and that information regarding them be updated as soon as
  790. it changes. It is also desirable to keep the number of servers low
  791. so that the path length between any two points is kept minimal and
  792. the spanning tree as strongly branched as possible.
  793. Kalt Informational [Page 21]
  794. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  795. 6.2 Labels
  796. The current IRC protocol has 4 types of labels: the nickname, the
  797. channel name, the server name and the service name. Each of the four
  798. types has its own domain and no duplicates are allowed inside that
  799. domain. Currently, it is possible for users to pick the label for
  800. any of the first three, resulting in collisions. It is widely
  801. recognized that this needs reworking, with a plan for unique names
  802. for nicks that don't collide being desirable as well as a solution
  803. allowing a cyclic tree.
  804. 6.2.1 Nicknames
  805. The idea of the nickname on IRC is very convenient for users to use
  806. when talking to each other outside of a channel, but there is only a
  807. finite nickname space and being what they are, it's not uncommon for
  808. several people to want to use the same nick. If a nickname is chosen
  809. by two people using this protocol, either one will not succeed or
  810. both will be removed by use of KILL (See Section 3.7.1 of "IRC Client
  811. Protocol" [IRC-CLIENT]).
  812. 6.2.2 Channels
  813. The current channel layout requires that all servers know about all
  814. channels, their inhabitants and properties. Besides not scaling
  815. well, the issue of privacy is also a concern. A collision of
  816. channels is treated as an inclusive event (people from both nets on
  817. channel with common name are considered to be members of it) rather
  818. than an exclusive one such as used to solve nickname collisions.
  819. This protocol defines "Safe Channels" which are very unlikely to be
  820. the subject of a channel collision. Other channel types are kept for
  821. backward compatibility.
  822. 6.2.3 Servers
  823. Although the number of servers is usually small relative to the
  824. number of users and channels, they too are currently REQUIRED to be
  825. known globally, either each one separately or hidden behind a mask.
  826. 6.3 Algorithms
  827. In some places within the server code, it has not been possible to
  828. avoid N^2 algorithms such as checking the channel list of a set of
  829. clients.
  830. Kalt Informational [Page 22]
  831. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  832. In current server versions, there are only few database consistency
  833. checks, most of the time each server assumes that a neighbouring
  834. server is correct. This opens the door to large problems if a
  835. connecting server is buggy or otherwise tries to introduce
  836. contradictions to the existing net.
  837. Currently, because of the lack of unique internal and global labels,
  838. there are a multitude of race conditions that exist. These race
  839. conditions generally arise from the problem of it taking time for
  840. messages to traverse and effect the IRC network. Even by changing to
  841. unique labels, there are problems with channel-related commands being
  842. disrupted.
  843. 7. Security Considerations
  844. 7.1 Authentication
  845. Servers only have two means of authenticating incoming connections:
  846. plain text password, and DNS lookups. While these methods are weak
  847. and widely recognized as unsafe, their combination has proven to be
  848. sufficient in the past:
  849. * public networks typically allow user connections with only few
  850. restrictions, without requiring accurate authentication.
  851. * private networks which operate in a controlled environment often
  852. use home-grown authentication mechanisms not available on the
  853. internet: reliable ident servers [IDENT], or other proprietary
  854. mechanisms.
  855. The same comments apply to the authentication of IRC Operators.
  856. It should also be noted that while there has been no real demand over
  857. the years for stronger authentication, and no real effort to provide
  858. better means to safely authenticate users, the current protocol
  859. offers enough to be able to easily plug-in external authentication
  860. methods based on the information that a client can submit to the
  861. server upon connection: nickname, username, password.
  862. 7.2 Integrity
  863. Since the PASS and OPER messages of the IRC protocol are sent in
  864. clear text, a stream layer encryption mechanism (like "The TLS
  865. Protocol" [TLS]) could be used to protect these transactions.
  866. Kalt Informational [Page 23]
  867. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  868. 8. Current support and availability
  869. Mailing lists for IRC related discussion:
  870. General discussion: ircd-users@irc.org
  871. Protocol development: ircd-dev@irc.org
  872. Software implementations:
  873. ftp://ftp.irc.org/irc/server
  874. ftp://ftp.funet.fi/pub/unix/irc
  875. ftp://coombs.anu.edu.au/pub/irc
  876. Newsgroup: alt.irc
  877. 9. Acknowledgements
  878. Parts of this document were copied from the RFC 1459 [IRC] which
  879. first formally documented the IRC Protocol. It has also benefited
  880. from many rounds of review and comments. In particular, the
  881. following people have made significant contributions to this
  882. document:
  883. Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
  884. Ruokonen, Magnus Tjernstrom, Stefan Zehl.
  885. 10. References
  886. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
  887. Requirement Levels", BCP 14, RFC 2119, March 1997.
  888. [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
  889. Specifications: ABNF", RFC 2234, November 1997.
  890. [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
  891. Protocol", RFC 1459, May 1993.
  892. [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
  893. April 2000.
  894. [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
  895. 2812, April 2000.
  896. [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
  897. 2811, April 2000.
  898. [ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
  899. Format Specification version 3.3", RFC 1950, May 1996.
  900. Kalt Informational [Page 24]
  901. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  902. [DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format
  903. Specification version 1.3", RFC 1951, May 1996.
  904. [GZIP] Deutsch, P., "GZIP file format specification version
  905. 4.3", RFC 1952, May 1996.
  906. [IDENT] St. Johns, M., "The Identification Protocol", RFC 1413,
  907. February 1993.
  908. [TLS] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
  909. January 1999.
  910. 11. Author's Address
  911. Christophe Kalt
  912. 99 Teaneck Rd, Apt #117
  913. Ridgefield Park, NJ 07660
  914. USA
  915. EMail: kalt@stealth.net
  916. Kalt Informational [Page 25]
  917. RFC 2813 Internet Relay Chat: Server Protocol April 2000
  918. 12. Full Copyright Statement
  919. Copyright (C) The Internet Society (2000). All Rights Reserved.
  920. This document and translations of it may be copied and furnished to
  921. others, and derivative works that comment on or otherwise explain it
  922. or assist in its implementation may be prepared, copied, published
  923. and distributed, in whole or in part, without restriction of any
  924. kind, provided that the above copyright notice and this paragraph are
  925. included on all such copies and derivative works. However, this
  926. document itself may not be modified in any way, such as by removing
  927. the copyright notice or references to the Internet Society or other
  928. Internet organizations, except as needed for the purpose of
  929. developing Internet standards in which case the procedures for
  930. copyrights defined in the Internet Standards process must be
  931. followed, or as required to translate it into languages other than
  932. English.
  933. The limited permissions granted above are perpetual and will not be
  934. revoked by the Internet Society or its successors or assigns.
  935. This document and the information contained herein is provided on an
  936. "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  937. TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  938. BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  939. HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  940. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  941. Acknowledgement
  942. Funding for the RFC Editor function is currently provided by the
  943. Internet Society.
  944. Kalt Informational [Page 26]