[Standards] Proposed XMPP Extension: Jingle File Transfer Description Format

Rachel Blackman rcb at ceruleanstudios.com
Wed Feb 7 18:52:38 UTC 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> HTTP is the *only* file transfer method that is possible for *all*  
>> clients (since it is the *only* way available to Web clients).
>> It also gets through firewalls better than any other method, and  
>> TLS/SSL makes it relatively secure (if you trust your server).  
>> Finally, I guess it's simple and easy for everyone to implement  
>> (assuming you have access to an HTTP library).
>> Here's the happy path that Web clients must follow:
>> 1. Sender -> HTTP POST (file) -> Sender's Web server
>> 2. Web server makes file available at a URL
>> 3. Web server -> HTTP OK (URL) -> Sender
>> 4. Sender -> XMPP (URL) -> Receiver
>> 5. Receiver -> HTTP GET (URL) -> Sender's Web server
>> 6. Web server -> HTTP OK (file) -> Receiver
>> 7. Receiver -> XMPP (success) -> Sender
>
> Er, no, I think it's something like this:
>
> 1. sender and receiver negotiate a tcp connection
> 2. sender and receiver use http syntax over the tcp connection as  
> the way to transfer files

1. Client author implements a TCP stack atop STUN+TURN+ICE UDP.
2. Client author has nervous breakdown, retires to Florida.
3. Next client author includes libjingle in project.
...
10. Sender and receiver negotiate a UDP connection.
11. Sender and receiver negotiate a psuedo-TCP connection atop UDP  
connection.
12. Sender and receiver -- who enjoy being 'imaginative' in private  
- -- pretend to be a webserver and a browser,
13. Data is exchanged...
...
29. Profit!

(Okay, I think it's time to step away from the keys and get some  
caffeine.)

More seriously, though, I do see the point there about web-based  
clients.  If the file transfer method underlying is HTTP the  
immediate leaps is that for web-based clients (who, hey, already have  
access to a URL->HTTP->file flow by virtue of being running on a  
webserver), it /would/ be useful to be able to send the URL that way.

However, I'd argue that either iq:oob (that /is/ still around,  
right?) or just a simple "<a href="blah">Look!  A file!</a>" xhtml  
block would be the appropriate way to send a file via simple HTTP.   
If a client doesn't support iq:oob /and/ doesn't do xhtml with  
clickable links, I think you're probably fairly hosed on them  
supporting Jingle-FT, much less Jingle-FT-over-standard-HTTP.  At  
which point, hey, you can just send the URL in the body of a message  
and let them copy-and-paste it. ;)

- --
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFyh/5vcwcncUz5OERAsiXAKCLKFrmZ/4sEDRtUncNTHQy1myOMgCdGRJS
x2kftHUrxcjANDFOKQJznOw=
=Off4
-----END PGP SIGNATURE-----



More information about the Standards mailing list