👽 alcatraz

Let's all agree to fix our software so that it does not require the CR in the CRLF end-of-line mark. In other words, let's accept inputs that using only a bare NL as the end-of-line.
Once all the software has been fixed, then we can all stop sending CRs.

https://fossil-scm.org/home/ext/stop-requiring-crlf.md

This topic is relevant to the Gemini protocol specification.

Under `requests`:

The client connects to the server and sends a request which consists of an absolute URI followed by a CR (character 13) and LF (character 10).

gemini://geminiprotocol.net/docs/protocol-specification.gmi

1 month ago · 👍 lucifer_jehovah_smith

Links

https://fossil-scm.org/home/ext/stop-requiring-crlf.md

gemini://geminiprotocol.net/docs/protocol-specification.gmi

Actions

👋 Join Station

2 Replies

👽 hanzbrix

@lufte It means that it should be ignored yes or treated as an LF.

While CR and LF are ancient leftovers, I don't see it as a problem that needs to be fixed, especially not by replacing the LF character with an NL. It's an established standard, hate it or like it, changing it over will just cause issues and a second standard. · 1 month ago

👽 lufte

The spec also states that “since text/gemini is a subtype of MIME type "text", line breaks are therefore represented by the sequence CRLF”. I wonder if clients respect this. Does this mean that single LF characters should be ignored? · 1 month ago