gemline/gemini0.13.0.gmi

**Ahoy!

I have just pushed some changes to the Gemini specification.
> You can see the new new v0.13.0 spec at:

* gemini://gemini.circumlunar.space/docs/specification.gmi
* gopher://gemini.circumlunar.space/0/docs/specification.txt
* https://gemini.circumlunar.space/docs/specification.html

Perhaps the biggest change, in conceptual terms, is the introduction of the "lang" parameter for text/gemini.
However, most clients will not need to make any changes whatsoever on account of this.

The other changes are either small clarifications or enhancements of existing functionality and have all been discussed previously on the mailing list.

## SUMMARY OF CHANGES:

### text/gemini documents can now specify which natural language(s) they are written in via a "lang" parameter to the media type.
Valid values of "lang" are comma-separated lists of language tags, as defined in RFC4646.
These are actually pretty powerful tags and can specify language, script (which implies a particular direction of text rendering), usage of regional variant, etc.
Of course, clients can pay as much or as little attention to these details as their authors seem fit.
Servers never have to provide this parameter (although it would be good practice to do so) and clients never have to pay attention to it.
> See section 5.2 for full details.

### The definition of unordered list item lines has been changed so that they begin not just with "*" but with "* ".
This allows the first word of a regular text line to be *emphasised* in a common fashion without the line being accidentally considered a list item.
GUS data suggests that everybody, or almost everybody, is already writing their list items this way, so this should not require any content updates by authors.
> See section 5.4.2 for full details.

### Lines beginning with ">" are now defined to be quote lines, as per popular demand.
Nothing is prescribed about how clients should display this.
I expect terminal-based clients will simply keep the ">" visible as its use to convey quotation is extremely widely used and familiar from email and usenet.
When wrapping long lines to fit the screen, each resultant line may have a ">" placed at the front.
This is mostly just a styling matter, but I consider it to be styling which conveys important semantic information and when quoting multiple paragraphs of text it helps to disambiguate where the quotation ends.
This is the last advanced line type I expect to ever add to the spec.
> See section 5.4.3 for full details.

### Status code 11 has been defined for requesting "sensitive" input, like passwords.
Clients should treat it exactly like status code 10 except they should not echo the user's input to the screen.
This will allow us to experiment with different authentication paradigms as part of client certificate work-flows.
> See Appendix 1 for full details.

### The need to use percent-encoding on reserved characters and spaces in URLs, both in requests and in the link lines of text/gemini bodies, has been made explicit due to observed variation in how clients/servers actually handle this.
> See sections 3.2.1 and 5.4.2 for full details.

### The definition of link lines now clarifies that clients "MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. gemini://,
gopher://, https://, ftp://, etc.)".
> See section 5.4.2 for full details.

## IMPLICATIONS FOR SERVER AUTHORS:

You SHOULD consider providing a way for admins and/or users to specify which value of the "lang" parameter should be sent for text/gemini content.

If your server automatically generates text/gemini content (e.g. directory listings), you MUST make sure it uses percent-encoding in its URLs (filenames with spaces in them are a good test case!).

## IMPLICATIONS FOR CLIENT AUTHORS:

Your client MAY make use of the value of the "lang" parameter in interpreting text/gemini content (this will mostly be relevant for the Rhapsode audio browser and perhaps for search engines).

If your client recognises unordered list item lines and treats them differently from plain text lines, you MUST change the code which identifies them to require a space after the *.

You MAY update your client to recognise the new quote line type.

You MAY update your client to treat status code 11 differently from status code 10.

If your client supports status codes beginning with 1, you MUST be percent-encoding the user input when formatting the subsequent request.

If your client has been automatically making network connections you MUST remove this behaviour and atone for your sins!

## IMPLICATIONS FOR CONTENT AUTHORS:

If your content has unordered list item lines which do not include a space after the initial *, you MUST insert that space.

Cheers,
**"Solderpunk