Progress on closing GitLab issues

I have read gemini://geminiprotocol.net/news/2024_08_15.gmi and I have some
comments. (I have not read the GitLab issue tracker, since my computer does
not display them. So, be aware of this as you read the below comments.)

P19: I read the new spec, which says "the client MUST replace the query
string with the user input". This is also what I thought it should do, since
it is how relative URLs are working.

P22: This is about licensing. Public domain equivalent is a good choice, so
this is good. (There might be a reason to ensure that unofficial modified
versions are not confused with the original version, but ND should not be
required in order to do that. There should not be any reason to need NC for
these specifications, as far as I know.)

G05: It is good.

G07 and G14: I agree, it is a good idea to use ABNF for this. However,
maybe preformatted text lines should have their own definitions in ABNF;
this could be done by defining a preformatted block as a ABNF instead of
preformatting toggle lines.

P12: I am not so sure that client certificates should be disallowed if you
do not use TLS 1.3, although the client should warn you before sending a
certificate, since TLS 1.2 does not encrypt client certificates. The
specification already says this. The specification should recommend that
servers and clients should implement TLS 1.3.

P18: Like I said, I don't know what the issue tracker says. If I knew,
then I might have a further comment about this.

P23: Clients should probably disable TLS session resumption by default,
but may enable it if client certificates are used (although it should
be possible for the user to configure it to disable it in this case too).
If the client certificate is removed or changed, then the session
resumption also should be removed or changed.

G10: In my opinion it would be simpler to require exactly one space (not a
tab) after => and after the URL, although the specification says otherwise,
so perhaps it is not the time to change it now. I don't remember if I have
seen files that omit the space after => although the specification says it
is required. The specification says that spaces are optional for heading
lines but mandatory for links. I don't know whether or not this should be
changed and what it should be changed to.

G03: What the fragment part does is not specified for Gemini. There are a
few possibilities; maybe they are discussed in GitLab (as I said, I did not
read them). One would be to add something at the end of the heading to
specify the name to refer to that heading in URLs.

P08: Redirection with fragments (if that is what they mean by "frags") is
confusing. (My Scorpion protocol specification says that fragment parts of
URLs should (but are not required to) be kept if the URL being redirected
to does not have its own fragment part, but this will not always be
desirable, so it is unclear which way is better.)

P15: I think error messages should always be displayed to users if the
client would display anything to the user (which most do).

P17: I also believed status type 11 should be removed (and the specification
I made of Scorpion protocol does not have it), since it is not a good way
of handling passwords.

P33: Maybe you should send SNI with the IP address, if the URL specifies
the IP address but not the domain name. (If you deliberately want to send a
domain name, the user might manually set the IP address corresponding to
that domain name (e.g. in the /etc/hosts file) and then just use the domain
name in the URL. Some clients might include further controls over this; my
own "astroget" program has a -A switch to override the IP address and port
number to connect to instead of using the URL to decide.)

P36: Unicode byte order marks should not be allowed at the beginning of the
request. If a text/gemini file begins with a Unicode byte order mark then it
should treat that line as a plain line and not a heading or something else.
(I avoided this mess in mine by not using Unicode. But, even if you do use
Unicode, this seems like the most sensible thing to do, anyways.)

P01: My opinion is that IRI is no good.

G08: I would disallow non-ASCII characters in the domain name. In the rest
of the URL, non-ASCII bytes might be allowed, but probably it is best not to
use non-ASCII bytes in the URL, in case the client converts the character
encoding, since some will do so and then the URL will not necessarily be
valid. (Again, I avoided this mess in mine by not using Unicode.)

G17: This is also something that I had thought of. The best way to fix it
in my opinion would be for the starting and ending lines of a preformatted
block to match, although some people have objected to this, so maybe it is
not the best way to do it.

At the bottom they say that many of the TLS related issues are not actually
within the scope of the formal specifications, and I think that is correct;
some of them should go in a best practices document instead.

--
Don't laugh at the moon when it is day time in France.