Re: [Standards] File Transfer Roadmap
On Mon, Jul 27, 2015 at 3:33 AM, Christian Schudt christian.sch...@gmx.de wrote: 1) How to do offline file transfer? (see HTTP Upload-XEP) 2) How to send a file in a MUC room to all occupants/members? I don't think JFT is really suitable for this in the general everyday XMPP-IM use case, but I also don't see any reason why it couldn't be done, and can imagine that it would be useful for specialized applications. I could see this being added to JFT, or I could see a separate XEP being made which simply sends a message with a receive URI and a mechanism for triggering a JFT session with the server (and provides a way to initialize a JFT session with the server to upload the file). —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
Re: [Standards] File Transfer Roadmap
mån jul 27 00:33:40 2015 GMT+0200 skrev Sam Whited: Thoughts? Sounds good. -- Zash
Re: [Standards] File Transfer Roadmap
Hi, sorry for not responding properly in Thread (Gmail denies me proper Thread view). So take this as a response to all of you. I think P2P file transfer (as defined with Jingle FT) and file upload to a server (HTTP File Upload) can and should coexist. HTTP file transfer is meant primarily for smaller files like images or short audio / voice recordings in a strict Whatsapp-like IM context where people have multiple connected clients at once and also are interested in having access to a history. P2P file transfer on the other hand can scale up to large files that I only need once. (Buddy wants to send me a Full HD movie before he comes over for movie night. I probably are only going to need to download this file once and only at one of my devices. And I'm certainly not interested in having this in my history.) As for what P2P file transfer mechanisms to choose I'm all with Sam and would vote for Jingle FT. Jingle FT - being based on Jingle - has the advantage of being able to plug in different modes of transport. There are IBB, Socks and WebRTC Datachannels (XEP-0343) (which Sam missed in his list). Two of those transport mechanisms address Georges concerns with encryption. cheers Daniel 2015-07-27 14:25 GMT+02:00 Kim Alvefur z...@zash.se: mån jul 27 00:33:40 2015 GMT+0200 skrev Sam Whited: Thoughts? Sounds good. -- Zash
Re: [Standards] File Transfer Roadmap
Mon, 27 Jul 2015 10:33:15 +0200 Christian Schudt christian.sch...@gmx.de wrote: 1) How to do offline file transfer? (see HTTP Upload-XEP) 2) How to send a file in a MUC room to all occupants/members? I think before moving JFT to Draft, the above two questions should be discussed. HTTP upload is a really good conception which will work for MUC as well. No need to bypass NATs. Extremely easy to implement.
Re: [Standards] File Transfer Roadmap
* Sam Whited s...@samwhited.com [2015-07-27 00:35]: With that in mind, I'd like to know what the council (and everyone elses) opinion is of moving Jingle File Transfer forward in the process? I am strictly against pushing forward a mechanism that does not specify strong, mandatory, end-to-end encryption. We have had mandatory encryption on s2s links for over a year now, thanks to the Manifesto. And now we are going to promote plain-text transfers for the really sensitive data (it's not all lolcats and funny jingles)? It looks like IBB is currently the only specification that does not reduce the media transfer security compared to normal chats, at the cost of killing the server's performance and traffic bills. There is a bunch of different encryption ideas, implementations and proposals that all failed to gain adoption so far. I think we need to evaulate them and pick a winner, which should be promoted into an XEP then: * XEP-0116: Encrypted Session Negotiation (Deferred since 2007) * XEP-: XMPP Transport Layer Security (stale since 2009) * OTRv3 media keys (obviously requires OTR; also broken for the multi-client use cases) * ZRTP (used in Jingle for VoIP traffic) * End-to-End Object Encryption (draft-miller-xmpp-e2e; expired in 2013) * ChatSecure's HTTP transfers over OTR over XMPP messages * Conversations' HTTP Uploader with the key appended to the URL * Axolotl (also solves multi-client end-to-end chats; currently implemented in Conversations as a GSoC) * WebRTC (would allow interop with browsers, if done right; also solves the NAT problem; already implemented in jitsi-videobridge?) Personally, I think that Axolotl and WebRTC are the two strongest candidates here, with the former establishing a secure channel between the two (or N) clients, from where a media encryption protocol still needs to be derived (maybe in combination with Jingle). The latter does not secure regular messages, and I suppose it does not allow peer-to-multi-peer data transmissions without a trusted hub server, but it gives us NAT traversal and interop with browsers. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? || ++ IRCnet OFTC OPN ||_|| signature.asc Description: Digital signature
Re: [Standards] File Transfer Roadmap
Hi, there's another related XEP: XEP-0137: Publishing Stream Initiation Requests. I am not sure if Jingle File Transfer should cover the following use cases as well, but what I am reading and hearing more and more (in this list, in my company, in forums) are the following two requirements: 1) How to do offline file transfer? (see HTTP Upload-XEP) 2) How to send a file in a MUC room to all occupants/members? I don't think these use cases are properly covered by existing XEPs, maybe XEP-0066 for 1) and XEP-0137 for 2), but still very vague. I suggested to use JFT for uploading a file to a server (for the offline case, instead of the HTTP Upload-XEP approach), but I am still not sure, if JFT is suitable for this. I think before moving JFT to Draft, the above two questions should be discussed. - Christian Gesendet: Montag, 27. Juli 2015 um 00:33 Uhr Von: Sam Whited s...@samwhited.com An: XMPP Standards standards@xmpp.org Betreff: [Standards] File Transfer Roadmap As I mentioned on the MUC room earlier, I've been investigating the state of file transfer in XMPP, which has historically been a sticky point for the protocol (especially where compatibility between different clients is concerned). After digging a bit, the following XEP's appear to be related to file transfer or stream initialization to some degree (please do point out any that I've overlooked): - XEP-0047: In-Band Bytestreams (Final Standard) - XEP-0065: SOCKS5 Bytestreams (Draft Standard) - XEP-0066: Out of Band Data (Draft Standard) - XEP-0095: Stream initialization (Draft Standard) - XEP-0096: SI File Transfer (Draft Standard) - XEP-0166: Jingle (Draft Standard) - XEP-0234: Jingle File Transfer (Experimental) - XEP-0260: Jingle SOCKS5 Bytestreams Transport Method (Draft Standard) - XEP-0261: Jingle In-Band Bytestreams Transport Method (Draft Standard) - HTTP Upload (ProtoXEP in PR [1]) The only real sticking point I can see for obsoleting several of these XEPs and pushing forward with Jingle as the officially recommended method is the fact that Jingle File Transfer is still marked as experimental. However, it is already begining to gain adoption (Gajim, Conversations, Swift, Stanza.io, Babbler, probably others that I'm unaware of), while other clients, such as the ever popular libpurple, tend to refuse to implement XEPs that are still in the Experimental stage (I'm not sure if that's actually what's happening WRT Jingle File Transfer). With that in mind, I'd like to know what the council (and everyone elses) opinion is of moving Jingle File Transfer forward in the process? What needs to be done? The last time JFT was discussed (as far as I'm aware), the only problem was the complaint that the request/ flow had been removed, however, Lance pointed out that this was a reimplementation of existing Jingle semantics [2] and was planning on adding a section to describe how this worked in JFT:4. If this is indeed the only blocker, I'd like to propose the following roadmap for XMPP file transfer: - Incorporate Lance's changes to JFT (or, if he is no longer working on those, I will propose similar changes to describe the plain-Jingle re-request flow) - Advance Jingle File Transfer to Proposed (and then hopefully to Draft shortly thereafter) - Deprecate XEP-0096 and mark it as obsoleted by XEP-0234 - Evaluate moving XEP-0047, and XEP-0065 fully into XEP-0234, and XEP0260 (which partially re-describe them) to reduce confusion, or leaving it alone to reduce work and needless changes. As I said, I'm happy to drive any or all of this, but want to get some idea of how people feel about it before attempting any of the work (eg. are Lance's patches to JFT still being worked on or should I (or anyone else who has a better grasp of Jingle than I do) take up the torch, will the XSF ever actually obsolete SI File Transfer or will that be a down-vote from the get-go at which point there's no reason to work on it, etc.) Thoughts? —Sam [1]: https://github.com/xsf/xeps/pull/30 [2]: http://mail.jabber.org/pipermail/standards/2015-July/030021.html[http://mail.jabber.org/pipermail/standards/2015-July/030021.html] -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com[https://blog.samwhited.com]
Re: [Standards] File Transfer Roadmap
Hi Sam / others, I hope I'm not being ignorant by not having been in the MUC, but one issue deserves attention I think: When talking of file transfer, the issue of NAT traversal invariably pops up, and becomes a strong selection criterium for the mechanism to use. Please don't forget that file transfer between pre-negotiated endpoints is *much* easier in the case of transparant addressing, which we may assume when IPv6 is being used. A sound choice of mechanism should take IPv6 into account, or a separate mechanism might be preferred for IPv6, or perhaps a variation e.g. without NAT traversal techniques. To simplify the transition, ideally the same mechanism would be used for IPv4 and IPv6 of course. Cheers, -Rick
Re: [Standards] file transfer
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. Ive been reading this thread with interest and while I must agree with most of the comments about Jonathan's suggestion expressed here it has stirred up some simple ideas of my own related to file transfer. 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. 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. Richard
Re: [Standards] file transfer
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. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] file transfer
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
Re: [Standards] file transfer
Richard Dobson wrote: 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 started working on such a beast a while back but never finished: http://www.xmpp.org/extensions/inbox/jingle-bytestreams.html That covered XEP-0065 only, but naturally we could define a transport type for IBB (XEP-0047) too. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] file transfer
No, it would work the other way around -- it enables you to re-use your existing SOCK5 and IBB code, but for the negotiation you'd use Jingle instead of SI. Ah I see, I thought so, I was suggesting doing things the other way around which would be far more backwards compatible as you wouldnt need to implement two separate ways of initiating file transfers which allows you to reuse not just the SOCKS5 and IBB code but also the SI and file transfer initiation code and you are just adding an extra stream-method which makes things much simpler, certainly for me it would make implementing it 100x simpler as my SI/file transfer code is all abstracted out and all I would need to do was implement a jingle bytestream stream-method, not redo all the file transfer discovery, offering, acceptance etc etc which makes things very much more complicated. Richard
Re: [Standards] file transfer
Richard Dobson wrote: No, it would work the other way around -- it enables you to re-use your existing SOCK5 and IBB code, but for the negotiation you'd use Jingle instead of SI. Ah I see, I thought so, I was suggesting doing things the other way around which would be far more backwards compatible as you wouldnt need to implement two separate ways of initiating file transfers which allows you to reuse not just the SOCKS5 and IBB code but also the SI and file transfer initiation code and you are just adding an extra stream-method which makes things much simpler, certainly for me it would make implementing it 100x simpler as my SI/file transfer code is all abstracted out and all I would need to do was implement a jingle bytestream stream-method, not redo all the file transfer discovery, offering, acceptance etc etc which makes things very much more complicated. I understand. But SI and Jingle essentially perform the same functions, since they both enable negotiation. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] file transfer
On Tue, Aug 28, 2007 at 09:21:43PM +0100, Richard Dobson wrote: Peter Saint-Andre wrote: [.snip.] I understand. But SI and Jingle essentially perform the same functions, since they both enable negotiation. Yes but jingle also provides access to ICE and pseudo-tcp so it would be helpful rather than have the entire file transfer negotiation using just jingle if it was separated in two so that all the jingle side is doing is negotiating a generic bytestream that can be then reused by things like SI, to me this seems like a sensible compromise as there is no real benefit that I can see of doing the whole thing in jingle as its just duplicating effort, whereas creating a new bytestream method is complimentory, anyone else think its a good idea? I generally thought that reimplementing all that with jingle is a bad idea. And I as client/library author surely don't like the idea of duplicating code or functinality. I agree completly with you. Robin
Re: [Standards] file transfer
Dnia 28-08-2007, Wt o godzinie 21:21 +0100, Richard Dobson napisał(a): Yes but jingle also provides access to ICE and pseudo-tcp so it would be helpful rather than have the entire file transfer negotiation using just jingle if it was separated in two so that all the jingle side is doing is negotiating a generic bytestream that can be then reused by things like SI, to me this seems like a sensible compromise as there is no real benefit that I can see of doing the whole thing in jingle as its just duplicating effort, whereas creating a new bytestream method is complimentory, anyone else think its a good idea? Me. :-) +1 for SI/Jingle FT -- Tomasz Sterna Xiaoka.com http://www.xiaoka.com/
Re: [Standards] file transfer
I sense some confusion... Robin Redeker wrote: On Tue, Aug 28, 2007 at 09:21:43PM +0100, Richard Dobson wrote: Peter Saint-Andre wrote: [.snip.] I understand. But SI and Jingle essentially perform the same functions, since they both enable negotiation. Yes but jingle also provides access to ICE and pseudo-tcp so it would be helpful rather than have the entire file transfer negotiation using just jingle if it was separated in two so that all the jingle side is doing is negotiating a generic bytestream that can be then reused by things like SI, to me this seems like a sensible compromise as there is no real benefit that I can see of doing the whole thing in jingle as its just duplicating effort, whereas creating a new bytestream method is complimentory, anyone else think its a good idea? It's unclear exactly what you mean. You want a Jingle method as one option in stream initiation, like this? iq type='set' id='offer1' to='[EMAIL PROTECTED]/resource' si xmlns='http://jabber.org/protocol/si' id='a0' mime-type='text/plain' profile='http://jabber.org/protocol/si/profile/file-transfer' file xmlns='http://jabber.org/protocol/si/profile/file-transfer' name='test.txt' size='1022'/ feature xmlns='http://jabber.org/protocol/feature-neg' x xmlns='jabber:x:data' type='form' field var='stream-method' type='list-single' option valueurn:xmpp:jingle/value /option /field /x /feature /si /iq And then you do a Jingle negotiation to figure out how to proceed? I generally thought that reimplementing all that with jingle is a bad idea. And I as client/library author surely don't like the idea of duplicating code or functinality. I agree completly with you. See earlier list discussion. We had rough consensus that in the long term client developers didn't want both SI and Jingle as negotiation mechanisms -- that it would be easier to have just one approach. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] file transfer
It's unclear exactly what you mean. You want a Jingle method as one option in stream initiation, like this? Not quite, it would be more like this: iq type='set' id='offer1' to='[EMAIL PROTECTED]/resource' si xmlns='http://jabber.org/protocol/si' id='a0' mime-type='text/plain' profile='http://jabber.org/protocol/si/profile/file-transfer' file xmlns='http://jabber.org/protocol/si/profile/file-transfer' name='test.txt' size='1022'/ feature xmlns='http://jabber.org/protocol/feature-neg' x xmlns='jabber:x:data' type='form' field var='stream-method' type='list-single' option valueurn:xmpp:jingle:bytestreams/value /option option valuehttp://jabber.org/protocol/bytestreams/value /option option valuehttp://jabber.org/protocol/ibb/value /option /field /x /feature /si /iq i.e. completely backwards compatible for all receiving clients, only clients that know about the jingle bytestream method would try to use it, others would fall back to traditional methods, all without needing a separate jingle file transfer offer mechanism with all the associated discovery and duplicate implementation and complexity that would arise from that. And then you do a Jingle negotiation to figure out how to proceed? Only in that jingle would be negotiating a generic bytestream just as how SOCKS5 and IBB work and then passing the file to it. See earlier list discussion. We had rough consensus that in the long term client developers didn't want both SI and Jingle as negotiation mechanisms -- that it would be easier to have just one approach. Maybe, but ive seen plenty of people also comment that they dont like the fact they are going to have to implement two different file transfer establishment methods in order to maintain backwards compatibility, also I dont seem to remember anyone suggesting this particular compromise back then and I wanted to see what people thought about it, so far two votes for yes. Richard
[Standards] file transfer (was: Re: [LONG] Jeez, Sorry)
Please stop top-posting. It makes the discussion hard to follow. Jonathan Chayce Dickinson wrote: I'm sorry. Didn't mean any harm. I know you didn't. I appreciate your enthusiasm, I really do! But let's temper it with some realism. :) I'm not too hot on bandwidth here, I'm not too hot on mental bandwidth here, either. :) so I didn't come across MTOM. So you didn't research very thoroughly, did you? If you click I'm Feeling Lucky at http://www.google.com/ when searching for Direct Internet Message Encapsulation, you come to the following page: http://xml.coverpages.org/dime.html And right there at the top you find this text: Note: Microsoft has listed DIME among Superseded Specifications in its Messaging Specifications Index Page. See Direct Internet Message Encapsulation (DIME) [June 17, 2002]: This specification has been superseded by the SOAP Message Transmission Optimization Mechanism (MTOM) specification. So here we find many things we need to know. In particular, the technology was superseded and was never seriously pursued. So why are we discussing it here? However, your suggestion might lead to a productive discussion about file transfer / file sharing, see below I wasn't wasting your time, quote: Didn't want to push this forward until I got some feedback. I don't like wasting people's time, hell, I love helping people out and solving problems: don't reply to this and you will never hear of it again; all it takes is nope, not a good idea, not something as violent as fanciful (ouch!). It's fanciful to seriously suggest using a technology that was superseded and abandoned over 5 years ago. Let's try to use more standardized and widely-available technologies if possible. Read the spec and you will see that it has a lot to do with XMPP: Namely (quoted from my draft): 1. DIME will rectify the absence of true In-Band Bytestreams, as it defines methods to send multiple payloads in a atomical message. Each payload in the message can reference other payloads in the message. XMPP needs, in my opinion, a way to negotiate real in-band bytestreams. What are the problems with XEP-0047? Base64 seems like a cop-out to me, it really does. 2. Furthermore compression methods used by servers (which tend to be fast instead of -small-effective) will, at best, return the data to near it's original length. If the data is presented to these algorithms in its original state they may be able to compress it even further. Not everyone has a T3 connection at home, some of us live in South Africa, and well, bandwidth here is rather expensive: and so is a static IP (yes, we differentiate between them here, we /actually/ have non-static ones too). When you have to weigh up the value of 1MB, you will know. 3. Ultimately this protocol will smooth out the issues plaguing Jabber regarding file sharing. This was a hot topic on JDev not too long ago! Demand, supply. If the developers are demanding it, I ASSURE you, the users will be fast following (faster than any cheetah metaphores ;) 4. Almost all the existing XEPs should be able to derive some further benefit from this extension (especially Jingle and SI). That is a bit fanciful and ambitious, I admit. Add XHTML to that list, and well there you go, not even nearly all, but 3, which is a start. (Just coming in on that regard, SOAP has nothing to do with XMPP, but neither did SASL (at the start), or XHTML... And there is SOAP over XMPP now) And, well, *both* are XML and *both* suffer from the fact that you can't package binary data reliably and efficiently in an XML document. This is very true. Jabber was not designed for binary transfer. This is a strength for the core use cases, but a weakness for things like file transfer and file sharing and media sessions, as we have painfully discovered time and again. However, personally I'd say we don't want to use an abandoned technology to solve the problem. Another approach would be to define a BEEP transport: http://www.beepcore.org/ Yes, BEEP is not widely implemented either, but I at least there are RFCs (and I am aware of a new push for wider implementation). Maybe it would help if I finished writing up some results of the file transfer discussions at the recent XMPP DevCon? MTOM wouldn't exist if it wasn't a real problem. It would have ended with DIME. But why was DIME abandoned? (Not that I like MTOM, mind you!) A lot of protocols do it, hell, even your cellphone does something similar (which is why you can call someone and surf over GPRS/3G/HSDPA at the same time). In regard to Dave's email, about the negative compression etc. very true, didn't think of that. Nice, constructive criticism. Dave: the very reason I thought of it was because a P2P connection isn't always possible, as in my case (I don't need it, but the awareness is there). I was hoping to use the server to host the Peer-To-Host-To-Peer connection instead of some 3rd
Re: [Standards] file transfer (was: Re: [LONG] Jeez, Sorry)
On 8/28/07, Peter Saint-Andre [EMAIL PROTECTED] wrote: [snip] That appears to be a sensible line of thinking. However, it seems to me that the wide availability of HTTP servers (which could be bundled with your favorite XMPP server) makes an HTTP approach even more appealing. Part of my question is: do we really need to stream files? Think about the difference between media streaming and media downloading. The use cases in which true streaming is needed seem few. Even things like podcasting are not truly casted in real time -- they are uploaded to an HTTP server and then downloaded, to be listened to on demand. Similarly, it seems to me that if I want to send you a file, I could upload it to an HTTP (associated with my XMPP server), get a URL for that file, then send you the URL. If I don't have an HTTP server at my disposal, I could fall back to in-band bytestreams. But let's face it, the HTTP community has file-upload and file-download down cold. Why not leverage all that? We don't need to do *everything* via XMPP! Do we really need streaming here, or does it just seem cool? [huge snip] Again I think the fundamental question is: do we *really* need to stream things, or can we use sender-upload and receiver-download for many or most use cases, with in-band bytestreams as the fallback? Peter Being a only newbie user, with expensive bandwidth, I like this path. Currently, I know of disk.jabbim.cz service which provides HTTP hosting for files, say http://disk.jabbim.cz/[EMAIL PROTECTED]/. That is really convenient for me, either I can tell it to send the file to some JID, or I can copy the URL of the file to post independently. That's good (except for the Czechy messages, maybe someone can hack xml:lang support into it). The other booster is private storage, sharing the same hosting space but the files don't have HTTP access. People can't just build up the URLs and download the files from everywhere, abusing the hosting service. I know that this is using SI for sending between JIDs, but it provides a nice alternative for people with expensive Internet access. Hiếu
