Section: 2.3 (still in effect in the current RFC revision at the date of this post)
2.3 Messages
Servers and clients send eac hother messages which may or may not
generate a reply. If the message contains a valid command, as
described in later sections, the client should expect a reply as
specified but it is not advised to wait forever for the reply; client
to server and server to server communication is essentially
asynchronous in nature.
Each IRC message may consist of up to three main parts: the prefix
(optional), the command, and the command parameters (of which there
may be up to 15). The prefix, command, and all parameters are
separated by one (or more) ASCII space character(s) (0x20).
The presence of a prefix is indicated with a single leading ASCII
colon character (':', 0x3b), which must be the first character of the
message itself. There must be no gap (whitespace) between the colon
and the prefix. The prefix is used by servers to indicate the true
Oikarinen & Reed [Page 7]
RFC 1459 Internet Relay Chat Protocol May 1993
origin of the message. If the prefix is missing from the message, it
is assumed to have originated from the connection from which it was
received. Clients should not use prefix when sending a message from
themselves; if they use a prefix, the only valid prefix is the
registered nickname associated with the client. If the source
identified by the prefix cannot be found from the server's internal
database, or if the source is registered from a different link than
from which the message arrived, the server must ignore the message
silently.
The command must either be a valid IRC command or a three (3) digit
number represented in ASCII text.
IRC messages are always lines of characters terminated with a CR-LF
(Carriage Return - Line Feed) pair, and these messages shall not
exceed 512 characters in length, counting all characters including
the trailing CR-LF. Thus, there are 510 characters maximum allowed
for the command and its parameters. There is no provision for
continuation message lines. See section 7 for more details about
current implementations.
Code: Select all
#define DBUF_BLOCK_SIZE (512)
./* 512 bytes -- 510 character bytes + \r\n, per rfc1459 */
what is the technical reason to maintain these limitations in today's communications.
What is (if any) the problem with the math in 2019?