Sean Conner writes: > So, the upshot (as I see it) is that the gopher URL format is divorced > from the RFC-3986 URL and is its own thing. You can't really say they have > the same semantic rules. This is also reflected in the caps.txt file you > will sometimes find on gopher servers to address the bit in RFC-1436 that > gopher selectors are opaque and *no* meaning is to be inferred by the > client. Completely agree that gopher is special here, but my reading of RFC-3986 section 6.2.3 was that itactually allows for some scheme-dependent behaviour anyway. > As far as Gemini goes, I've been parsing Gemini URLs under RFC-3986, just > like http:, https:, ftp: and file:. > > -spc (Did that answer your question?) You almost certainly have answered my question, but I'm being really daft and still not getting it. (Feel free to give up!) I'm not asking about what constitutes a valid gemini URL and more about whether it's already been decided that a server which responds with a 2x status for gemini://example.com/ must also respond with a 2x (and the same document) for gemini://example.com - even though they're both valid URLs. Or are you saying that this semantic equivalence is already mandated by RFC-3986? plugd
---
Previous in thread (7 of 15): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (9 of 15): 🗣️ Sean Conner (sean (a) conman.org)