--- irc3-20010711.txt Wed Jul 11 23:49:57 2001 +++ irc3-20011015.txt Tue Oct 16 17:00:14 2001 @@ -1,5 +1,5 @@ Network Working Group A. Church -Request For Comments: nnnn July, 2001 +Request For Comments: nnnn October, 2001 Obsoletes: 1459 Category: Experimental @@ -29,7 +29,7 @@ extensible standard be defined to alleviate these incompatibilities. This protocol was given the name "version 3" due to the reference - RFC1459 implementation being known as "irc2". + RFC1459 implementation being known as "ircII" (IRC 2). Table of Contents @@ -59,7 +59,8 @@ 2.2.3 Replies 2.2.4 Acknowledgements and acknowledgement requests 2.3 Summary of message flag bits - 2.4 Time values + 2.4 Timestamps + 2.5 Text transmission 3. Message details 3.1 Connection registration and cancellation 3.1.1 Password message @@ -434,19 +435,19 @@ 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. + Currently, there is a movement to establish a wide-character + 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 @@ -1087,13 +1088,13 @@ 2.4 Timestamps - A number of messages require timestamps to be sent. All servers on - a network MUST assign the same meaning to this time value; servers - SHOULD use the current de-facto standard (seconds since 1 January - 1970 00:00 GMT, used in most if not all current IRC servers and also - the return value of the standard Unix time(2) system call), to - reduce difficulties for clients in determining what timestamp system - is in use. + A number of messages require timestamps (numerical values indicating + a particular instant int time) to be sent. All servers on a network + MUST assign the same meaning to this time value; servers SHOULD use + the current de-facto standard (seconds since 1 January 1970 00:00 + GMT, used in most if not all current IRC servers and also the return + value of the standard Unix time(2) system call), to reduce + for clients in determining what timestamp system is in use. Since servers that use the time system described above will run into problems beginning in January 2038 if a 32-bit signed integer is @@ -1108,6 +1109,37 @@ (particularly in response to query messages; see section 3.6) MUST be prepared to handle values outside the range of a 32-bit integer. +2.5 Text transmission + + There are many different computer systems in use on the Internet, + often with differing methods of encoding text. While resolving the + problems associated with differing character sets (such as the + ISO-8859 sets, 16-bit Asian character sets, and Unicode) is outside + the scope of this document, in order to avoid certain difficulties + between operating systems, this document makes the following + requirements: + + * Clients and servers SHOULD send only one line of text per string + parameter. When sending multiple lines in a single string, clients + and servers MUST use the single character 0x0A (ASCII LF) to + separate individual lines (this character is not required after the + last line). Here, "character" refers to the smallest unit of + storage which can represent a character; this is typically an + octet, but in some systems may be two or more octets. + + Note: The author is aware that the two-character sequence 0x0D 0x0A + (ASCII CR, LF) is in common use in other Internet protocols, + but does not see the need to use two octets for a single + terminator. Furthermore, 0x0A alone is already used as a + line terminator in many existing systems. + + * Clients and servers SHOULD NOT use the character 0xA0 as a + substitute for the ASCII space character (0x20). Some systems use + the 0xA0 character to indicate a "non-breaking space", i.e. a space + character at which a line of text cannot be wrapped, but that + character may be displayed differently on different systems; the + author himself has experienced this problem on many occasions. + 3. MESSAGE DETAILS @@ -2621,7 +2653,8 @@ Code: 0x0500 Parameters: who (string), [target-server (string)] nickname (string), status (bits-16), - userhost (addr-string), name (string) + userhost (addr-string), real-name (string), + servername (string), [extra (string)] bits-16 = shortint @@ -2632,26 +2665,38 @@ for each match) with the same message code and the following parameters: - nickname: The nickname of the client. - status: A 16-bit word with bits set as follows: - Bit 3: 1 if the client has UMODE_INVISIBLE set (see - section 3.4.4). - Bit 2: 1 if the client is marked away (see section - 3.4.2). - Bit 1: 1 if the client is a channel operator on at - least one channel. - Bit 0: 1 if the client is an IRC operator. - userhost: The address of the client in "user@host" format. - name: The name provided by the client. + nickname: The nickname of the client. + status: A 16-bit word with bits set as follows: + Bit 3: 1 if the client has UMODE_INVISIBLE set (see + section 3.4.4). + Bit 2: 1 if the client is marked away (see section + 3.4.2). + Bit 1: 1 if the client is a channel operator on at + least one channel. + Bit 0: 1 if the client is an IRC operator. + userhost: The address of the client in "user@host" format. + real-name: The "real name" provided by the client. + servername: The name of the server to which the client is + connected. + extra: Any other information on the client (format is + implementation- and server-dependent). The upper four bits of the status parameter are reserved for experimental and/or local use. All other bits are reserved for future expansion of the protocol and MUST NOT be used by any client or server. - If there are no matches, nothing is returned by the server. Clients - with UMODE_INVISIBLE set do not match any string (even one without - wildcards) unless the sender is an IRC operator. + Clients with UMODE_INVISIBLE set do not match any string (even one + without wildcards) unless the sender is an IRC operator, in which + case they match as normal clients do. + + Servers MUST send a RPL_WHO_END reply after the last response + message. This reply is sent even when no response messages are + generated (i.e. no clients match the given wildcard). + + If a target-server parameter is provided, the message MUST be + forwarded to the given server, which will then respond from its point + of view. Examples: @@ -2664,7 +2709,7 @@ Replies: - ERR_NEED_MORE_PARAMS + ERR_NEED_MORE_PARAMS RPL_WHO_END 3.6.2 Names message @@ -2693,6 +2738,9 @@ not returned unless the preceding condition is satisfied and the client is in the channel. + Servers MUST return a RPL_NAMES_END reply after all responses (if + any) have been sent. + Examples: CS: 0x0501 "#dragon*" @@ -2707,7 +2755,7 @@ Replies: - ERR_NEED_MORE_PARAMS + ERR_NEED_MORE_PARAMS RPL_NAMES_END ERR_NAME_TOO_LONG ERR_INVALID_NAME @@ -2719,14 +2767,18 @@ topic (string) Requests information on any channels matching the given channel - string, which may contain wildcards. The clients parameter is set to - the total number of clients (including clients with UMODE_INVISIBLE - set; see section 3.4.4) in the channel, and the topic parameter is - set to the channel's current topic. Private channels (channels with - CMODE_PRIVATE set; see section 3.3.3) are not listed unless the given - string is an exact (case-insensitive) match for the channel name; - secret channels are not listed unless the preceding condition is - satisfied and the client is in the channel. + string, which may contain wildcards. In responses, the clients + parameter is set to the total number of clients (including clients + with UMODE_INVISIBLE set; see section 3.4.4) in the channel, and the + topic parameter is set to the channel's current topic. Private + channels (channels with CMODE_PRIVATE set; see section 3.3.3) are not + listed unless the given string is an exact (case-insensitive) match + for the channel name; secret channels are not listed unless the + preceding condition is satisfied and the client is in the channel. + + One response message is sent for each channel matching the query; + after all responses have been sent, a RPL_LIST_END reply is sent + indicating the end of the list. Examples: @@ -2735,7 +2787,7 @@ Replies: - ERR_NEED_MORE_PARAMS + ERR_NEED_MORE_PARAMS RPL_LIST_END ERR_NAME_TOO_LONG ERR_INVALID_NAME @@ -2757,8 +2809,7 @@ servername: The name of the server the client is connected to. serverdesc: The description of the server the client is connected to. - signon: Time in seconds since 1 January 1970 00:00 UTC when - the client connected to its server. + signon: Time when the client connected to its server. idle: Time in seconds since the client last send a public or private message (see sections 3.2.1 and 3.2.2). If the client is not directly connected to the @@ -2792,22 +2843,21 @@ Code: 0x0504 Parameters: nickname, [target-server (string)] nickname (string), userhost (string), - name (string), servername (string), + real-name (string), servername (string), signoff (timestamp) - Requests information on previous users of a nickname. One reply is - returned for each user, starting from the most recent. The number - of replies returned is implementation-dependent; however, if a server - does not return any information, it MUST send ERR_WAS_NO_SUCH_USER. + Requests information on previous users of a nickname. One response + message is returned for each user, starting from the most recent. + The number of responses returned is implementation-dependent; + however, a RPL_WHOWAS_END reply MUST be sent after the last response. The values of the parameters in the reply are: nickname: Nickname of the client, as sent in the query. userhost: Address of the client, in "user@host" format. - name: Name given by the client at registration time. + real-name: "Real name" given by the client at registration time. servername: The name of the server the client was connected to. - signoff: Time in seconds since 1 January 1970 00:00 UTC when - the client disconnected from its server. + signoff: Time when the client disconnected from its server. This command MAY be unimplemented. @@ -2820,10 +2870,9 @@ Replies: - ERR_NOT_IMPLEMENTED + ERR_NOT_IMPLEMENTED RPL_WHOWAS_END ERR_NEED_MORE_PARAMS ERR_NAME_TOO_LONG - ERR_WAS_NO_SUCH_USER 3.6.6 Ison message @@ -2897,21 +2946,21 @@ Replies: - ERR_NOT_IMPLEMENTED RPL_USERS + ERR_NOT_IMPLEMENTED RPL_USERS_END ERR_NAME_TOO_LONG 3.6.8 Message of the Day message Code: 0x0507 - Parameters: [server (string)] + Parameters: [server (string)] + text (string) Requests the "Message of the Day" from the client's server or the - specified server. The text of this message is server-dependent; - the server MAY either send a single RPL_MOTD reply with the entire - text or split the text into multiple RPL_MOTD replies. In either - case, the server MUST send an RPL_MOTD_END reply after the last - RPL_MOTD reply. All RPL_MOTD replies to this message MUST include - strings. + specified server. The text of this message is server-dependent. + The server MAY either send a single response with the entire text or + split the text into multiple responses (for example, one response + per line); in either case, the server MUST send a RPL_MOTD_END reply + after the last response. Examples: @@ -2919,89 +2968,100 @@ A client requests the Message of the Day from the server to which it is connected. + SC: 0x0507 "This is the Message of the Day." + The server responds with its Message of the Day. + CS: 0x0507 "dragonfire.esper.net" A client requests the Message of the Day from the server "dragonfire.esper.net". Replies: - ERR_NAME_TOO_LONG RPL_MOTD - RPL_MOTD_END + ERR_NAME_TOO_LONG RPL_MOTD_END 3.6.9 Administrative information message Code: 0x0508 - Parameters: [server (string)] + Parameters: [server (string)] + text (string) Requests administrative information from the client's server or the - specified server. The server MUST respond with at least one - RPL_ADMININFO reply, though it MAY send more. All replies to this - message MUST include appropriate descriptive strings. The format of - the reply is implementation- and server-dependent. + specified server. The server MUST respond with at least one message, + though it MAY send more. The server MUST sent a RPL_ADMININFO_END + reply after the last response message. The format of the response + text is implementation- and server-dependent. Examples: See section 3.6.8. Replies: - ERR_NAME_TOO_LONG RPL_ADMININFO + ERR_NAME_TOO_LONG RPL_ADMININFO_END 3.6.10 Server information message Code: 0x0509 - Parameters: [server (string)] + Parameters: [server (string)] + text (string) Requests information about the client's server or the specified - server. The server MUST respond with at least one RPL_SERVERINFO - reply, though it MAY send more. All replies to this message MUST - include appropriate descriptive strings. The format of the reply is + server. The server MUST respond with at least one message, though it + MAY send more. The server MUST sent a RPL_SERVERINFO_END reply after + the last response message. The format of the response text is implementation- and server-dependent. Examples: See section 3.6.8. Replies: - ERR_NAME_TOO_LONG RPL_SERVERINFO + ERR_NAME_TOO_LONG RPL_SERVERINFO_END 3.6.11 Server version message Code: 0x050A - Parameters: [server (string)] + Parameters: [server (string)] + version (string), [extra (string)] Requests version information for the client's server or the specified - server. The server MUST respond with exactly one RPL_SERVERVERSION - reply, which MUST include an appropriate descriptive string. The - reply string MUST begin with a version number or identifier followed - by a space character (ASCII 0x20); the format of the version number - and the remainder of the reply string is implementation- and - server-dependent, with the exception that the version number or - identifier MUST NOT include the space character. + server. In the response, the version parameter MUST contain a string + giving only the server's version number; any additional information, + such as the software build date, should be included in the second + parameter (extra). - Examples: See section 3.6.8. + Examples: + + SC: 0x050A "1.3.10" "build 159, compiled Oct 31 1999" + A server replies with its version information to a client. Replies: - ERR_NAME_TOO_LONG RPL_SERVERVERSION + ERR_NAME_TOO_LONG 3.6.12 Statistics message Code: 0x050B - Parameters: type (byte), [server (string)] + Parameters: type (byte), [server (string)] + type (byte), text (string) ... byte = octet Requests server statistics of the given type from the client's server - or the named server. The low 8 bits of the reply code sent MUST be - equal to the type value. All replies to this message MUST include - appropriate descriptive strings, with the exception that servers MUST - send a reply with no string after processing a request to signal the - end of information. A server MUST generate ERR_BAD_STATS_TYPE_* - (with the low 8 bits of the reply code equal to the type value) if it - is not prepared to handle a given type request. + or the named server. The server responds with zero or more messages + using the same code and the same value for the type parameter, + followed by a RPL_STATS_*_END message in which the 8 bits of the + reply code sent are equal to the type value. However, a server MUST + generate ERR_BAD_STATS_TYPE_* (with the low 8 bits of the reply code + equal to the type value) if it is not prepared to handle a given type + request. + + The actual statistics information is included in the text parameter + or parameters. All parameters (other than the first parameter, type) + MUST be strings; numeric information SHOULD be encoded in a + human-readable format, such as decimal or hexadecimal values. Servers MAY limit all or some type requests to operators only. Servers MAY generate ERR_BAD_STATS_TYPE_* instead of ERR_PERMISSION_DENIED when denying a particular request type, but - SHOULD generate ERR_PERMISSION_DENIED if all requests are denied to + SHOULD generate ERR_PERMISSION_DENIED if all types are denied to unprivileged users. For the purpose of this protocol, the meaning of the type parameter @@ -3012,20 +3072,18 @@ requests. For implementations supporting these requests as described, replies are defined to have the following format: - * All items listed MUST be sent in the order listed, MUST separated - by a single space character (ASCII 0x20), and MUST NOT contain the - space character except as described. - * Any reply MAY contain additional information after the required - information, but such additional information MUST be preceded by - the space character. + * All items listed MUST be sent in the order listed. Additional + items MAY be appended after the required information. * The format of remote addresses in statistics information is implementation- and server-dependent, but addresses MUST NOT contain the comma character (ASCII 0x2C). * All numeric values MUST be represented as decimal values using the characters "0" through "9" (ASCII 0x30 through 0x39), except where otherwise specified; hexadecimal values MUST be represented using - the characters "0" through "9" and "A" through "F" (ASCII 0x30 - through 0x39 and 0x41 through 0x46). + the characters "0" through "9", "A" through "F", and "a" through + "f" (ASCII 0x30 through 0x39, 0x41 through 0x46, and 0x61 through + 0x66). Implementations SHOULD consistently use either upper case + or lower case letters for all hexadecimal values in responses. * For requests on connection restrictions and bans, rules MUST be listed in the order in which they are applied. @@ -3119,7 +3177,7 @@ Replies: - ERR_NEED_MORE_PARAMS RPL_STATS_* + ERR_NEED_MORE_PARAMS RPL_STATS_*_END ERR_NAME_TOO_LONG ERR_PERMISSION_DENIED ERR_BAD_STATS_TYPE_* @@ -3127,58 +3185,67 @@ 3.6.13 Links message Code: 0x050C (servers only), 0x058C (all connections) - Parameters: [server (string)] + Parameters: [server (string)] + type (octet), established (timestamp), + active (timestamp), writebuf (longint), + readbuf(longint), ipaddr (string), + hostname (string), username (string), + [extra (string)] Requests information on active connections for the client's server or the specified server. If the sender is an IRC operator or another server and the message code is 0x058C, information on all connections is sent; otherwise, only information on server connections is sent. - The server MUST send one RPL_LINKS reply for each active connection, - and MAY send zero or more RPL_LINKS_EXTRA replies for additional - information; any RPL_LINKS_EXTRA replies for a connection MUST be - sent immediately after the RPL_LINKS reply for that connection and - before any other replies are sent. All replies to this message MUST - include appropriate descriptive strings. - - RPL_LINKS replies MUST contain the following information in the order - given, with all items separated by a single space character (ASCII - 0x20). Numeric items MUST be sent using the characters "0" through - "9" (ASCII 0x30 through 0x39). Items MUST NOT contain the space - character unless explicitly permitted in the description of the item. - - One character representing the connection type: "S" for a server - on the same network, "B" for a border server of another network, - "O" for an IRC operator, "C" for a non-IRC-operator client, or "?" - for a connection which has not yet registered. Servers MAY send - other characters to indicate special types of connections, and MAY - use the space character. - - The timestamp when the connection was established. - - The timestamp when data was most recently received from the remote - end of the connection. - - The number of octets of data which have been scheduled to be sent - to the remote host but have not yet been passed to the transport - layer (i.e. write buffer length). - - The number of octets of data which have been received from the - remote host but not yet processed by the server (i.e. read buffer - length). - - The raw address of the remote host (dotted-quad format, e.g. - 123.45.67.89, for IPv4). - - The hostname as determined by the server (which may be the same as - the raw address; see section 6.2). + The server MUST respond with the same message code as was used in the + request. A RPL_LINKS_END is sent after all responses have been sent. - The username iff the connection is a client. + The parameters are as follows: - Any other information considered relevant. This item MAY include - the space character. - - The format of the RPL_LINKS_EXTRA replies are implementation- and - server-dependent. + * type + One character (octet) representing the connection type: "S" + (ASCII 0x53) for a server on the same network, "B" (ASCII 0x42) + for a border server of another network, "O" (ASCII 0x4F) for an + IRC operator, "C" (ASCII 0x42) for a non-IRC-operator client, or + "?" (ASCII 0x3F) for a connection which has not yet registered. + Servers MAY use other values to indicate special types of + connections, but SHOULD restrict those values to values which + are printable as characters in ASCII. + + * established + The timestamp when the connection was established. + + * active + The timestamp when data was most recently received from the + remote end of the connection. + + * writebuf + The number of octets of data which have been scheduled to be + sent to the remote host but have not yet been passed to the + transport layer (i.e. write buffer length). If the + implementation does not support a write buffer, this value is + zero. + + * readbuf + The number of octets of data which have been received from the + remote host but not yet processed by the server (i.e. read + buffer length). If the implementation does not support a read + buffer, this value is zero. + + * ipaddr + The raw address of the remote host (dotted-quad format, e.g. + 123.45.67.89, for IPv4). + + * hostname + The hostname as determined by the server (which may be the same as + the raw address; see section 6.2). + + * username + If the connection is a client, the client's username, otherwise + an empty string. + + * extra + Any other information considered relevant. The format of this + information is implementation- and server-dependent. Servers MAY limit the use of this command to IRC operators, or MAY limit the information returned to non-operator clients. @@ -3187,28 +3254,35 @@ Replies: - ERR_NAME_TOO_LONG RPL_LINKS - ERR_PERMISSION_DENIED RPL_LINKS_EXTRA + ERR_NAME_TOO_LONG RPL_LINKS_END + ERR_PERMISSION_DENIED 3.6.14 Trace message Code: 0x050D (server), 0x058D (client) - Parameters: target (string) + Parameters: target (string) + [text (string)] Requests information on the route through the IRC network to a particular target (which may be a client nickname or a server name). - Any server receiving this message MUST send a RPL_TRACE reply with an - appropriate descriptive string back to the source. Furthermore, 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. - Servers MUST NOT send trace messages to clients. The format of the - replies are implementation- and server-dependent. + Any server receiving this message which is not the target (including + the server to which a target client is connected) MUST send a + RPL_TRACE reply back to the source. The target server (in the case + of a client target, the server to which the client is connected) + sends a response using the same message code as the original request + used; in the case of a client target, this response MUST be sent + after the RPL_TRACE reply from the server itself. Servers MUST NOT + send trace messages to clients. + + The format of any text message included with either the RPL_TRACE + reply or the message response is implementation- and + server-dependent. Servers MAY limit the use of this command to IRC operators. Examples: - CS: 0x058D "dragonfire.esper.net" + CS: 0x050D "dragonfire.esper.net" A client requests information on the route to the server "dragonfire.esper.net". @@ -3221,18 +3295,19 @@ 3.6.15 Time message Code: 0x050E - Parameters: [server (string)] + Parameters: [server (string)] + time (timestamp) - Requests the server's current time. The server MUST send a RPL_TIME - reply with a descriptive string containing only the server's idea of - the current time expressed as a timestamp, represented in decimal - using the characters "0" through "9" (ASCII 0x30 through 0x39). + Requests the server's current time. The server MUST send a response + containing the server's idea of the current time. (This need not be + the same as, for example, the current time returned by the system on + which the server is running; servers may have a method, not defined + in this protocol, to synchronize their clocks with each other or + otherwise adjust their idea of the current time.) Examples: See section 3.6.8. - Replies: - - RPL_TIME + Replies: None. 3.7 Miscellaneous messages @@ -3245,7 +3320,7 @@ The ping message is designed to test the integrity of a client or server connection. A client or server which receives a ping message - MUST reply by sending a pong message (see section 3.7.3) to the + MUST reply by sending a pong message (see section 3.7.2) to the sender as soon as possible. If the optional text parameter is included in the ping message, an identical text parameter MUST be sent with the corresponding pong message. @@ -3435,35 +3510,42 @@ 0x0121 RPL_SILENCE_DEL Sent to confirm deletion of a mask $Bw=(B the client's silence list. - 0x0200 RPL_USERS + 0x0200 RPL_WHO_END + Sent in response to a who message (see section 3.6.1). + + 0x0201 RPL_NAMES_END + Sent in response to a names message (see section 3.6.2). + + 0x0202 RPL_LIST_END + Sent in response to a list message (see section 3.6.3). + + 0x0204 RPL_WHOWAS_END + Sent in response to a whowas message (see section 3.6.5). + + 0x0206 RPL_USERS_END Sent in response to a users message (see section 3.6.7). - 0x0210 RPL_MOTD - 0x0211 RPL_MOTD_END + 0x0207 RPL_MOTD_END Sent in response to a Message of the Day request (see section 3.6.8). - 0x0220 RPL_ADMININFO + 0x0208 RPL_ADMININFO_END Sent in response to an administrative information request (see section 3.6.9). - 0x0230 RPL_SERVERINFO + 0x0209 RPL_SERVERINFO_END Sent in response to a server information request (see section 3.6.10). - 0x0240 RPL_SERVERVERSION - Sent in response to a server version request (see section 3.6.11). - - 0x0250 RPL_LINKS - 0x0251 RPL_LINKS_EXTRA + 0x020C RPL_LINKS_END Sent in response to a links request (see section 3.6.13). - 0x0260 RPL_TRACE + 0x02FF RPL_TRACE Sent in response to a trace request (see section 3.6.14). - 0x0300 RPL_STATS_00 + 0x0300 RPL_STATS_00_END through - 0x03FF RPL_STATS_FF + 0x03FF RPL_STATS_FF_END Sent in response to statistics requests (see section 3.6.12). 4.2 Error messages @@ -4104,7 +4186,7 @@ | AWAY | 0x0301 | | | CONNECT | 0x0400 | | | DIE | 0x0404 | | - | ERROR | (none) | | + | ERROR | (none) | G | | INFO | 0x0509 | | | INVITE | 0x0208 | | | ISON | 0x0505 | | @@ -4175,3 +4257,6 @@ *F: When registering, the nickname (formerly from the NICK command) is included in the user registration message. + + *G: Connection errors are signalled through standard replies, as with + errors from other commands.