[Standards-JIG] File transfer in MUC

[Mridul]

Hi Ian,

  Please see inline.

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

They require it for basic functionality , and it is common across all 
clients : not specific to a few users.
What I was trying to get at was that unless there is a standard 
infrastructure which the xmpp server deployment exposes , each client 
would need to come up with their own ways of uploading to a publically 
accessible file server.

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

You are not allowed access to arbitrary servers - if I am within sun 
network talking to you and suppose both of us are on some public xmpp 
server , we wont be able to transfer files unless I upload the files I 
want to share to a public internet.
My IT infrastructure will not allow me to expose arbitrary files to the 
external world (like most other companies out there) , and my local 
private webserver will not be accessible to you since you are outside my 
firewall.
Ofcourse , in environments like this , pretty much most of the p2p file 
transfer is precluded.

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

If the constraints allow it - oob would be really great and I would 
prefer it too :-)
But in a lot of cases , this is not possible - especially for most 
security conscious customers.

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

Implementation is not the issue - more of standardizing a approach so 
that all clients could implement it and discover server side support for it.
What we have currently works for our server (for more than a year now 
actually) , so will other custom solutions - but there is zero 
interoperability unfortunately between the solutions.
So would be great if there is a proposal in this space which allows 
multicasting files to users.

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

If a client is not interested, or is unable to receive a file - that is 
a different case imo.
It could ignore the file transfer stanza's , or notify the user of it.
Btw , I would assume it will be possible for webclients to do ibb  (more 
complex than opening a uri for oob ofcourse) or pick up a uri from a 
pubsub node and initiate a transfer from there.
I am not sure how expensive it will be though.

Actually there are other obvious extensions to the requirements :
* setting up acl's on who can multicast files.
* setting up acl's on who can receive files.


Thanks,
Mridul

>
> Regards,
>
> - Ian
>