[Standards] XEP-0363 and Message MIME content type

Kim Alvefur zash at zash.se
Fri Jan 29 17:09:27 UTC 2016


Hi,

On 01/29/2016 05:38 PM, Anurodh Pokharel wrote:
>  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.

It does not specify how the URL is sent. I know at least one
implementation just dumps it in a message <body>, which would not let
you specify any additional metadata.

Something like OOB <http://xmpp.org/extensions/xep-0066.html> combined
with SHIM <http://xmpp.org/extensions/xep-0131.html> could carry more
detailed metadata.  Or Jingle FT with the HTTP transport method:
<http://www.xmpp.org/extensions/xep-0370.html>

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

I believe existing implementations do HEAD requests first to determine
size and content type. I *think* the HEAD method is required by the HTTP
specification.

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


-- 
Kim "Zash" Alvefur

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160129/dfc5c28e/attachment.sig>


More information about the Standards mailing list