[Standards] file transfer

[Richard Dobson]

> Yes, but (certainly on my phone) it cuts the GPRS while you do so.
Fair enough, mine doesn't, must be a limitation either with your handset 
or your network provider (I would expect its just the handset trying to 
maximize battery life and radio usage, as you arn't entirely likely to 
be needing to use it while on a call rather than being a limitation of 
GPRS), does yours send incoming calls to voicemail as Rachael says hers 
does when you are doing GPRS transfers?
> 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. ;-)
LOL, although technically im pretty sure GPRS (and 3G) often uses 
multiple channels in order to speed up data transfer speeds anyway.
> 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.

The thing is the specs (XEP-0047, XEP-0065, XEP-0095, XEP-0096) mention 
nothing about using TLS over the bytestream so im pretty sure that would 
break all existing implementations, whereas pre-compressing the file is 
completely backwards compatible with whats being sent over the 
bytestream and compatible with all receiving clients as the user will 
still likely be able to decompress a zip file themselves if their client 
does not support automatic decompressing.

> 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).
Yea but would be good if we can implement it in the most backwards 
compatible way we possibly can which creating a jingle bytestreams (ala 
XEP-0047/XEP-0065) spec should do, it also reuses existing work, and 
even allows the reuse of the jingle bytestream in other specs (i.e. the 
idea of SI) without changing anything in jingle itself.

Richard