[Standards] Proposed XMPP Extension: HTTP File Upload

Mickaël Rémond mremond at process-one.net
Fri Aug 7 15:29:18 UTC 2015

Hello Philipp,

On 30 Jul 2015, at 20:12, Philipp Hancke wrote:

> HTTP Upload is just another transport as far as jingle is concerned.
> So you would send your session-initiate with the XEP-0234 description 
> (instead of reinventing this in example 5) along with an empty 
> <transport/> qualified by 
> urn:xmpp:jingle:http-transport-something-something.
> In the session-accept you would get a transport element telling you 
> where to put this. This would basically be the put url.
> After the transfer is done, the receiver sends a session-info telling 
> you the location where to get the file (this is the only design change 
> compared to the current approach but I think it allows the service to 
> process things and decouple things)
> I think this wouldn't change the semantics of the proposal much, just 
> how things are done on the wire.

In my mind, Jingle set of protocols are for live streams and they have 
the following characteristics:
- You negotiate either an "infinite" stream (for voice / video calls) or 
more limited streams.
- Negotiation happens between sending and receiving party. It means they 
need to be both online at the same time.
- They can agree on any transport they like, including HTTP. We have 
developed a streaming HTTP proxy to allow upload and download at the 
same time before the file is fully received. However, the semantic in 
that case is still "live" transfer.

The protocol proposed by Daniel is asynchronous by nature. It is more 
about file sharing than transfer actually.

I truly think both approach have their use and they do not overlap:
- Jingle for live negotiation if binary stream transfer. Use is mostly 
for live conferencing systems for example.
- HTTP file slot approach for asynchronous sharing. Use is mostly for 
mobile client that have, by nature, very intermittent connection.

I hope clearly specialising both XEP will make developers of both types 
of apps happy.

Mickaël Rémond

More information about the Standards mailing list