[SPEC-CHANGE] Simplified client certs, URI scheme, alt text

Ahoy, Geminauts!

I have just made the proposed spec changes that I asked for comment on
over the just past weekend official.

SUMMARY OF CHANGES:
 
* A gemini:// URI scheme is formally defined for the first time,
  explicitly disallowing the use of the userinfo subcomponent of the
  authority component.
* The client certificate system has been substantially simplified, with
  transient certificates no long a formally defined concept with
  prescribed behaviour.
* A lightweight notion of alt text for pre-formatted content has been
  introduced as a tentative step toward fixing the worst search and
  accessibility related problems with pre-formatted non-textual content.
  No special structures or semantics for alt text are defined - if a
  convention for doing this organically arises in the community it may
  become a recommended best practice.
* A few minor corrections and tidyups.

IMPLICATIONS FOR SERVER AUTHORS:
   
Servers SHOULD return status 59 (BAD REQUEST) if they receive a request
for a gemini:// URL containing a userinfo subcomponent.  If you really
want to be hyper-Postelian, you MAY instead strip out the userinfo so
that, for example, it does not end up in logs, is not passed to CGI
apps, etc.
    
IMPLICATIONS FOR CLIENT AUTHORS:
     
Clients should either refuse to follow gemini:// links with userinfo
subcomponents, or should strip out the userinfo before following the
link.

Clients with support for client certificates should adapt to the new
simplified specification, which may involve e.g. removing support for
the deprecated status code 21.

Clients may do something with alt text.  This is probably most relevant
to search engines and accessibility-focussed clients, but I suppose e.g.
graphical clients may wish to support web browser style hover over
display.  Strictly optional in all cases.
      
IMPLICATIONS FOR CONTENT AUTHORS:

If you have authored content which includes gemini:// links with
userinfo subcomponents, you MUST remove the userinfo.

You may wish to add alt text to preformatted content which is not
meaningfully screen readable or search engine indexable.

Cheers,
Solderpunk

Sounds good! Can this be updated on the website?

makeworld

??????? Original Message ???????
On Monday, June 15, 2020 12:13 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> Ahoy, Geminauts!
>
> I have just made the proposed spec changes that I asked for comment on
> over the just past weekend official.
>
> SUMMARY OF CHANGES:
>
> -   A gemini:// URI scheme is formally defined for the first time,
>     explicitly disallowing the use of the userinfo subcomponent of the
>     authority component.
>
> -   The client certificate system has been substantially simplified, with
>     transient certificates no long a formally defined concept with
>     prescribed behaviour.
>
> -   A lightweight notion of alt text for pre-formatted content has been
>     introduced as a tentative step toward fixing the worst search and
>     accessibility related problems with pre-formatted non-textual content.
>     No special structures or semantics for alt text are defined - if a
>     convention for doing this organically arises in the community it may
>     become a recommended best practice.
>
> -   A few minor corrections and tidyups.
>
>     IMPLICATIONS FOR SERVER AUTHORS:
>
>     Servers SHOULD return status 59 (BAD REQUEST) if they receive a request
>     for a gemini:// URL containing a userinfo subcomponent. If you really
>     want to be hyper-Postelian, you MAY instead strip out the userinfo so
>     that, for example, it does not end up in logs, is not passed to CGI
>     apps, etc.
>
>     IMPLICATIONS FOR CLIENT AUTHORS:
>
>     Clients should either refuse to follow gemini:// links with userinfo
>     subcomponents, or should strip out the userinfo before following the
>     link.
>
>     Clients with support for client certificates should adapt to the new
>     simplified specification, which may involve e.g. removing support for
>     the deprecated status code 21.
>
>     Clients may do something with alt text. This is probably most relevant
>     to search engines and accessibility-focussed clients, but I suppose e.g.
>     graphical clients may wish to support web browser style hover over
>     display. Strictly optional in all cases.
>
>     IMPLICATIONS FOR CONTENT AUTHORS:
>
>     If you have authored content which includes gemini:// links with
>     userinfo subcomponents, you MUST remove the userinfo.
>
>     You may wish to add alt text to preformatted content which is not
>     meaningfully screen readable or search engine indexable.
>
>     Cheers,
>     Solderpunk
>

Whoops, sorry!  I totally forgot that's a seprate process now, since the
reformatting of the spec to actually be a text/gemini document!  It's
done now, thanks for the reminder.

Cheers,
Solderpunk

On Mon, Jun 15, 2020 at 07:02:22PM +0000, colecmac at protonmail.com wrote:
> Sounds good! Can this be updated on the website?
> 
> makeworld