[spec] Oustanding issues

Johann Galle johann at qwertqwefsday.eu
Sun Dec 27 17:54:38 GMT 2020


On 2020-12-27T10:47Z, Solderpunk wrote among other things:
 > * Clarification on the use of TLS close_notify has been requested.
 >   This is actually mandated by both TLS 1.2 and 1.3 specs so technically
 >   it's redundant to mention it in the Gemini spec, but given how poorly
 >   implemented it is, some explicit reminding could not hurt.  I think
 >   there's a tiny wrinkle to consider here on *when* the client should
 >   send this (due to a change in semantics between TLS 1.2 and 1.3).
 > * The spec is a bit vague on under which circumstances the META part of
 >   a response header may be empty, and on exactly what that means (e.g.
 >   is a tab after the status code still required in any case?). This
 >   needs to be tightened up, and I'm pretty sure this should be done by
 >   just making non-empty META a requirement.

As you have now mentioned these two issues, there was a mail with these two and
another issue[1], namely if lone LFs (or lone CRs or other line breaking code
points for that matter) are allowed inside META.

Johann

[1] https://lists.orbitalfox.eu/archives/gemini/2020/003276.html
---
You can verify the digital signature on this email with the public key
available through web key discovery. Try e.g. `gpg --locate-keys`...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/0895ac48/attachment-0001.sig>


More information about the Gemini mailing list