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/3f66 7e48/attachment-0001.htm>
---
Previous in thread (6 of 8): 🗣️ Ash (ext0l (a) riseup.net)
Next in thread (8 of 8): 🗣️ defdefred (defdefred (a) protonmail.com)