💾 Archived View for rawtext.club › ~sloum › geminilist › 005537.gmi captured on 2023-11-04 at 13:54:34. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Alex // nytpu alex at nytpu.com
Tue Feb 23 19:54:39 GMT 2021
- - - - - - - - - - - - - - - - - - -
On 2021-02-23 05:21PM, Oliver Simmons wrote:
At current the Gemini spec is dual-purpose, it describes the protocol,
and the text/gemini format.The current spec, while it is the "formal" spec, is intended to berather informal (compared to other specs), and I suppose it was justeasier to group them together at the time.
Whilst gemtext is the "native" format for Gemini (as HTML is to HTTP),
one isn't required for the other to work, they are two distinct
things.Something that should be emphasized more IMO, since people don't seem tounderstand this every time they suggest to add inline markup.
I think that they should be split into two specs, one for the protocol
and one for gemtext.I'm sure if Solderpunk ever pursues submitting it as a formal RFC(something that he was contemplating, but wanted to wait until the finalspec freeze) then the IETF would help us formalize it and organize itmore coherently. Using my knowledge of how RFCs are structured I'mfairly sure they would both be in one RFC but separated meaningfully.The current spec has gemtext separated, but the distinction could bemade more clear.
-- Alex // nytpualex at nytpu.comGPG Key: https://www.nytpu.com/files/pubkey.ascKey fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5Bhttps://useplaintext.email/-------------- next part --------------A non-text attachment was scrubbed...Name: signature.ascType: application/pgp-signatureSize: 833 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210223/d184f6ef/attachment-0001.sig>