💾 Archived View for rawtext.club › ~sloum › geminilist › 002253.gmi captured on 2020-09-24 at 03:15:09. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Caranatar caranatar at riseup.net
Sat Jul 18 21:23:48 BST 2020
- - - - - - - - - - - - - - - - - - -
A possible solution is changing the grammar to be
=
[whitespace]URL[[whitespace][friendly name]][whitespace]
Since whitespace shouldn't parse out as part of the url anyway
On July 18, 2020 3:20:20 PM EDT, Ash <ext0l at riseup.net> wrote:
On 7/18/20 2:18 AM, Katarina Eriksson wrote:
cage <cage-dev at twistfold.it <mailto:cage-dev at twistfold.it>
wrote:
On Fri, Jul 17, 2020 at 11:45:28AM -0400, Matthew Graybosch
wrote:
If each terms after the url was optional i expect the specs
was
something like:
=
[<whitespace>]<URL>[<whitespace>][<USER-FRIENDLY LINK NAME>]
That one makes the whitespace separator between <URL> and
<USER-FRIENDLY >
LINK NAME
optional, making it hard to parse.
This is what you were looking for:
=
[<whitespace>]<URL>[<whitespace>[<USER-FRIENDLY LINK NAME>]]
However, I think it's reasonable to assume the ending whitespace was
unintentional and ignore it.
Postel's law:
Be conservative in what you do, be liberal in what you accept
from
others
--
Katarina
For what it's worth, I think one should be careful in applying Postel's
law, since it can encourage drift from the spec: if everyone else
accepts messages that are misformatted in a particular way, then new
implementations need to do so as well.
That being said, I think this case is simple enough that I would 100%
support parsers tolerating the trailing whitespace, and even support
changing the spec in the way you described.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200718/3f667e48/attachment-0001.htm>