💾 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

View Raw

More Information

⬅️ Previous capture (2021-11-30)

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

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

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