--- irc3-19991002.txt Sat Oct 2 08:08:34 1999 +++ irc3-20000104.txt Tue Jan 4 21:26:18 2000 @@ -1,5 +1,5 @@ Network Working Group A. Church -Request For Comments: nnnn October, 1999 +Request For Comments: nnnn January, 2000 Obsoletes: 1459 Category: Experimental @@ -298,12 +298,7 @@ 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, or names that begin - with "#" or "&", as those are used at the beginning of channel names - under the old protocol, which has no way to distinguish server names - and nicknames from channel names except by the first character. This - name is used by clients to refer to a particular server, but is not - used in server-server communication. + 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 @@ -350,13 +345,15 @@ 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, or nicknames that begin with "#" or "&", as those are used - at the beginning of channel names under the old protocol, which has - no way to distinguish nicknames from channel names except by the - first character. Case is not relevant. (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.) + 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 @@ -411,7 +408,8 @@ 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 - case-insensitive. + case-insensitive. However, the first character of a channel name + has certain limitations; see below. There are two distinct types of channels defined by this protocol: distributed channels and local channels. Distributed channels are @@ -422,18 +420,13 @@ more servers may have local channels with exactly the same names, but clients in one server's channel will know nothing of clients in another server's channel, as the two channels are completely - separate. Channels are distributed by default; they may be made - local by using the channel mode command (see section 3.3.3). - - Compatibility note: The old protocol required channel names to begin - with either "#" or "&"; the former was for distributed channels, the - latter for local channels. When communicating with a client or - server using the old protocol, the server MUST prepend either "#" or - "&" to the name of a distributed or local channel, respectively, - whenever the name appears in a message. Note that this extends the - maximum length of a channel name string with respect to old-protocol - clients to 64 characters (not 63); implementors should take care to - avoid buffer overflow problems. + separate. The type of channel (distributed or local) is determined + by the first character of the channel name; if the first character is + "#" (ASCII 0x23), the channel is distributed, and if "&" (ASCII + 0x26), the channel is local. Implementations MAY define meanings for + other initial characters, but MUST treat a channel with an + unrecognized first character exactly as if the channel's first + character was a "#". In order to become part of a channel, a client sends a "join" command (see section 3.3.1). If the channel does not already exist, it is @@ -1105,6 +1098,16 @@ ERR_NOT_REGISTERED is not listed; see section 3.9 for conditions under which it is to be generated. + Note that in general, servers are not permitted to reject messages + from other servers on permission or other grounds; for example, while + a channel join message (see section 3.3.1) sent by a client directly + connected to a server indicates a request by the client to join the + channel, and may be rejected by the server for various reasons, the + same message coming from another server indicates an event that has + _already happened_, and if the server were to reject the message, its + copy of the network state would become desynchronized from the rest + of the servers on the network, quite likely resulting in total chaos. + Where a description refers to "forwarding" a message received by a server and is not otherwise qualified, the term refers to the server sending, to all other servers on the network, a server-server message @@ -1190,6 +1193,10 @@ The time parameter is added to the message by the server to which the client connected before the message is broadcast to other servers. + If the nickname given by the client is longer than the maximum length + (31 characters), the server MUST return ERR_NAME_TOO_LONG and ignore + the message. + If the nickname given by the client is already in use, the server MUST return ERR_NICKNAME_IN_USE and ignore the message. @@ -1484,6 +1491,11 @@ to any servers on which there is a client in the channel, and to any clients in the channel on that server, including the sender. + Servers MAY discard a message and reply with ERR_INVALID_NAME if the + message is from a directly-connected client and the first character + of the channel name is not recognized by the server (see section + 3.9). + Examples: CS: 0x0100 "#dragonweyr" "Hi, all." @@ -1493,6 +1505,7 @@ ERR_NEED_MORE_PARAMS ERR_NAME_TOO_LONG + ERR_INVALID_NAME ERR_NO_SUCH_CHANNEL ERR_CANNOT_SEND @@ -1631,12 +1644,12 @@ given channel-operator status in those channels (see section 3.3.5). New channels do not have any modes active (see section 3.3.3). If a client is not allowed to join a channel, the reply ERR_CANNOT_JOIN is - sent for each such channel. Failed join messages MUST NOT be + sent for each such channel. Rejected join messages MUST NOT be forwarded. The second form of the join message is used when a channel has a key associated with it (see section 3.3.3); only one channel may be - joined with a single message in this form. + joined per message in this form. When broadcasting join messages to clients in the joined channel(s), the server MUST send a separate join message for each channel using @@ -1648,6 +1661,11 @@ if the user had sent a topic message (section 3.3.4), mode message (section 3.3.3), and names message (section 3.6.2) for the channel. + Servers SHOULD NOT accept join messages from directly-connected + clients with channel names whose first character is unrecognized; + however, servers MUST accept such messages if received from another + server. + Examples: CS: 0x0200 "#dragonweyr" "#help" @@ -1665,6 +1683,7 @@ ERR_NEED_MORE_PARAMS ERR_NAME_TOO_LONG + ERR_INVALID_NAME ERR_CANNOT_JOIN 3.3.2 Part message @@ -1678,8 +1697,7 @@ channels are deleted. In the second form, the client may send a reason with the part - message. Only one channel at a time may be left with this form of the - message. + message. Only one channel per message may be left with this form. When broadcasting the part message to clients in the parted channel(s), the server MUST use message code 0x0281, and MUST send an @@ -1702,6 +1720,7 @@ ERR_NEED_MORE_PARAMS ERR_NAME_TOO_LONG + ERR_INVALID_NAME ERR_NOT_IN_CHANNEL 3.3.3 Channel mode message @@ -1724,8 +1743,11 @@ When this message is used to change channel modes, the server's reply includes only those modes which were changed in the new-modes-mask parameter; to obtain a full list of channel modes, a query message - must be sent. A query message is simply a channel mode message - with no mode parameters. + must be sent. + + A query message is simply a channel mode message with no mode + parameters; the server replies with the current set of modes for the + channel, and sets all bits in the new-modes-mask parameter. Some modes require parameters when they are set active; these are given in increasing bit order -- i.e. the parameter for the lowest @@ -1786,13 +1808,6 @@ key given with the mode message. Note that the key is never sent to any client in a mode status or change message. - 0x00000100 CMODE_LOCAL - If this mode is set, the channel is local; if this mode is not - set, the channel is distributed. This mode may only be changed - when there is exactly one client in the channel; otherwise, the - server MUST return ERR_CANNOT_CHANGE_DIST_LOCAL and discard the - entire message. - 0x00800000 CMODE_LOCKED If this mode is set, the channel mode is "locked", i.e. may not be changed. Specifically, if a client without IRC operator @@ -1809,11 +1824,7 @@ or server. If any mode change in a mode change request is disallowed, the entire - mode change request MUST be discarded. For example, if a client with - channel operator privileges tries to set both CMODE_LOCAL and - CMODE_MODERATED in the same message, the server MUST discard the - message without changing any modes, even though the CMODE_MODERATED - flag by itself would have been permitted. + mode change request MUST be discarded. Examples: @@ -1845,6 +1856,7 @@ ERR_NEED_MORE_PARAMS ERR_NAME_TOO_LONG + ERR_INVALID_NAME ERR_NO_SUCH_CHANNEL ERR_NOT_IN_CHANNEL ERR_PERMISSION_DENIED @@ -1877,6 +1889,7 @@ ERR_NEED_MORE_PARAMS ERR_NAME_TOO_LONG + ERR_INVALID_NAME ERR_NO_SUCH_CHANNEL ERR_NOT_IN_CHANNEL ERR_PERMISSION_DENIED @@ -1901,6 +1914,7 @@ ERR_NEED_MORE_PARAMS ERR_NAME_TOO_LONG + ERR_INVALID_NAME ERR_NO_SUCH_CHANNEL ERR_NOT_IN_CHANNEL ERR_PERMISSION_DENIED @@ -1926,6 +1940,7 @@ ERR_NEED_MORE_PARAMS ERR_NAME_TOO_LONG + ERR_INVALID_NAME ERR_NO_SUCH_CHANNEL ERR_NOT_IN_CHANNEL ERR_PERMISSION_DENIED @@ -1951,6 +1966,7 @@ ERR_NEED_MORE_PARAMS ERR_NAME_TOO_LONG + ERR_INVALID_NAME ERR_NO_SUCH_CHANNEL ERR_NOT_IN_CHANNEL ERR_PERMISSION_DENIED @@ -1989,6 +2005,7 @@ ERR_NEED_MORE_PARAMS ERR_NAME_TOO_LONG + ERR_INVALID_NAME ERR_NO_SUCH_CHANNEL ERR_NOT_IN_CHANNEL ERR_PERMISSION_DENIED @@ -2011,6 +2028,7 @@ ERR_NEED_MORE_PARAMS ERR_NAME_TOO_LONG + ERR_INVALID_NAME ERR_NO_SUCH_CHANNEL ERR_NO_SUCH_USER ERR_NOT_IN_CHANNEL @@ -2029,7 +2047,9 @@ Allows a client to change its nickname. If the nickname is already in use, the server MUST return ERR_NICK_IN_USE and MUST NOT forward - the message. + the message. If the nickname is longer than the maximum length (31 + characters), the server MUST return ERR_NAME_TOO_LONG and ignore the + message. This message may also be generated by a server to cause a client to change its nickname. A client receiving a nick message for itself @@ -2571,6 +2591,7 @@ ERR_NEED_MORE_PARAMS ERR_NAME_TOO_LONG + ERR_INVALID_NAME 3.6.3 List message @@ -2598,6 +2619,7 @@ ERR_NEED_MORE_PARAMS ERR_NAME_TOO_LONG + ERR_INVALID_NAME 3.6.4 Whois message @@ -3176,13 +3198,19 @@ either invalid characters or too many characters. Error messages corresponding to these conditions are listed in section 4.2.1. - Of the syntactic errors, the only one whose generation is not - mandatory is ERR_NAME_TOO_LONG. In the case of a name which is - longer than the maximum allowable length, a server MAY send this - reply, or MAY continue processing the message normally (with or - without truncation of the offending name). All other syntactic - errors MUST be generated as soon as the corresponding condition - occurs, and the server generating the error MUST discard the message. + Of the syntactic errors, the only ones whose generation is not + mandatory are ERR_NAME_TOO_LONG and ERR_INVALID_NAME. In the case + of a name which is longer than the maximum allowable length, a server + MAY send this reply and discard the message; if it does not do so, it + MUST truncate the offending name to the maximum allowable length and + continue processing the message normally. In the case of a channel + name whose first character is not recognized by the server, the + server MAY generate ERR_INVALID_NAME and discard the message if the + message is from a directly-connected client, but MUST accept the + channel name and continue processing the message normally, without + altering the channel name, otherwise. All other syntactic errors + MUST be generated as soon as the corresponding condition occurs, and + the server generating the error MUST discard the message. Functional errors are much more numerous, and which messages can generate which errors varies from message to message. There is, @@ -3284,7 +3312,7 @@ Sent to confirm addition of a mask to the client's silence list. 0x0121 RPL_SILENCE_DEL - Sent to confirm deletion of a mask ÷½ the client's silence list. + Sent to confirm deletion of a mask $Bw=(B the client's silence list. 0x0200 RPL_USERS Sent in response to a users message (see section 3.6.7). @@ -3416,10 +3444,6 @@ 0xC211 ERR_CANNOT_JOIN A join message was disallowed. - 0xC212 ERR_CANNOT_CHANGE_DIST_LOCAL - A client tried to change the distributed/local channel mode (see - section 3.3.3) when there were other clients in the channel. - 0xC213 ERR_CANNOT_CHANGE_LOCKED A client tried to change channel modes while the CMODE_LOCKED mode (see section 3.3.3) was set. @@ -3927,8 +3951,7 @@ 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, or begin with the "#" or "&" - characters. (1.1) + 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 @@ -3946,12 +3969,9 @@ 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, or begin with the "#" or "&" - characters. (1.2) - REQ: When communicating with a client or server using the old - protocol, servers MUST prepend either "#" or "&" to the name of - a distributed or local channel, respectively, whenever the name - appears in a message. (1.4) + 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 @@ -4096,6 +4116,10 @@ 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) @@ -4153,6 +4177,8 @@ 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 @@ -4161,10 +4187,6 @@ attempts to change channel modes, the server MUST reply with ERR_PERMISSION_DENIED and discard the message without processing it. (3.3.3) - REQ: A server receiving an otherwise valid channel mode message - requesting a change of the CMODE_LOCAL flag when more than one - client is in the channel MUST return - ERR_CANNOT_CHANGE_DIST_LOCAL and discard the message. (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 @@ -4327,6 +4349,12 @@ 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.