💾 Archived View for gemi.dev › gemini-mailing-list › 000510.gmi captured on 2023-11-04 at 12:53:16. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Greetings Geminauts!
As per recent mailing list discovery, I've made a very small change to
the specification. Previously, Gemini requests and links in text/gemini
documents could both omit the scheme, and servers/clients were expected
to add an implicit scheme of "gemini". This has been changed and now
schemes are mandatory in URLs in both these contexts.
This is a trivial simplification of the spec, reflecting observations
from multiple people that schemeless URLs are both very rarely used and
very rarely understood (a leading "//" is required to disambiguate
schemeless URLs from relative URLs, but nobody knows that because
informal use of notation like gemini:// and https:// has caused us all
to mistakenly believe the "//" is associated with the scheme when it is
actually part of the authority). The implicit scheme idea dates back to
very early stages of Gemini when I was unduly concerned with minimising
protocol overhead relative to Gopher. As soon as mandatory TLS was
added, saving the 7 bytes of "gemini:" became of no practical concern
and getting rid of this idea just eliminates a confusing edge case.
On a related note, the spec was also changed in various places so that
it does not perpetuate the misunderstanding of URL structure by talking
about "a scheme of gemini://".
Server authors MAY update their servers to return status 59 ("bad
request") upon receipt of a request with no scheme in the URL, but this
should not be considered an urgent change, as leaving existing behaviour
of assuming a scheme of gemini in place could be considered a valid
application of Postel's law.
Client authors MUST update their clients so that if a user manually
enters a URL without a scheme, a scheme of gemini is included in the
request (many clients likely do this anyway). Clients MAY treat
schemeless links in text/gemini documents as errors, but again assuming
a scheme of gemini may be considered a valid application of Postel's
law.
Authors of Gemini content or software which generates Gemini content
MUST add explicit schemes to any schemeless links.
Cheers,
Solderpunk
On Sun, Nov 29, 2020 at 2:33 PM Solderpunk <solderpunk at posteo.net> wrote: 100% agreement up to this point. Clients MAY treat > schemeless links in text/gemini documents as errors, but again assuming > a scheme of gemini may be considered a valid application of Postel's > law. > They aren't errors: they are relative references. If a file "gemini:// example.net/this/that/file1.gmi" has a link saying " example.com/path/to/file2.gmi", for example, that does *not* mean in RFC 3986 "gemini://example.com/path/to/file2.gmi" but rather "gemini:// example.net/this/that/example.com/path/to/file2.gmi". So this is a Big Bang change in the interpretation of text/gemini files. But I am still for it, not against it. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org At the end of the Metatarsal Age, the dinosaurs abruptly vanished. The theory that a single catastrophic event may have been responsible has been strengthened by the recent discovery of a worldwide layer of whipped cream marking the Creosote-Tutelary boundary. --Science Made Stupid
On Sun Nov 29, 2020 at 4:33 PM EST, John Cowan wrote: > > Clients MAY treat > > schemeless links in text/gemini documents as errors, but again assuming > > a scheme of gemini may be considered a valid application of Postel's > > law. > > They aren't errors: they are relative references. If a file "gemini:// > example.net/this/that/file1.gmi" has a link saying " > example.com/path/to/file2.gmi", for example, that does *not* mean in RFC > 3986 "gemini://example.com/path/to/file2.gmi" but rather "gemini:// > example.net/this/that/example.com/path/to/file2.gmi". So this is a Big > Bang change in the interpretation of text/gemini files. But I am still > for it, not against it. I think that schemeless links in text/gemini documents should not be considered errors. Clients should resolve the relative reference before sending the request.
On Sunday, November 29, 2020, Solderpunk <solderpunk at posteo.net> wrote: > ... links in text/gemini > documents could both omit the scheme, and servers/clients were expected > to add an implicit scheme of "gemini". This has been changed and now > schemes are mandatory > This makes sense for requests because you are supposed to send an absolute URI anyway, but I strongly disagree with this change for documents. It is useful for those who serve the same content on HTTP and Gemini to be able to have links that work on both. I would appreciate it if schemeless links in gemtext continued to be allowed. PS: When replying to emails on the list do I reply to the person I am replying to and cc the list or just send to the list? -- ? <https://www.google.com/teapot>
(I keep replying only to the author and not the list, sorry.) I agree with everything up to this: > Clients MAY treat > schemeless links in text/gemini documents as errors, but again assuming > a scheme of gemini may be considered a valid application of Postel's > law. > > Authors of Gemini content or software which generates Gemini content > MUST add explicit schemes to any schemeless links. What is the issue with scheme-less link lines? These are perfectly valid, and any client with a good URL parsing library should support them. They are already in use by authors, and are of particular importance to sites that support bi-hosting on the Web and on Gemini, like flounder.online. That way the links users make will work in both spaces automatically. I believe this part of the change should be reversed, and schemeless links should be allowed. It is only the request part of the spec that was previously ambiguous. I'm sorry for not bringing this up earlier, I misunderstood the earlier discussion an did not realize that removing schemeless link support was on the table. makeworld
On Sun Nov 29, 2020 at 4:54 PM EST, wrote: > What is the issue with scheme-less link lines? These are perfectly valid, > and any client with a good URL parsing library should support them. They > are already in use by authors, and are of particular importance to sites > that support bi-hosting on the Web and on Gemini, like flounder.online. > That way the links users make will work in both spaces automatically. > > I believe this part of the change should be reversed, and schemeless links > should be allowed. It is only the request part of the spec that was > previously ambiguous. > > I'm sorry for not bringing this up earlier, I misunderstood the earlier > discussion an did not realize that removing schemeless link support was on > the table. I agree. When I proposed this change, I mentioned that schemeless links should still work: https://lists.orbitalfox.eu/archives/gemini/2020/003534.html > Linking to a URL without a scheme should still work. It would be up to > the client to resolve the URL reference before making the request. This > functionality should already be provided by whatever library the client > uses to handle relative URLs.
On 29-Nov-2020 21:54, colecmac at protonmail.com wrote: > (I keep replying only to the author and not the list, sorry.) > > > I agree with everything up to this: > >> Clients MAY treat >> schemeless links in text/gemini documents as errors, but again assuming >> a scheme of gemini may be considered a valid application of Postel's >> law. >> >> Authors of Gemini content or software which generates Gemini content >> MUST add explicit schemes to any schemeless links. > What is the issue with scheme-less link lines? These are perfectly valid, > and any client with a good URL parsing library should support them. They > are already in use by authors, and are of particular importance to sites > that support bi-hosting on the Web and on Gemini, like flounder.online. > That way the links users make will work in both spaces automatically. I think there is some confusion in this thread. Here is my interpretation, maybe it can help clarify the conversation. There are two "types" of link we are talking about. 1. The link lines in gemtext files (the line types beginning =>) In the first case, if you want a "schemeless" link (i.e. one that works for HTTP and Gemini) use the following form: \\server\path\to\endpoint If there is no scheme or double slash, the client should interpret the link as a relative path with respect to the current location. 2. The URL submitted to the server with the client request. This is where there is a change to the spec, which is now that the URL sent to the server must be a fully qualified link with a scheme. > Clients MAY treat > schemeless links in text/gemini documents as errors, but again assuming > a scheme of gemini may be considered a valid application of Postel's > law. Solderpunk mentioned (pasted text above) if there is no scheme, the
On 29-Nov-2020 22:06, Luke Emmet wrote: > > > On 29-Nov-2020 21:54, colecmac at protonmail.com wrote: >> (I keep replying only to the author and not the list, sorry.) >> >> >> I agree with everything up to this: >> >>> Clients MAY treat >>> schemeless links in text/gemini documents as errors, but again assuming >>> a scheme of gemini may be considered a valid application of Postel's >>> law. >>> >>> Authors of Gemini content or software which generates Gemini content >>> MUST add explicit schemes to any schemeless links. >> What is the issue with scheme-less link lines? These are perfectly >> valid, >> and any client with a good URL parsing library should support them. They >> are already in use by authors, and are of particular importance to sites >> that support bi-hosting on the Web and on Gemini, like flounder.online. >> That way the links users make will work in both spaces automatically. > > I think there is some confusion in this thread. Here is my > interpretation, maybe it can help clarify the conversation. > > There are two "types" of link we are talking about. > > 1. The link lines in gemtext files (the line types beginning =>) > > In the first case, if you want a "schemeless" link (i.e. one that > works for HTTP and Gemini) use the following form: > > \\server\path\to\endpoint > Oops - did you spot the obvious error (too many hours spent on UNC paths in Windows methinks) Of course, I meant: //server/path/to/endpoint - Luke
> I think there is some confusion in this thread. Here is my > interpretation, maybe it can help clarify the conversation. > > There are two "types" of link we are talking about. > 1. The link lines in gemtext files (the line types beginning =>) > [snip] > 2. The URL submitted to the server with the client request. I was only talking about the first kind in my email. I'm fine with the change to the request URL. > I think to clarify, if there is no scheme > on the URL sent to the server, it is the server that should respond > with an error (after all it is not a valid full URL that is submitted). > > If there is no scheme on the expressed link in the gemtext (type 1 > above), the client should interpret it as a relative path, unless it > starts "//" Yes, I agree with all of this. I take issue with two parts: > Clients MAY treat schemeless links in text/gemini documents as errors and > Authors of Gemini content or software which generates Gemini content > MUST add explicit schemes to any schemeless links. I think both of these changes are not great, as I explained in my original email. It effectively disallows schemeless links in gemtext, which I'm not in favour of. makeworld
On 29-Nov-2020 22:22, colecmac at protonmail.com wrote: > > [...] I take issue with two parts: >> Clients MAY treat schemeless links in text/gemini documents as errors > and > >> Authors of Gemini content or software which generates Gemini content >> MUST add explicit schemes to any schemeless links. > I think both of these changes are not great, as I explained in my original > email. It effectively disallows schemeless links in gemtext, which I'm > not in favour of. Ok - I'm following you now, and I think I agree about not needing this restriction in gemtext itself. on the first point, schemeless links of the form //authority/path in the gemtext are quite valid and will be mapped to gemini://authority/path in a gemini client and http://authority/path in a web client schemeless links of the form server.foo/path are not schemeless links, but rather relative paths with respect to the current URL. On the second point, gemtext generating software should allow for the //authority/path form of links. - Luke
On Sun, Nov 29, 2020 at 4:55 PM <colecmac at protonmail.com> wrote: > They are already in use by authors, and are of particular importance to > sites > that support bi-hosting on the Web and on Gemini, like flounder.online. > That way the links users make will work in both spaces automatically. > They are also important for capsules (or websites) with many internal links, as it makes them portable to other Internet locations. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Mark Twain on Cecil Rhodes: I admire him, I freely admit it, and when his time comes I shall buy a piece of the rope for a keepsake.
I can't find the change concerning the text/gemini media type reflected in the spec. Is there some version history which I could diff? This would simplify things a bit. So far, this part of the spec seems fine in my opinion, I would disagree with said change. RFC 3986 has a section on reference resolution (section 5) and even a pseudocode algorithm and a regex, this should be implemented anyway. I do not think the right way to go here is adapting the spec to mistakes people make, I rather think those mistakes should be fixed. RFC 3986 defines an unambigous set of valid URIs and their meaning. As I see it, the difference between URIs and URI References is important here. In Gemini requests, we ask for a specific, resource, so only a URI makes sense here, complete with a scheme, authority, path and query. This is now reflected in the spec, which I quite like! In Gemini documents however, where we refer to different resources, we use an URI Reference. Here, omitting the scheme has valid usecases, as have relative URI References. This is unambiguously defined in RFC 3986, I do not see a point in adding limitations where there is no ambiguity. In theory, software which generates Gemini content doesn't know over what protocol this content will be served, it may, for example, be HTTP. Thus, it can't possibly add an explicit scheme Furthermore, I do not know whether RFC 3986 even allows this limitation. It may well be that this is not our decision to make, following the RFC, although this is just speculation.
On Sun, Nov 29, 2020 at 07:38:21PM +0100, Solderpunk <solderpunk at posteo.net> wrote a message of 42 lines which said: > leaving existing behaviour of assuming a scheme of gemini in place > could be considered a valid application of Postel's law. Note that one of the reasons why the Web became so bloated is precisely Postel's law (the robustness principle). Browsers and servers violate the spec, these violations soon became de-facto-mandatory-to-support and one after the other, the "unofficial spec" became much larger than the real one. That's one of the reasons why Postel's law is quite criticized today <https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/>.
> > leaving existing behaviour of assuming a scheme of gemini in place > > could be considered a valid application of Postel's law. > > Note that one of the reasons why the Web became so bloated is > precisely Postel's law (the robustness principle). Browsers and > servers violate the spec, these violations soon became > de-facto-mandatory-to-support and one after the other, the "unofficial > spec" became much larger than the real one. I agree with the general principle that you should be conservative (even draconian) in your implementation. Stick to the specification, and keep the specification concise and unambiguous. If you receive requests or answers that don't adhere to the specification these should be treated as errors. A liberal or lenient interpretation of the spec leads to problems down the line. On the topic of explicit scheme in gemtext links I have one opinion and one question. Opinion: when cross-hosting between the web and geminispace I think the publisher can reasonably be expected to run a search-replace. If I host on both https://tilde.team/~ew0k/ and gemini://tilde.team/~ew0k/ I can easily make sure to replace that particular line in links. I see that there may be an issue if I link to someone else who also cross-posts, though... I'm willing to admit that the scheme should NOT be required in gemtext links. Question: How does this work with relative links in gemtext documents? Cheers, ew0k
It was thus said that the Great Bj?rn W?rmedal once stated: > On the topic of explicit scheme in gemtext links I have one opinion > and one question. > > Opinion: when cross-hosting between the web and geminispace I think > the publisher can reasonably be expected to run a search-replace. If I > host on both https://tilde.team/~ew0k/ and gemini://tilde.team/~ew0k/ > I can easily make sure to replace that particular line in links. I see > that there may be an issue if I link to someone else who also > cross-posts, though... I'm willing to admit that the scheme should NOT > be required in gemtext links. > > Question: How does this work with relative links in gemtext documents? Luke Emmet mentioned this, but I think it got lost. In text/gemini, the following are all legal links: => gemini://example.net/path/foo.gemini Absolute URL - fully specified => //example.net/path/foo.gemini relative URL - no scheme => /path/foo.gemini relative URL - no host => foo.gemini relative URL - no path => ../path/foo.gemini relative URL - relative It is up to the client to resolve these, using rules specified in RFC-3986 section 5.2. What Solderpunk just changed was the request *TO* a Gemini server. It used to be the following two forms were allowed when making a request to a Gemini server: gemini://example.net/path/foo.gemini //example.net/path/foo.gemini This was confusing, and so the schemeless format is no longer allowed when making a request to a Gemini server. The only form that is now allowed when making a request to a Gemini server is: gemini://example.net/path/foo.gemini -spc
November 30, 2020 5:07 AM, "Sean Conner" <sean at conman.org> wrote: > Luke Emmet mentioned this, but I think it got lost. In text/gemini, the > following are all legal links: > > => gemini://example.net/path/foo.gemini Absolute URL - fully specified > => //example.net/path/foo.gemini relative URL - no scheme > => /path/foo.gemini relative URL - no host > => foo.gemini relative URL - no path > => ../path/foo.gemini relative URL - relative > > It is up to the client to resolve these, using rules specified in RFC-3986 > section 5.2. > > What Solderpunk just changed was the request *TO* a Gemini server. It > used to be the following two forms were allowed when making a request to a > Gemini server: > > gemini://example.net/path/foo.gemini > //example.net/path/foo.gemini > > This was confusing, and so the schemeless format is no longer allowed when > making a request to a Gemini server. The only form that is now allowed when > making a request to a Gemini server is: > > gemini://example.net/path/foo.gemini > > -spc Not so. From Solderpunk's email that started the whole chain (emphasis mine): > Previously, Gemini requests *and links in text/gemini documents* could both omit the scheme, and servers/clients were expected to add an implicit scheme of "gemini". This has been changed and now schemes are mandatory in URLs in *both* these contexts. Correct me if I'm wrong (perhaps this is just an ambiguous statement I didn't pick up on), but the implication I got is that links now also need the gemini scheme. Also from Solderpunk's email (again, emphasis mine): > Authors of Gemini content or software which generates Gemini content MUST add explicit schemes to *any schemeless links*. Again, if all that was changed was the request side of things, this wouldn't need to be in the email. I'm all for getting rid of the ambiguity of schemeless URLs in requests, but not for link lines. Just my two cents, Robert "khuxkm" Miles
On Mon, Nov 30, 2020 at 3:28 AM Stephane Bortzmeyer <stephane at sources.org>
wrote:
Note that one of the reasons why the Web became so bloated is
> precisely Postel's law (the robustness principle). Browsers and
> servers violate the spec, these violations soon became
> de-facto-mandatory-to-support and one after the other, the "unofficial
> spec" became much larger than the real one.
>
Not that I was there at the time, but I firmly believe that Postel's law
has always meant "Don't exploit obscure features of the protocol when
sending; but do be prepared for them, as well as for outright errors, when
receiving", and so has nothing to do with trying to make sense of received
but invalid transmissions. RFC 1122 (1989) section 1.1.2 agrees with this
interpretation:
At every layer of the protocols, there is a general rule whose
application can lead to enormous benefits in robustness and
interoperability:
"Be liberal in what you accept, and
conservative in what you send"
Software should be written to deal with every conceivable
error, no matter how unlikely; sooner or later a packet will
come in with that particular combination of errors and
attributes, and unless the software is prepared, chaos can
ensue. In general, it is best to assume that the network is
filled with malevolent entities that will send in packets
designed to have the worst possible effect. This assumption
will lead to suitable protective design, although the most
serious problems in the Internet have been caused by
unenvisaged mechanisms triggered by low-probability events;
mere human malice would never have taken so devious a course!
Adaptability to change must be designed into all levels of
Internet [...] software. As a simple example, consider a
protocol specification that contains an enumeration of values
for a particular header field -- e.g., a type field, a port
number, or an error code; this enumeration must be assumed to
be incomplete. Thus, if a protocol specification defines four
possible error codes, the software must not break when a fifth
code shows up. An undefined code might be logged [...],
but it must not cause a failure.
The second part of the principle is almost as important:
software on other hosts may contain deficiencies that make it
unwise to exploit legal but obscure protocol features. It is
unwise to stray far from the obvious and simple, lest untoward
effects result elsewhere. A corollary of this is "watch out
for misbehaving hosts"; host software should be prepared, not
just to survive other misbehaving hosts, but also to cooperate
to limit the amount of disruption such hosts can cause to the
shared communication facility.
I think that implementers have in effect misunderstood the phrase "deal
with every conceivable error" as if it meant "accept every conceivable
error and try to act on it", but the context makes it clear (to me, at
least) that what is meant is "not crash on any conceivable error".
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
Almost all theorems are true, but almost all proofs have bugs.
--Paul Pedersen
Hi, if I am not mistaken there are some errors in your list of valid URI References. > => gemini://example.net/path/foo.gemini Absolute URL - fully > specified > => //example.net/path/foo.gemini??????? relative URL - no scheme > => /path/foo.gemini???????????????????? relative URL - no host > => foo.gemini?????????????????????????? relative URL - no path > => ../path/foo.gemini?????????????????? relative URL - relative First of, these are not URLs, RFC 3986 specifies URIs and URI References. As we are speaking about links, we need to speak about URI References rather then URLs or URIs. Note that this does not apply to requests, there we speak about URIs. So instead, this would be the terminology I would use: => gemini://example.net/path/foo.gemini URI Reference => //example.net/path/foo.gemini relative URI reference - no scheme, absolute path => /path/foo.gemini relative URI Reference - no host, absolute path => foo.gemini relative URI Reference - no host, relative path (Note that this is not a reference without a specified path, for that, it would have to begin with //.) => ../path/foo.gemini relative URI Reference - no host, relative path The following examples would also be valid: => gemini://example.net URI Reference - empty path => //example.net relative URI Reference - no scheme, empty path => / relative URI Reference - no host, absolute path Looking at the ABNF in Appendix A of RFC 3986, this gets pretty clear. IMO the current solution is pretty good, requiring a URI for requests and a URI Reference for links, this is as it should be. If I read the spec change email correctly, now text/gemini documents also require full URIs in the links, I don't think of this as a good idea
On Monday, November 30, 2020, Waweic <waweic at activ.ism.rocks> wrote: > The following examples would also be valid: > > => gemini://example.net URI Reference - empty path > => //example.net relative URI Reference - no > scheme, empty path > => / relative URI Reference - no > host, absolute path What would => . relative URI Reference - no host, relative path do? Reload the current page? -- ? <https://www.google.com/teapot>
> What would > => .??????????????????????????????????? relative URI Reference - no > host, relative path > do? Reload the current page? If I am not mistaken, it should load the current directory. So if you are currently at ```gemini://example.net/a/b/c.gmi``` It would read ```gemini://example.net/a/b/.``` which would be normalized as ```gemini://example.net/a/b/``` In theory, it should be possible to have an empty path as a URI Reference, or an empty path with a query and / or a fragment. I don't think it's possible to have this situation in Gemini.
On Monday, November 30, 2020 12:51 AM, Waweic <waweic at activ.ism.rocks> wrote: > I can't find the change concerning the text/gemini media type reflected > in the spec. Is there some version history which I could diff? This > would simplify things a bit. Solderpunk made a git repo a while back... ? curl -sSL https://lists.orbitalfox.eu/archives/gemini/2020.txt.gz | gzip -dc | grep 'git://' git clone git://gemini.circumlunar.space/gemini-site Ah, there it is. If you clone that you'll get the full site, including the spec changes. The scheme change is commit e7b5c52. I've attached the diff for easy viewing as well. The important part is that when describing links lines in section 5.4.2, this change was made: -* <URL> is a URL, which may be absolute or relative. If the URL does not include a scheme, a scheme of gemini:// is implied. +* <URL> is a URL, which may be absolute or relative. Two things: As other emails have mentioned, this should be a URI reference, not a URL. And if a scheme of 'gemini' is not there, it SHOULD be implied. But this is already covered by the URI spec, afaik. makeworld
On Mon, Nov 30, 2020 at 06:51:23AM +0100, Waweic wrote: Hi! > I can't find the change concerning the text/gemini media type reflected > in the spec. Is there some version history which I could diff? This > would simplify things a bit. Sure! https://lists.orbitalfox.eu/archives/gemini/2020/002428.html Hope this was what you was looking for! :) Bye! C.
It was thus said that the Great Robert khuxkm Miles once stated: > November 30, 2020 5:07 AM, "Sean Conner" <sean at conman.org> wrote: > > > What Solderpunk just changed was the request *TO* a Gemini server. It > > used to be the following two forms were allowed when making a request to a > > Gemini server: > > > > gemini://example.net/path/foo.gemini > > //example.net/path/foo.gemini > > > > This was confusing, and so the schemeless format is no longer allowed when > > making a request to a Gemini server. The only form that is now allowed when > > making a request to a Gemini server is: > > > > gemini://example.net/path/foo.gemini > > > Not so. From Solderpunk's email that started the whole chain (emphasis > mine): > > > Previously, Gemini requests *and links in text/gemini documents* could > > both omit the scheme, and servers/clients were expected to add an > > implicit scheme of "gemini". This has been changed and now schemes are > > mandatory in URLs in *both* these contexts. > > Correct me if I'm wrong (perhaps this is just an ambiguous statement I > didn't pick up on), but the implication I got is that links now also need > the gemini scheme. Also from Solderpunk's email (again, emphasis mine): No, you are right, I misread his email. I personally think he made a mistake here in removing relative links (which include schemeless links) from text/gemini. -spc
On Mon Nov 30, 2020 at 10:27 PM CET, Sean Conner wrote: > No, you are right, I misread his email. I personally think he made a > mistake here in removing relative links (which include schemeless links) > from text/gemini. Oh, gosh darn it. I obviously didn't mean to do that. This is what I get for trying to squeeze spec changes into small slices of free time. Sorry, everyone. I will fix this tomorrow. Cheers, Solderpunk
> Oh, gosh darn it. I obviously didn't mean to do that. This is what > I > get for trying to squeeze spec changes into small slices of free > time. > Sorry, everyone. I will fix this tomorrow. I think the actual change in the spec is fine, it doesn't disallow relative URI References, (called Relative URLs in the spec, which should be changed imo) it even explicitly allows them. Assuming a scheme of gemini:// (which was removed) would be wrong, since a text/gemini document could be accessed via other protocols. So, apart from the URL / URI / URI Reference stuff, I think the spec is on point here
On Sun, 29 Nov 2020 19:38:21 +0100 "Solderpunk" <solderpunk at posteo.net> wrote: > On a related note, the spec was also changed in various places so that > it does not perpetuate the misunderstanding of URL structure by talking > about "a scheme of gemini://". This is a welcome change! I also want to suggest clarifying the meaning of absolute/relative URLs by referring to the corresponding concepts in RFC 3986. The primary reason for this suggestion is that it may be unclear whether an "absolute URL" is what RFC 3986 calls an "URI", an "absolute-URI" or what RFC 1808 calls an "absolute URL", all of which are subtly different:
On Mon Nov 30, 2020 at 11:03 PM CET, Solderpunk wrote: > > No, you are right, I misread his email. I personally think he made a > > mistake here in removing relative links (which include schemeless links) > > from text/gemini. > > Oh, gosh darn it. I obviously didn't mean to do that. This is what I > get for trying to squeeze spec changes into small slices of free time. > Sorry, everyone. I will fix this tomorrow. ...wait. I didn't actually remove relative links at all. That's a relief. I was tired when I saw Sean's email and assumed the first! I just went through everything again. My email to this list explaining the changes I made didn't square up with the actual changes I made to the spec. Sorry for the confusion. To be very clear, relative links are absolutely still permitted in text/gemini documents, and in fact even schemeless links are still permitted in text/gemini documents. The only actual change to the spec that pertains to => links is that I removed the part saying that if there was no scheme the client should assume one of gemini://. This, I think, is actually fine - see Alex Schroeder's post on the nice use of these rare kind of link for serving text/gemini over other protocols: gemini://alexschroeder.ch/page/2020-11-30_Gemini_specification_changes_in_a _disagreeable_way Schemeless links are only forbidden in requests, i.e. what a client sends to a server. Sorry again for the confusion. I hope this won't happen again, and I hope it would also be obvious, but for the record, where a change to the spec and my announcement to the spec don't match up, the actual spec document is, of course, authoritative. Cheers, Solderpunk
---
Previous Thread: CGI and client certificate, or do we need a CGI spec