[Standards-JIG] File transfer in MUC

[Mridul]

Ian Paterson wrote:
> 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).

Just to add , if there was a common way to attach a file to the muc , it 
would just be the case of a file transfer from the user to the muc , and 
then multicast from the muc to the participants.
This need not be ibb , but can be oob too - just depends on what the muc 
and the client negotiate on.
We need not define a new protocol to do this - the current file transfer 
profiles can be reused for this : this is a variant of what we currently 
have - but this is not really attaching a file to the conference : more 
of multicasting.
As things stand now - multicasting of files is not possible to all 
participants of the muc without a custom client/server protocol - so 
solving and standardizing this problem will be great.

I was thinking of a simple extension to this - if a file gets attached 
to the public muc (in some way) , it could get archived , picked up by 
later joinee's , etc too : not just current participants.
I was thinking along these lines since it is alluded to in the muc spec 
and thought it might be a more generic solution.
The current problem we have is - how can the client send a file to all 
participants of a muc : once this is solved , other requirements might 
come in later :-)

Regards,
Mridul

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