[Standards-JIG] File transfer in MUC

[Ian Paterson]

Mridul wrote:
> 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 
except HTTP.

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

Yes.

> 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 
> users/clients.

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 
accessable...
2. The format of the POST (compatible with the POST of a file from a Web 
browser).
3. The format of the response (trivially wrapped in HTML for Web-client 
compatability).

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.

Regards,

- Ian