--- irc3-20000104.txt Tue Jan 4 21:26:18 2000 +++ irc3-20000330.txt Thu Mar 30 14:22:28 2000 @@ -1,5 +1,5 @@ Network Working Group A. Church -Request For Comments: nnnn January, 2000 +Request For Comments: nnnn March, 2000 Obsoletes: 1459 Category: Experimental @@ -44,7 +44,7 @@ 1.3 Requirements for clients and servers 1.4 Channels 1.4.1 Channel operators - 1.5 Unicode and names + 1.5 Unicode 1.6 Communication 1.6.1 The shortest-path algorithm 1.6.2 One-to-one messages @@ -142,34 +142,25 @@ 6.2 DNS spoofing 6.3 Network sniffing 6.4 Time overflow + 6.5 Special characters in names 7. Author's address 8. References and notes 9. Copyright notice Appendix A: Dijkstra's algorithm Appendix B: Alphabetical index of message and reply elements - Appendix C: List of requirements and recommendations - C.1 Basic client and server requirements - C.2 Names and identifiers - C.3 Privilege levels - C.4 Unicode support - C.5 Message generation, transmission and receipt - C.6 Messages - C.7 Replies - C.8 Collisions - C.9 Other requirements - Appendix D: Conversion table for the RFC 1459 protocol + Appendix C: Conversion table for the RFC 1459 protocol 0. PREFACE 0.1 Acknowledgements - The author wishes to acknowledge the assistance of Ian Justman and - Andrew Kempe for offering suggestions on this document and the - protocol defined therein. The author also wishes to acknowledge an - IRC protocol proposal by Steven Arnold [2] for providing the idea for - inter-network communication. + The author wishes to acknowledge the assistance of Ian Justman, + Andrew Kempe, and Trevor Talbot, among many others, for offering + suggestions on this document and the protocol defined therein. The + author also wishes to acknowledge an IRC protocol proposal by Steven + Arnold [2] for providing the idea for inter-network communication. 0.2 Terminology @@ -297,8 +288,9 @@ characters in length, and MUST NOT contain the character with value zero (ASCII NUL). All other characters are legal; however, for compatibility with older clients, servers SHOULD NOT use names with - the space (" ", ASCII 0x20) and comma (",", ASCII 0x2C) characters, - as those are delimiters under the old protocol. + the space (" ", ASCII 0x20), comma (",", ASCII 0x2C), or CR/LF (ASCII + 0x0D and 0x0A) characters, as those are delimiters under the old + protocol. Note that this identification scheme only allows up to 65,536 servers to exist in a single network. While the author believes this to be @@ -343,17 +335,17 @@ that server. The nickname MUST be no longer than 31 characters, and has the same restrictions (except for length) as server names; again, for compatibility with older clients, newer clients SHOULD NOT allow - users to select nicknames with the space (" ", ASCII 0x20) and comma - (",", ASCII 0x2C) characters, as those are delimiters under the old - protocol. Additionally, clients SHOULD NOT allow nicknames that - begin with "#" or "&", as those are used at the beginning of channel - names (see section 1.4), and while this protocol has no ambiguity - between nicknames and channel names, it may be difficult for a human - user to distinguish between the two. Case is not relevant in - nicknames. (Compatibility note: The old protocol required three - pairs of non-alphabetic characters to be pairwise equivalent: "[" - and "{"; "]" and "}"; and "\" and "|". These six characters are all - distinct in this protocol.) + users to select nicknames with the space, comma, or CR/LF characters, + as those are delimiters under the old protocol. Additionally, + clients SHOULD NOT allow nicknames that begin with "#" or "&", as + those are used at the beginning of channel names (see section 1.4), + and while this protocol has no ambiguity between nicknames and + channel names, it may be difficult for a human user to distinguish + between the two. Case is not relevant in nicknames. (Compatibility + note: The old protocol required three pairs of non-alphabetic + characters to be pairwise equivalent: "[" and "{"; "]" and "}"; and + "\" and "|". These six characters are all distinct in this + protocol.) Each client also has an address in the form "user@host" associated with it, where "user" is the username of the client (e.g. a Unix @@ -406,8 +398,8 @@ the last client leaves it. A channel name is a string which consists of up to 63 characters. - Specifically, channel names MUST obey the same restrictions as - server names: no NUL, space and comma are discouraged, names are + Channel names MUST obey the same restrictions as server names: no + NUL, space, comma and CR/LF are discouraged, names are case-insensitive. However, the first character of a channel name has certain limitations; see below. @@ -455,39 +447,34 @@ to channel operators and/or clients in the channel, even when the privileged user is not a channel operator or is not in the channel. -1.5 Unicode and names +1.5 Unicode As of the writing of this document, the most common system for encoding characters in digital form is to use an eight-bit encoding - system such as ASCII or ISO 8859 (although countries such as Japan - with larger character sets use 16-bit systems). However, a new, - 16-bit standard known as Unicode is emerging, and may replace current - 8-bit standards in the future. Obviously, this protocol should be - able to support Unicode as well as traditional standards. - - A server or client implementation which is capable of receiving and - processing Unicode strings MUST set the "Unicode support" flag (see - section 2.2) in all messages, and MUST set the "Unicode" flag in any - messages sent which contain Unicode-encoded strings. Servers and - clients MUST NOT include both Unicode and non-Unicode strings in the - same message. A server with Unicode support which has the ability to - generate and send text messages (such as descriptive error messages; - see section 2.2.3) SHOULD include support for sending the same text - messages in the preferred non-Unicode encoding for the language used - (when such an encoding exists). Note that a client implementation - which is capable of understanding Unicode need not necessarily - generate strings in Unicode. - - Implementors of clients or servers with Unicode support should take - note of the distinction between "characters" and "octets". For - example, the maximum length of a nickname (as given in section 1.2.1) - is 31 characters; this means that a 62-octet (31-character) Unicode - string is also legal. - - Any implementation that uses Unicode MUST translate all characters - referred to in this document into their Unicode equivalents rather - than using the hexadecimal octet values given (single octets make no - sense as characters in Unicode anyway). + system such as ASCII or ISO 8859; some languages, such as Japanese, + which require more than eight bits to represent characters use a + 16-bit system such as ISO-2022-JP. + + Currently, there is a movement to establish a single 16-bit standard, + known as Unicode, to allow encoding text in all major languages using + a single character set. However, problems with this encoding are + emerging; in particular, users of the so-called "CJK" languages + (Chinese, Japanese, and Korean, all of which use ideographs numbering + in the thousands) have noted that the Unicode definition does not + include all characters necessary for their languages, or has in some + cases inappropriately combined characters from different languages + into a single glyph. Moreover, the incredible amount of text that + currently exists in 8-bit format and tools which process and/or + display them suggest that even if a 16-bit standard such as Unicode + were to be accepted worldwide, it would take a good deal of time + before such a system became standard. + + Nonetheless, it is desirable to at minimum provide a framework for + such a character set should it come into use. Therefore, two flags + in the message structure (see section 2.2) are reserved for this + purpose, although their meaning is left undefined. Should such a + character set become widely accepted and used, this protocol will be + revised to include concrete support for that character set. 1.6 Communication @@ -786,14 +773,9 @@ though it MAY log the message or in some other way record the fact that it received such an erroneous message. - Bit 13 of the flag parameter is the Unicode support flag (see section - 1.5); any message sent by a client or server which supports Unicode - MUST have this flag set, whether or not the message actually uses any - Unicode characters. - - Bit 12 of the flag parameter is the Unicode flag (see section 1.5); - any message which includes strings containing Unicode characters MUST - have this flag set. + Bits 13 and 12 of the flag parameter are reserved for multi-byte + character set use in future versions of the protocol (see section + 1.5), and MUST be cleared (zero) in all messages. If bit 9 of the flag parameter is set, all strings are considered to have 32-bit length fields rather than 16-bit length fields. @@ -855,16 +837,13 @@ containing the sender's nickname (or the server name, if the sender is a server), possibly followed by a string containing the sender's user@host address (if the sender is a client). If the address is - included, bit 11 of the flag parameter MUST be set. If the Unicode - flag is set, the address MUST be in Unicode (type "addr-unistring" - below); otherwise, the address MUST NOT be in Unicode (type - "addr-string" below). The address MUST be sent on all client join, - leave, and quit messages which are broadcast to other clients, and - MAY be sent with any other client-generated message. (Obviously, the - address makes no sense for server-generated messages.) Clients MUST - accept any length string in the sender address field, though they MAY - discard a string longer than a certain length depending on display - and other requirements. + included, bit 11 of the flag parameter MUST be set. The address MUST + be sent on all client join, leave, and quit messages which are + broadcast to other clients, and MAY be sent with any other + client-generated message. (Obviously, the address makes no sense for + server-generated messages.) Clients MUST accept any length string in + the sender address field, though they MAY discard a string longer + than a certain length depending on display and other requirements. The augmented BNF description of a client message is: @@ -1012,8 +991,8 @@ Bit 15: Reserved, set to 0. 14: 1 if the message is from a server, else 0. - 13: 1 if the sender of the message supports Unicode, else 0. - 12: 1 if the message uses Unicode, else 0. + 13: Reserved, set to 0. + 12: Reserved, set to 0. 11: 1 if the message includes a sender address field, else 0. 10: 1 if the message is a reply, else 0. 9: 1 if the message has strings with 32-bit lengths, else 0. @@ -1200,6 +1179,18 @@ If the nickname given by the client is already in use, the server MUST return ERR_NICKNAME_IN_USE and ignore the message. + Servers MAY limit the set of characters they accept in client + nicknames and usernames. If a nickname is determined to be invalid, + the server MUST return ERR_INVALID_NAME and discard the message. If + a username is determined to be invalid, the server MAY modify the + username and accept the rest of the message as-is instead of + discarding it; in this case, the server SHOULD send a notice to the + client (see section 3.2.3) explaining what was done. (For example, + the server might remove all invalid characters, or replace them with + an innocuous character such as "x".) See section 6.5 for a + discussion of potential security problems with allowing any character + to be used in a name. + Examples: CS: 0x0001 "Alcan" "achurch" "Andrew Church" @@ -1219,6 +1210,7 @@ ERR_CLIENT_DENIED ERR_NICKNAME_IN_USE ERR_NAME_TOO_LONG + ERR_INVALID_NAME 3.1.2.1 A note on the Ident Protocol @@ -1286,6 +1278,11 @@ version-id parameter is as described for the user registration message (see section 3.1.2). + Servers MAY limit the set of characters they accept in server names, + as described for the user registration message. Servers MUST reject + registration attempts with invalid server names with + ERR_INVALID_NAME. + A server MUST reject an attempted registration with ERR_WRONG_VERSION if it is not prepared to support the version supplied. Servers compliant with this protocol MUST accept connections which supply the @@ -1330,6 +1327,7 @@ ERR_BAD_PASSWORD ERR_SERVER_DENIED ERR_NAME_TOO_LONG + ERR_INVALID_NAME ERR_WRONG_VERSION 3.1.4 Remote server message @@ -1351,6 +1349,11 @@ registration message in section 3.1.3. Note that servers MUST NOT send state information to remote networks. + Servers MAY limit the set of characters they accept in server names + and network names, as described for the user registration message + (section 3.1.2). Servers MUST reject registration attempts with + invalid server or network names with ERR_INVALID_NAME. + Unlike all other messages between servers except the server message, this message is sent in client-server message format. @@ -1369,6 +1372,7 @@ ERR_SERVER_DENIED ERR_NETWORK_DENIED ERR_NAME_TOO_LONG + ERR_INVALID_NAME 3.1.5 Network message @@ -2557,18 +2561,22 @@ Code: 0x0501 Parameters: channel (string), [target-server (string)] - channel (string), nickname (string) ... + channel (string), status-nickname (string) ... Requests a list of clients in channels matching the given channel string, which may contain wildcards. For each channel matching the - given string, a message is returned, with the first parameter set to + given string, a message is returned with the first parameter set to the channel name and subsequent parameters set to the nicknames of - the clients in the channel. If a particular client is a channel - operator in the channel, the character "@" (ASCII 0x40) is prefixed - to the nickname; if the client is not a channel operator but has been - "given a voice" (see section 3.3.6), the character "+" (ASCII 0x2B) - is prefixed. If the sending client is not in the channel, clients - with UMODE_INVISIBLE set (see section 3.4.4) are not printed. + the clients in the channel; each nickname is prefixed by an 8-bit + value with bits set as follows: + Bits 7-6: Reserved for experimental or local use. + Bits 5-2: Reserved, all clear (0). + Bit 1: Set (1) if the client is a channel operator, else clear (0) + Bit 0: Set (1) if the client has been "given a voice" (see section + 3.3.6), else clear (0) + If the sending client is not in the channel, clients with + UMODE_INVISIBLE set (see section 3.4.4) are not included in the + generated message. Private channels (channels with CMODE_PRIVATE set; see section 3.3.3) are not returned unless the given string is an exact @@ -2582,10 +2590,11 @@ A client requests a list of the clients in any channels matching the string "#dragon*". - SC: 0x0501 "#dragonweyr" "@Alcan" + SC: 0x0501 "#dragonweyr" "\x02Alcan" The server returns a list of nicknames in channel "#dragonweyr", showing that Alcan is a channel operator in that - channel. + channel. (The notation "\x02" is used to indicate an octet with + hexadecimal value 02.) Replies: @@ -3522,12 +3531,12 @@ Like the earlier IRC protocol, there exists the possibility of name collisions. These are caused by race conditions which are - unavoidable due to the nature of IRC; for example, two clients may - connect to two different servers at exactly the same time, and choose - the same nickname, resulting in a nickname collision when the two - messages' paths intersect. The following sections detail the - procedures for resolving collisions of the different categories of - names. + unavoidable due to the distributed nature of IRC; for example, two + clients may connect to two different servers at exactly the same + time and choose the same nickname, resulting in a nickname collision + when the two messages' paths intersect. The following sections + detail the procedures for resolving collisions of the different + categories of names. 5.2.1 Nickname collisions @@ -3536,10 +3545,14 @@ nickname of a client already present on the IRC network, the server receiving the colliding message MUST remove from its internal list of nicknames whichever has the more recent nickname change time (which - is the time of connection registration if the client has not changed - nicknames since then). If that client is directly connected to the - server, then the server MUST terminate the connection with an - appropriate quit message (see section 3.1.6). + is the registration time for a client registration message). If that + client is directly connected to the server, then the server MUST + terminate the connection with an appropriate quit message (see + section 3.1.6). In the case where both nicknames have the same + change time, the server MUST remove both nicknames (and terminate + connections as necessary). + + FIXME: compare this with TS8 5.2.2 Server name or ID collisions @@ -3784,6 +3797,11 @@ integers) rather than the predefined "time_t" type for handling timestamps. +6.5 Special characters in names + + The wide range of allowable characters in names (nicknames, server + names, and so on) creates the potential for + 7. AUTHOR'S ADDRESS @@ -3822,7 +3840,7 @@ [7] St. Johns, M., "Identification Protocol", RFC 1413, February, 1993. - [8] *** FIXME: Does anyone know of a good CTCP reference? + [8] http://www.undernet.org/documents/ctcpinfo.txt [9] http://achurch.org/services/ @@ -3832,7 +3850,7 @@ 9. Copyright notice - This document is copyright (c) 1999 Andrew Church. This document may + This document is copyright (c) 2000 Andrew Church. This document may be freely distributed as-is, and may be excerpted as-is provided that the excerpt includes an attribution to the author. This document may be modified, but modified versions may not be distributed unless this @@ -3918,513 +3936,7 @@ user-string = length * -Appendix C. List of requirements and recommendations - - Requirements (MUST, MUST NOT) are prefixed with "REQ:"; - recommendations (SHOULD, SHOULD NOT) are prefixed with "REC:". - Additionally, the section number in which each requirement or - recommendation is stated is given in parentheses after the - requirement or recommendation itself. - -C.1 Basic client and server requirements - - REQ: Both clients and servers MUST be capable of sending and - receiving arbitrary data octets. (1.3) - REQ: Servers MUST use the protocol defined in this document for - transmitting data to other servers compatible with this - protocol. (1.3) - REQ: Servers MUST communicate with a remote client or server using - the same protocol it registered with. (1.3) - REC: Servers SHOULD recognize both the old and current protocols. - (1.3) - REQ: Servers MUST use a transport protocol that guarantees - in-order delivery of data, or explicitly implement such a - protocol on top of an existing transport protocol. (2.2.2, 5.5) - REC: Servers SHOULD use some method to keep their clocks - synchronized. (5.3) - REC: Servers SHOULD use a reliable transport protocol to minimize the - possibility of desynchronization. (5.4) - -C.2 Names and identifiers - - REQ: Server names MUST be no more than 63 characters in length. (1.1) - REQ: Server names MUST NOT contain the character with value zero - (ASCII NUL). (1.1) - REC: Server names SHOULD NOT contain the space (" ", ASCII 0x20) or - comma (",", ASCII 0x2C) characters. (1.1) - REQ: Servers MUST NOT use the identifier 65,535 (hexadecimal FFFF) - when registering. (1.1) - REQ: Servers MUST reject a server registration message which uses the - identifier 65,535 (hexadecimal FFFF). (1.1) - REQ: Client names MUST be no more than 31 characters in length. (1.2) - REQ: Client names MUST NOT contain the character with value zero - (ASCII NUL). (1.2) - REC: Client names SHOULD NOT contain the space (" ", ASCII 0x20) or - comma (",", ASCII 0x2C) characters, or begin with the "#" or "&" - characters. (1.2) - REQ: Servers MUST NOT assign the ID 65,535 (hexadecimal FFFF) to any - client. (1.2) - REQ: Channel names MUST be no more than 63 characters in length. - (1.4) - REQ: Channel names MUST NOT contain the character with value zero - (ASCII NUL). (1.4) - REC: Channel names SHOULD NOT contain the space (" ", ASCII 0x20) or - comma (",", ASCII 0x2C) characters. (1.4) - REQ: Servers MUST treat channels with unrecognized initial characters - as beginning with the "&" character. (1.4) - -C.3 Privilege levels - - REQ: Normal (unprivileged) users MUST NOT be able to execute any - functions which require IRC operator privileges in this protocol - description. (1.2) - REQ: Normal (unprivileged) users MUST NOT be able to execute any - functions which require channel operator privileges in this - protocol description. - -C.4 Unicode support - - REQ: A server or client which is capable of receiving and processing - Unicode strings MUST set the "Unicode support" flag in all - messages. (1.5) - REQ: A server or client which includes Unicode strings in a message - MUST set the "Unicode" flag in that message. (1.5) - REQ: Servers and clients MUST NOT include both Unicode and - non-Unicode strings in the same message. (!.5) - REC: A server with Unicode support which has the ability to generate - and send text messages SHOULD include support for sending the - same text messages in the preferred non-Unicode encoding for the - language used. (1.5) - REQ: Any implementation that uses Unicode MUST translate all - characters referred to in this document into their Unicode - equivalents rather than using the hexadecimal octet values - given. (1.5) - -C.5 Message generation, transmission and receipt - - REQ: If the length of a string is greater than 32,767 octets, a - 32-bit length MUST be used to represent the string length. (2.1) - REC: If the length of a string is less than 32,768 octets, a 16-bit - length SHOULD be used to represent the string length. (2.1) - REQ: Bit 15 of the flag parameter MUST be set to zero when sending a - message. (2.2) - REQ: The Unicode support flag (bit 13 of the flag parameter) MUST be - set in any message sent by a client or server which supports - Unicode. (2.2) - REQ: The Unicode flag (bit 12 of the flag parameter) MUST be set in - any message which contains Unicode strings. (2.2) - REQ: The network field MUST be included wherever allowed if and only - if bit 5 of the flag parameter is set for a message. (2.2) - REQ: All flag bits not defined by this protocol MUST be set to zero - when sending a message. (2.2) - REQ: Clients MUST NOT include a sender field when generating a - message. (2.2.1) - REQ: If the address is included in a sender field, bit 11 of the flag - parameter MUST be set. (2.2.1) - REQ: The address part of a sender field MUST be in Unicode iff the - Unicode flag is set. (2.2.1) - REQ: The address part of a sender field MUST be sent on all client - join, leave, and quit messages which are broadcast to other - clients. (2.2.1) - REQ: Servers MUST include a timestamp for the user registration and - nickname change messages. (2.2.2, 3.1.2) - REQ: Bit 8 of the flag parameter MUST be set if a timestamp is - included in the message. (2.2.2) - REC: Servers SHOULD NOT include descriptive strings when sending - replies to other servers. (2.2.3) - - REQ: Every server on a network MUST use the same method for computing - link weights for shortest-path determination. (1.6.1) - REQ: When sending a message to another server, the sender MUST append - its server ID to the path field of the message. (1.6.1) - REQ: A server MUST NOT send a message to a server which is listed in - the message's path field. (1.6.1) - REQ: Servers which precalculate the shortest path to every other - server on the network MUST update their tables whenever a server - is added to or removed from the network. (1.6.1) - REQ: Both clients and servers MUST send exactly the number of octets - they specify in the length parameter. - - REQ: A server receiving a message with its own ID in the path field - MUST discard the message. (1.6.1) - REQ: If the first octet of a supposed message does not have the - decimal value 253, the client or server MUST discard the octet - as belonging to a previous message. (2.2) - REQ: If a client receives a server message or a server receives a - server message from a client or a client message from a server, - it MUST discard that message. (2.2) - REQ: Both clients and servers MUST read exactly the number of octets - given by the length parameter, regardless of the validity of the - message. (2.2) - REQ: When discarding a message, if the remote client or server is not - immediately disconnected, the receiver MUST read the number of - bytes specified in the length parameter from the input stream - before beginning to process the next message. (2.2) - REQ: When discarding a message, if the length parameter has not been - completely received, the remote client or server MUST be - disconnected. (2.2) - REQ: If the length given for a parameter would exceed the length of - the message, the server or client receiving the message MUST - truncate the parameter when the message's length is reached and, - in the case of a server, MUST send an ERR_NEED_MORE_PARAMS reply - and discard the message if there are fewer parameters than - expected. (2.2.1) - REQ: Clients MUST accept any length string in the sender address - field. (2.2.1) - REQ: For server messages, if the signed 32-bit difference - (message sequence number) - (source's last seen sequence number) - is less than or equal to zero, the server MUST discard the - message. (2.2.2) - REQ: If a server receives a reply from a client, it MUST ignore the - reply. (2.2.3) - REQ: If a server receives a string in a reply, it MUST pass that - string along unmodified. (2.2.3) - REC: Clients SHOULD display a default description if one is not sent - with the reply. (2.2.3) - - REQ: All servers on a network MUST assign the same meaning to the - value of a timestamp. (2.4) - REQ: Timestamps, when sent in binary format, MUST be sent using 64 - bits. (2.4) - REQ: Clients and servers MUST be prepared to properly handle any - timestamp value, including values outside the range of a 32-bit - integer. (2.4) - REQ: Clients which process decimal time values MUST be prepared to - handle values outside the range of a 32-bit integer. (2.4) - -C.6 Messages - - REQ: All of the messages listed in section 3 MUST be implemented by - all servers with exactly the behavior listed. (3) - REQ: If a server encounters a fatal error while parsing a message, - it MUST immediately stop parsing that message and return an - error reply to the source of the message. (3) - REQ: If a server successfully parses a message, it MUST act on all of - the parameters, sending appropriate replies for each. - REQ: In any message including a target, the message MUST be sent to - that target as described under section 1.5 unless otherwise - noted. (3) - REQ: All connection registration/cancellation messages MUST be - forwarded, except for password and remote server messages, which - MUST NOT be forwarded. (3.1) - REQ: If a password message is sent, it MUST be sent before the - connection registration message. (3.1.1) - REQ: Implementors which add or modify features of this protocol MUST - choose a new version-id value in the range 0x8000-0xFFFF for - their revised protocol. (3.1.2) - REQ: If the nickname given by a client in a user registration message - or nick message is already in use, the server MUST return - ERR_NICKNAME_IN_USE and ignore (not forward) the message. - (3.1.2, 3.4.1) - REQ: If the nickname given by a client in a user registration message - or nick message is longer than the maximum length, the server - MUST return ERR_NAME_TOO_LONG and ignore the message. (3.1.2, - 3.4.1) - REQ: A server MUST reject an attempted registration with - ERR_WRONG_VERSION if it is not prepared to support the version - supplied. (3.1.3) - REQ: Servers compliant with this protocol MUST accept connections - which supply the value 0x0100 in the version-id field. - REQ: Upon successful registration of a server, both the registering - server and the server to which it connected MUST send all state - information. (3.1.3) - REQ: Servers MUST NOT send state information to remote networks. - (3.1.4) - REC: Servers SHOULD forcibly close a client connection in only the - following cases: a ping timeout, a kill message, a nickname - collision, and an operating system error which prevents the - server from reading data from the client's connection. (3.1.6) - REQ: A server which forcibly closes a client's connection MUST - generate a quit message on the client's behalf, it MUST include - a "reason" describing why the connection was closed, and it MUST - send that quit message to the client whose connection is being - closed (if possible). (3.1.6) - REQ: Any server receiving a quit message, whether from a - directly-connected client or from another server, MUST send that - message to all clients connected to it who are on any channel - the quitting client was on. (3.1.6) - REQ: Upon receipt of a server quit message, if any now-unreachable - clients were on channels that any clients local to the receiving - server are also on, then the server MUST generate and send quit - messages on their behalf. - REC: The "reason" in quit messages resulting from a server quit - message SHOULD be of the form "server1 server2", where server1 - and server2 are the servers at either end of the severed - connection: server1 is the server which is still on the IRC - network, and server2 is the server which is no longer on the - network. (3.1.7) - REQ: When a server forcibly disconnects a remote server, it MUST - generate and send a server quit message to the server whose - connection is being closed, and MUST include an explanation of - why the connection is being closed. - REQ: A client or server which receives a notice MUST NOT generate - any other messages (including server error messages) in response - to the notice. (3.2.3) - REC: Status messages relevant to the entire network SHOULD be sent as - operator messages. (3.2.4) - REQ: Server notices MUST be ignored when received from a client. - (3.2.4) - REC: For events local to a single server, servers SHOULD use server - notices for reporting. (3.2.5) - REQ: All channel messages MUST be forwarded except as noted, and MUST - be sent by each server to all clients connected to that server - on the channel sent in the message. (3.3) - REQ: Failed join messages MUST NOT be forwarded. (3.3.1) - REQ: When broadcasting join messages to clients in joined channel(s), - the server MUST send a separate join message for each channel - using message code 0x0200, and MUST NOT include any key used in - the original join message. (3.3.1) - REC: Upon joining, the server SHOULD send to the client the channel - topic, current channel modes, and a list of all clients on the - channel. (3.3.1) - REQ: Servers MUST accept join messages from other servers even if the - first character of the channel name is unrecognized. (3.3.1) - REQ: When broadcasting a part message to clients in the parted - channel(s), the server MUST use message code 0x0281, and MUST - send an empty string for the "reason" parameter if one was not - given in the original message. (3.3.2) - REQ: If a client which does not have channel operator privileges - attempts to change channel modes, the server MUST reply with - ERR_PERMISSION_DENIED and discard the message without processing - it. (3.3.3) - REQ: If a client without IRC operator privileges attempts to change - channel modes on a channel which has the CMODE_LOCKED flag set, - the server MUST return ERR_CANNOT_CHANGE_LOCKED and discard the - entire message. (3.3.3) - REQ: All channel mode bits not defined in this protocol are reserved - for future expansion and MUST NOT be used by any client or - server. (3.3.3) - REQ: If any mode change in a mode change request is disallowed, the - entire mode change request MUST be discarded. (3.3.3) - REQ: A server MUST NOT permit topic changes by unprivileged clients - not in the channel, and MUST NOT permit topic changes by - unprivileged clients in the channel iff the CMODE_TOPIC_OPS flag - is set. (3.3.4) - REQ: The sender of a channel operator, channel voice, kick, channel - ban add, channel ban remove, or invite message MUST be a channel - operator. (3.3.5, 3.3.6, 3.3.7, 3.3.8) - REQ: For the channel ban list message, the server MUST send exactly - one ban per response message. (3.3.8) - REQ: For the channel ban add and remove messages, at least one string - MUST be given. (3.3.8) - REQ: Client control messages MUST be forwarded except as specified. - (3.4) - REQ: A client receiving a nick message for itself MUST change its - nickname to that specified in the message. (3.4.1) - REQ: A server generating a nick message for a client MUST forward the - message to all other servers. (3.4.1) - REQ: Any client which sends a private message to a client marked away - MUST be sent an away message with the sender field set to the - nickname of the client to which the message was sent. (3.4.2) - REQ: Servers MUST NOT discard any messages sent to a client marked - away. (3.4.2) - REQ: If client B matches an entry on client A's silence list, then - any private messages or notices from client B to client A MUST - be discarded by both client B's server and client A's server, - and any other type of message or notice sent by client B which - client A would normally receive MUST NOT be sent to client A. - (3.4.3) - REQ: If a client attempts to set the UMODE_OPERATOR flag directly, - the server MUST return ERR_PERMISSION_DENIED and discard the - entire client mode message. (3.4.4) - REQ: Normal clients MUST NOT receive operator messages regardless of - the setting of the UMODE_OPER_MESSAGES mode. (3.4.4) - REQ: In the parameter for the UMODE_SERVER_NOTICES mode, a "1" bit - MUST indicate a request that messages of a particular type be - sent, and a "0" bit MUST indicate that messages of that type - should not be sent. (3.4.4) - REC: Clients SHOULD default to sending a parameter for the - UMODE_SERVER_NOTICES mode containing all bits set. (3.4.4) - REQ: Servers which limit the UMODE_SREVER_NOTICES mode to IRC - operators only MUST return ERR_PERMISSION_DENIED and discard the - entire mode message if sent from a non-privileged client, and - MUST unset the UMODE_SERVER_NOTICES mode whenever the - UMODE_OPERATOR mode is unset. (3.4.4) - REQ: Servers MUST NOT send the UMODE_SERVER_NOTICES mode when - reporting client modes to other servers. (3.4.4) - REQ: All user mode bits not defined in this protocol are reserved for - future expansion and MUST NOT be used by any client or server. - REQ: If any mode change in a mode change request is disallowed, the - entire mode change request MUST be discarded. - REQ: If the nickname parameter is included in an operator message, - the server MUST treat the request as if it had come from the - given nickname. (3.4.5) - REC: Servers SHOULD allow operator messages with nickname parameters - even if another client has gained operator privileges under the - same nickname. (3.4.5) - REQ: The operator message MUST NOT be forwarded; instead, a client - mode message MUST be generated which sets the UMODE_OPERATOR - flag and forwarded. The client mode message MUST also be sent - to the client. (3.4.5) - REQ: The server to which a client which is the target of a kill - message is connected MUST send the kill message to the client - and then immediately terminate the connection upon receipt of - this message. - REQ: Non-operator clients MUST NOT be permitted to use the kill, - server ban, or network ban messages. (3.4.6, 3.4.7, 3.4.8) - REQ: The server ban message MUST NOT be forwarded. - REQ: If a server receives a user message from another server for a - client whose username and hostname match a network ban, it MUST - issue a kill message for that client, generate a network ban - message from the banned username and hostname masks which the - client matched, and forward that message to all servers. - REQ: For server control messages, if a destination server is supplied - and the sender is an IRC operator, the message MUST be forwarded - to the destination server; otherwise, the message MUST NOT be - forwarded. (3.5) - REQ: The dest-server parameter for server control messages, if - supplied, MUST be a server name. (3.5) - REQ: Non-operator clients MUST NOT be permitted to use server control - commands. (3.5) - REC: The server-to-connect parameter for the connect message SHOULD - be a server name as given in the server registration message. - (3.5.1) - REQ: Upon receiving a connect message, a server MUST attempt to - establish a direct connection to the specified server if one - does not already exist. (3.5.1) - REQ: The server-to-disconnect parameter for the disconnect message - MUST be the name of a server. (3.5.2) - REQ: Upon receipt of a restart message, the server MUST terminate all - connections to it, clear all state information, and re-read any - configuration information. (3.5.4) - REQ: Upon receipt of a die message, the server MUST terminate all - connections to it and free all system resources it owns. (3.5.5) - REQ: Query messages MUST NOT be forwarded, except to the target - server (where appropriate). (3.6) - REQ: All bits in the who message reply status not specified are - reserved for future expansion and MUST NOT be used. (3.6.1) - REQ: All bits in the whois message reply status not specified are - reserved for future expansion and MUST NOT be used. (3.6.4) - REQ: If a server does not return any information for a whowas - message, it MUST send ERR_WAS_NO_SUCH_USER. (3.6.5) - REQ: The ison message MUST be parsed by the client's server and MUST - NOT be forwarded to any other server. (3.6.6) - REQ: An ERR_NAME_TOO_LONG reply MUST NOT be generated by the ison - message even if a nickname given in the list is longer than the - allowable length. (3.6.6) - REQ: The reply to the users message MUST include an appropriate - descriptive string. (3.6.7) - REQ: Servers MUST send an RPL_MOTD_END message after the last - RPL_MOTD message sent in reply to a Message of the Day message. - (3.6.8) - REQ: All RPL_MOTD replies to a Message of the Day message MUST - include strings. (3.6.8) - REQ: Servers MUST respond to an administrative information message - with at least one RPL_ADMININFO reply. (3.6.9) - REQ: All replies to the administrative information message MUST - include appropriate descriptive strings. (3.6.9) - REQ: Servers MUST respond to a server information message with at - least one RPL_SERVERINFO reply. (3.6.10) - REQ: All replies to the server information message MUST include - appropriate descriptive strings. (3.6.10) - REQ: Servers MUST respond to the server version message with - exactly one RPL_SERVERINFO reply, which MUST include an - appropriate descriptive string. (3.6.11) - REQ: The low 8 bits of the reply code sent for a statistics - message MUST be equal to the type value. (3.6.12) - REQ: All replies to the statistics message MUST include appropriate - descriptive strings. (3.6.12) - REQ: Servers MUST send one RPL_LINKS reply for each active connection - in response to a links message. (3.6.13) - REQ: All replies to the links message MUST include appropriate - descriptive strings. (3.6.13) - REQ: Any server receiving a trace message MUST send a RPL_TRACE reply - with an appropriate descriptive string back to the source. - (3.6.14) - REQ: A server receiving a trace message with a target of a client - connected to that server MUST send a RPL_TRACE reply on that - client's behalf. (3.6.14) - REQ: Servers MUST NOT send trace messages to clients. (3.6.14) - REQ: A client or server which receives a ping message MUST reply by - sending a pong message to the sender as soon as possible. - (3.7.1) - REQ: If the optional text parameter is included in the ping message, - an identical text parameter MUST be sent with the corresponding - pong message. (3.7.1) - REQ: Servers MUST NOT send (or forward) ping messages to clients - which are not directly connected to them. (3.7.1) - REQ: Servers and clients MUST NOT generate any messages or replies - upon receiving a pong message, with the exception that a server - MAY geneate server noticecs indicating the status of a - particular link. (3.7.2) - REQ: Clients and servers MUST NOT generate messages with reserved - command codes, and MUST discard any such message received. (3.8) - REQ: If a server does not reject a message with an invalid channel - name, it MUST continue processing the message normally without - altering the channel name. - REQ: If a server does not reject a message with an over-long name, it - MUST truncate that name to the maximum allowable length and - continue processing the message normally. (3.9) - REQ: All syntactic errors other than ERR_NAME_TOO_LONG MUST be - generated as soon as the corresponding condition occurs, and the - server generating the error MUST discard the message. - REQ: If a client sends any message other than the password message - before sending a registration message, the server receiving the - message MUST discard it and generate an ERR_NOT_REGISTERED - reply. (3.9) - REQ: Implementors who create new messages SHOULD select new message - numbers by adding 8000 hexadecimal to an existing message - number. (3.10) - REQ: A client which sends an experimental message code and receives - an ERR_UNKNOWN_COMMAND response MUST resend the message - according to the protocol defined in this document when - possible. (3.10) - REQ: Implementors MUST ensure that, regardless of any modifications - or enhancements made to this protocol, the messages specified in - section 3 function exactly as described when used in the manner - described. - -C.7 Replies - - REQ: All reply codes not listed in section 4 are reserved for future - expansion of the IRC protocol, and servers MUST NOT generate any - such replies. (4.3) - -C.8 Collisions - - REQ: If a server receives a client registration or nickname change - message from another server, and the nickname for the new - client matches the nickname of a client already present on the - IRC network, the server receiving the colliding message MUST - remove from its internal list of nicknames whichever has the - more recent nickname change time. If that client is directly - connected to the server, then the server MUST terminate the - connection with an appropriate quit message. (5.2.1) - REQ: If a server receives a server registration message from another - (already-connected) server, and either the name or the ID number - (but not both) match those of another server present on the - network, the server receiving the message MUST issue a - server-quit message for the ID number(s) of both servers. - (5.2.2) - REC: Servers SHOULD NOT issue a server-quit message for the forwarder - of a colliding server message. (5.2.2) - REQ: When a server receives a channel mode message or join message - from another server, it MUST act on that message regardless of - any other state information. - -C.9 Other requirements - - REC: Servers SHOULD NOT use the Ident Protocol for any purpose - directly related to the implementation of this protocol, - including but not limited to access control decisions. (3.1.2.1) - REC: Servers SHOULD send a ping message immediately upon registration - of a connection, including in the message one parameter - containing a randomly generated series of octets. (6.1) - REQ: Servers which implement the anti-IP-spoofing method described in - section 6.1 MUST discard all messages from the remote end of the - connection without processing them until either the remote end - replies with a pong message containing the same string or the - ping timeout period expires. (6.1) - REC: Servers SHOULD follow the procedure described in section 6.2 for - determining the hostname of a remote connection. (6.2) - REQ: Servers using the procedure described in section 6.2 MUST use - the remote host's raw address for the remote hostname. (6.2) - REC: Servers SHOULD NOT close the connection on a lookup failure or - mismatch, but SHOULD generate some sort of warning for such an - occurrance. (6.2) - - -Appendix D. Conversion table for the RFC 1459 protocol +Appendix C. Conversion table for the RFC 1459 protocol This table lists the commands defined in RFC 1459 and their equivalent message codes in the protocol defined by this document, @@ -4443,7 +3955,7 @@ in this document for details on how to translate messages. | RFC 1459 | | | - | Command | New Command | Notes | + | Command | New Msg. Code | Notes | +----------+----------------+-------+ | ADMIN | 0x0508 | | | AWAY | 0x0301 | | @@ -4453,20 +3965,20 @@ | INFO | 0x0509 | | | INVITE | 0x0208 | | | ISON | 0x0505 | | - | JOIN | 0x0200,0x0280 | E | + | JOIN | 0x0200,0x0280 | A | | KICK | 0x0206 | | | KILL | 0x0305 | | | LINKS | 0x050C,0x058C | | | LIST | 0x0502 | | | LUSERS | 0x0506 | | - | MODE | 0x0303,0x0202, | C | + | MODE | 0x0303,0x0202, | B | | | 0x0204,0x0284, | | | | 0x0205,0x0285, | | | | 0x0207,0x0247, | | | | 0x0287 | | | MOTD | 0x0507 | | | NAMES | 0x0501 | | - | NICK | 0x0300 | A | + | NICK | 0x0300 | C | | NOTICE | 0x0102,0x0103, | D | | | 0x0104,0x0106 | | | OPER | 0x0304 | | @@ -4482,28 +3994,28 @@ | SERVER | 0x0002 | | | SQUIT | 0x0005,0x0401 | | | STATS | 0x050B | | - | SUMMON | (none) | | + | SUMMON | (none) | E | | TIME | 0x050E | | | TOPIC | 0x0203 | | | TRACE | 0x050D | | - | USER | 0x0001 | B | - | USERS | (none) | | + | USER | 0x0001 | F | + | USERS | (none) | E | | VERSION | 0x050A | | | WALLOPS | 0x0105 | | | WHO | 0x0500 | | | WHOIS | 0x0503 | | | WHOWAS | 0x0504 | | - *E: JOIN 0 (leave all channels) is not supported. + *A: JOIN 0 (leave all channels) is not supported. - *C: MODE command summary: + *B: MODE command summary: 0x0303 = MODE for a client 0x0202 = MODE for a channel (except o/v/b) 0x0204,0x0284 = MODE +o/-o for a channel 0x0205,0x0285 = MODE +v/-v for a channel 0x0207,0x0247,0x0287 = MODE +b/-b for a channel (0x0247=list) - *A: For the NICK command used to change a client's nickname. When + *C: For the NICK command used to change a client's nickname. When used at registration time, there is no equivalent; see the USER command. @@ -4511,5 +4023,11 @@ messages/notices to a channel (public) and messages/notices to a client (private). - *B: When registering, the nickname (formerly from the NICK command) + *E: The SUMMON and USERS commands were deliberately left out of this + protocol definition, as their functionality is considered + unrelated to the IRC protocol and better left to other protocols + (e.g. E-mail or finger). The author has never seen an IRC server + with these commands enabled. + + *F: When registering, the nickname (formerly from the NICK command) is included in the user registration message.