💾 Archived View for gemi.dev › gemini-mailing-list › 000573.gmi captured on 2023-12-28 at 15:49:26. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
SEDR 300 VOLUME I PROJECT GEMINI familiarization manual LONG RANGE and MODIFIED CONFIGURATIONS https://www.ibiblio.org/apollo/Documents/GeminiManualVol1.pdf I suggest the following deliverables for 2021: 1 ? RFC x1965 The Gemini Protocol: describes the over-the-wire protocol itself 1 ? RFC x1966 The Gemini Document:. describes the text/gemini document format The above are normative, neutral in tone, IETF RFC style documents with interaction diagrams, syntax grammar, security considerations, and all. Dry & pedantic. 1 x RFC x1967 Gemini Implementation Recommendations: opinion piece about what Gemini is meant to be, its philosophy, its origin story. Plus practical bits and pieces. Not normative. 1 x IANA Registration for URI scheme gemini://:1965 1 x IANA Registration for Media Type text/gemini 1 x cURL gemini://: implementation as per https://curl.se/dev/new-protocol.html Miscellanies: A version control systems to support such collaborative work process. A more preeminent domain name, such as gemini.info, gemini.xyz or something to host all of the above. Plus matching social media presence, @gemini everywhere. Thoughts? Opinions? Suggestions?
On Sun Dec 27, 2020 at 4:32 PM CET, Petite Abeille wrote: > The above are normative, neutral in tone, IETF RFC style documents with > interaction diagrams, syntax grammar, security considerations, and all. > Dry & pedantic. This is basically the plan, I just want to get the current less formally structured specification finalised before starting. Translating it to a proper RFC while it's still undergoing changes does not seem like a good use of time/energy. > 1 x IANA Registration for URI scheme gemini://:1965 > 1 x IANA Registration for Media Type text/gemini We are not guaranteed to be able to get port 1965, as it's already assigned by IANA - to some apparently obsolete commercial protocol now owned (but not, as far as I can tell, actively used or promoted) by IBM. I have no idea what IANA's policy on re-assigning previously assigned port numbers is. To my mind, permanently assigning numbers to proprietary/commercial protocols is a bad idea as they are unlikely to have long lifespans, but this is all obviously out of our hands. So the final port number may end up changing. That's a shame, but it should be an extremely easy fix to existing software. I also don't know how the chicken-egg problem is usually resolved whereby when applying for a port number registration from IANA you need to give them a reference to a stable description of the protocol, but obviously said stable description cannot, at that point in time, contain the as-yet unassigned port number. But obviously there is a way to handle this, and we'll deal with it when the time comes. > A more preeminent domain name, such as gemini.info, gemini.xyz or > something to host all of the above. This is also something I'm planning. Everything currently lives at circumlunar.space because I already owned the domain and, in the early days, it was not clear things would come as far as they have and that buying a new domain was warranted. Going forward, I would like a clearer separation between these two projects. Naturally, I'll maintain permanent redirects for a substantial time after the change. > Plus matching social media presence, > @gemini everywhere. I have zero interest in running that myself, and don't really see enough value in it to delegate that task to somebody else. The most enthusiastic uptake of Gemini has been people who I suspect have very similar feelings. It seems a poor cultural match. Cheers, Solderpunk
> On Dec 27, 2020, at 17:17, Solderpunk <solderpunk at posteo.net> wrote: > > This is basically the plan, I just want to get the current less formally > structured specification finalized before starting. Yes, once all the current open issues are settled. Sounds like a plan. 2021 is going to be groovy.
On Sun, Dec 27, 2020 at 10:32 AM Petite Abeille <petite.abeille at gmail.com> wrote: > 1 ? RFC x1965 The Gemini Protocol: describes the over-the-wire protocol > itself > 1 ? RFC x1966 The Gemini Document:. describes the text/gemini document > forma > +1. Note, however, that creating standards-track RFCs (as I hope we will) implies the possibility that the IETF WG will make changes. If the present Gemini community doesn't want to give up change control, we can publish an informational RFC instead. Anyone with an email address can join an IETF WG, however, so we can still have influence, just not control. > 1 x RFC x1967 Gemini Implementation Recommendations: opinion piece about > what Gemini is meant to be, its philosophy, its origin story. Plus > practical bits and pieces. Not normative. > Typically documents like this are not RFCs nowadays. 1 x IANA Registration for URI scheme gemini://:1965 > 1 x IANA Registration for Media Type text/gemini > There is no reason not to merge the IANA registrations into the main documents. Separate RFCs have been used in the past when the protocol or media type was already in use but there was no existing URI scheme. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Heh, heh: ... or three pairs of wheels? I wonder what would have happened if Ravna had just read a little further. In some weird way, Twirlip knows the Secret of the Riders. --Vernor Vinge, note 601 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/2a2a 7d46/attachment.htm>
On Sun Dec 27, 2020 at 9:21 PM CET, John Cowan wrote: > +1. Note, however, that creating standards-track RFCs (as I hope we > will) > implies the possibility that the IETF WG will make changes. If the > present > Gemini community doesn't want to give up change control, we can publish > an > informational RFC instead. Anyone with an email address can join an IETF > WG, however, so we can still have influence, just not control. This is something I've been concerned about (slightly, distantly). I haven't looked much into the IETF/IANA processes yet because, as I've said, I want to focus on first getting the final details locked down so we can start productively working toward it. But I have wondered exactly what is involved and to what extent we sacrifice control. I have a generally positive perception of the IETF, but I am also acutely aware that the cultural/ideological perspective of Gemini folks is rare and unusual in the wider world, and I don't know to what extent it would be valued and preserved by a standards body that necessarily nowadays must have quite strong ties to the exactly the kind of big, powerful commercial entities that Gemini is trying to provide an escape from... Cheers, Solderpunk
> On Dec 27, 2020, at 21:31, Solderpunk <solderpunk at posteo.net> wrote: > > the cultural/ideological perspective of Gemini folks is rare and unusual in the wider world Yes, diversity is valuable, and an added value to Gemini as it makes it stand out from the commercial crowd; but the Internet Engineering Task Force (IETF) concerns itself with engineering issues, not cultural ones. I don't foresee any engineering issues if we do our due diligence. If, somehow, things get derailed, an informational RFC is as good as a standard-track for the intended purpose of formally describing the protocol. Irrespectively, the value added of the IETF is its process and formalism. It's up to us to raise to their standard.
> On Dec 27, 2020, at 21:21, John Cowan <cowan at ccil.org> wrote: > > 1 x IANA Registration for URI scheme gemini://:1965 > 1 x IANA Registration for Media Type text/gemini > > There is no reason not to merge the IANA registrations into the main documents. Separate RFCs have been used in the past when the protocol or media type was already in use but there was no existing URI scheme. Sure. Didn't mean they have to be separate documents (even though there is a bit of bureaucracy involved), but rather to list them as TODOs.
>> A more preeminent domain name, such as gemini.info, gemini.xyz or >> something to host all of the above. > > This is also something I'm planning. Everything currently lives at > circumlunar.space because I already owned the domain and, in the early The big problem with that is that since Gemini is a relatively common name, most domains are taken. After reading this thread, just out of interest, I contacted the seller(/scalper/) of gemini.net; they're quoting about $30k which is probably too much, even though that domain is just parked. -- Karmanyaah Malhotra https://karmanyaah.malhotra.cc/contact/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/fa55 61fd/attachment-0001.sig>
On Sun, Dec 27, 2020 at 3:36 PM Solderpunk <solderpunk at posteo.net> wrote: But I have wondered > exactly what is involved and to what extent we sacrifice control. I > have a generally positive perception of the IETF, but I am also acutely > aware that the cultural/ideological perspective of Gemini folks is rare > and unusual in the wider world, and I don't know to what extent it would > be valued and preserved by a standards body that necessarily nowadays > must have quite strong ties to the exactly the kind of big, powerful > commercial entities that Gemini is trying to provide an escape from... > I'd say it has the fewest possible such ties, less than any other standards organization except the ISO (whose members are countries). While it's true that most IETF participants (= members) are there as part of their paid employment, the IETF makes it very clear that nobody speaks for anyone or anything except themselves. "The Tao of IETF" spells this out in great detail. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/998d 4eec/attachment.htm>
> On Dec 27, 2020, at 23:20, Karmanyaah Malhotra <karmanyaahm at gmail.com> wrote: > > gemini.net Perhaps gemi.ni if one can get the Nicaraguans to cooperate :D Alternatively, geminiprotocol.dev goes for a low-low price of $15.99! Going fast! Get it now! While supplies last!
On Sun Dec 27, 2020 at 11:20 PM CET, John Cowan wrote: > I'd say it has the fewest possible such ties, less than any other > standards > organization except the ISO (whose members are countries). While it's > true > that most IETF participants (= members) are there as part of their paid > employment, the IETF makes it very clear that nobody speaks for anyone > or > anything except themselves. This is very encouraging, thank you! > "The Tao of IETF" spells this out in great > detail. For anybody else curious: https://www.ietf.org/about/participate/tao/ Cheers, Solderpunk
> On Dec 27, 2020, at 23:20, John Cowan <cowan at ccil.org> wrote:
>
> "The Tao of IETF" spells this out in great detail.
# wc rfc4677.txt
2946 18541 127593 rfc4677.txt
?I didn't have time to write a short letter, so I wrote a long one instead.?
-- Mark Twain, allegedly
https://quoteinvestigator.com/2012/04/28/shorter-letter/
> On Dec 27, 2020, at 22:43, Petite Abeille <petite.abeille at gmail.com> wrote: > > I don't foresee any engineering issues if we do our due diligence. Honestly, I do have doubts now. Engineering wise. This is not meant to be insulting to anyone's ego, but let's be realistic about our technical acumen, or possible lack thereof. We do not appear to understand the two basic building blocks around which the whole of Gemini is constructed: URL and UTF-8. ? Not to mention how they relate to each other. Exhibit ? 1: the path segment discussion Neither Stephane, who has spend his entire adult life versed in RFC literature, nor Sean, a technical master if there is one, nor even Google's own Go library, get it right. In 2020. Path segments have been around since time immemorial. They are not optional. It's not a "nice to have". Not understanding them betray a fundamental misunderstanding of what an URL is. Exhibit ? 2: the URI vs. IRI saga The only difference between URI & IRI is the ASCII armor around UTF-8. They are identical otherwise. They can both represent UTF-8, and therefore Unicode. Just differently. And yet the conversation has been everywhere but at the crux of the issue, which is Unicode. As always. Just yesterday, Soldierpunk had his eureka moment: "...and actually, now that I think about, this issue is not specific to IRI support, is it? " You are not saying. Nothing to do with IRI indeed. Everything to do with Unicode, as always. I do appreciate we all have different level of technical understandings, and it never stops. Turtles all the way down. But still, this is meant to be about designing a formal protocol. We must understand these basic building blocks to succeed. On the other hand, there is Solene, who single-handily, without blinking, demonstrates what the essence of an IRI is, with ? a dozen lines of old fashioned C code. ? So perhaps not everything is lost. But what a slog. ? Ignoring TLS, no one understand it. ? Yes, ? some details. But see Exhibit ? 1 and ? 2.
It was thus said that the Great Petite Abeille once stated:
>
> We do not appear to understand the two basic building blocks around which
> the whole of Gemini is constructed: URL and UTF-8. ?
>
> Not to mention how they relate to each other.
>
> Exhibit ? 1: the path segment discussion
>
> Neither Stephane, who has spend his entire adult life versed in RFC
> literature, nor Sean, a technical master if there is one, nor even
> Google's own Go library, get it right. In 2020.
>
> Path segments have been around since time immemorial.
Nope. The first RFC to specify the format for URLs is RFC-1630 (June
1994), and no path segments (as currently defined). It's not until four
years later, with RFC-2396 (August 1998) that we get the first recognizable
path segment (with path parameter).
> They are not optional. It's not a "nice to have". Not understanding them
> betray a fundamental misunderstanding of what an URL is.
First off, SETTLE DOWN!
Second, just because a feature exists doesn't mean it's actually used.
Here's a task---find ONE example out on the web where %2F has semantic
meaning *other* than a path separator, *in the path segment* of a URL (other
than your own stuff). I've been using the web since the early 90s, and I
don't think this has actually been done. I don't think I've even seen path
paramters (using the ';' sub-delimeter) used! [1]
I suspect no one got "it right" because it's just not a thing (either
encoded slashes, or path parameters) that have actually been needed. Go's
take is probably the best you can find, with both decoding it and having the
raw path available.
Even the modern concept of a URL, from the WhatWG [2], is getting away
from this. As defined there, the "path percent-encode set" is:
U+0000 .. U+001F
U+007F .. U+10FFFF
U+0020 SPACE
U+0022 "
U+0023 #
U+0025 %
U+003C <
U+003E >
U+003F ?
U+0060 `
U+007B {
U+007D }
Nothing about U+002F ('/'). I'm not saying we need to switch from
RFC-3986 (or RFC-3987) and use the WhatWG definition of a URL, but the
WhatWG is very pragmatic and are looking at *what is actually being used,*
not *what can be used.*
Here's another task---create a Gemini server where %2F *is required* to
retrieve the resource. Then see how many clients can actually query it, and
then convince all the client authors to fix their code.
Good luck. We're counting on you.
> Exhibit ? 2: the URI vs. IRI saga
[ snip ]
> On the other hand, there is Solene, who single-handily, without blinking,
> demonstrates what the essence of an IRI is, with ? a dozen lines of old
> fashioned C code. ?
Yes, I can believe it. If you aren't really doing any heavy text
processing, then even parsing "byte-by-byte" can work well with UTF-8. I
wrote my own blogging engine [3] assuming only US-ASCII, and it works just
fine with UTF-8. Hell, even my own very simplistic URL parser I wrote back
in the mid-90s parsed a IRI just fine, but that's down to a lax parser.
Compare that with my own URL parser [4], based off the BNF of RFC-3986,
won't deal with an IRI, because of the stricter requirements.
I'm not intentionally belittling Solene, I'm just pointing out that
supporting UTF-8, depending on the processing, just sometimes happens "for
free". I also recall there being an issue with Solene's client not
supporting port numbers, so it's not always perfect engineering.
A third task for you---try writing code to properly wrap *this* page:
gemini://gemini.conman.org/test/torture/0049
You can assume a monospace font and a width of 80 character cells (aka, a
typical terminal width).
Good luck. We're counting on you.
-spc
[1] There were originally defined for ftp: URLs in RFC-1630, and only
applied after the path.
[2] https://url.spec.whatwg.org/#percent-encoded-bytes
[3] https://github.com/spc476/mod_blog
[4] https://github.com/spc476/LPeg-Parsers/blob/master/url.lua
> On Dec 30, 2020, at 00:19, Sean Conner <sean at conman.org> wrote: > > First off, SETTLE DOWN! :) > Second, just because a feature exists doesn't mean it's actually used. https://en.wikipedia.org/wiki/A%2FB_testing
It was thus said that the Great Petite Abeille once stated: > > On Dec 30, 2020, at 00:19, Sean Conner <sean at conman.org> wrote: > > > > First off, SETTLE DOWN! > > :) > > > Second, just because a feature exists doesn't mean it's actually used. > > https://en.wikipedia.org/wiki/A%2FB_testing Touch?. One task down, you have two left. Good luck. We're counting on you. -spc
> On Dec 30, 2020, at 00:28, Sean Conner <sean at conman.org> wrote: > > Touch?. > > One task down, you have two left. > Right. Second task: considering we cannot even agree what an URL is, ?20 years later, it's rather pointless to try with Gemini, where the concept is truly alien, "radical familiarity" notwithstanding. Third task: wrap *this* page. Hmmm. Why would I? What does it has to do with anything? Is that a throw back from the textflow mega thread? Long, uninterrupted sequences of random characters are not unique to Unicode. Or is the distinction between characters vs bytes? Then yes, it's 2020. Randomly chopping bytes is not appropriate indeed.
> On Dec 30, 2020, at 00:41, Petite Abeille <petite.abeille at gmail.com> wrote: > > Long, uninterrupted sequences of random characters are not unique to Unicode. Or is the distinction between characters vs bytes? Then yes, it's 2020. Randomly chopping bytes is not appropriate indeed. At a more practical level, while fmt doesn't quick handle non-ASCII, par might: http://www.nicemice.net/par/
It was thus said that the Great Petite Abeille once stated: > > On Dec 30, 2020, at 00:28, Sean Conner <sean at conman.org> wrote: > > > > Touch?. > > > > One task down, you have two left. > > Right. > > Second task: considering we cannot even agree what an URL is, ?20 years > later, it's rather pointless to try with Gemini, where the concept is > truly alien, "radical familiarity" notwithstanding. > Third task: wrap this* page. Hmmm. Why would I? What does it has to do > *with anything? Is that a throw back from the textflow mega thread? No. It's in reference to Solene's processing of UTF-8. Some tasks, processing UTF-8 is easy, others, not so much. Since you seem to be on a tear about UTF-8, I thought I might hand you one that isn't quite so straightforwards. > Long, uninterrupted sequences of random characters are not unique to > Unicode. Or is the distinction between characters vs bytes? Then yes, it's > 2020. Randomly chopping bytes is not appropriate indeed. Indeed. -spc
> On Dec 30, 2020, at 00:57, Sean Conner <sean at conman.org> wrote: > > No. It's in reference to Solene's processing of UTF-8. She doesn't. No problem. > Some tasks, > processing UTF-8 is easy, others, not so much. Since you seem to be on a > tear about UTF-8, I thought I might hand you one that isn't quite so > straightforwards. Meh. # openssl s_client -quiet -crlf -connect gemini.conman.org:1965 <<< gemini://gemini.conman.org/test/torture/0049 2>/dev/null | par L?o?r?e?m?i?p?s?u?m?d?o?l?o?r?s?i?t?a?m?e?t?c?o? n?s?e?c?t?e?t?u?r?a?d?i?p?i?s?c?i?n?g?e?l?i?t?I? n?l?a?c?i?n?i?a?s?e?m?p?e?r?f?r?i?n?g?i?l?l?a?D? o?n?e?c?v?e?h?i?c?u?l?a?f?e?r?m?e?n?t?u?m?m?a?x? i?m?u?s?A?l?i?q?u?a?m?e?g?e?t?f?e?l?i?s?q?u?a?m? C?r?a?s?e?g?e?t?u?l?l?a?m?c?o?r?p?e?r?n?u?n?c?S? u?s?p?e?n?d?i?s?s?e?i?d?l?a?o?r?e?e?t?r?i?s?u?s? U?t?a?e?r?o?s?m?i?M?a?u?r?i?s?a?l?o?r?e?m?p?o?s? u?e?r?e?e?l?e?m?e?n?t?u?m?j?u?s?t?o?s?e?d?p?e?l? l?e?n?t?e?s?q?u?e?q?u?a?m?A?e?n?e?a?n?s?a?g?i?t? t?i?s?q?u?a?m?e?u?p?r?e?t?i?u?m?p?o?r?t?t?i?t?o? r?I?n?n?e?c?s?e?m?a?e?n?i?m?v?e?h?i?c?u?l?a?f?a? u?c?i?b?u?s?A?e?n?e?a?n?l?u?c?t?u?s?n?o?n?l?o?r? e?m?a?c?b?l?a?n?d?i?t?I?n?t?e?g?e?r?t?i?n?c?i?d? u?n?t?l?e?c?t?u?s?n?e?c?p?u?l?v?i?n?a?r?c?o?n?g? u?e?e?s?t?e?n?i?m?p?h?a?r?e?t?r?a?l?i?b?e?r?o?u? t?g?r?a?v?i?d?a?d?o?l?o?r?n?e?q?u?e?e?u?l?i?b?e? r?o?P?r?a?e?s?e?n?t?r?i?s?u?s?e?s?t?p?o?s?u?e?r? e?a?t?a?u?g?u?e?u?t?f?e?r?m?e?n?t?u?m?f?e?r?m?e? n?t?u?m?t?o?r?t?o?r?D?o?n?e?c?a?t?n?u?l?l?a?v?i? t?a?e?a?u?g?u?e?m?a?x?i?m?u?s?u?l?l?a?m?c?o?r?p? e?r?N?u?l?l?a?m?p?r?e?t?i?u?m?a?n?t?e?e?t?n?i?s? i?f?a?c?i?l?i?s?i?s?e?t?u?l?t?r?i?c?e?s?l?e?o?u? l?l?a?m?c?o?r?p?e?r?M?o?r?b?i?s?i?t?a?m?e?t?l?a? c?u?s?i?n?t?e?l?l?u?s?s?e?m?p?e?r?h?e?n?d?r?e?r? i?t?v?e?l?v?e?n?e?n?a?t?i?s?j?u?s?t?o?N?u?l?l?a? m?v?i?t?a?e?n?i?s?i?e?u?d?i?a?m?f?e?r?m?e?n?t?u? m?c?o?n?v?a?l?l?i?s?N?u?n?c?o?d?i?o?r?i?s?u?s?p? u?l?v?i?n?a?r?a?f?e?l?i?s?i?n?p?h?a?r?e?t?r?a?a? l?i?q?u?e?t?m?a?g?n?a?F?u?s?c?e?e?g?e?t?a?l?i?q? u?e?t?e?l?i?t?E?t?i?a?m?i?n?m?a?s?s?a?c?o?n?g?u? e?n?e?q?u?e?o?r?n?a?r?e?p?e?l?l?e?n?t?e?s?q?u?e? s?i?t?a?m?e?t?u?t?l?a?c?u?s?V?e?s?t?i?b?u?l?u?m? e?u?t?i?n?c?i?d?u?n?t?n?i?s?l?n?e?c?a?l?i?q?u?a? m?u?r?n?a?I?n?t?e?g?e?r?i?a?c?u?l?i?s?a?l?i?q?u? a?m?l?o?r?e?m?n?o?n?f?r?i?n?g?i?l?l?a?N?u?l?l?a? f?a?c?i?l?i?s?i?A?l?i?q?u?a?m?e?u?e?l?i?t?a?u?c? t?o?r?v?i?v?e?r?r?a?m?a?s?s?a?e?u?f?r?i?n?g?i?l? l?a?e?s?t?D?u?i?s?d?i?c?t?u?m?e?f?f?i?c?i?t?u?r? t?e?m?p?u?s?V?e?s?t?i?b?u?l?u?m?n?u?l?l?a?t?o?r? t?o?r?s?o?l?l?i?c?i?t?u?d?i?n?s?c?e?l?e?r?i?s?q? u?e?l?i?g?u?l?a?i?d?b?l?a?n?d?i?t?e?f?f?i?c?i?t? u?r?e?s?t?S?u?s?p?e?n?d?i?s?s?e?p?o?t?e?n?t?i?N? u?l?l?a?m?a?x?i?m?u?s?s?o?l?l?i?c?i?t?u?d?i?n?s? e?m?a?f?r?i?n?g?i?l?l?a?m?a?s?s?a?p?r?e?t?i?u?m? r?h?o?n?c?u?s?N?u?l?l?a?d?i?c?t?u?m?v?e?s?t?i?b? u?l?u?m?e?r?o?s?a?t?s?e?m?p?e?r?t?u?r?p?i?s?u?l? t?r?i?c?i?e?s?n?o?n?I?n?d?i?a?m?q?u?a?m?e?l?e?m? e?n?t?u?m?s?i?t?a?m?e?t?e?r?a?t?s?i?t?a?m?e?t?f? e?r?m?e?n?t?u?m?p?u?l?v?i?n?a?r?s?a?p?i?e?n?V?i? v?a?m?u?s?e?l?e?m?e?n?t?u?m?t?i?n?c?i?d?u?n?t?o? r?c?i?e?l?e?m?e?n?t?u?m?l?a?o?r?e?e?t?m?a?g?n?a? b?l?a?n?d?i?t?e?t?U?t?m?a?s?s?a?a?u?g?u?e?p?r?e? t?i?u?m?q?u?i?s?a?u?g?u?e?s?e?d?u?l?t?r?i?c?i?e? s?f?e?u?g?i?a?t?l?i?b?e?r?o?P?r?a?e?s?e?n?t?a?t? f?e?u?g?i?a?t?q?u?a?m?I?n?t?e?g?e?r?p?o?s?u?e?r? e?h?e?n?d?r?e?r?i?t?p?u?r?u?s?u?t?d?a?p?i?b?u?s? q?u?a?m?v?a?r?i?u?s?a?c?Q?u?i?s?q?u?e?v?e?n?e?n? a?t?i?s?d?o?l?o?r?a?t?e?l?l?u?s?r?h?o?n?c?u?s?v? i?t?a?e?u?l?t?r?i?c?e?s?m?i?t?e?m?p?o?r?S?e?d?s? e?d?v?i?v?e?r?r?a?i?p?s?u?m?V?i?v?a?m?u?s?e?u?n? i?s?i?m?e?t?u?s?M?o?r?b?i?a?l?i?q?u?e?t?a?u?g?u? e?n?o?n?m?a?u?r?i?s?t?i?n?c?i?d?u?n?t?a?u?c?t?o? r?E?t?i?a?m?v?e?l?f?r?i?n?g?i?l?l?a?m?a?u?r?i?s? C?u?r?a?b?i?t?u?r?e?g?e?t?d?o?l?o?r?d?o?l?o?r?N? a?m?u?t?l?e?o?a?m?a?u?r?i?s?e?l?e?m?e?n?t?u?m?s? a?g?i?t?t?i?s?I?n?v?e?l?p?u?r?u?s?a?q?u?a?m?i?n? t?e?r?d?u?m?v?a?r?i?u?s?e?t?f?a?u?c?i?b?u?s?m?e? t?u?s?S?u?s?p?e?n?d?i?s?s?e?s?i?t?a?m?e?t?a?r?c? u?v?i?t?a?e?s?e?m?v?e?s?t?i?b?u?l?u?m?a?c?c?u?m? s?a?n?V?i?v?a?m?u?s?e?l?i?t?v?e?l?i?t?l?u?c?t?u? s?s?e?d?e?u?i?s?m?o?d?u?t?p?r?e?t?i?u?m?e?u?d?u? i?D?o?n?e?c?m?o?l?e?s?t?i?e?l?e?c?t?u?s?i?d?s?o? l?l?i?c?i?t?u?d?i?n?l?o?b?o?r?t?i?s?V?e?s?t?i?b? u?l?u?m?g?r?a?v?i?d?a?m?a?u?r?i?s?m?a?x?i?m?u?s? e?l?i?t?c?o?n?v?a?l?l?i?s?u?t?c?o?n?d?i?m?e?n?t? u?m?d?i?a?m?p?o?s?u?e?r?e?S?e?d?v?e?l?e?l?e?m?e? n?t?u?m?o?d?i?o?S?e?d?s?e?d?e?x?e?u?i?s?m?o?d?e? l?e?i?f?e?n?d?n?u?n?c?u?l?l?a?m?c?o?r?p?e?r?f?e? u?g?i?a?t?d?i?a?m?E?t?i?a?m?l?a?o?r?e?e?t?e?l?e? m?e?n?t?u?m?e?r?o?s?a?c?t?i?n?c?i?d?u?n?t?S?e?d? v?a?r?i?u?s?o?d?i?o?e?g?e?t?e?l?i?t?c?u?r?s?u?s? i?n?s?o?l?l?i?c?i?t?u?d?i?n?a?n?t?e?v?e?h?i?c?u? l?a?P?r?o?i?n?m?a?x?i?m?u?s?q?u?a?m?q?u?i?s?u?l? l?a?m?c?o?r?p?e?r?m?a?t?t?i?s?V?i?v?a?m?u?s?v?a? r?i?u?s?e?s?t?s?e?d?v?i?v?e?r?r?a?l?o?b?o?r?t?i? s?S?e?d?f?e?u?g?i?a?t?s?c?e?l?e?r?i?s?q?u?e?u?l? t?r?i?c?e?s?V?i?v?a?m?u?s?n?i?b?h?u?r?n?a?f?r?i? n?g?i?l?l?a?m?a?t?t?i?s?m?i?a?m?o?l?e?s?t?i?e?p? r?e?t?i?u?m?o?r?c?i?D?o?n?e?c?u?l?l?a?m?c?o?r?p? e?r?e?r?a?t?e?l?i?t?s?i?t?a?m?e?t?p?e?l?l?e?n?t? e?s?q?u?e?d?u?i?g?r?a?v?i?d?a?e?t?P?r?a?e?s?e?n? t?h?e?n?d?r?e?r?i?t?m?o?l?e?s?t?i?e?m?a?g?n?a?e? u?c?o?m?m?o?d?o?e?s?t?A?l?i?q?u?a?m?g?r?a?v?i?d? a?e?r?o?s?s?c?e?l?e?r?i?s?q?u?e?a?r?c?u?f?e?u?g? i?a?t?a?u?c?t?o?r?N?u?n?c?t?i?n?c?i?d?u?n?t?s?u? s?c?i?p?i?t?s?c?e?l?e?r?i?s?q?u?e?M?o?r?b?i?s?e? d?i?m?p?e?r?d?i?e?t?n?u?l?l?a?Q?u?i?s?q?u?e?e?u? a?n?t?e?e?r?a?t?D?o?n?e?c?i?d?f?r?i?n?g?i?l?l?a? v?e?l?i?t?s?i?t?a?m?e?t?i?a?c?u?l?i?s?m?a?u?r?i? s?C?u?r?a?b?i?t?u?r?e?g?e?t?r?i?s?u?s?o?r?n?a?r? e?f?i?n?i?b?u?s?d?u?i?u?t?o?r?n?a?r?e?s?e?m?I?n? b?i?b?e?n?d?u?m?p?u?r?u?s?a?r?c?u?A?l?i?q?u?a?m? s?o?l?l?i?c?i?t?u?d?i?n?t?u?r?p?i?s?e?g?e?t?r?i? s?u?s?s?a?g?i?t?t?i?s?r?u?t?r?u?m?Q?u?i?s?q?u?e? v?e?l?i?t?n?e?q?u?e?t?e?m?p?o?r?s?i?t?a?m?e?t?p? u?l?v?i?n?a?r?s?e?d?t?i?n?c?i?d?u?n?t?n?e?c?e?l? i?t?N?u?l?l?a?m?t?r?i?s?t?i?q?u?e?c?o?n?s?e?c?t? e?t?u?r?a?n?t?e?e?g?e?t?v?a?r?i?u?s?a?r?c?u?c?o? n?s?e?c?t?e?t?u?r?e?t?I?n?t?e?g?e?r?n?o?n?v?e?s? t?i?b?u?l?u?m?l?i?g?u?l?a?v?u?l?p?u?t?a?t?e?a?l? i?q?u?e?t?s?e?m?N?u?n?c?d?i?c?t?u?m?a?u?g?u?e?a? d?i?a?m?d?i?c?t?u?m?a?t?p?o?r?t?a?a?n?t?e?b?i?b? e?n?d?u?m?N?u?n?c?v?i?t?a?e?m?a?g?n?a?i?n?e?r?o? s?s?c?e?l?e?r?i?s?q?u?e?g?r?a?v?i?d?a?a?c?a?a?u? g?u?e?N?u?n?c?p?r?e?t?i?u?m?c?o?n?s?e?q?u?a?t?r? i?s?u?s?V?i?v?a?m?u?s?a?o?r?c?i?l?i?g?u?l?a?M?o? r?b?i?a?n?i?b?h?i?m?p?e?r?d?i?e?t?m?o?l?e?s?t?i? e?e?x?e?u?c?o?m?m?o?d?o?n?i?s?l?P?h?a?s?e?l?l?u? s?e?f?f?i?c?i?t?u?r?a?n?t?e?q?u?i?s?v?e?s?t?i?b? u?l?u?m?l?a?o?r?e?e?t?U?t?f?r?i?n?g?i?l?l?a?n?u? n?c?s?i?t?a?m?e?t?i?p?s?u?m?f?a?u?c?i?b?u?s?v?e? n?e?n?a?t?i?s?F?u?s?c?e?m?a?t?t?i?s?q?u?i?s?j?u? s?t?o?o?r?n?a?r?e?e?u?i?s?m?o?d?V?e?s?t?i?b?u?l? u?m?e?u?s?a?p?i?e?n?v?o?l?u?t?p?a?t?c?o?m?m?o?d?
> On Dec 30, 2020, at 00:19, Sean Conner <sean at conman.org> wrote: > > create a Gemini server where %2F *is required* to retrieve the resource. By the way, what happens on your implementation if I name the actual gemini/text like "b%2Fw.gmi"? Burn and crash? b/w ? (art) Initialism of black-and-white. https://en.wiktionary.org/wiki/b%2Fw ? ???
It was thus said that the Great Petite Abeille once stated: > > > > On Dec 30, 2020, at 00:19, Sean Conner <sean at conman.org> wrote: > > > > create a Gemini server where %2F *is required* to retrieve the resource. > > By the way, what happens on your implementation if I name the actual > gemini/text like "b%2Fw.gmi"? Burn and crash? No. It will be sent as "b/w.gmi". -spc
> On Jan 3, 2021, at 22:55, Sean Conner <sean at conman.org> wrote: > > No. It will be sent as "b/w.gmi". And then? What happens when it's requested? 51 NOT FOUND? ? ???
It was thus said that the Great Petite Abeille once stated: > > On Dec 30, 2020, at 00:19, Sean Conner <sean at conman.org> wrote: > > > > create a Gemini server where %2F *is required* to retrieve the resource. > > b/w ? (art) Initialism of black-and-white. > > https://en.wiktionary.org/wiki/b%2Fw Also, <https://en.wiktionary.org/wiki/b/w> works just as well. So does <https://en.wikipedia.org/wiki/A/B_testing>. -spc
It was thus said that the Great Petite Abeille once stated: > > > > On Jan 3, 2021, at 22:55, Sean Conner <sean at conman.org> wrote: > > > > No. It will be sent as "b/w.gmi". > > And then? What happens when it's requested? 51 NOT FOUND? I don't know, Petite. Do does your server return? -spc
> On Jan 3, 2021, at 22:59, Sean Conner <sean at conman.org> wrote: > > Also, <https://en.wiktionary.org/wiki/b/w> works just as well. So does > <https://en.wikipedia.org/wiki/A/B_testing>. Sure. It's wikipedia, they must deal with non-compliant clients. They are a public service, pretty much. How does your server handles it? What's your excuse? No reply needed. You are in good company, not even the intern who implemented the Go library during last summer of code got it right. No shame. ? ???
> On Jan 3, 2021, at 23:00, Sean Conner <sean at conman.org> wrote: > > I don't know, Petite. Do does your server return? Let me help: % touch b%2Fw.gmi This gets published as b/w.gmi, according to your own account. If a client request such url, on your server, what would happen? Some magic ala wikipedia? 51 NOT FOUND? Something else? No reply needed either. ? ???
It was thus said that the Great Petite Abeille once stated: > > > > On Jan 3, 2021, at 22:59, Sean Conner <sean at conman.org> wrote: > > > > Also, <https://en.wiktionary.org/wiki/b/w> works just as well. So does > > <https://en.wikipedia.org/wiki/A/B_testing>. > > Sure. It's wikipedia, they must deal with non-compliant clients. They are > a public service, pretty much. > > How does your server handles it? What's your excuse? Laziness and spite, just to piss you off. Yes, you specifically. > No reply needed. You are in good company, not even the intern who > implemented the Go library during last summer of code got it right. No > shame. So where is your server and client that is correctly written? -spc (No, really! Where is your code? So we mere peons can see your godlike code? Or is it too crystaline perfect for our eyes?) P.S. In other words, put up or shut up!
> On Jan 3, 2021, at 23:29, Sean Conner <sean at conman.org> wrote: > > Laziness and spite, just to piss you off. Yes, you specifically. You do realize I couldn't care less about what your code does or doesn't do, right? It's your code after all. No one else care. But do not bullshit me in regards to what an URL is or isn't. No amount of historicism is going to get you out of this one. A simple "not supported" would do. Again, no one cares. Again, best to drop it. ? ???
It was thus said that the Great Petite Abeille once stated: > > > > On Jan 3, 2021, at 23:29, Sean Conner <sean at conman.org> wrote: > > > > Laziness and spite, just to piss you off. Yes, you specifically. > > You do realize I couldn't care less about what your code does or doesn't do, right? It's your code after all. No one else care. > > But do not bullshit me in regards to what an URL is or isn't. No amount of historicism is going to get you out of this one. > > A simple "not supported" would do. Again, no one cares. NOT FUCKING SUPPORTED! -spc
> On Jan 3, 2021, at 23:40, Sean Conner <sean at conman.org> wrote: > > NOT FUCKING SUPPORTED! There you go. Not that difficult after all. On that note, Happy New Year. ? ???
Jeesus this place is a hell hole. On 0, Sean Conner <sean at conman.org> wrote: >It was thus said that the Great Petite Abeille once stated: >> >> >> > On Jan 3, 2021, at 23:29, Sean Conner <sean at conman.org> wrote: >> > >> > Laziness and spite, just to piss you off. Yes, you specifically. >> >> You do realize I couldn't care less about what your code does or doesn't do, right? It's your code after all. No one else care. >> >> But do not bullshit me in regards to what an URL is or isn't. No amount of historicism is going to get you out of this one. >> >> A simple "not supported" would do. Again, no one cares. > > NOT FUCKING SUPPORTED! > > -spc
> On Jan 3, 2021, at 23:48, Luke Murphy <lukewm at riseup.net> wrote: > > Jeesus this place is a hell hole. Happy New Year to you as well. Where have you been in 2020? Never mind. ? ???
Chill out Petite Abeille, please let?s not not start 2021 with some anger. You already have a least a third of the messages on this list, never can?t really tell if it?s just contrarian or real suggestions. At least there is food for thoughts. Perhaps it?s time for you to actually use the protocol and share some of your ideas in a more constructive way? My 2 c?ents julienxx
> On Jan 4, 2021, at 00:05, Julien Blanchard <julien at typed-hole.org> wrote: > > Chill out Petite Abeille, please let?s not not start 2021 with some anger. Thanks. No anger though. Plain spoken if anything. Possibly chatty. That said, if mild technical challenges make some lose bowel control in a fit of rage, then perhaps best not to go to the IETF afterall. They will shred this to pieces. Nothing wrong keeping it "speculative" and casual. Formalism can be overrated. ? ???
On Sun, Jan 3, 2021 at 4:55 PM Sean Conner <sean at conman.org> wrote: > > By the way, what happens on your implementation if I name the actual > > gemini/text like "b%2Fw.gmi"? Burn and crash? > > No. It will be sent as "b/w.gmi". > In what circumstances? If the URL bar or text link says "b%2Fw.gmi", that's what should be sent to the server; if it says "b/w.gmi", then *that* is what should be sent to the server. The server may treat those differently or the same. The reason is that / is a reserved character. The server ought to treat http://abc.com:80/~smith/home.html and http://abc.com:80/%7Esmith/home.html exactly the same, per RFC 2616. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org You cannot enter here. Go back to the abyss prepared for you! Go back! Fall into the nothingness that awaits you and your Master. Go! --Gandalf -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210104/fb43 16ec/attachment-0001.htm>
It was thus said that the Great John Cowan once stated: > On Sun, Jan 3, 2021 at 4:55 PM Sean Conner <sean at conman.org> wrote: > > > > > By the way, what happens on your implementation if I name the actual > > > gemini/text like "b%2Fw.gmi"? Burn and crash? > > > > No. It will be sent as "b/w.gmi". > > In what circumstances? If the URL bar or text link says "b%2Fw.gmi", > that's what should be sent to the server; if it says "b/w.gmi", then *that* > is what should be sent to the server. The server may treat those > differently or the same. The reason is that / is a reserved character. > The server ought to treat http://abc.com:80/~smith/home.html and > http://abc.com:80/%7Esmith/home.html exactly the same, per RFC 2616. "All non-trivial abstractions, to some degree, are leaky." -- Joel Spolsky [1] "Doctor, it hurts when I do this." "Then stop doing that." -- Old vaudville joke. I've already rejected tons of replies to this, so I think I'll ask a question. You are writing a client, and you come across this link: => %2E%2E/%52%3A%20%41%2F%42%20%31%25%20%40%20%24%33%3B%76%3D%31 This is a relative URI, so this needs to be resolved against the base URI, and for this question, the base URI is gemini://example.com/%66%6F%6F/%62%61%72%3B%33/ How should the client (or a URI/URL/IRI parser) deal with such links. What, in your mind, should they manipulate or parse the URLs? It's not a matter of "no body should generate such links" because you can't control that. The client gets what it gets. When I wrote my URL parser, I wrote it to be useful to me (with the hope that others would find it useful). But it seems it does The Wrong Thing. So in your opinion, what should it, nay, MUST it do? Here's the list of references I've been pouring through the past week: RFC-1630 Jun 1994 RFC-1738 Dec 1994 RFC-1808 Jun 1995 RFC-2396 Aug 1998 RFC-3986 Jan 2005 WHATWG URL Jan 2021 (it keeps changing) [2] Also, do ANY existing URL parsing library get it right? Please make sure to justify your answer(s). -spc [1] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ [2] https://url.spec.whatwg.org/
On Fri, Jan 8, 2021 at 1:27 AM Sean Conner <sean at conman.org> wrote: > How should the client (or a URI/URL/IRI parser) deal with such links. IMO they should decode all characters allowed in that section of the URL. For example, a %2f wouldn't be decoded, because it would split the path segment. %61 would, because it decodes to "a", which is allowed and wouldn't change the meaning. The Chrome (Might actually be V8, idk) and Firefox URL parsers do this for HTTP(S), but not other protocols. I think this makes sense because it makes a single normalized form, and allows for files with special characters in their names. I'm not sure how servers would handle filenames with slashes in them, though. - easrng
On Fri, Jan 8, 2021 at 1:27 AM Sean Conner <sean at conman.org> wrote: > You are writing a client, and you come across this link: > > => %2E%2E/%52%3A%20%41%2F%42%20%31%25%20%40%20%24%33%3B%76%3D%31 > If we unescape all of the RFC 2396 unreserved characters, we get "../R%3A%20A%2FB%201%25%20%40%20%243;%3Bv%3D1" (my reference to RFC 2616 was erroneous). RFC 3986 makes a lot of concessions to WHATWG, and requires the %2E%2E to be left alone, which changes resolution. IMO Gemini should stick with 2396 on this and a number of other points. This is a relative URI, so this needs to be resolved against the base URI, > and for this question, the base URI is > > gemini://example.com/%66%6F%6F/%62%61%72%3B%33/ RFC 2396 doesn't actually allow an unescaped trailing slash in the pathname, although RFC 3986 does. If that is removed, then there there are no escaped reserved characters, so this is equivalent to "gemini:// example.com/foo/bar%3B3/". Normal URI resolution then gives us "gemini:// example.com/foo/R%3A%20A%2FB%201%25%20%40%20%243;%3Bv%3D1", which is what should be sent to the server. Exactly how, if at all, the last component of the path is translated into a file on the filesystem is completely up to the server. That's my best shot. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Evolutionary psychology is the theory that men are nothing but horn-dogs, and that women only want them for their money. --Susan McCarthy (adapted) -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210108/4d40 1344/attachment.htm>
> On Jan 8, 2021, at 07:27, Sean Conner <sean at conman.org> wrote:
What about:
[BASE]
gemini://example.com/foo/bar%3b3/
_["scheme"]="gemini"
_["host"]="example.com"
_["authority"]="example.com"
_["path"]={}
_["path"][1]="foo"
_["path"][2]="bar;3"
_["path"]["directory"]=true
_["path"]["absolute"]=true
[RELATIVE]
../R:%20A%2fB%201%25%20@%20$3%3bv=1
_["path"]={}
_["path"][1]=".."
_["path"][2]="R: A/B 1% @ $3;v=1"
_["path"]["directory"]=false
_["path"]["absolute"]=false
[ABSOLUTE]
gemini://example.com/R:%20A%2fB%201%25%20@%20$3%3bv=1
_["path"]={}
_["path"][1]="R: A/B 1% @ $3;v=1"
_["path"]["directory"]=false
_["path"]["absolute"]=true
_["host"]="example.com"
_["scheme"]="gemini"
_["authority"]="example.com"
Works? Fails? What do you get?
? ???
---
Previous Thread: [users] Manually curated directory of capsules?