Proposed minor spec changes, for comment.

[Luke Emmet]

On 21-May-2020 22:50, Martin Keegan wrote:
> On Thu, 21 May 2020, Luke Emmet wrote:
>
>> If we force one line ending kind on authors, it will be a deterrent 
>> to them forging ahead with writing user content if they have to use 
>> some tool just to be able to get the content onto the server. Look at 
>> XHTML, it was a resounding failure and rejected by authors even 
>> though there were some good (and ill conceived) intentions of the 
>> spec writers.
>
> I believe there's a difference between requiring servers only to use 
> CRLF in the body, and content authors only to use CRLF. If it were 
> specified that servers "MUST NOT" send text/gemini bodies that use 
> line separators other than CRLF, then it remains up to server 
> implementers to choose whether
>
> 1) to require content authors to develop or save their content with 
> CRLFs, or
>
> 2) to translate the content themselves (either on the fly, or by
> caching a fettled version with the right line separators).

I see better now what the alternative suggestions are, thanks.

I still think a robust client has to in all likelihood anticipate both 
CRLF and LF. There will be a range of servers out there and just getting 
the content of the file sent to you isnt going to be unusual. Probably 
plain Mac/CR is too ancient to be widely found, but see below.

Another consideration that comes to me now is for any applications of 
Gemini that might require a binary correct transfer of a text file from 
A to B. For example if we are gemini as a content transfer layer for a 
source code repository. There is already a Git over gemini service which 
seems interesting. In these scenarios as the end user, you would expect 
that a GMI file served to you from the repo was the same as it is on the 
server. So I think we should support all "normal" plain text formats as 
the response body and not in general have the server munging or 
adjusting them.

Best Wishes

  - Luke