💾 Archived View for gemini.bortzmeyer.org › gemini › fragment.gmi captured on 2023-07-22 at 22:25:48. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
There are two issues with the current (january 2021) Gemini specification regarding to fragments.
Issue #8 in the specification work
What to do when redirecting? If original URI is <gemini://foobar.example/#baz> and there is a redirect to <gemini://thing.example/doit>, should the Gemini client consider is has to go to <gemini://thing.example/doit#baz> or to <gemini://thing.example/doit>?
The spec says "The path, query and fragment components are allowed and have no special meanings beyond those defined by the generic syntax." But RFC 3986 just describes a *syntax*, it seems silent about semantics.
Therefore, for HTTP, RFC 7231 has to describe in detail what the client ("user agent", in HTTP parlance) has to do with fragments. Should we consider that "in doubt, do as HTTP does?"
RFC 3986 on generic URI syntax
John Cowan's proposal on fragments, close to HTTP
There are many proposals for a semantic for fragments in text/gemini resources.
Issue #3 in the specification work
Sean Conner's proposal on fragment identifiers
Luke Emmet's proposal on fragment identifiers