[announce] Delegation of responsibility for spec finalisation

[Juan J. Martinez]

On 02/03/2021 00:23, Scot wrote:
>[...]
> 
> After writing C and Python client and server implementations
> last fall, and examing packet traces, my conclusion was that
> this does not work with most TLS libraries. Mostly, they will
> close the connection in both directions if they receive a
> close_notify. Some of this is documented here [1]. This in
> turn causes problems for programming languages which
> expect a given library to behave in a certain way. For example,
> Python still does not allow sending a close_notify from the
> client after the request has been delivered and before
> receiving the response [2].
> 
> So, in my opinion, the simplest thing would be to utilize the
> <CR><LF> of the Gemini request to indicate that the client
> is finished sending its request.
> 
> Three benefits of this approach would be:
> 
> 1. All Gemini clients will keep working right now without changes
> 
> 2. Because the <CR><LF> can be explicitely sent by a client
> application and explicetely examined by the server application,
> without broken TLS libraries intervening, it is easy to correctly
> implement
> 
> 3. Gemini client authors will not experience intense frustration
> at the sad state of TLS library support for half-open close_notify
> (this is the voice of experience speaking...)

I'm not in any way a TLS expert, but I think you're right: TLS 1.2 uses 
a duplex-close policy (while TLS 1.3 uses a half-close policy, so that 
should work better).

IMHO the spec should probably refer to the RFC when available and 
perhaps make a recommendation, but getting into specific details on how 
the TLS implementation must behave is hairy and probably not practical.

As long as the spec is clear, real world can differ and still work, and 
that's OK.

Regards,

Juan

-- 
Website: usebox.net/jjm/
Twitter: @reidrac