💾 Archived View for rawtext.club › ~sloum › geminilist › 001345.gmi captured on 2020-09-24 at 01:56:47. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Ryan Kavanagh rak at rak.ac
Thu Jun 4 17:56:51 BST 2020
- - - - - - - - - - - - - - - - - - -
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 allsystems. Indeed, clients are currently required to accept *both* CRLFand bare LF as being representative of a line break. The proposed changerequires them only to accept CRLF, while giving them the option to alsoaccept LF if they so desire. This means: clients satisfying the spec nowwill satisfy the spec after the change.
You are correct in that it increases the burden for servers (regardlessof the host system): they must convert bare LF endings to CRLF beforetransmitting text. Whether or not this change imposes a "significant"burden is subjective. For what it's worth, the gopher protocol specifiesCRLF line endings, and gophernicus manages to do this conversion with ~5lines 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