12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178117911801181118211831184118511861187118811891190119111921193119411951196119711981199120012011202120312041205120612071208120912101211121212131214121512161217121812191220122112221223122412251226122712281229123012311232123312341235123612371238123912401241124212431244124512461247124812491250125112521253125412551256125712581259126012611262126312641265126612671268126912701271127212731274127512761277127812791280128112821283128412851286128712881289129012911292129312941295129612971298129913001301130213031304130513061307130813091310131113121313131413151316131713181319132013211322132313241325132613271328132913301331133213331334133513361337133813391340134113421343134413451346134713481349135013511352135313541355135613571358135913601361136213631364136513661367136813691370137113721373137413751376137713781379138013811382138313841385138613871388138913901391139213931394139513961397139813991400140114021403140414051406140714081409141014111412141314141415141614171418141914201421142214231424142514261427142814291430143114321433143414351436143714381439144014411442144314441445144614471448144914501451145214531454145514561457 |
-
-
-
-
- Network Working Group C. Kalt
- Request for Comments: 2813 April 2000
- Updates: 1459
- Category: Informational
-
-
- Internet Relay Chat: Server Protocol
-
- Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- Abstract
-
- While based on the client-server model, the IRC (Internet Relay Chat)
- protocol allows servers to connect to each other effectively forming
- a network.
-
- This document defines the protocol used by servers to talk to each
- other. It was originally a superset of the client protocol but has
- evolved differently.
-
- First formally documented in May 1993 as part of RFC 1459 [IRC], most
- of the changes brought since then can be found in this document as
- development was focused on making the protocol scale better. Better
- scalability has allowed existing world-wide networks to keep growing
- and reach sizes which defy the old specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Kalt Informational [Page 1]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- Table of Contents
-
- 1. Introduction ............................................... 3
- 2. Global database ............................................ 3
- 2.1 Servers ................................................ 3
- 2.2 Clients ................................................ 4
- 2.2.1 Users ............................................. 4
- 2.2.2 Services .......................................... 4
- 2.3 Channels ............................................... 4
- 3. The IRC Server Specification ............................... 5
- 3.1 Overview ............................................... 5
- 3.2 Character codes ........................................ 5
- 3.3 Messages ............................................... 5
- 3.3.1 Message format in Augmented BNF ................... 6
- 3.4 Numeric replies ........................................ 7
- 4. Message Details ............................................ 7
- 4.1 Connection Registration ................................ 8
- 4.1.1 Password message .................................. 8
- 4.1.2 Server message .................................... 9
- 4.1.3 Nick .............................................. 10
- 4.1.4 Service message ................................... 11
- 4.1.5 Quit .............................................. 12
- 4.1.6 Server quit message ............................... 13
- 4.2 Channel operations ..................................... 14
- 4.2.1 Join message ...................................... 14
- 4.2.2 Njoin message ..................................... 15
- 4.2.3 Mode message ...................................... 16
- 5. Implementation details .................................... 16
- 5.1 Connection 'Liveness' .................................. 16
- 5.2 Accepting a client to server connection ................ 16
- 5.2.1 Users ............................................. 16
- 5.2.2 Services .......................................... 17
- 5.3 Establishing a server-server connection. ............... 17
- 5.3.1 Link options ...................................... 17
- 5.3.1.1 Compressed server to server links ............ 18
- 5.3.1.2 Anti abuse protections ....................... 18
- 5.3.2 State information exchange when connecting ........ 18
- 5.4 Terminating server-client connections .................. 19
- 5.5 Terminating server-server connections .................. 19
- 5.6 Tracking nickname changes .............................. 19
- 5.7 Tracking recently used nicknames ....................... 20
- 5.8 Flood control of clients ............................... 20
- 5.9 Non-blocking lookups ................................... 21
- 5.9.1 Hostname (DNS) lookups ............................ 21
- 5.9.2 Username (Ident) lookups .......................... 21
- 6. Current problems ........................................... 21
- 6.1 Scalability ............................................ 21
- 6.2 Labels ................................................. 22
-
-
-
- Kalt Informational [Page 2]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- 6.2.1 Nicknames ......................................... 22
- 6.2.2 Channels .......................................... 22
- 6.2.3 Servers ........................................... 22
- 6.3 Algorithms ............................................. 22
- 7. Security Considerations .................................... 23
- 7.1 Authentication ......................................... 23
- 7.2 Integrity .............................................. 23
- 8. Current support and availability ........................... 24
- 9. Acknowledgements ........................................... 24
- 10. References ................................................ 24
- 11. Author's Address .......................................... 25
- 12. Full Copyright Statement ................................... 26
-
- 1. Introduction
-
- This document is intended for people working on implementing an IRC
- server but will also be useful to anyone implementing an IRC service.
-
- Servers provide the three basic services required for realtime
- conferencing defined by the "Internet Relay Chat: Architecture"
- [IRC-ARCH]: client locator (via the client protocol [IRC-CLIENT]),
- message relaying (via the server protocol defined in this document)
- and channel hosting and management (following specific rules [IRC-
- CHAN]).
-
- 2. Global database
-
- Although the IRC Protocol defines a fairly distributed model, each
- server maintains a "global state database" about the whole IRC
- network. This database is, in theory, identical on all servers.
-
- 2.1 Servers
-
- Servers are uniquely identified by their name which has a maximum
- length of sixty three (63) characters. See the protocol grammar
- rules (section 3.3.1) for what may and may not be used in a server
- name.
-
- Each server is typically known by all other servers, however it is
- possible to define a "hostmask" to group servers together according
- to their name. Inside the hostmasked area, all the servers have a
- name which matches the hostmask, and any other server with a name
- matching the hostmask SHALL NOT be connected to the IRC network
- outside the hostmasked area. Servers which are outside the area have
- no knowledge of the individual servers present inside the area,
- instead they are presented with a virtual server which has the
- hostmask for name.
-
-
-
-
- Kalt Informational [Page 3]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- 2.2 Clients
-
- For each client, all servers MUST have the following information: a
- netwide unique identifier (whose format depends on the type of
- client) and the server to which the client is connected.
-
- 2.2.1 Users
-
- Each user is distinguished from other users by a unique nickname
- having a maximum length of nine (9) characters. See the protocol
- grammar rules (section 3.3.1) for what may and may not be used in a
- nickname. In addition to the nickname, all servers MUST have the
- following information about all users: the name of the host that the
- user is running on, the username of the user on that host, and the
- server to which the client is connected.
-
- 2.2.2 Services
-
- Each service is distinguished from other services by a service name
- composed of a nickname and a server name. The nickname has a maximum
- length of nine (9) characters. See the protocol grammar rules
- (section 3.3.1) for what may and may not be used in a nickname. The
- server name used to compose the service name is the name of the
- server to which the service is connected. In addition to this
- service name all servers MUST know the service type.
-
- Services differ from users by the format of their identifier, but
- more importantly services and users don't have the same type of
- access to the server: services can request part or all of the global
- state information that a server maintains, but have a more restricted
- set of commands available to them (See "IRC Client Protocol" [IRC-
- CLIENT] for details on which) and are not allowed to join channels.
- Finally services are not usually subject to the "Flood control"
- mechanism described in section 5.8.
-
- 2.3 Channels
-
- Alike services, channels have a scope [IRC-CHAN] and are not
- necessarily known to all servers. When a channel existence is known
- to a server, the server MUST keep track of the channel members, as
- well as the channel modes.
-
-
-
-
-
-
-
-
-
-
- Kalt Informational [Page 4]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- 3. The IRC Server Specification
-
- 3.1 Overview
-
- The protocol as described herein is for use with server to server
- connections. For client to server connections, see the IRC Client
- Protocol specification.
-
- There are, however, more restrictions on client connections (which
- are considered to be untrustworthy) than on server connections.
-
- 3.2 Character codes
-
- No specific character set is specified. The protocol is based on a a
- set of codes which are composed of eight (8) bits, making up an
- octet. Each message may be composed of any number of these octets;
- however, some octet values are used for control codes which act as
- message delimiters.
-
- Regardless of being an 8-bit protocol, the delimiters and keywords
- are such that protocol is mostly usable from US-ASCII terminal and a
- telnet connection.
-
- Because of IRC's Scandinavian origin, the characters {}|^ are
- considered to be the lower case equivalents of the characters []\~,
- respectively. This is a critical issue when determining the
- equivalence of two nicknames, or channel names.
-
- 3.3 Messages
-
- Servers and clients send each other messages which may or may not
- generate a reply. Most communication between servers do not generate
- any reply, as servers mostly perform routing tasks for the clients.
-
- Each IRC message may consist of up to three main parts: the prefix
- (OPTIONAL), the command, and the command parameters (maximum of
- fifteen (15)). The prefix, command, and all parameters are separated
- by one ASCII space character (0x20) each.
-
- The presence of a prefix is indicated with a single leading ASCII
- colon character (':', 0x3b), which MUST be the first character of the
- message itself. There MUST be NO gap (whitespace) between the colon
- and the prefix. The prefix is used by servers to indicate the true
- origin of the message. If the prefix is missing from the message, it
- is assumed to have originated from the connection from which it was
- received. Clients SHOULD not use a prefix when sending a message
- from themselves; if they use one, the only valid prefix is the
- registered nickname associated with the client.
-
-
-
- Kalt Informational [Page 5]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- When a server receives a message, it MUST identify its source using
- the (eventually assumed) prefix. If the prefix cannot be found in
- the server's internal database, it MUST be discarded, and if the
- prefix indicates the message comes from an (unknown) server, the link
- from which the message was received MUST be dropped. Dropping a link
- in such circumstances is a little excessive but necessary to maintain
- the integrity of the network and to prevent future problems. Another
- common error condition is that the prefix found in the server's
- internal database identifies a different source (typically a source
- registered from a different link than from which the message
- arrived). If the message was received from a server link and the
- prefix identifies a client, a KILL message MUST be issued for the
- client and sent to all servers. In other cases, the link from which
- the message arrived SHOULD be dropped for clients, and MUST be
- dropped for servers. In all cases, the message MUST be discarded.
-
- The command MUST either be a valid IRC command or a three (3) digit
- number represented in ASCII text.
-
- IRC messages are always lines of characters terminated with a CR-LF
- (Carriage Return - Line Feed) pair, and these messages SHALL NOT
- exceed 512 characters in length, counting all characters including
- the trailing CR-LF. Thus, there are 510 characters maximum allowed
- for the command and its parameters. There is no provision for
- continuation message lines. See section 5 for more details about
- current implementations.
-
- 3.3.1 Message format in Augmented BNF
-
- The protocol messages must be extracted from the contiguous stream of
- octets. The current solution is to designate two characters, CR and
- LF, as message separators. Empty messages are silently ignored,
- which permits use of the sequence CR-LF between messages without
- extra problems.
-
- The extracted message is parsed into the components <prefix>,
- <command> and list of parameters (<params>).
-
- The Augmented BNF representation for this is found in "IRC Client
- Protocol" [IRC-CLIENT].
-
- The extended prefix (["!" user "@" host ]) MUST NOT be used in server
- to server communications and is only intended for server to client
- messages in order to provide clients with more useful information
- about who a message is from without the need for additional queries.
-
-
-
-
-
-
- Kalt Informational [Page 6]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- 3.4 Numeric replies
-
- Most of the messages sent to the server generate a reply of some
- sort. The most common reply is the numeric reply, used for both
- errors and normal replies. The numeric reply MUST be sent as one
- message consisting of the sender prefix, the three digit numeric, and
- the target of the reply. A numeric reply is not allowed to originate
- from a client; any such messages received by a server are silently
- dropped. In all other respects, a numeric reply is just like a normal
- message, except that the keyword is made up of 3 numeric digits
- rather than a string of letters. A list of different replies is
- supplied in "IRC Client Protocol" [IRC-CLIENT].
-
- 4. Message Details
-
- All the messages recognized by the IRC server and client are
- described in the IRC Client Protocol specification.
-
- Where the reply ERR_NOSUCHSERVER is returned, it means that the
- target of the message could not be found. The server MUST NOT send
- any other replies after this error for that command.
-
- The server to which a client is connected is required to parse the
- complete message, returning any appropriate errors. If the server
- encounters a fatal error while parsing a message, an error MUST be
- sent back to the client and the parsing terminated. A fatal error
- may follow from incorrect command, a destination which is otherwise
- unknown to the server (server, client or channel names fit this
- category), not enough parameters or incorrect privileges.
-
- If a full set of parameters is presented, then each MUST be checked
- for validity and appropriate responses sent back to the client. In
- the case of messages which use parameter lists using the comma as an
- item separator, a reply MUST be sent for each item.
-
- In the examples below, some messages appear using the full format:
-
- :Name COMMAND parameter list
-
- Such examples represent a message from "Name" in transit between
- servers, where it is essential to include the name of the original
- sender of the message so remote servers may send back a reply along
- the correct path.
-
- The message details for client to server communication are described
- in the "IRC Client Protocol" [IRC-CLIENT]. Some sections in the
- following pages apply to some of these messages, they are additions
- to the message specifications which are only relevant to server to
-
-
-
- Kalt Informational [Page 7]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- server communication, or to the server implementation. The messages
- which are introduced here are only used for server to server
- communication.
-
- 4.1 Connection Registration
-
- The commands described here are used to register a connection with
- another IRC server.
-
- 4.1.1 Password message
-
- Command: PASS
- Parameters: <password> <version> <flags> [<options>]
-
- The PASS command is used to set a 'connection password'. The
- password MUST be set before any attempt to register the connection is
- made. Currently this means that servers MUST send a PASS command
- before any SERVER command. Only one (1) PASS command SHALL be
- accepted from a connection.
-
- The last three (3) parameters MUST be ignored if received from a
- client (e.g. a user or a service). They are only relevant when
- received from a server.
-
- The <version> parameter is a string of at least four (4) characters,
- and up to fourteen (14) characters. The first four (4) characters
- MUST be digits and indicate the protocol version known by the server
- issuing the message. The protocol described by this document is
- version 2.10 which is encoded as "0210". The remaining OPTIONAL
- characters are implementation dependent and should describe the
- software version number.
-
- The <flags> parameter is a string of up to one hundred (100)
- characters. It is composed of two substrings separated by the
- character "|" (%x7C). If present, the first substring MUST be the
- name of the implementation. The reference implementation (See
- Section 8, "Current support and availability") uses the string "IRC".
- If a different implementation is written, which needs an identifier,
- then that identifier should be registered through publication of an
- RFC. The second substring is implementation dependent. Both
- substrings are OPTIONAL, but the character "|" is REQUIRED. The
- character "|" MUST NOT appear in either substring.
-
- Finally, the last parameter, <options>, is used for link options.
- The only options defined by the protocol are link compression (using
- the character "Z"), and an abuse protection flag (using the character
-
-
-
-
-
- Kalt Informational [Page 8]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- "P"). See sections 5.3.1.1 (Compressed server to server links) and
- 5.3.1.2 (Anti abuse protections) respectively for more information on
- these options.
-
- Numeric Replies:
-
- ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
-
- Example:
-
- PASS moresecretpassword 0210010000 IRC|aBgH$ Z
-
- 4.1.2 Server message
-
- Command: SERVER
- Parameters: <servername> <hopcount> <token> <info>
-
- The SERVER command is used to register a new server. A new connection
- introduces itself as a server to its peer. This message is also used
- to pass server data over whole net. When a new server is connected
- to net, information about it MUST be broadcasted to the whole
- network.
-
- The <info> parameter may contain space characters.
-
- <hopcount> is used to give all servers some internal information on
- how far away each server is. Local peers have a value of 0, and each
- passed server increments the value. With a full server list, it
- would be possible to construct a map of the entire server tree, but
- hostmasks prevent this from being done.
-
- The <token> parameter is an unsigned number used by servers as an
- identifier. This identifier is subsequently used to reference a
- server in the NICK and SERVICE messages sent between servers. Server
- tokens only have a meaning for the point-to-point peering they are
- used and MUST be unique for that connection. They are not global.
-
- The SERVER message MUST only be accepted from either (a) a connection
- which is yet to be registered and is attempting to register as a
- server, or (b) an existing connection to another server, in which
- case the SERVER message is introducing a new server behind that
- server.
-
- Most errors that occur with the receipt of a SERVER command result in
- the connection being terminated by the destination host (target
- SERVER). Because of the severity of such event, error replies are
- usually sent using the "ERROR" command rather than a numeric.
-
-
-
-
- Kalt Informational [Page 9]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- If a SERVER message is parsed and it attempts to introduce a server
- which is already known to the receiving server, the connection, from
- which that message arrived, MUST be closed (following the correct
- procedures), since a duplicate route to a server has been formed and
- the acyclic nature of the IRC tree breaks. In some conditions, the
- connection from which the already known server has registered MAY be
- closed instead. It should be noted that this kind of error can also
- be the result of a second running server, problem which cannot be
- fixed within the protocol and typically requires human intervention.
- This type of problem is particularly insidious, as it can quite
- easily result in part of the IRC network to be isolated, with one of
- the two servers connected to each partition therefore making it
- impossible for the two parts to unite.
-
- Numeric Replies:
-
- ERR_ALREADYREGISTRED
-
- Example:
-
- SERVER test.oulu.fi 1 1 :Experimental server ; New server
- test.oulu.fi introducing itself and
- attempting to register.
-
- :tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server
- tolsun.oulu.fi is our uplink for
- csd.bu.edu which is 5 hops away. The
- token "34" will be used by
- tolsun.oulu.fi when introducing new
- users or services connected to
- csd.bu.edu.
-
- 4.1.3 Nick
-
- Command: NICK
- Parameters: <nickname> <hopcount> <username> <host> <servertoken>
- <umode> <realname>
-
- This form of the NICK message MUST NOT be allowed from user
- connections. However, it MUST be used instead of the NICK/USER pair
- to notify other servers of new users joining the IRC network.
-
- This message is really the combination of three distinct messages:
- NICK, USER and MODE [IRC-CLIENT].
-
- The <hopcount> parameter is used by servers to indicate how far away
- a user is from its home server. A local connection has a hopcount of
- 0. The hopcount value is incremented by each passed server.
-
-
-
- Kalt Informational [Page 10]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- The <servertoken> parameter replaces the <servername> parameter of
- the USER (See section 4.1.2 for more information on server tokens).
-
- Examples:
-
- NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New
- user with nickname "syrk", username
- "kalt", connected from host
- "millennium.stealth.net" to server
- "34" ("csd.bu.edu" according to the
- previous example).
-
- :krys NICK syrk ; The other form of the NICK message,
- as defined in "IRC Client Protocol"
- [IRC-CLIENT] and used between
- servers: krys changed his nickname to
- syrk
-
- 4.1.4 Service message
-
- Command: SERVICE
- Parameters: <servicename> <servertoken> <distribution> <type>
- <hopcount> <info>
-
- The SERVICE command is used to introduce a new service. This form of
- the SERVICE message SHOULD NOT be allowed from client (unregistered,
- or registered) connections. However, it MUST be used between servers
- to notify other servers of new services joining the IRC network.
-
- The <servertoken> is used to identify the server to which the service
- is connected. (See section 4.1.2 for more information on server
- tokens).
-
- The <hopcount> parameter is used by servers to indicate how far away
- a service is from its home server. A local connection has a hopcount
- of 0. The hopcount value is incremented by each passed server.
-
- The <distribution> parameter is used to specify the visibility of a
- service. The service may only be known to servers which have a name
- matching the distribution. For a matching server to have knowledge
- of the service, the network path between that server and the server
- to which the service is connected MUST be composed of servers whose
- names all match the mask. Plain "*" is used when no restriction is
- wished.
-
- The <type> parameter is currently reserved for future usage.
-
-
-
-
-
- Kalt Informational [Page 11]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- Numeric Replies:
-
- ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
- ERR_ERRONEUSNICKNAME
- RPL_YOURESERVICE RPL_YOURHOST
- RPL_MYINFO
-
- Example:
-
- SERVICE dict@irc.fr 9 *.fr 0 1 :French Dictionary r" registered on
- server "9" is being announced to
- another server. This service will
- only be available on servers whose
- name matches "*.fr".
-
- 4.1.5 Quit
-
- Command: QUIT
- Parameters: [<Quit Message>]
-
- A client session ends with a quit message. The server MUST close the
- connection to a client which sends a QUIT message. If a "Quit
- Message" is given, this will be sent instead of the default message,
- the nickname or service name.
-
- When "netsplit" (See Section 4.1.6) occur, the "Quit Message" is
- composed of the names of two servers involved, separated by a space.
- The first name is that of the server which is still connected and the
- second name is either that of the server which has become
- disconnected or that of the server to which the leaving client was
- connected:
-
- <Quit Message> = ":" servername SPACE servername
-
- Because the "Quit Message" has a special meaning for "netsplits",
- servers SHOULD NOT allow a client to use a <Quit Message> in the
- format described above.
-
- If, for some other reason, a client connection is closed without the
- client issuing a QUIT command (e.g. client dies and EOF occurs on
- socket), the server is REQUIRED to fill in the quit message with some
- sort of message reflecting the nature of the event which caused it to
- happen. Typically, this is done by reporting a system specific
- error.
-
- Numeric Replies:
-
- None.
-
-
-
- Kalt Informational [Page 12]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- Examples:
-
- :WiZ QUIT :Gone to have lunch ; Preferred message format.
-
- 4.1.6 Server quit message
-
- Command: SQUIT
- Parameters: <server> <comment>
-
- The SQUIT message has two distinct uses.
-
- The first one (described in "Internet Relay Chat: Client Protocol"
- [IRC-CLIENT]) allows operators to break a local or remote server
- link. This form of the message is also eventually used by servers to
- break a remote server link.
-
- The second use of this message is needed to inform other servers when
- a "network split" (also known as "netsplit") occurs, in other words
- to inform other servers about quitting or dead servers. If a server
- wishes to break the connection to another server it MUST send a SQUIT
- message to the other server, using the name of the other server as
- the server parameter, which then closes its connection to the
- quitting server.
-
- The <comment> is filled in by servers which SHOULD place an error or
- similar message here.
-
- Both of the servers which are on either side of the connection being
- closed are REQUIRED to send out a SQUIT message (to all its other
- server connections) for all other servers which are considered to be
- behind that link.
-
- Similarly, a QUIT message MAY be sent to the other still connected
- servers on behalf of all clients behind that quitting link. In
- addition to this, all channel members of a channel which lost a
- member due to the "split" MUST be sent a QUIT message. Messages to
- channel members are generated by each client's local server.
-
- If a server connection is terminated prematurely (e.g., the server on
- the other end of the link died), the server which detects this
- disconnection is REQUIRED to inform the rest of the network that the
- connection has closed and fill in the comment field with something
- appropriate.
-
- When a client is removed as the result of a SQUIT message, the server
- SHOULD add the nickname to the list of temporarily unavailable
- nicknames in an attempt to prevent future nickname collisions. See
-
-
-
-
- Kalt Informational [Page 13]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- section 5.7 (Tracking recently used nicknames) for more information
- on this procedure.
-
- Numeric replies:
-
- ERR_NOPRIVILEGES ERR_NOSUCHSERVER
- ERR_NEEDMOREPARAMS
-
- Example:
-
- SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi
- has been terminated because of "Bad
- Link".
-
- :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; message
- from Trillian to disconnect
- "cm22.eng.umd.edu" from the net
- because "Server out of control".
-
- 4.2 Channel operations
-
- This group of messages is concerned with manipulating channels, their
- properties (channel modes), and their contents (typically users). In
- implementing these, a number of race conditions are inevitable when
- users at opposing ends of a network send commands which will
- ultimately clash. It is also REQUIRED that servers keep a nickname
- history to ensure that wherever a <nick> parameter is given, the
- server check its history in case it has recently been changed.
-
- 4.2.1 Join message
-
- Command: JOIN
- Parameters: <channel>[ %x7 <modes> ]
- *( "," <channel>[ %x7 <modes> ] )
-
- The JOIN command is used by client to start listening a specific
- channel. Whether or not a client is allowed to join a channel is
- checked only by the local server the client is connected to; all
- other servers automatically add the user to the channel when the
- command is received from other servers.
-
- Optionally, the user status (channel modes 'O', 'o', and 'v') on the
- channel may be appended to the channel name using a control G (^G or
- ASCII 7) as separator. Such data MUST be ignored if the message
- wasn't received from a server. This format MUST NOT be sent to
- clients, it can only be used between servers and SHOULD be avoided.
-
-
-
-
-
- Kalt Informational [Page 14]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- The JOIN command MUST be broadcast to all servers so that each server
- knows where to find the users who are on the channel. This allows
- optimal delivery of PRIVMSG and NOTICE messages to the channel.
-
- Numeric Replies:
-
- ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
- ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
- ERR_CHANNELISFULL ERR_BADCHANMASK
- ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
- ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE
- RPL_TOPIC
-
- Examples:
-
- :WiZ JOIN #Twilight_zone ; JOIN message from WiZ
-
- 4.2.2 Njoin message
-
- Command: NJOIN
- Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
- *( "," [ "@@" / "@" ] [ "+" ] <nickname> )
-
- The NJOIN message is used between servers only. If such a message is
- received from a client, it MUST be ignored. It is used when two
- servers connect to each other to exchange the list of channel members
- for each channel.
-
- Even though the same function can be performed by using a succession
- of JOIN, this message SHOULD be used instead as it is more efficient.
- The prefix "@@" indicates that the user is the "channel creator", the
- character "@" alone indicates a "channel operator", and the character
- '+' indicates that the user has the voice privilege.
-
- Numeric Replies:
-
- ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
- ERR_ALREADYREGISTRED
-
- Examples:
-
- :ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN
- message from ircd.stealth.net
- announcing users joining the
- #Twilight_zone channel: WiZ with
- channel operator status, syrk with
- voice privilege and avalon with no
- privilege.
-
-
-
- Kalt Informational [Page 15]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- 4.2.3 Mode message
-
- The MODE message is a dual-purpose command in IRC. It allows both
- usernames and channels to have their mode changed.
-
- When parsing MODE messages, it is RECOMMENDED that the entire message
- be parsed first, and then the changes which resulted passed on.
-
- It is REQUIRED that servers are able to change channel modes so that
- "channel creator" and "channel operators" may be created.
-
- 5. Implementation details
-
- A the time of writing, the only current implementation of this
- protocol is the IRC server, version 2.10. Earlier versions may
- implement some or all of the commands described by this document with
- NOTICE messages replacing many of the numeric replies. Unfortunately,
- due to backward compatibility requirements, the implementation of
- some parts of this document varies with what is laid out. One
- notable difference is:
-
- * recognition that any LF or CR anywhere in a message marks
- the end of that message (instead of requiring CR-LF);
-
- The rest of this section deals with issues that are mostly of
- importance to those who wish to implement a server but some parts
- also apply directly to clients as well.
-
- 5.1 Connection 'Liveness'
-
- To detect when a connection has died or become unresponsive, the
- server MUST poll each of its connections. The PING command (See "IRC
- Client Protocol" [IRC-CLIENT]) is used if the server doesn't get a
- response from its peer in a given amount of time.
-
- If a connection doesn't respond in time, its connection is closed
- using the appropriate procedures.
-
- 5.2 Accepting a client to server connection
-
- 5.2.1 Users
-
- When a server successfully registers a new user connection, it is
- REQUIRED to send to the user unambiguous messages stating: the user
- identifiers upon which it was registered (RPL_WELCOME), the server
- name and version (RPL_YOURHOST), the server birth information
- (RPL_CREATED), available user and channel modes (RPL_MYINFO), and it
- MAY send any introductory messages which may be deemed appropriate.
-
-
-
- Kalt Informational [Page 16]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- In particular the server SHALL send the current user/service/server
- count (as per the LUSER reply) and finally the MOTD (if any, as per
- the MOTD reply).
-
- After dealing with registration, the server MUST then send out to
- other servers the new user's nickname (NICK message), other
- information as supplied by itself (USER message) and as the server
- could discover (from DNS servers). The server MUST NOT send this
- information out with a pair of NICK and USER messages as defined in
- "IRC Client Protocol" [IRC-CLIENT], but MUST instead take advantage
- of the extended NICK message defined in section 4.1.3.
-
- 5.2.2 Services
-
- Upon successfully registering a new service connection, the server is
- subject to the same kind of REQUIREMENTS as for a user. Services
- being somewhat different, only the following replies are sent:
- RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO.
-
- After dealing with this, the server MUST then send out to other
- servers (SERVICE message) the new service's nickname and other
- information as supplied by the service (SERVICE message) and as the
- server could discover (from DNS servers).
-
- 5.3 Establishing a server-server connection.
-
- The process of establishing a server-to-server connection is fraught
- with danger since there are many possible areas where problems can
- occur - the least of which are race conditions.
-
- After a server has received a connection following by a PASS/SERVER
- pair which were recognized as being valid, the server SHOULD then
- reply with its own PASS/SERVER information for that connection as
- well as all of the other state information it knows about as
- described below.
-
- When the initiating server receives a PASS/SERVER pair, it too then
- checks that the server responding is authenticated properly before
- accepting the connection to be that server.
-
- 5.3.1 Link options
-
- Server links are based on a common protocol (defined by this
- document) but a particular link MAY set specific options using the
- PASS message (See Section 4.1.1).
-
-
-
-
-
-
- Kalt Informational [Page 17]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- 5.3.1.1 Compressed server to server links
-
- If a server wishes to establish a compressed link with its peer, it
- MUST set the 'Z' flag in the options parameter to the PASS message.
- If both servers request compression and both servers are able to
- initialize the two compressed streams, then the remainder of the
- communication is to be compressed. If any server fails to initialize
- the stream, it will send an uncompressed ERROR message to its peer
- and close the connection.
-
- The data format used for the compression is described by RFC 1950
- [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].
-
- 5.3.1.2 Anti abuse protections
-
- Most servers implement various kinds of protections against possible
- abusive behaviours from non trusted parties (typically users). On
- some networks, such protections are indispensable, on others they are
- superfluous. To require that all servers implement and enable such
- features on a particular network, the 'P' flag is used when two
- servers connect. If this flag is present, it means that the server
- protections are enabled, and that the server REQUIRES all its server
- links to enable them as well.
-
- Commonly found protections are described in sections 5.7 (Tracking
- recently used nicknames) and 5.8 (Flood control of clients).
-
- 5.3.2 State information exchange when connecting
-
- The order of state information being exchanged between servers is
- essential. The REQUIRED order is as follows:
-
- * all known servers;
-
- * all known client information;
-
- * all known channel information.
-
- Information regarding servers is sent via extra SERVER messages,
- client information with NICK and SERVICE messages and channels with
- NJOIN/MODE messages.
-
- NOTE: channel topics SHOULD NOT be exchanged here because the TOPIC
- command overwrites any old topic information, so at best, the two
- sides of the connection would exchange topics.
-
-
-
-
-
-
- Kalt Informational [Page 18]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- By passing the state information about servers first, any collisions
- with servers that already exist occur before nickname collisions
- caused by a second server introducing a particular nickname. Due to
- the IRC network only being able to exist as an acyclic graph, it may
- be possible that the network has already reconnected in another
- location. In this event, the place where the server collision occurs
- indicates where the net needs to split.
-
- 5.4 Terminating server-client connections
-
- When a client connection unexpectedly closes, a QUIT message is
- generated on behalf of the client by the server to which the client
- was connected. No other message is to be generated or used.
-
- 5.5 Terminating server-server connections
-
- If a server-server connection is closed, either via a SQUIT command
- or "natural" causes, the rest of the connected IRC network MUST have
- its information updated by the server which detected the closure.
- The terminating server then sends a list of SQUITs (one for each
- server behind that connection). (See Section 4.1.6 (SQUIT)).
-
- 5.6 Tracking nickname changes
-
- All IRC servers are REQUIRED to keep a history of recent nickname
- changes. This is important to allow the server to have a chance of
- keeping in touch of things when nick-change race conditions occur
- with commands manipulating them. Messages which MUST trace nick
- changes are:
-
- * KILL (the nick being disconnected)
-
- * MODE (+/- o,v on channels)
-
- * KICK (the nick being removed from channel)
-
- No other commands need to check nick changes.
-
- In the above cases, the server is required to first check for the
- existence of the nickname, then check its history to see who that
- nick now belongs to (if anyone!). This reduces the chances of race
- conditions but they can still occur with the server ending up
- affecting the wrong client. When performing a change trace for an
- above command it is RECOMMENDED that a time range be given and
- entries which are too old ignored.
-
-
-
-
-
-
- Kalt Informational [Page 19]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- For a reasonable history, a server SHOULD be able to keep previous
- nickname for every client it knows about if they all decided to
- change. This size is limited by other factors (such as memory, etc).
-
- 5.7 Tracking recently used nicknames
-
- This mechanism is commonly known as "Nickname Delay", it has been
- proven to significantly reduce the number of nickname collisions
- resulting from "network splits"/reconnections as well as abuse.
-
- In addition of keeping track of nickname changes, servers SHOULD keep
- track of nicknames which were recently used and were released as the
- result of a "network split" or a KILL message. These nicknames are
- then unavailable to the server local clients and cannot be re-used
- (even though they are not currently in use) for a certain period of
- time.
-
- The duration for which a nickname remains unavailable SHOULD be set
- considering many factors among which are the size (user wise) of the
- IRC network, and the usual duration of "network splits". It SHOULD
- be uniform on all servers for a given IRC network.
-
- 5.8 Flood control of clients
-
- With a large network of interconnected IRC servers, it is quite easy
- for any single client attached to the network to supply a continuous
- stream of messages that result in not only flooding the network, but
- also degrading the level of service provided to others. Rather than
- require every 'victim' to provide their own protection, flood
- protection was written into the server and is applied to all clients
- except services. The current algorithm is as follows:
-
- * check to see if client's `message timer' is less than current time
- (set to be equal if it is);
-
- * read any data present from the client;
-
- * while the timer is less than ten (10) seconds ahead of the current
- time, parse any present messages and penalize the client by two (2)
- seconds for each message;
-
- * additional penalties MAY be used for specific commands which
- generate a lot of traffic across the network.
-
- This in essence means that the client may send one (1) message every
- two (2) seconds without being adversely affected. Services MAY also
- be subject to this mechanism.
-
-
-
-
- Kalt Informational [Page 20]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- 5.9 Non-blocking lookups
-
- In a real-time environment, it is essential that a server process
- does as little waiting as possible so that all the clients are
- serviced fairly. Obviously this requires non-blocking IO on all
- network read/write operations. For normal server connections, this
- was not difficult, but there are other support operations that may
- cause the server to block (such as disk reads). Where possible, such
- activity SHOULD be performed with a short timeout.
-
- 5.9.1 Hostname (DNS) lookups
-
- Using the standard resolver libraries from Berkeley and others has
- meant large delays in some cases where replies have timed out. To
- avoid this, a separate set of DNS routines were written for the
- current implementation. Routines were setup for non-blocking IO
- operations with local cache, and then polled from within the main
- server IO loop.
-
- 5.9.2 Username (Ident) lookups
-
- Although there are numerous ident libraries (implementing the
- "Identification Protocol" [IDENT]) for use and inclusion into other
- programs, these caused problems since they operated in a synchronous
- manner and resulted in frequent delays. Again the solution was to
- write a set of routines which would cooperate with the rest of the
- server and work using non-blocking IO.
-
- 6. Current problems
-
- There are a number of recognized problems with this protocol, all of
- which are hoped to be solved sometime in the near future during its
- rewrite. Currently, work is underway to find working solutions to
- these problems.
-
- 6.1 Scalability
-
- It is widely recognized that this protocol does not scale
- sufficiently well when used in a large arena. The main problem comes
- from the requirement that all servers know about all other servers
- and clients and that information regarding them be updated as soon as
- it changes. It is also desirable to keep the number of servers low
- so that the path length between any two points is kept minimal and
- the spanning tree as strongly branched as possible.
-
-
-
-
-
-
-
- Kalt Informational [Page 21]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- 6.2 Labels
-
- The current IRC protocol has 4 types of labels: the nickname, the
- channel name, the server name and the service name. Each of the four
- types has its own domain and no duplicates are allowed inside that
- domain. Currently, it is possible for users to pick the label for
- any of the first three, resulting in collisions. It is widely
- recognized that this needs reworking, with a plan for unique names
- for nicks that don't collide being desirable as well as a solution
- allowing a cyclic tree.
-
- 6.2.1 Nicknames
-
- The idea of the nickname on IRC is very convenient for users to use
- when talking to each other outside of a channel, but there is only a
- finite nickname space and being what they are, it's not uncommon for
- several people to want to use the same nick. If a nickname is chosen
- by two people using this protocol, either one will not succeed or
- both will be removed by use of KILL (See Section 3.7.1 of "IRC Client
- Protocol" [IRC-CLIENT]).
-
- 6.2.2 Channels
-
- The current channel layout requires that all servers know about all
- channels, their inhabitants and properties. Besides not scaling
- well, the issue of privacy is also a concern. A collision of
- channels is treated as an inclusive event (people from both nets on
- channel with common name are considered to be members of it) rather
- than an exclusive one such as used to solve nickname collisions.
-
- This protocol defines "Safe Channels" which are very unlikely to be
- the subject of a channel collision. Other channel types are kept for
- backward compatibility.
-
- 6.2.3 Servers
-
- Although the number of servers is usually small relative to the
- number of users and channels, they too are currently REQUIRED to be
- known globally, either each one separately or hidden behind a mask.
-
- 6.3 Algorithms
-
- In some places within the server code, it has not been possible to
- avoid N^2 algorithms such as checking the channel list of a set of
- clients.
-
-
-
-
-
-
- Kalt Informational [Page 22]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- In current server versions, there are only few database consistency
- checks, most of the time each server assumes that a neighbouring
- server is correct. This opens the door to large problems if a
- connecting server is buggy or otherwise tries to introduce
- contradictions to the existing net.
-
- Currently, because of the lack of unique internal and global labels,
- there are a multitude of race conditions that exist. These race
- conditions generally arise from the problem of it taking time for
- messages to traverse and effect the IRC network. Even by changing to
- unique labels, there are problems with channel-related commands being
- disrupted.
-
- 7. Security Considerations
-
- 7.1 Authentication
-
- Servers only have two means of authenticating incoming connections:
- plain text password, and DNS lookups. While these methods are weak
- and widely recognized as unsafe, their combination has proven to be
- sufficient in the past:
-
- * public networks typically allow user connections with only few
- restrictions, without requiring accurate authentication.
-
- * private networks which operate in a controlled environment often
- use home-grown authentication mechanisms not available on the
- internet: reliable ident servers [IDENT], or other proprietary
- mechanisms.
-
- The same comments apply to the authentication of IRC Operators.
-
- It should also be noted that while there has been no real demand over
- the years for stronger authentication, and no real effort to provide
- better means to safely authenticate users, the current protocol
- offers enough to be able to easily plug-in external authentication
- methods based on the information that a client can submit to the
- server upon connection: nickname, username, password.
-
- 7.2 Integrity
-
- Since the PASS and OPER messages of the IRC protocol are sent in
- clear text, a stream layer encryption mechanism (like "The TLS
- Protocol" [TLS]) could be used to protect these transactions.
-
-
-
-
-
-
-
- Kalt Informational [Page 23]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- 8. Current support and availability
-
- Mailing lists for IRC related discussion:
- General discussion: ircd-users@irc.org
- Protocol development: ircd-dev@irc.org
-
- Software implementations:
- ftp://ftp.irc.org/irc/server
- ftp://ftp.funet.fi/pub/unix/irc
- ftp://coombs.anu.edu.au/pub/irc
-
- Newsgroup: alt.irc
-
- 9. Acknowledgements
-
- Parts of this document were copied from the RFC 1459 [IRC] which
- first formally documented the IRC Protocol. It has also benefited
- from many rounds of review and comments. In particular, the
- following people have made significant contributions to this
- document:
-
- Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
- Ruokonen, Magnus Tjernstrom, Stefan Zehl.
-
- 10. References
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
- Protocol", RFC 1459, May 1993.
-
- [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
- April 2000.
-
- [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
- 2812, April 2000.
-
-
- [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
- 2811, April 2000.
-
- [ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
- Format Specification version 3.3", RFC 1950, May 1996.
-
-
-
-
- Kalt Informational [Page 24]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- [DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format
- Specification version 1.3", RFC 1951, May 1996.
-
- [GZIP] Deutsch, P., "GZIP file format specification version
- 4.3", RFC 1952, May 1996.
-
- [IDENT] St. Johns, M., "The Identification Protocol", RFC 1413,
- February 1993.
-
- [TLS] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
- January 1999.
-
- 11. Author's Address
-
- Christophe Kalt
- 99 Teaneck Rd, Apt #117
- Ridgefield Park, NJ 07660
- USA
-
- EMail: kalt@stealth.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Kalt Informational [Page 25]
-
- RFC 2813 Internet Relay Chat: Server Protocol April 2000
-
-
- 12. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
- Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Kalt Informational [Page 26]
-
|