content-disposition defines either inline or attachment, when it comes to how to display content. text/gemini link is firmly in the external camp, assuming explicit user action to interact with linked content: a link is an external resource to the document, an attachment, to be activated by the user. Additionally, perhaps text/gemini could embraces data url as small inline adornment. For example, given a small data encoded vCard, 917 bytes long: data:text/vcard;charset=utf-8;base64,QkVHSU46VkNBUkQNClZFUlNJT046NC4wDQpOOk d1bXA7Rm9ycmVzdDs7TXIuOw0KRk46Rm9ycmVzdCBHdW1wDQpPUkc6QnViYmEgR3VtcCBTaHJpb XAgQ28uDQpUSVRMRTpTaHJpbXAgTWFuDQpQSE9UTztNRURJQVRZUEU9aW1hZ2UvZ2lmOmh0dHA6 Ly93d3cuZXhhbXBsZS5jb20vZGlyX3Bob3Rvcy9teV9waG90by5naWYNClRFTDtUWVBFPXdvcms sdm9pY2U7VkFMVUU9dXJpOnRlbDorMS0xMTEtNTU1LTEyMTINClRFTDtUWVBFPWhvbWUsdm9pY2 U7VkFMVUU9dXJpOnRlbDorMS00MDQtNTU1LTEyMTINCkFEUjtUWVBFPVdPUks7UFJFRj0xO0xBQ kVMPSIxMDAgV2F0ZXJzIEVkZ2VuQmF5dG93biwgTEEgMzAzMTRuVW5pdGVkIFN0YXRlcyBvZiBB bWVyaWNhIjo7OzEwMCBXYXRlcnMgRWRnZTtCYXl0b3duO0xBOzMwMzE0O1VuaXRlZCBTdGF0ZXM gb2YgQW1lcmljYQ0KQURSO1RZUEU9SE9NRTtMQUJFTD0iNDIgUGxhbnRhdGlvbiBTdC5uQmF5dG 93biwgTEEgMzAzMTRuVW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhIjo7OzQyIFBsYW50YXRpb24gU 3QuO0JheXRvd247TEE7MzAzMTQ7VW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhDQpFTUFJTDpmb3Jy ZXN0Z3VtcEBleGFtcGxlLmNvbQ0KUkVWOjIwMDgwNDI0VDE5NTI0M1oNCngtcXE6MjE1ODg4OTE NCkVORDpWQ0FSRA== A client MAY render it inline, for the user to interact with, in any appropriate ways: BEGIN:VCARD VERSION:4.0 N:Gump;Forrest;;Mr.; FN:Forrest Gump ORG:Bubba Gump Shrimp Co. TITLE:Shrimp Man PHOTO;MEDIATYPE=image/gif:http://www.example.com/dir_photos/my_photo.gif TEL;TYPE=work,voice;VALUE=uri:tel:+1-111-555-1212 TEL;TYPE=home,voice;VALUE=uri:tel:+1-404-555-1212 ADR;TYPE=WORK;PREF=1;LABEL="100 Waters Edge\nBaytown\, LA 30314\nUnited States of America":;;100 Waters Edge;Baytown;LA;30314;United States of America ADR;TYPE=HOME;LABEL="42 Plantation St.\nBaytown\, LA 30314\nUnited States of America":;;42 Plantation St.;Baytown;LA;30314;United States of America EMAIL:forrestgump at example.com REV:20080424T195243Z x-qq:21588891 END:VCARD Forrest Gump Bubba Gump Shrimp Co. Shrimp Man 100 Waters Edge Baytown LA 30314 United States of America +1-111-555-1212 forrestgump at example.com There is a bunch of micro format such as text/vcard, text/calendar, text/directory, text/csv, application/x-x509-ca-cert , etc, etc, worthwhile displaying as small inline attachment. [1] https://en.wikipedia.org/wiki/VCard -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/f066 4873/attachment.htm>
Petite Abeille <petite.abeille at gmail.com> writes: > Additionally, perhaps text/gemini could embraces data url as small inline adornment. > > For example, given a small data encoded vCard, 917 bytes long: > > data:text/vcard;charset=utf-8;base64,QkVHSU46VkNBUkQNClZFUlNJT046NC4wDQpO Okd1bXA7Rm9ycmVzdDs7TXIuOw0KRk46Rm9ycmVzdCBHdW1wDQpPUkc6QnViYmEgR3VtcCBTaHJ pbXAgQ28uDQpUSVRMRTpTaHJpbXAgTWFuDQpQSE9UTztNRURJQVRZUEU9aW1hZ2UvZ2lmOmh0dH A6Ly93d3cuZXhhbXBsZS5jb20vZGlyX3Bob3Rvcy9teV9waG90by5naWYNClRFTDtUWVBFPXdvc mssdm9pY2U7VkFMVUU9dXJpOnRlbDorMS0xMTEtNTU1LTEyMTINClRFTDtUWVBFPWhvbWUsdm9p Y2U7VkFMVUU9dXJpOnRlbDorMS00MDQtNTU1LTEyMTINCkFEUjtUWVBFPVdPUks7UFJFRj0xO0x BQkVMPSIxMDAgV2F0ZXJzIEVkZ2VuQmF5dG93biwgTEEgMzAzMTRuVW5pdGVkIFN0YXRlcyBvZi BBbWVyaWNhIjo7OzEwMCBXYXRlcnMgRWRnZTtCYXl0b3duO0xBOzMwMzE0O1VuaXRlZCBTdGF0Z XMgb2YgQW1lcmljYQ0KQURSO1RZUEU9SE9NRTtMQUJFTD0iNDIgUGxhbnRhdGlvbiBTdC5uQmF5 dG93biwgTEEgMzAzMTRuVW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhIjo7OzQyIFBsYW50YXRpb24 gU3QuO0JheXRvd247TEE7MzAzMTQ7VW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhDQpFTUFJTDpmb3 JyZXN0Z3VtcEBleGFtcGxlLmNvbQ0KUkVWOjIwMDgwNDI0VDE5NTI0M1oNCngtcXE6MjE1ODg4O TENCkVORDpWQ0FSRA== > > > A client MAY render it inline, for the user to interact with, in any appropriate ways: Please, no. I'd be all for a client rendering text/vcard and similar content types as pages, with whatever formatting the client author likes, but they should be rendered as separate documents. If you want an inline link preview, you can write it by hand, or have it generated by a script. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada |
> On Jun 4, 2020, at 17:48, Jason McBrayer <jmcbray at carcosa.net> wrote: > > If you want an inline link preview, you can write it by hand, or have it generated by a script. On the server side, I presume? What happened to the notion of client's agency? 5.3.2 Link lines Clients can present links to users in whatever fashion the client author wishes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/7d68 757a/attachment.htm>
On 6/4/20 3:58 PM, Petite Abeille wrote: > On the server side, I presume? > > What happened to the notion of client's agency? > > 5.3.2 Link lines/Clients can present links to users in whatever fashion > the client author wishes./ The clients can present _links_ to users in whatever fashion. They should still be links. If a URL pattern allows for the encoding of random material, that should not be license to inline content. The goals of the project are clear philosophically that text/gemini represents a single document format that can hyperlink. Pulling in data in the ways you are describing is no different from the earlier suggestion of a <= line or frames. If your client wants to display images inline in the document AFTER a user clicks on a link, that would be within the purview of a client author. A client should not choose to inline images automatically, though, as they would no longer be links. I think this idea, not the specific technical parts, but the theory and philosophy, should answer all of the ideas you've been presenting regarding URL hackery collectively in the negative.
> On Jun 4, 2020, at 18:31, James Tomasino <tomasino at lavabit.com> wrote: > > I think this idea, not the specific technical parts, but the theory and > philosophy, should answer all of the ideas you've been presenting > regarding URL hackery collectively in the negative. Fair enough. So, to summarize, standard URL hackery: big no-no, on philosophical grounds. But hacking your heart content by overloading the link description or otherwise randomly spraying text/gemini with obscure hieroglyphs? Ohhhhhh YES! ?? I foretell a schism ?? "When you come to a fork in the road, take it." -- Yogi Berra, allegedly -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200604/0c49 1fc6/attachment.htm>
In the Vcard example, I don't see why you couldn't put the Vcard between code fences. Optionally with an alt text starting it's a Vcard, if the client wants to get fancy. Otherwise, you could just copy and paste it.. it's a text format, after all. Which makes me think: there's two kinds of things these 'data:' URIs (which I am against, tho not on a protocol level; I just don't think any client will bother with them): text and binary-encoded-as-text. For the text, just fence it if you really want it inline. For binary, just link them. Surely encoding a binary file as text takes up more space than it does in disk! If a client really wants to display it inline, they can do another request and go totally off spec. If they just have to. On Thu, Jun 4, 2020, at 10:48 AM, Jason McBrayer wrote: > Petite Abeille <petite.abeille at gmail.com> writes: > > > Additionally, perhaps text/gemini could embraces data url as small inline adornment. > > > > For example, given a small data encoded vCard, 917 bytes long: > > > > data:text/vcard;charset=utf-8;base64,QkVHSU46VkNBUkQNClZFUlNJT046NC4wDQ pOOkd1bXA7Rm9ycmVzdDs7TXIuOw0KRk46Rm9ycmVzdCBHdW1wDQpPUkc6QnViYmEgR3VtcCBTa HJpbXAgQ28uDQpUSVRMRTpTaHJpbXAgTWFuDQpQSE9UTztNRURJQVRZUEU9aW1hZ2UvZ2lmOmh0 dHA6Ly93d3cuZXhhbXBsZS5jb20vZGlyX3Bob3Rvcy9teV9waG90by5naWYNClRFTDtUWVBFPXd vcmssdm9pY2U7VkFMVUU9dXJpOnRlbDorMS0xMTEtNTU1LTEyMTINClRFTDtUWVBFPWhvbWUsdm 9pY2U7VkFMVUU9dXJpOnRlbDorMS00MDQtNTU1LTEyMTINCkFEUjtUWVBFPVdPUks7UFJFRj0xO 0xBQkVMPSIxMDAgV2F0ZXJzIEVkZ2VuQmF5dG93biwgTEEgMzAzMTRuVW5pdGVkIFN0YXRlcyBv ZiBBbWVyaWNhIjo7OzEwMCBXYXRlcnMgRWRnZTtCYXl0b3duO0xBOzMwMzE0O1VuaXRlZCBTdGF 0ZXMgb2YgQW1lcmljYQ0KQURSO1RZUEU9SE9NRTtMQUJFTD0iNDIgUGxhbnRhdGlvbiBTdC5uQm F5dG93biwgTEEgMzAzMTRuVW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhIjo7OzQyIFBsYW50YXRpb 24gU3QuO0JheXRvd247TEE7MzAzMTQ7VW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhDQpFTUFJTDpm b3JyZXN0Z3VtcEBleGFtcGxlLmNvbQ0KUkVWOjIwMDgwNDI0VDE5NTI0M1oNCngtcXE6MjE1ODg 4OTENCkVORDpWQ0FSRA== > > > > > > A client MAY render it inline, for the user to interact with, in any appropriate ways: > > Please, no. I'd be all for a client rendering text/vcard and similar > content types as pages, with whatever formatting the client author > likes, but they should be rendered as separate documents. If you want an > inline link preview, you can write it by hand, or have it generated by a > script. > > -- > +-----------------------------------------------------------+ > | Jason F. McBrayer jmcbray at carcosa.net | > | If someone conquers a thousand times a thousand others in | > | battle, and someone else conquers himself, the latter one | > | is the greatest of all conquerors. --- The Dhammapada | >
---