<div dir="ltr">Hi all, <div> In the process of implementing XEP-0363  (HTTP file uploads <a href="http://xmpp.org/extensions/xep-0363.html">http://xmpp.org/extensions/xep-0363.html</a>) 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. </div><div><br></div><div>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.  <br><div><br></div></div><div>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:</div><div><br></div><div>1. Is it a format that can be displayed inline?</div><div>2. Is the file small enough to download automatically? In particular, this is a concern for mobile users.</div><div>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. </div><div><br></div><div>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.</div><div><br></div><div><br></div><div>Thanks, </div><div>-Anu</div><div><br></div></div>