💾 Archived View for gemi.dev › gemini-mailing-list › 000463.gmi captured on 2023-12-28 at 15:47:40. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-11-04)

🚧 View Differences

-=-=-=-=-=-=-

Clarifications to the Spec

1. Adnan Maolood (me (a) adnano.co)

Based on recent discussion, I believe the following clarifications
should be made to the spec:

- Is it valid for META to contain the line feed character?
	10 Is\nThis\nValid?\r\n
- Is it valid for META to be empty?
- Should servers be required to send TLS close_notify?

Link to individual message.

2. Johann Galle (johann.galle (a) protonmail.com)

> -   Is it valid for META to contain the line feed character?
>     10 Is\nThis\nValid?\r\n

As it stands, it should be legal because \n can be distinguished from \r\n. But
I think not many clients are as strictly written to the spec as to handle this
correctly, most would probably consider the meta ended after the first \n.

My personal opinion is that it should not be allowed and that the line ending
should be just \n, but maybe this is a use case that was considered when writing
the gemni spec?

> -   Is it valid for META to be empty?

I do not see a reason why it should never be allowed to be empty from the spec.
It only states a max length of 1024 bytes and UTF-8 encoding. (?3.1)
In some cases I would consider it illegal in context with 3x status codes.

Reasonable behaviour of a client for empty META would be IMHO:
????????????????????????????????????????????????????????????????????????????????
?1x?Display as normal, but the user gets no message. This might look strange,  ?
?  ?but that is something the particular server admin should fix, not gemini.  ?
????????????????????????????????????????????????????????????????????????????????
?2x?Assume a default MIME type of text/gemini.                                 ?
????????????????????????????????????????????????????????????????????????????????
?3x?This should be a hard error, the sentence in ?3.2.3 might be rephrased as: ?
?  ?"<META> MUST be a new URL for the requested resource."                     ?
????????????????????????????????????????????????????????????????????????????????
?4x?Show a default error message, which might be based on the exact status code?
?5x?                                                                           ?
????????????????????????????????????????????????????????????????????????????????
?6x?No difference, META is only informational.                                 ?
????????????????????????????????????????????????????????????????????????????????

> -   Should servers be required to send TLS close_notify?

I think it has been laid out that this is included in the TLS spec and thus it
is non-optional. Also, the spec explicitly states that the server closes the
connection which - with TLS - includes sending close_notify.

Link to individual message.

3. Sudipto Mallick (smallick.dev (a) gmail.com)

In my opinion, we should not allow empty META because it's not worth it.

For those who want to know about why CR LF is used in internet
protocol, here's a little bit of history:
https://www.rfc-editor.org/old/EOLstory.txt

~smlckz

Link to individual message.

4. Johann150 (johann.galle (a) protonmail.com)

> Reasonable behaviour of a client for empty META would be IMHO:
> -SNIP-

I just wanted to add that there is a thread regarding this topic -
"0-length META" to be exact - in the mailing list archive and that thread might
be interesting to read too:
<gemini://gemi.dev/gemini-mailing-list/messages/003009.gmi>

Link to individual message.

---

Previous Thread: [ANN] New server gemini.crowesnest.io

Next Thread: [ANN] stargazer - A new gemini server