Reasoning behing 76 being the line length limit for MIME sections, as defined by RFC 2045?

Question

RFC 2045 defines the maxmimum line length for encoded data as 76 - however I cannot find any explanation as to why it is 76. Is this number entirely arbitrary, or is there s

Answer 1

The bit to do with user interfaces

http://en.wikipedia.org/wiki/Text_mode#PC_common_text_modes

Basically, 80 characters across (and usually 25 or 30 lines) was the most common standard for displays. 78 provides a sane standard as this allows for some small decorations to be used (borders).

Answer 2

Actually the original RFC 822 defines a limit at 72 characters and the culprit is a teletype, which was a standard output device with the early computers.

You can also "thank" teletype devices for the line terminator in emails (and Windows) being 2 characters, which are CR (Carriage Return) and LF (Line Feed).

It was essential to transmit this sequence at the end of each line in order for a teletype to move a caret to position 0 and advance paper one tick up.

By the time RFC 2822 obsoleted the original, nobody was using teletypes to render emails, so it was relaxed a bit in order to fit into a default TTY monitor device.

Answer 3

The maximum line length of 80 including the terminating carriage return and line feed originates from the good old punch cards which contained up to 80 colums of holes.
Why 80? Because in any book, a line is rarely longer than 80 characters including spaces.
It implied a maximum line length of 80 including the terminating Carriage Return (which moved the carriage of the teletype or typing machine to the leftmost position) and Line Feed (which advanced the paper by one line).
Since Base64 is in multiples of 4 characters, we end up with a maximum of 76, not counting CR+LF.
Another example is the TLE (Two-Line Element set) which describes a satellite's orbit. It fits on just two punch cards.
Since CR (horizontal movement to the leftmost, maintaining the vertical position) and LF (vertical movement to next line, keeping the horizontal position as is) are two fully independent things, we still have both of them. The next line should start at the leftmost position, shouldn't it?
For printing in bold, a line was printed twice with only a CR between them, i.e. without advancing the paper. Therefore the standard sequence is CR first and then LF.
However, the good old mechanical typing machine usually did the LF first and then the CR.

Answer 4

RFC2822 is legacy standard of EMail. In section 2.1.1 of RFC2822, you can find reason as below: It also affects MIME.

There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.

The 998 character limit is due to limitations in many implementations which send, receive, or store Internet Message Format messages that simply cannot handle more than 998 characters on a line. Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake. However, there are so many implementations which (in compliance with the transport requirements of [RFC2821]) do not accept messages containing more than 1000 character including the CR and LF per line, it is important for implementations not to create such messages.

The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification (and that of [RFC2821] if they actually cause information to be lost). Again, even though this limitation is put on messages, it is encumbant upon implementations which display messages to handle an arbitrarily large number of characters in a line (certainly at least up to the 998 character limit) for the sake of robustness.