repo: gemini-site
action: commit
revision: 
path_from: 
revision_from: a29ed24ff9087e2b965d262d30135ef1fb32d820:
path_to: 
revision_to: 

commit a29ed24ff9087e2b965d262d30135ef1fb32d820
Author: Solderpunk 
Date:   Sun Jun 7 10:46:50 2020 +0000

    Fix erroneous reference to HTTP.

diff --git a/docs/specification.gmi b/docs/specification.gmi

--- a/docs/specification.gmi
+++ b/docs/specification.gmi
@@ -2,7 +2,7 @@

 ## Speculative specification

-v0.12.3, May 26th 2020
+v0.12.4, June 7th 2020

 This is an increasingly less rough sketch of an actual spec for Project Gemini.  Although not finalised yet, further changes to the specification are likely to be relatively small.  You can write code to this pseudo-specification and be confident that it probably won't become totally non-functional due to massive changes next week, but you are still urged to keep an eye on ongoing development of the protocol and make changes as required.

@@ -119,7 +119,7 @@ Response bodies only accompany responses whose header indicates a SUCCESS status

 Internet media types are registered with a canonical form.  Content transferred via Gemini MUST be represented in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph.

-When in canonical form, media subtypes of the "text" type use CRLF as the text line break.  Gemini relaxes this requirement and allows the transport of text media with plain LF alone (but NOT a plain CR alone) representing a line break when it is done consistently for an entire response body.  Gemini clients MUST accept CRLF and bare LF as being representative of a line break in text media received via HTTP.
+When in canonical form, media subtypes of the "text" type use CRLF as the text line break.  Gemini relaxes this requirement and allows the transport of text media with plain LF alone (but NOT a plain CR alone) representing a line break when it is done consistently for an entire response body.  Gemini clients MUST accept CRLF and bare LF as being representative of a line break in text media received via Gemini.

 If a MIME type begins with "text/" and no charset is explicitly given, the charset should be assumed to be UTF-8.  Compliant clients MUST support UTF-8-encoded text/* responses.  Clients MAY optionally support other encodings.  Clients receiving a response in a charset they cannot decode SHOULD gracefully inform the user what happened instead of displaying garbage.

-----END OF PAGE-----