Re: [art] URI content hints

On 3/9/23 17:17, Dale R. Worley wrote:
> "Soni L." <fakedme+art@gmail.com> writes:
>>> feature.  But looking at this documentation for the A element
>>> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a, it lists a
>>> "type" attribute for "Hints at the linked URL's format with a MIME
>>> type. No built-in functionality."  Perhaps this could be made functional
>>> in a practical way?
>> 
>> Sure. Sadly those don't work over e.g. IRC, so you can't tell someone's 
>> IRC client "this is likely a feed, open it in a feed reader if you have 
>> any".
> 
> Can you clarify exactly what you're looking for?  It seems that you want
> not only a hint, but to have the hint integrated into the URI in some
> way.  That could be messy, as there's no guarantee that any arbitrary
> URI leads to any sort of "content negotiation" process ... The only
> content negotiation I know of is in HTTP and SIP, which are restricted
> to http:, https:, sip:, and sips: URIs.  A few concrete examples would
> help as well.

Hmm, if only HTTP is particularly relevant here then (SIP doesn't seem 
to be of significant relevance, doubt anyone's running RSS or Atom feeds 
over that), we guess we could have something like 
cehttps://domain.example/path/?application/atom+xml or 
cehttps://domain.example/path/?application/atom+xml?page=2 then? A 
"content-enabled" web browser would use these to steer content 
negotiation and then open them in an appropriate app.

Back in the IE6 days you could do this with ActiveX. But that led to 2MB 
Accept headers and it basically never did what the user wanted anyway. 
Consider this a privacy-preserving variation of that idea.

> 
> Dale
> 
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art

-- 
1st person: we/us
2nd person: it/its
3rd person: she/they