content-disposition vs data URI

Petite Abeille <petite.abeille (a) gmail.com>

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

Link to individual message.

Jason McBrayer <jmcbray (a) carcosa.net>

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    |

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> 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.

Link to individual message.

James Tomasino <tomasino (a) lavabit.com>

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.

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> 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

Link to individual message.

Case Duckworth <acdw (a) acdw.net>


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    |  
>

Link to individual message.

---

Previous Thread: Small break

Next Thread: The Gemini Assigned Protocols Authority (GAPA)