It has been made abundantly clear that Gemini is meant to be a frozen, immutable protocol ? without any possible extensions whatsoever. The forever protocol. So be it. Nevertheless, here is the outline of a small extension mechanism for Gemini: CAPA, short for capabilities. CAPA manifest itself as a directive, expressed as an URN: urn:gemini:capa The CAPA directive itself returns a list of capabilities supported by a given service, if any, or an error code otherwise: C: urn:gemini:capa S: 20 text/gemini => urn:gemini:capa => urn:gemini:capa:connection:keep-alive => urn:gemini:capa:transfer-encoding:chunked => urn:gemini:capa:turn <end of connection> In this case, the service understand CAPA itself, plus a handful of other capabilities, such as persistent connection, and chunked transfer encoding. A client enable a give capability by sending the relevant directive to the service: C: urn:gemini:capa:connection:keep-alive S: 10 Continue To which the conformant service replies with an informational status code ?10 Continue? acknowledging the new capability. In this example ?with the keep-alive capability enabled? the network connection is persistent and not dropped to indicate end-of-transmission after each request. Additionally, keep-alive enables the chunked transfer encoding ? as now the Gemini service needs a different mechanism to indicate end-of-transmission to the client. Wrapping all this together: C: urn:gemini:capa:connection:keep-alive S: 10 Continue C: gemini://host.xyz:/life-is-a-long-quiet-river.gmi S: 20 text/gemini;charset=utf-8;connection:keep-alive;transfer-encoding=chunked; 4\r\n Wiki\r\n (data) 6\r\n pedia \r\n (data) E\r\n in \r\n \r\n chunks.\r\n 0\r\n \r\n <service maintain connection, awaiting next request> That's all folks. ?0?
---
Previous Thread: [spec] avoiding the transport layer security trap
Next Thread: [spec] ☿️ gemini — a minimalist gemini protocol