Ambiguity in spec regarding line endings

[Ryan Kavanagh]

Hi,

On Thu, Jun 04, 2020 at 12:23:26PM -0400, prisonpotato at tilde.team wrote:
> I disagree with this idea, as it adds a signifigant burden to both
> server implementations and client implementations running on unix
> systems.

The proposed modification *reduces* the burden for clients on all
systems. Indeed, clients are currently required to accept *both* CRLF
and bare LF as being representative of a line break. The proposed change
requires them only to accept CRLF, while giving them the option to also
accept LF if they so desire. This means: clients satisfying the spec now
will satisfy the spec after the change.

You are correct in that it increases the burden for servers (regardless
of the host system): they must convert bare LF endings to CRLF before
transmitting text. Whether or not this change imposes a "significant"
burden is subjective. For what it's worth, the gopher protocol specifies
CRLF line endings, and gophernicus manages to do this conversion with ~5
lines of code [0, 1].

The question boils down to a cost-benefit analysis of:

    preserving spec compliance for existing servers and not having
    servers worry about line endings

versus

    respecting network protocol conventions that have been established
    for decades and not violating a MUST requirement of RFC 2046 §4.1.1

Best,
Ryan

[0] https://github.com/gophernicus/gophernicus/blob/master/src/file.c#L68
[1] https://github.com/gophernicus/gophernicus/blob/master/src/string.c#L122

-- 
|)|/  Ryan Kavanagh      | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac     |      BD95 8F7B F8FC 4A11 C97A