[Standards] file transfer

Dave Cridland dave at cridland.net
Tue Aug 28 11:38:42 UTC 2007

On Tue Aug 28 09:39:39 2007, Richard Dobson wrote:
>> I digress, but... you cannot surf and call on GPRS at the same 
>> time, generally.  This is why if someone calls a GSM phone while 
>> you are loading a webpage, they will generally go straight to 
>> voicemail.
> Just to correct you here but they wont goto voicemail (if you are 
> connected to WAP using a dial up method maybe), but you can 
> definitely be downloading via GPRS/3G/HSDPA and still make and 
> receive calls, i've done it myself.
Yes, but (certainly on my phone) it cuts the GPRS while you do so.

However, it's certainly possible to have multiple data transfers 
going on in a single GPRS session, but that, of course, is using this 
really cool bytestream technology called "TCP". I here it's used 
quite widely, these days. ;-)

> automatic file pre-compression
> -----
> It would be handy to be able to automatically compress files before 
> they are transferred and then be able to specify this in the SI 
> negotiation allowing the receiving client to then automatically 
> decompress the file once it has received it, this could greatly 
> help with the size of file transfers and would also only need to be 
> done for file types that would benefit from it, i.e. you wouldn't 
> bother with files that were already compressed or things like audio 
> and video files that are likely to only get marginal gains.
If you're transferring over a compressed stream (say, a modern TLS 
implementation), then it's worth noting that compression algorithms 
usually contain some mechanism for identity encoding.

This is needed because files with high entropy (ones that are already 
compressed) would otherwise lead to alarming expansion. This allows 
for not only transparent compression, but also transparent 
non-compression, and allows applications to stop trying to 
second-guess whether data is compressible or not.

Interleaving different data streams will defeat this, but if a new 
data stream (and thus compression state) is used for each transfer, 
this will work out okay.

If you want to transfer multiple files, do so either in distinct 
sessions (if you want to do so concurrently), or serially within the 
same session, with an intervening flush.

As an unrelated aside, TLS in this instance would benefit from 
mandatory support for anonymous cipher suites. ADH et al would be 
perfect for this kind of thing.

> jingle bytestream
> -----
> When we come to implement file transfer using jingle I would 
> suggest that rather than creating a brand new backwards 
> incompatible file transfer protocol that we simply implement a new 
> jingle bytestream transport just like XEP-0047 and XEP-0065 which 
> would allow complete compatibility with the SI negotiation but 
> still gets all the benefits a file transfer over jingle UDP would 
> bring, i.e. better likelihood of connection.

I'd be interested to here what Rob McQueen and other knowledgeable 
folk would think about transferring files over ICE. I vaguely recall 
there are existing mechanisms for layering SCTP over UDP, which 
presumably might fit here and save a lot of work. (Not that SCTP is 
quite what you want for file transfers, but it'll do).

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list