A minor clarification below... On 07-Jun-2020 22:47, Luke Emmet wrote: > Hello all > > On 07-Jun-2020 17:27, solderpunk wrote: >> The definition of link lines now clarifies that clients "MUST NOT >> automatically make any network connections as part of displaying links >> whose scheme corresponds to a network protocol (e.g. gemini://, >> gopher://, https://, ftp://, etc.)". See section 5.4.2 for full >> details. >> >> <snip> >> >> IMPLICATIONS FOR CLIENT AUTHORS: >> >> <snip> >> >> If your client has been automatically making network connections you >> MUST remove this behaviour and atone for your sins! >> > I think all the changes are sensible, apart from the wording that > tries to specify client behaviour. It is not for the spec IMO to > prescribe the client behaviour, rather it should specify the exchange > format and markup (both of which it does well). Sorry, to clarify that particular point, my intended point was that it is not for the spec to prescribe *when* the client makes or does not make its network requests in light of on its interpretation of the textual content. The spec should stick to correct computer to computer exchange (protocol matters) and the markup format (both of which it does well). > > If a client must not make subsequent network requests when > interpreting a page, does this mean that search engines and crawlers > are now non-compliant clients? This seems to go much too far. > > I would think the "MUST NOT" would be better as a "SHOULD NOT" in case > you are adamant to try to shape client behaviour. In my view this is > not in scope of a protocol and markup format specification. > > Also minor point, I would recommend removing the "atone for your sins" > sentence as it is overly informal for a spec. > > I like the explicit requirements covering URL encoding, lang, and > bullets. I wonder how authors will reliably signal the language to the > server though, particularly as it may be on a page by page basis. > > Otherwise keep up the good work! > > Best wishes > > - Luke >
---
Previous in thread (6 of 35): 🗣️ Luke Emmet (luke.emmet (a) gmail.com)
Next in thread (8 of 35): 🗣️ Sean Conner (sean (a) conman.org)