[SPEC-CHANGE] lang parameter, minor line type changes, clarifications...

[solderpunk]

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