[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