[spec] Oustanding issues

[Gary Johnson]

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-level
clarification:

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 all
these issues over.

Happy hacking,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect 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