💾 Archived View for gemini.bortzmeyer.org › gemini › fragment.gmi captured on 2024-02-05 at 13:02:27. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

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 <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

RFC 7231 on HTTP

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