💾 Archived View for gemi.dev › gemini-mailing-list › 000161.gmi captured on 2023-11-04 at 12:29:42. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Presently, a successful status code may look like: 20 text/gemini; charset=utf-8 Would it be reasonable to consider the structure of <META> as equivalent to a modernized MIME header? We already have the charset, so... as we have 1024 bytes to play with... ... we could add a couple of further information such as Content-Length [1], Content-Disposition [2], Content-Language [3], and Date[4].. Perhaps something like this: 20 text/gemini; charset=utf-8; length=28102; name="Speculative specification"; date=2020-05-26; language=en-US A slim 107 bytes altogether. All optional. Heresy? -- PA [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition [3] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Language [4] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date
It was thus said that the Great Petite Abeille once stated: > Presently, a successful status code may look like: > > 20 text/gemini; charset=utf-8 > > Would it be reasonable to consider the structure of <META> as equivalent to a modernized MIME header? > > We already have the charset, so... as we have 1024 bytes to play with... > > ... we could add a couple of further information such as Content-Length [1], Content-Disposition [2], Content-Language [3], and Date[4].. > > Perhaps something like this: > > 20 text/gemini; charset=utf-8; length=28102; name="Speculative specification"; date=2020-05-26; language=en-US > > A slim 107 bytes altogether. All optional. > > Heresy? I previously proposed the filesize for this, and solderpunk rejected that (reasoning here: https://lists.orbitalfox.eu/archives/gemini/2020/000808.html). And I'm not a fan at all of Content-Disposition because of the way web browsers implement it (no! I don't want to save that! I want to *see* it! Let me see it in the browser!). I think language will pass, but that's about it ... -spc
> On May 29, 2020, at 04:19, Sean Conner <sean at conman.org> wrote: > > I previously proposed the filesize for this, and solderpunk rejected that Well, the thing is, as soon as we open the door for semicolons in what is effectively the content-type header, then... we open the floodgates to extensions. The whole 1024 bytes of them :) You mentioned it yourself nearly a year ago: "The MIME type that is returned can have parameters, and these parameters can act as small headers" -- File size issues, Sean Conner, August 18 2019 https://lists.orbitalfox.eu/archives/gemini/2019/000045.html What's the current thinking one year on? -- PA
> On May 29, 2020, at 04:19, Sean Conner <sean at conman.org> wrote: > > (reasoning here: https://lists.orbitalfox.eu/archives/gemini/2020/000808.html). "Someone is bound to ask: "Oh, does this mean text/gemini; content-size=1234 is okay, too?". No!" -- solderpunk, Cognitive aspects of navigation in gemini space, May 18 2020 Fair enough. The information I'm really after is a date byline [1]. In the same way as text is not just a collection of bytes, but have an actual language, they are also anchored in time, not just floating in the ether, timeless. [1] https://en.wikipedia.org/wiki/Dateline
It was thus said that the Great Petite Abeille once stated: > > On May 29, 2020, at 04:19, Sean Conner <sean at conman.org> wrote: > > > > I previously proposed the filesize for this, and solderpunk rejected that > > Well, the thing is, as soon as we open the door for semicolons in what is > effectively the content-type header, then... we open the floodgates to > extensions. The whole 1024 bytes of them :) > > You mentioned it yourself nearly a year ago: > > "The MIME type that is returned can have parameters, and these parameters > can act as small headers" > -- File size issues, Sean Conner, August 18 2019 > > https://lists.orbitalfox.eu/archives/gemini/2019/000045.html > > What's the current thinking one year on? I still feel the same way, and I don't have an issue with this. We'll have to see what solderpunk thinks of this. -spc
On Fri, 29 May 2020, Petite Abeille wrote:
> 20 text/gemini; charset=utf-8; length=28102; name="Speculative
specification"; date=2020-05-26; language=en-US
>
> A slim 107 bytes altogether. All optional.
It's not really the length that's the issue for me. Why not
20 text/gemini; execute-js=true; utm_term=sexual+health+checkup;
cookie=U29tZSBhcmJpdHJhcnkgY29va2llIHRleHQK
etc, etc?
Mk
> On May 29, 2020, at 05:11, Martin Keegan <martin at no.ucant.org> wrote: > > It's not really the length that's the issue for me. Why not > > 20 text/gemini; execute-js=true; utm_term=sexual+health+checkup; > cookie=U29tZSBhcmJpdHJhcnkgY29va2llIHRleHQK > > etc, etc? Sure thing. It's a MIME header. You can put anything in it. The main difference with TheProtocolThatShallNotBeNamed is that such line noise will just end up in /dev/null as there is no one to look, nor act, on it. On the other hand, if you put such nice utm_term in the Gemini request or in a text/gemini link line... that would be another can of worms altogether :)
An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200529/1377 cc7d/attachment.htm>
On Fri, May 29, 2020 at 04:10:40AM +0200, Petite Abeille wrote: I can see this has triggered a thread of replies already but I only have a little time before I need to start work so I thought I'd just reply now to the first post without having read anything else to share my initial and uninfluenced reaction (which I don't think will change, mind you). > Presently, a successful status code may look like: > > 20 text/gemini; charset=utf-8 > > Would it be reasonable to consider the structure of <META> as equivalent to a modernized MIME header? They're not "equivalent to a modernized MIME header", they are literally specced as being exactly that (well, without the modernized part). From section 3.3: > Response bodies only accompany responses whose header indicates a > SUCCESS status (i.e. a status code whose first digit is 2). For such > responses, <META> is a MIME media type as defined in RFC 2046. This is very deliberate! It lets people use pre-existing machinery for parsing MIME types to easily throw together Gemini software without having to write any customised code. > We already have the charset, so... as we have 1024 bytes to play with... Yes, it's true we are free to define additional parameters for our media type, and I *have* stressed out about this in the past. However... > ... we could add a couple of further information such as Content-Length [1], Content-Disposition [2], Content-Language [3], and Date[4].. > > Perhaps something like this: > > 20 text/gemini; charset=utf-8; length=28102; name="Speculative specification"; date=2020-05-26; language=en-US ...most of what is new here makes no sense whatsoever. We are allowed to define parameters for our media type, but we can't change the fact that it is a *media type*. It is information for clients about *what kind of thing* they're about to get, so they can determine how to handle it. It is *category* information. "English text with Gemini line types" is a sensible category. There can be infinitely many documents in that category and it makes sense for a user agent to treat them all identically, and to perhaps treat them a little differently from "Arabic text with Gemini line types" (by rendering text LTR instead of RTL). Those are genuine "types of stuff". But "28102 bytes of English text with Gemini line types written three days ago with the title Speculative specification" isn't a "type of stuff". It's not a sensible category. Information which is unique to a particular document is just wholly inappropriate in a MIME media type, it's not the place for it. I'm definitely not going to spec any parameters for text/gemini which I don't feel fit with the semantics of what a media type is. It's true that I can't stop servers from doing this (and the MIME RFC clearly says that clients must ignore parameters they don't recognise, so I can't even recommend that clients refuse to handle responses which do this as a kind of defensive measure). I hope people will be disuaded from doing this not just by virtue of it being against my wishes for and the intended spirit of Gemini, but also because it completely and clearly violates the intent of a much older and more established piece of internet infrastructure. It's double wrong! Cheers, Solderpunk
> On May 29, 2020, at 11:24, solderpunk <solderpunk at SDF.ORG> wrote: > > It's double wrong! Fair enough ?? This leaves link lines: =>data:,Hello%2C%20World! =>data:message/rfc822;base64, ... =>data:multipart/mixed; boundary=--8<--;base64, ... =>dict://dict.org/d:shortcake: =>fax:+3585551234567 =>feed:https://example.com/entries.atom =>geo:13.4125,103.8667 =>mailto:someone at example.com =>sms:+15105550101 =>tag:example.com,2004:1234 =>tel:+12125551234 Those could be nicely rendered, perhaps in some creative, interesting, and weird ways. Time will tell.
On Fri, 29 May 2020, Petite Abeille wrote:
> Those could be nicely rendered, perhaps in some creative, interesting,
and weird ways. Time will tell.
Good catch. I think we need to rule out the equivalent of
=> data:text/javascript,(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']
=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new
Date();a=s.createElement(o),m=s.getElementsByTagName(o)[0];a.async=1;a.src=
g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js'
,'ga');ga('create', 'UA-XXXXX-Y', 'auto');ga('send', 'pageview');
or it compromises one of key benefits of Gemini.
Mk
--
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/
> I think we need to rule out the equivalent of
All existing clients rule this out, I don't see the issue. As long as
clients continue not to execute arbitrary Javascript, it should be fine.
makeworld
??????? Original Message ???????
On Friday, May 29, 2020 10:55 AM, Martin Keegan <martin at no.ucant.org> wrote:
> On Fri, 29 May 2020, Petite Abeille wrote:
>
> > Those could be nicely rendered, perhaps in some creative, interesting,
and weird ways. Time will tell.
>
> Good catch. I think we need to rule out the equivalent of
>
> => data:text/javascript,(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject
']=r;i[r]=i[r]||function(){
>
> (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new
Date();a=s.createElement(o),m=s.getElementsByTagName(o)[0];a.async=1;a.src=
g;m.parentNode.insertBefore(a,m)
> })(window,document,'script','https://www.google-analytics.com/analytics.j
s','ga');ga('create', 'UA-XXXXX-Y', 'auto');ga('send', 'pageview');
>
> or it compromises one of key benefits of Gemini.
>
> Mk
>
> -------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
-------------------------------------------------------
>
> Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/
On 5/29/20 3:10 PM, colecmac at protonmail.com wrote: >> I think we need to rule out the equivalent of > All existing clients rule this out, I don't see the issue. As long as > clients continue not to execute arbitrary Javascript, it should be fine. > > makeworld More-so, I think we just keep beating people over the head that text/gemini is a text document format and links *MUST* not be prefetched or loaded without user interaction. They should also be inspectable in some way so the user knows where they lead. These are security things, not a matter of convenience and pretty display. An image link pointing to a tracking pixel shouldn't auto-load. A data link trying to run an arbitrary script should be seen for what it is. I'd suggest that be made extremely clear in the spec itself. *Can* someone build a client on gemini that doesn't follow that rule? Sure! There will be crawlers running through its space doing exactly that, but a client for users should respect their users.
> On May 29, 2020, at 17:17, James Tomasino <tomasino at lavabit.com> wrote: > > These are security things, not a matter of convenience and pretty > display. An image link pointing to a tracking pixel shouldn't auto-load. > A data link trying to run an arbitrary script should be seen for what it is. Right. That said, where does the content originate from? The users themselves. For their own convenience, supposedly. Hopefully they will not poison themselves with toxic content. But, if they choose to, well, then, it's their own deliberate choice. Medical advise be damned. Have a large serving of metaphorical chloroquine with that thought :P "As a scientist, you have a loyalty to reason. It makes you a little untrustworthy.? -- General Mark Naird, Space Force, 2020 -- PA
On Fri, May 29, 2020 at 03:10:30PM +0000, colecmac at protonmail.com wrote: > > I think we need to rule out the equivalent of > > All existing clients rule this out, I don't see the issue. As long as > clients continue not to execute arbitrary Javascript, it should be fine. The issue is that the history of the web demonstrates that the most powerful/inclusive interpretation of a spec tends to become the only acceptable implementation over a long enough timeline. Everybody builds their content for that interpretation, and more conservative clients come to be considered "broken". It's like trying to surf the modern web with cookies and JS turned off: nothing works. The only hope is to design specs where the most powerful interpretation is within acceptable limits. Which seems to me to be impossible in a world where URLs can be harmless pointers to network resources *or* arbitrarily large chunks of data of arbitrary but unamiguous type. In that crazy world, our only hope is a strong cultural norm of "No, don't do that!". It's true that maybe that will work better for Gemini than it did for the web, because, you know, the web is actually there alongside Gemini and people who really want the worst of the web will just stick with it and leave us alone. But I really didn't want to just rely on politely asking people not to do certain things, but to make it impossible or very difficult to do them at the protocol level. I know you can never *really* do that, people can ignore RFCs and implement totally broken stuff and the internet police don't come and arrest them. But I had hoped we could get really close to that ideal. Cheers, Solderpunk
> On May 29, 2020, at 17:45, solderpunk <solderpunk at SDF.ORG> wrote: > > The issue is that the history of the web demonstrates that the most > powerful/inclusive interpretation of a spec tends to become the only > acceptable implementation over a long enough timeline. To echo spc sentiment [1]: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." -- Zawinski's law of software envelopment =>data:message/rfc822;base64, ... We already can! ?? No drama though, it's all going to be good. Perhaps we will have learned something after ~30 years of web browsing. ?? [1] https://lists.orbitalfox.eu/archives/gemini/2020/000975.html
It was thus said that the Great solderpunk once stated: > On Fri, May 29, 2020 at 03:10:30PM +0000, colecmac at protonmail.com wrote: > > > I think we need to rule out the equivalent of > > > > All existing clients rule this out, I don't see the issue. As long as > > clients continue not to execute arbitrary Javascript, it should be fine. > > The issue is that the history of the web demonstrates that the most > powerful/inclusive interpretation of a spec tends to become the only > acceptable implementation over a long enough timeline. Everybody builds > their content for that interpretation, and more conservative clients > come to be considered "broken". It's like trying to surf the modern web > with cookies and JS turned off: nothing works. > The only hope is to > design specs where the most powerful interpretation is within acceptable > limits. Which seems to me to be impossible in a world where URLs can be > harmless pointers to network resources *or* arbitrarily large chunks of > data of arbitrary but unamiguous type. I added the test for data: URIs for the lulz (it is, after all, a *client torture* test), which the expectation that no one would really do anything with it. And the data itself is 'text/gamini' as a nice treat for anyone that did anything with it. One way to think of data: is not to inline data, but as a pre-fetch of data, but without the overhead of a second request. Yes, it's silly, but it is what it is. Besides, as just a gut feeling, I think the majority (well over 99%) of the links you'll find in the Geminisphere are: gemini: gopher: https: http: mailto: I have no numbers to back that up, but that feels right to me, and such links as tel: or sip: will almost *never* show up (for the record, I haven't come across tel: or sip: on the web in the wild [1]). > But I really didn't want to just rely on politely asking people not to > do certain things, but to make it impossible or very difficult to do > them at the protocol level. I know you can never *really* do that, > people can ignore RFCs and implement totally broken stuff and the > internet police don't come and arrest them. But I had hoped we could > get really close to that ideal. Creativity is amplified by restrictions, and oh boy is Gemini restrictive. So it's not surprising to me that people are poking and proding at the edges to see what's possible. I never realized that music consisting of the same note was a thing until this video: https://www.youtube.com/watch?v=eSuK_5zW2iM or how about the restriction of using a single color for a painting? https://www.youtube.com/watch?v=u-pdyTFOvYw Years ago, a friend sent me an email of only 26 words. It was a coherent message *where every word was in alphabetical order!* I replied with another 26 words, with a coherent message, but in *reverse alphabetical order!* I mention these as a way to explain the recent activity in Gemini, as more peoples' creativity has been unleashed by the contraints of Gemini. And always keep in mind, a polite "no" is always a viable answer. -spc [1] I do at work, but at work I deal with SIP, so tel: and sip: comes with that territory.
---
Previous Thread: Possibly silly text/gemini spec suggestion: Frames