Systemspace Network List
Network Enhancement Idea 10
Quintuplicate
23 August 2021
INPUT ON THE SPECIFICATION FOR THE ETF
I. Context
NEI 2, the draft specification for the Enhanced Text Format (ETF), requires lines to be split using the line feed (LF) character "\n" (ASCII 10), because the carriage return (CR) character "\r" (ASCII 13) "[does] not split lines nor ideally should it be contained in a valid document." To be compliant with NEI 2, a program must treat CR in two ways:
(1) Ignore it and treat it as "a normal but invisible character".
(2) "Strip [CR] out if that is possible especially if [it is] transmitting, transforming or saving the document." Yori recommends this.

NEI 4 declares that ETF is intended for use in Yori Chat, an "extended IRC" protocol, "for formatting messages" so that it would "feel like more modern chats".
II. Suggestion
LF, CR, or both, should all be acceptable to split lines in ETF.

The framers of ASCII meant LF to control "the movement of the printing position to the next printing line", while they intended CR to control "the movement of the printing position to the first printing position on the same printing line." (RFC 20) Importantly, LF had "the meaning 'New Line' (NL)", that is, controlled "the movement of the printing point to the first printing position on the next printing line", only with "agreement between sender and recipient of data."

This shows that CR and LF are complementary, not competitors. One moves the printing position to the beginning of the line and the other moves it down one line. While they may not work that way nowadays, this is no reason to require ETF writers and readers to abandon their original intent. 

The founders of ARPANET used CR for consoles to send what they had typed to remote computers (RFC 1). Likewise, the inventors of IRC required messages to be "lines of characters terminated with a CR-LF...pair" (RFC 2812). Although RFC 2812 is obsolete in many ways, this is not one of them. It remains in an update which its author describes as "what I think it would look like" "if a new RFC was released today describing how IRC works": "An IRC message is a single line, delimited by a pair of CR...and LF...characters." (https://modern.ircdocs.horse/) This update further explicitly requires servers to "only parse and process a message once you encounter the \r\n at the end of it." If Yori Chat obeys this requirement, CR will definitely "be contained" in its messages.

Feed has no problem parsing line breaks formed by either LF or a CR-LF pair.

There are certainly advantages to having an indigenous protocol we determine for ourselves. But I think that, in this case, the costs outweigh the benefits. I can find no basis, historical or technical, for violating the principle of "be conservative in what you send but liberal in what you accept" by prescribing LF for splitting lines.