[Standards-JIG] File transfer in MUC
ian.paterson at clientside.co.uk
Sat Oct 14 09:51:04 UTC 2006
> Ian Paterson wrote:
>> 1. It gets through any firewall without needing a STUN server.
>> 2. The sending client only needs to transfer the file once - however
>> many people might receive it (simple clients).
>> 3. People joining the room later will see the URL in the history, and
>> can get a copy of the file even if the sending client has gone offline.
>> 4. The method can be supported by all clients, even clients that run
>> in constrained runtime environments (like Web clients).
>> 5. It is secure as long as https: (SSL/TLS) is used (assuming the MUC
>> room and the HTTP server are secure - although those may be big
>> assumptions to make).
>> 6. Almost every client already supports XEP-0066.
> The intention here is , how to send a file to all participants with
> minimum of additional infrastructure requirements.
Yes, the HTTP solution requires extra infrastructure, but so do
solutions that use a STUN server. Although pure p2p solutions can be
more secure and efficient, they will often prove impractical. So HTTP
and/or STUN servers will still need to be deployed.
> For example , requiring to have a fileserver on a publically
> accessible internet (the users could behind different firewalls) when
> user wants to share a file with 3 contacts in a muc is stretching
> things a bit too much :-)
Hmm, I'm not sure I understand. Almost every firewall allows Web form
submition (HTTP POST). In fact plenty of them won't allow anything
> The problem usually is that one of the users would not be using our
> client, and we run into issues. So if there is a documented way of
> initiating file transfer on a conference, it would be great.
> You can use muc as a middleware for multicast - in which case ,
> standard way to transmit binary content would be nice.
But then there could be big "karma" issues. For a solution to be
generally useful it needs to be OOB.
>> The long term might look something like that. But IMHO we've got an
>> excellent simple short-term solution already.
> The short term solution is not practical except for a small subset of
> usecases unfortunately... and you are expecting an 'enlightened' user
> (or a client which also uses webdav (and the like) to post content to
> public server and then publish that uri).
> Actually , it is not really practical to expect this from most
Most clients already have the ability to receive files by opening HTTP
URLs (XEP-0066). Most clients don't yet, but could easily, make the
sending side 100% transparent for users. We just need to standardise the
following in a XEP:
1. The details of how the XMPP server may advertise info about an HTTP
server to its clients via disco#info (similar to the STUN server
discovery protocol in section 5 of XEP-0176). The info would include the
file reception URL, maximum file size, if the server is publicly
2. The format of the POST (compatible with the POST of a file from a Web
3. The format of the response (trivially wrapped in HTML for Web-client
In fact you don't need a Webdav server. Both the server-side and
client-side functionality are so simple that they can be implemented in
a few hours. (If you're interested, I could send you the necessary
server-side source code for a Java Servlet, Python and PHP.)
One of your primary concerns is that all clients in the MUC room should
be able to receive (or send) the transfered file. Note that it is
*impossible* for clients running in constrained environments (like Web
clients) to support the other file transfer methods that are being
discussed in this thread.
More information about the Standards