[Standards] XEP-0363 and Message MIME content type
daniele.athome at gmail.com
Fri Jan 29 17:04:33 UTC 2016
There wasn't much interest I think. But I have to say that I didn't
take the initiative either :-)
On Fri, Jan 29, 2016 at 5:38 PM, Anurodh Pokharel <info at monal.im> wrote:
> Hi all,
> In the process of implementing XEP-0363 (HTTP file uploads
> http://xmpp.org/extensions/xep-0363.html) in Monal, I've come to the
> realization that it would make a lot of sense to include MIME content type
> and size in the message stanza. I've done a bit of searching and I haven't
> found any XEP that defines this behavior. If any of this sounds like it's
> already been done, please point me in the right direction.
> Essentially as I understand it, the issue is HTTP file uploads are designed
> to solve the problem of people using dropbox or some other third party cloud
> service and replace that with an XMPP server that performs all of this
> internally. This is great but simply posting a link to an image or video
> alone isn't very useful to the recipient. One way of resolving this is to
> have the receiving client present the link or preform an HTTP HEAD call to
> try to determine the media type and based on the response try to display the
> content inline. The problem here are there is nothing in the spec that
> requires the server serving the "attachment" to support HEAD. There is no
> guarantee that every HTTP configuration would allow this call.
> At the moment, on the client, we would have to scrape the URL to try to
> determine the media type (audio, video, image etc). While HEAD solves the
> problem, I believe rather than require HEAD support, it may make sense to
> include the content type and size in the message stanza that has the URL of
> the uploaded file. This would be the same data passed to the server in the
> upload request. HEAD would require 2 HTTP calls, first the HEAD to
> determine MIME content type and and size and the second GET to fetch the
> actual media The sender is aware of both the type and size and this allows
> the receiver to determine several things from the message stanza it self:
> 1. Is it a format that can be displayed inline?
> 2. Is the file small enough to download automatically? In particular, this
> is a concern for mobile users.
> 3. Is the file in a format that can can be streamed rather than kept in a
> local cache? This would make sense for audio and video.
> There are certain security considerations. Auto downloading content to
> display inline must require the receiver to trust/know the sender to prevent
> abuse (spam, web bugs to expose IP). Additionally, any decisions to download
> content based on the content size assumes the sender is honest about size.
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
More information about the Standards