CR-LF (Carriage Return - Line Feed) pair, @ 512 bytes

Talk about pretty much anything here, but DO NOT USE FOR SUPPORT.

Moderator: Supporters

Posts: 51
Joined: Mon Jan 16, 2017 8:07 pm
Location: online

CR-LF (Carriage Return - Line Feed) pair, @ 512 bytes

Post by HeXiLeD »

So we were having a conversation in the chatroom and we ended up on due to the fact that irc clients are not able to pass/input messages that are longer/bigger than 512 bytes.

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

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 */
So aside the fact that these RFC people still live in the 80's IRC and communications life as well as the devs that support them,
what is the technical reason to maintain these limitations in today's communications.

What is (if any) the problem with the math in 2019?
Constructive criticism leads to evolution and progress. Negative criticism leads to obsolescence. We are not in the 90's IRC world anymore.
CertFP: d985d21f89fe2977b593c4d381a1a86802e62990d9328d893db76d59f9935244