[Standards] XEP-0363 and Message MIME content type

Anurodh Pokharel info at monal.im
Fri Jan 29 16:38:07 UTC 2016

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160129/fb619dcb/attachment.html>

More information about the Standards mailing list