--- irc3-19990825.txt Wed Aug 25 23:05:11 1999 +++ irc3-19990929.txt Wed Sep 29 22:57:55 1999 @@ -1,5 +1,5 @@ Network Working Group A. Church -Request For Comments: nnnn August, 1999 +Request For Comments: nnnn September, 1999 Obsoletes: 1459 Category: Experimental @@ -15,18 +15,21 @@ Abstract Internet Relay Chat (IRC) is a client/server protocol allowing - Internet users to engage in realtime textual "conversation". It has - existed for a number of years, and the use of IRC has grown rapidly - during that time. IRC has classically been a purely text-based - protocol, as described in RFC 1459 [1]; however, current usage and - trends demand a more efficient method for allowing IRC servers to - communicate with each other than defined by the original protocol, as - well as more stability than that protocol allows. In addition, as - bandwidth availability increases, IRC should be extensible enough to - allow other forms of communication, such as audio and/or video. - Finally, the wide range of incompatible changes made to the protocol - suggest that a new, extensible standard be defined to alleviate these - incompatibilities. + Internet users to engage in realtime "conversation". It has existed + for a number of years, and the use of IRC has grown rapidly during + that time. IRC has classically been a purely text-based protocol + allowing for simple text-based interaction, as described in RFC 1459 + [1]; however, current usage and trends demand a more efficient method + for allowing IRC servers to communicate with each other than defined + by the original protocol, as well as more stability than that + protocol allows. In addition, as bandwidth availability increases, + IRC should be extensible enough to allow other forms of + communication, such as audio and/or video. Finally, the wide range + of incompatible changes made to the protocol suggest that a new, + 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". Table of Contents @@ -111,6 +114,7 @@ 3.6.12 Statistics message 3.6.13 Links message 3.6.14 Trace message + 3.6.15 Time message 3.7 Miscellaneous messages 3.7.1 Ping message 3.7.2 Pong message @@ -152,6 +156,7 @@ C.7 Replies C.8 Collisions C.9 Other requirements + Appendix D: Conversion table for the RFC 1459 protocol 0. PREFACE @@ -159,9 +164,10 @@ 0.1 Acknowledgements The author wishes to acknowledge the assistance of Ian Justman and - Andrew Kempe for offering suggestions on this document. The author - also wishes to acknowledge an IRC protocol proposal by Steven Arnold - [2] for providing the idea for inter-network communication. + 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. 0.2 Terminology @@ -302,8 +308,8 @@ more than sufficient for the foreseeable future, the server ID value 65,535 (hexadecimal FFFF) is reserved for future use should the need arise. Servers MUST NOT use this value when registering, and a - server which receives a server registration message with this value - MUST reject it. + which receives a server registration message with this value MUST + reject it. 1.2 Clients @@ -920,7 +926,9 @@ believe this situation will ever occur in practice, since, among others, all state change messages (including client connections and disconnections and channel joins and parts) are transmitted to all - servers. + servers. Should this situation occur, it could be resolved by + breaking the connection between the two servers (if one existed) and + reestablishing it. Note also that this algorithm assumes that all data is transmitted in sequence along all paths. Without this assumption, it is possible @@ -1070,10 +1078,10 @@ generated by that message. A particular message may cause none, one, some, or all of those replies to be sent. Note that this list only includes server-to-client messages which fall under the "replies" - category (section 2.2.3); they do NOT include "command" messages + category (section 2.2.3); they do not include "command" messages (section 2.2.1) sent back to the client. The reply code - ERR_NOT_REGISTERED is NOT listed; see section 3.9 for conditions - under which it may be generated. + ERR_NOT_REGISTERED is not listed; see section 3.9 for conditions + under which it is to be generated. Where a description refers to "forwarding" a message received by a server and is not otherwise qualified, the term refers to the server @@ -1082,9 +1090,11 @@ message. In any message including a target, the message MUST be sent to that target as described under section 1.5 unless otherwise noted. - "Wildcards" in a string refer to the characters "*" (ASCII 0x2A) and - "?" (ASCII 0x3F). The former matches any sequence of zero or more - characters, and the latter matches exactly one character. + "Wildcards" in a string refer to the characters "*" (asterisk, ASCII + 0x2A) and "?" (question mark, ASCII 0x3F). The former matches any + sequence of zero or more characters, and the latter matches exactly + one character. These are the same meanings as used in many Unix + shells, VAX/VMS, and MS-DOS, among others. Except as otherwise specified, all implementations MUST implement the messages below with exactly the behavior listed. Message codes, @@ -1524,7 +1534,7 @@ Examples: SC: 0x0104 "Client exiting: Alcan (Leaving)" - The server reports a client's quitting. + The server reports a client's disconnecting. Replies: None. @@ -1549,7 +1559,7 @@ Examples: - CS: 0x0104 "Watch out for clones from lame.org." + CS: 0x0105 "Watch out for clones from lame.org." An IRC operator sends a message to all other online operators. Replies: @@ -1559,7 +1569,7 @@ 3.2.6 Global messages - Code: 0x0105 + Code: 0x0106 Parameters: message (string), [target-server (string)] Sends a string to all clients on a given server. If the @@ -1573,7 +1583,7 @@ Examples: - CS: 0x0105 "This server will be shutting down in 2 minutes." + CS: 0x0106 "This server will be shutting down in 2 minutes." "dragonfire.esper.net" An IRC operator sends a message to all clients on server dragonfire.esper.net. @@ -1915,6 +1925,9 @@ Examples: CS: 0x0206 "#dragonweyr" "Flooding is not permitted." "LaMeR" + Forcibly removes the client with the nickname "LaMeR" from + channel #dragonweyr with the reason "Flooding is not + permitted." Replies: @@ -2036,10 +2049,11 @@ SC: 0x0301 "Alcan" "Getting food" A client tried to send a private message to Alcan, who was - marked away. + marked away, and the server responded with Alcan's current + away message. CS: 0x0301 - The client marks itself as no longer away. + A client marks itself as no longer away. Replies: @@ -2240,7 +2254,7 @@ Examples: CS: 0x0305 "lamer" "Flooding is not permitted" - Removes the client with nickname "lamer" from the network for + Removes the client with nickname "lamer" from the network with the reason "Flooding is not permitted". Replies: @@ -2377,6 +2391,10 @@ Examples: + CS: 0x0401 "weyr.esper.net" + A client instructs its server to disconnect the server named + "weyr.esper.net". + Replies: ERR_NEED_MORE_PARAMS @@ -2397,8 +2415,6 @@ This command MAY be unimplemented, or MAY be implemented for use by directly connected clients only. - Examples: - Replies: ERR_NOT_IMPLEMENTED @@ -2418,8 +2434,6 @@ This command MAY be unimplemented, or MAY be implemented for use by directly connected clients only. - Examples: - Replies: ERR_NOT_IMPLEMENTED @@ -2439,8 +2453,6 @@ This command MAY be unimplemented, or MAY be implemented for use by directly connected clients only. - Examples: - Replies: ERR_NOT_IMPLEMENTED @@ -2576,7 +2588,8 @@ nickname (string), userhost (string), name (string), servername (string), serverdesc (string), signon (time), - idle (longint, status (bits-16), [away (string)] + idle (longint), status (bits-16), + [away (string)] Requests information on a particular client. The fields in the reply are as follows: @@ -2591,8 +2604,8 @@ idle: Time in seconds since the client last send a public or private message (see sections 3.2.1 and 3.2.2). status: A 16-bit word with bits set as follows: - Bit 1: 1 if the client is marked away. - Bit 0: 1 if the client is an IRC operator. + Bit 1: 1 iff the client is marked away. + Bit 0: 1 iff the client is an IRC operator. away: The client's away message (see section 3.4.2). Sent iff the client is marked away. @@ -2684,14 +2697,36 @@ 3.6.7 Users message Code: 0x0506 - Parameters: [server (string)] + Parameters: [server (string)] + clients (longint), channels (shortint), + servers (shortint), my-clients (shortint), + my-servers (shortint) Requests information on the number of clients connected to the IRC network and the client's server. If the server parameter is given, the message is forwarded to that server, which replies from its point - of view. The reply MUST include an appropriate descriptive string. - The format of the reply is implementation-dependent. This command - MAY be unimplemented. + of view. The server MUST send a users message back to the client + with the following numeric information: + clients : Number of clients connected to the network. + channels : Number of channels existing on the network. + servers : Number of servers connected to the network. + my-clients: Number of clients connected to the responding server. + my-servers: Number of servers connected to the responding server. + + In addition, the server MUST send one or more RPL_USERS replies to + the client. A server MAY send a single RPL_USERS with no descriptive + string, or MAY send one or more RPL_USERS replies with descriptive + strings included; in the latter case, the server SHOULD include in + the reply strings all information included in the numeric response, + and MAY include any other information considered relevant. + + If an interactive client receives a reply without a descriptive + string, it SHOULD display the information received from the server in + an appropriate format; otherwise, it SHOULD display only the text + included in the RPL_USERS replies and use the numeric responses for + updating internal information only. + + This command MAY be unimplemented. Examples: @@ -2771,11 +2806,14 @@ Code: 0x050A Parameters: [server (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 format of the reply is implementation- and - server-dependent. + 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. Examples: See section 3.6.8. @@ -2791,10 +2829,127 @@ byte = octet Requests server statistics of the given type from the client's server - or the named server. The meaning of the type value and the format of - responses are implementation-dependent; however, 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. + 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. + + 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 + unprivileged users. + + For the purpose of this protocol, the meaning of the type parameter + and the format of the replies are implementation- and + server-dependent. However, the following values of "type" are + recommended by this document; all implementations SHOULD support + these types when possible, to provide a common set of statistics + 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. + * The format of remote addresses in statistics information is + implementation- and server-dependent, but addresses MUST NOT + contain the comma character (ASCII 0x2C). + * Absolute time values MUST be given as the number of seconds since + 1 January 1970, 00:00 UTC. + * 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). + * For requests on connection restrictions and bans, rules MUST be + listed in the order in which they are applied. + + 0x61: Network ban information + Requests a list of active network bans, including: + * Remote address to which the ban applies. + * Username to which the ban applies (possibly including + wildcards). + * Nickname to which the ban applies (possibly including + wildcards). + * Absolute time at which the ban expires, or "0" if the + ban does not expire. + + 0x63: Server connection information + Requests a list of what servers the server will attempt to + connect to or allow to connect, including: + * The character "B" for a border server or "S" for a regular + server. + * Server name. + * Comma-separated list of remote addresses to which this + server will attempt to connect upon receiving a connect + message for the given server. + * Comma-separated list of remote addresses from which this + server will allow the given server to register itself. + * The character "*" if a password is required for + connection, "-" otherwise. + + 0x69: Client connection restrictions + Requests a list of restrictions upon client connections, + including: + * Comma-separated list of remote addresses to which this + rule applies. + * The character "*" if a client matching the rule is + required to enter a password, "-" otherwise. + + 0x6B: Server ban information + Requests a list of active server bans, including: + * Remote address to which the ban applies. + * Username to which the ban applies (possibly including + wildcards). + * Nickname to which the ban applies (possibly including + wildcards). + * Absolute time at which the ban expires, or "0" if the + ban does not expire. + + 0x6C: Active connection statistics + Requests information on all active connections, including: + * The character "B" if the connection is a border server, + "S" if it is a regular server, "C" if it is a client. + * Remote address. + * Total number of octets sent. + * Total number of messages sent. + * Total number of octets received. + * Total number of messages received. + * Absolute time at which the connection was established. + + 0x6D: Message statistics + Requests information on message use, including: + * Message code, represented as a 4-digit hexadecimal number. + * Number of times the message has been received. + * Total number of octets included in all received instances + of the message. + Servers MAY omit messages which have never been received. + + 0x6F: Operator restrictions + Requests information on restrictions on clients becoming IRC + operators, including: + * Remote addresses from which the client may become an + operator. + * Username under which the client may become an operator + (possibly including wildcards). + * Nickname under which the client may become an operator + (possibly including wildcards). + + 0x75: Server uptime + Requests information on how long the server has been active, + as well as the maximum number of connections reached, + including: + * Number of seconds since the server was started. + * Maximum number of connections. + * Number of clients connected when the maximum number of + connectoins was first reached. + Examples: @@ -2806,6 +2961,8 @@ ERR_NEED_MORE_PARAMS RPL_STATS_* ERR_NAME_TOO_LONG + ERR_PERMISSION_DENIED + ERR_BAD_STATS_TYPE_* 3.6.13 Links message @@ -2818,16 +2975,61 @@ 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. All replies to this message MUST include appropriate - descriptive strings. The format of the replies are implementation- - and server-dependent. + 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 time (in seconds since 1 January 1970 00:00 UTC) when the + connection was acknowledged by the server. + + The time (in seconds since 1 January 1970 00:00 UTC) 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 username iff the connection is a client. + + 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. + + Servers MAY limit the use of this command to IRC operators, or MAY + limit the information returned to non-operator clients. Examples: See section 3.6.8. Replies: ERR_NAME_TOO_LONG RPL_LINKS - RPL_LINKS_EXTRA + ERR_PERMISSION_DENIED RPL_LINKS_EXTRA 3.6.14 Trace message @@ -2843,6 +3045,8 @@ Servers MUST NOT send trace messages to clients. The format of the replies are implementation- and server-dependent. + Servers MAY limit the use of this command to IRC operators. + Examples: CS: 0x058D "dragonfire.esper.net" @@ -2853,6 +3057,24 @@ ERR_NEED_MORE_PARAMS RPL_TRACE ERR_NAME_TOO_LONG + ERR_PERMISSION_DENIED + +3.6.15 Time message + + Code: 0x050E + Parameters: [server (string)] + + 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 the number of seconds since 1 January + 1970, 00:00 UTC, represented in decimal using the characters "0" + through "9" (ASCII 0x30 through 0x39). + + Examples: See section 3.6.8. + + Replies: + + RPL_TIME 3.7 Miscellaneous messages @@ -2876,6 +3098,10 @@ should be sent to the named server. Only servers can be pinged by clients in this fashion; servers MUST NOT send (or forward) ping messages to clients which are not directly connected to them. + Clients may implement a protocol on top of the IRC protocol, using + the standard message and notice commands (section 3.2), to allow a + client to ping another client (CTCP [8] is an example of such a + protocol). Examples: @@ -3191,6 +3417,12 @@ A remote server registration message (see section 3.1.4) was sent which was rejected by the receiving server. + 0xC300 ERR_BAD_STATS_TYPE_00 + through + 0xC3FF ERR_BAD_STATS_TYPE_FF + Sent in response to statistics requests (see section 3.6.12) when + the server cannot handle the requested type. + 0xDFFE ERR_INTERNAL_ERROR An internal error prevented the server from carrying out a function. @@ -3310,8 +3542,8 @@ circumvent channel mode and ban restrictions, or including support for a special "network service" server which would have the ability to change channel modes on request by sufficiently privileged users - (Services for IRC Networks [8], developed by the author, is an - example of such a "network service" server). + (Services for IRC Networks [9], originally developed by the author of + this document, is an example of such a "network service" server). 5.3 Timekeeping @@ -3322,7 +3554,7 @@ closely synchronized as possible. A server with a clock which differs significantly from those of other servers may cause unexpected results if collisions occur. Therefore, servers SHOULD - use a method such as the Network Time Protocol [9] to keep their + use a method such as the Network Time Protocol [10] to keep their clocks synchronized. 5.4 Connection desynchronization @@ -3393,6 +3625,7 @@ before making use of any new routes, but this is only a kludge, not a solution. + One solution might be to have the server actually sending the message (i.e. forwarders too, not just originators) set the message sequence number field to its own next sequence number. @@ -3413,6 +3646,15 @@ solving this problem require sending information on _every_ server's last seen sequence number? + Note that we can't just rely on waiting for the last sequence + number plus one (or some other calculatable number), like we do + with TCP sequence numbers, because not all messages go to all + servers. We could supposedly have individual sequence numbers + from every server to every server; would this be feasible or + eat up a huge amount of memory and CPU time? I haven't given + this option much thought yet, so I'm not sure whether it's + workable. + When a server sends a message (whether generated or forwarded) to another server, it inserts itself at the head of the server hop list in the message. Servers never forward messages to servers @@ -3503,7 +3745,8 @@ current servers, such as that used on the DALnet (http://www.dal.net/) and UnderNet (http://www.undernet.org/) networks, but not present in the reference implementation or in - the protocol definition. + the protocol definition--note that the exact timestamp protocol + also varies (incompatibly) between servers. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. @@ -3517,10 +3760,12 @@ [7] St. Johns, M., "Identification Protocol", RFC 1413, February, 1993. - [8] http://achurch.org/services/ + [8] *** FIXME: Does anyone know of a good CTCP reference? - [9] Mills, David L., "Network Time Protocol (Version 3)", RFC 1305, - March, 1992. + [9] http://achurch.org/services/ + + [10] Mills, David L., "Network Time Protocol (Version 3)", RFC 1305, + March, 1992. 9. Copyright notice @@ -3534,15 +3779,14 @@ may be obtained. -A. Dijkstra's algorithm +Appendix A. Dijkstra's algorithm Dijkstra's algorithm is an algorithm for finding the shortest path from one node in a graph to one or all others. It involves keeping a table of parents (the "parent" of a node is defined to be the previous node on the shortest path to the node from the starting node), path lengths (the length of a path is simply the sum of the - weights of all edges on the path; for the purpose of this protocol, - all weights are defined to be 1), and "finished" flags, indicating + weights of all edges on the path), and "finished" flags, indicating whether the shortest path to the node has been definitively determined. @@ -3563,7 +3807,7 @@ -B. Alphabetical list of message and reply elements +Appendix B. Alphabetical list of message and reply elements addr-octet = @@ -4102,3 +4346,94 @@ 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 + + This table lists the commands defined in RFC 1459 and their + equivalent message codes in the protocol defined by this document, + and is intended as a guide to implementors who wish to include + support for RFC 1459 clients. Commands are listed in alphabetical + order. + + Note that there is not a one-to-one correspondence between commands; + some commands from RFC 1459 have different message codes depending on + the circumstances of use, and others have no equivalent. Also note + that even for commands which have a direct equivalent, the semantics + of the command in the new protocol may be different from the + semantics defined for the command in RFC 1459, and that many IRC + servers have defined their own semantics for some of these commands. + See the notes at the bottom of the table and the message definitions + in this document for details on how to translate messages. + + | RFC 1459 | | | + | Command | New Command | Notes | + +----------+----------------+-------+ + | ADMIN | 0x0508 | | + | AWAY | 0x0301 | | + | CONNECT | 0x0400 | | + | DIE | 0x0404 | | + | ERROR | (none) | | + | INFO | 0x0509 | | + | INVITE | 0x0208 | | + | ISON | 0x0505 | | + | JOIN | 0x0200,0x0280 | E | + | KICK | 0x0206 | | + | KILL | 0x0305 | | + | LINKS | 0x050C | | + | LIST | 0x0502 | | + | LUSERS | 0x0506 | | + | MODE | 0x0303,0x0202, | C | + | | 0x0204,0x0284, | | + | | 0x0205,0x0285, | | + | | 0x0207,0x0247, | | + | | 0x0287 | | + | MOTD | 0x0507 | | + | NAMES | 0x0501 | | + | NICK | 0x0300 | A | + | NOTICE | 0x0102,0x0103, | D | + | | 0x0104,0x0106 | | + | OPER | 0x0304 | | + | PART | 0x0201 | | + | PASS | 0x0000 | | + | PING | 0x7FFE | | + | PONG | 0x7FFF | | + | PRIVMSG | 0x0100,0x0101, | D | + | | 0x0104,0x0106 | | + | QUIT | 0x0004 | | + | REHASH | 0x0402 | | + | RESTART | 0x0403 | | + | SERVER | 0x0002 | | + | SQUIT | 0x0005,0x0401 | | + | STATS | 0x050B | | + | SUMMON | (none) | | + | TIME | 0x050E | | + | TOPIC | 0x0203 | | + | TRACE | 0x050D | | + | USER | 0x0001 | B | + | USERS | (none) | | + | VERSION | 0x050A | | + | WALLOPS | 0x0105 | | + | WHO | 0x0500 | | + | WHOIS | 0x0503 | | + | WHOWAS | 0x0504 | | + + *E: JOIN 0 (leave all channels) is not supported. + + *C: 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 + used at registration time, there is no equivalent; see the USER + command. + + *D: Keep in mind that the new protocol distinguishes between + messages/notices to a channel (public) and messages/notices to a + client (private). + + *B: When registering, the nickname (formerly from the NICK command) + is included in the user registration message.