[spec] Oustanding issues

[Johann Galle]

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://mailing-list-archive.gemi.dev/www/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://mailing-list-archive.gemi.dev/www/attachments/20201227/0895ac48/attachment-0001.sig>