Fragments in the Gemini specification
There are two issues with the current (january 2021) Gemini specification regarding to fragments.
In the Gemini protocol
Issue #8 in the specification work
What to do when redirecting? If original URI is
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
In the Gemini (gemtext) files
There are many proposals for a semantic for fragments in text/gemini resources.
Issue #3 in the specification work
- state that they have no use and no meaning
- use the structure of the gemtext (headers, lines) to have fragment identifiers like h2.4 (fourth second level header)
- content-addressable text, the fragment would be a hash of part of the text
- use fragment identifiers of RFC 5147 (not very robust, any change would break them)
- fragment identifier as a search query in the page (Control-F…)
Sean Conner's proposal on fragment identifiers
Luke Emmet's proposal on fragment identifiers
Nervuri's proposal on fragment identifiers
RFC 5147 on fragment identifiers for plain text
Source