Last update on 28 february 2021.
This is a personal list of the things that, in my opinion, are missing or unclear in the Gemini specification. It helps me to follow the discussions and to be sure everything was addressed. They are roughly in order of decreasing importance (yes, that's subjective).
This is probably the worst part of the current specification, there are many other clarifications requested:
=> Issue #5 in the specification work
(Media types are commonly named MIME types.) Registering text/gemini:
=> The IANA registry for media types
=> RFC 6838, on media types registration
=> Issue #11 in the specification work
=> The IANA registry for port numbers (warning, huge file)
=> RFC 6335, on port numbers (and service names) registration
1965 is currently registered for the "tivoli-npm" service. It appears to be long forgotten. The contact is Ivana Cuozzo, but the email address bounces (2021-03-01, the Tivoli company stopped many years ago). IANA was contacted about this issue (ticket [IANA #1190212]) but offered no practical way to de-assign (sections 8.2 and 8.4 of the RFC) the port.
=> The IANA form to request a port
=> Issue #16 in the specification work
Currently, the syntax of the header response and of gemtext is specified mostly in natural language, which create ambiguities (for instance, is an end-of-line required at the last line of a page?). We should use a formal language, such as ABNF.
=> RFC 5234 on ABNF | Issue #7 on the specification work
Is an empty path equivalent to a single slash? Practically, is gemini://example.org equivalent to gemini://example.org/ and can a client canonicalize the former to the later? RFC 3986 says "In general, a URI that uses the generic syntax for authority with an empty path should be normalized to a path of '/' " (HTTP does it) but it is not said in Gemini specification.
=> Issue #2 in the specification work
=> Adnan Maolood's list This content has been proxied by September (ba2dc).Proxy Information
text/gemini; lang=en