Background.

When a user wants to chat with his contact, typically he does so with one to one messages - that is, he sends a <message /> with the to set explictly to the reciepent. Now, suppose he invites another contact into this chat : it ceases to be a one to one chat - there is an xmpp protocol extension for multi user chat (muc) defined for this.
In most clients, like ours, there is no visible difference in both usecases : the client upgrades the one to one chat to a private conference behind the scenes and things continue from there.
Actually in our client, there is no visible difference between a private one to one chat, a private conference or a public conference - the UI is consistent across all these usecases.

The problem

Unfortunately, functionality is not strictly the same ... and one of the key areas where this affects is in file transfer : something which users are used to. Currently, there are a number of ways defined on how to negotiate file transfer between two entities - how to negotiate the parameters, how to do the actual transfer - peer to peer/inband, etc.
But when it comes to file transfer in a muc, there is no standard extension or proposal.
This does not mean that file transfer is not supported at all - it just means that there is no standard way to support this.
For more than a year now, our client and server has been supporting filetransfer even in the case of conferences.
The problem is that, this works only with our client and server - as there is no standard in this space, none of the other clients can interoperate with our clients when it comes to this feature.

Requirements

Let us look at a minimal set of requirements :

1. Different clients used by the participants in a conference might support different set of file transfer profiles. Hence, there need not be a intersection of transfer profile supported by all.
2. If a single client is to multicast the file to all the participants, the bandwidth requirements could choke it.
3. The server might want to decide who gets the files in a conference, and might want means to enforce this. Ditto for who can send a file, file properties, etc.

Potential solution ?

I am not discribing what we support, but thinking of a really simple solution.
What could be done is :

1. XMPP Server has an affiliated 'hosting service' - say a http, ftp, etc server : on which it has reasonably high control. Let us assume HTTP service in this discussion.
   
2. This service is not browsable, so you cannot get listing of files - similarly, it must not be possible to easily guess/find arbitrary files from this store - unless the server has divulged the URI to you. Hence URI's generated should also be opqaue and non-guessable to a reasonable degree.
   
3. When client wants to send a file to a conference, it will negotiate with the room - not with the participants.
4. If transfer is to be allowed, the room will assign the client a URI to PUT the file to. Also, it might give it some sort of authorization credentials to be used at the HTTP service.
   
5. Once the client has transferred the file to the URI, it will notify the room - which in turn will multicast the location of the file at this URI to required participants (along with creds to fetch it, if any) : the sender would be specified as the initial user.
   
6. The participant clients will use GET to pick up the file from this service - while using the passed on creds.This way, even if you guess the URI, you will need to also guess the creds to retrieve it.
7. After successful transfer, participant clients would notify the room of completion. A file could get purged when all participants have downloaded it, or if some room configured timeout expires - need not be a pro-active cleanup, but possibility of cleanup after both could be high (impl detail actually).

The caveats are obvious :

1. We are introducing a new form of file transfer profile - though we are using HTTP above, it is still a new mechanism !
2. You are going to have N participants per conference hitting this service for the file - so the service should be able to scale well, in terms of client connections and bandwidth. Might not really be a concern for modern webservers though.
3. Associating URI based credentials might not be that simple : especially if you consider the tie-in required with the XMPP server for achieving this at runtime (PUT, GET creds) : can it be done ? Ofcourse it can be - out of the box support exists ? I am not very sure if it does.
4. You might need some mechanism to clean/purge stale files from the hosting service.
   

Comments, suggestions ?