question about links parsing

[Caranatar]

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>