💾 Archived View for rawtext.club › ~sloum › geminilist › 004744.gmi captured on 2023-11-14 at 10:37:25. Gemini links have been rewritten to link to archived content

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

[spec] Oustanding issues

Gary Johnson lambdatronic at disroot.org

Tue Jan 5 20:17:00 GMT 2021

- - - - - - - - - - - - - - - - - - -

Solderpunk <solderpunk at posteo.net> writes:

Greetings all,

I'm trying to prepare a list of spec issues that I want to finalise as

soon as possible. I probably should have been more disciplined about

this, but the high traffic rate of the mailing list combined with the

fact that an awful lot of the discussion is about stuff that I'm not

interested in means I've kind of lost track of the important things.

Below is everything I'm aware of which has been previously raised which

I think is worthy of some kind of consideration/response. If you think

I've forgotten something, please let me know.

A few other issues that have come up and could use spec-levelclarification:

1. What are the valid/invalid/recommended values for CN, SAN, and expiration dates in certificates in the context of TOFU?

It has been suggested on the mailing list that none of these values should have meaning under a TOFU security model. Others argue that they should have specific values and meanings. Clarity would be appreciated.

2. Client use of URL fragments (jump to heading, full text search, etc.)

Arguments for a variety of options (including none) have already been presented in another mailing list thread.

3. Extending bulleted lists to three level to match headings (*, **, ***)

Gemtext only defines a single-level unordered list line type (*). It was shown on the mailing list some time ago that different clients may have quite different ways of rendering attempts by authors to create nested list outlines. Here are two examples, both of which have variable renderings depending on the client used:

* TODOs ** Work *** Check email *** Be productive ** Home *** Eat food *** Clean body *** Get off your couch occasionally

* TODOs * Work * Check email * Be productive * Home * Eat food * Clean body * Get off your couch occasionally

It seems (at least to my eyes), that the (*, **, ***) examples are more in line with Gemini's 3-character line type indicator rule and match the same style as the three heading levels (#, ##, ###). Adding these to the Gemtext spec should be a strictly accretive (and therefore non-breaking) change that would standardize their display in different Gemini browsers.

4. Providing a concrete example of how to use text after opening ``` to specify client behavior (e.g., source code highlighting).

The Gemini spec mentions that the alt text can be used for this purpose but doesn't provide any clear mechanism for how this should be done. This leaves the choice entirely up to different clients, which seems like a recipe for competing browser wars and "Best Viewed In" notes on Gemtext pages. This is probably less than ideal.

Okay, that's all I can think of at the moment. Good luck mulling allthese issues over.

Happy hacking, Gary

-- GPG Key ID: 7BC158EDUse `gpg --search-keys lambdatronic' to find meProtect yourself from surveillance: https://emailselfdefense.fsf.org=======================================================================() ascii ribbon campaign - against html e-mail/\ www.asciiribbon.org - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.See http://www.gnu.org/philosophy/no-word-attachments.html