💾 Archived View for rawtext.club › ~sloum › geminilist › 000829.gmi captured on 2020-11-07 at 01:47:35. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2020-09-24)

-=-=-=-=-=-=-

<-- back to the mailing list

Proposed minor spec changes, for comment.

colecmac at protonmail.com colecmac at protonmail.com

Mon May 18 21:48:51 BST 2020

- - - - - - - - - - - - - - - - - - - 

These are good additions, thanks.

I take issue with, maybe predictably, number 2. I didn't realizethat RFC existed, and I was surprised to read it. Are there anyother formats that actually follow this? Take markdown forexample, plenty of people write markdown with only a \n at theend of each line, and it doesn't affect anything. In fact, in themarkdown spec, it explicitly says just \n is fine:https://spec.commonmark.org/0.29/#line-ending

I don't see the point in following the RFC in this case, I thinkit adds needless complication to the spec. Obviously it's notsuch a big change to server software, but I don't think there's agood reason to add it.

Rationale: Don't break foundational RFCs.

It would be hard to argue with this, except that there seems to bea precedent of not caring about this specific part of this RFC.I think Gemini would be less surprising and more simple, if itdisregarded this like most other specs seem to do.

I'm in favor of defining a line ending as \r\n OR \n.

Thoughts?

makeworld