On Jan 12, 2012, at 02:56, Sergey Dobrov wrote: > On 01/12/2012 03:57 PM, Marcus Lundblad wrote: >> tor 2012-01-12 klockan 15:47 +0700 skrev Sergey Dobrov: >>> Hello, I am reading the XEP-96 and see in the requirements section: >>> "Enable seamless file transfer, including fall-back mechanisms as >>> appropriate", then I see that socks5 and IBB are must be implemented in >>> a XEP-96 compatible implementation. Ok, we can try to use socks5 and if >>> it fail we will fallback to ibb and then we will guaranteed done with >>> our transfer. But where is described HOW this fallback should be >>> negotiated? The flow: >>> >>> 1. SI Request. We are must to include both socks5 and IBB as our >>> stream-methods. >>> 2. SI Response will always reply with socks5 because it must support >>> both of protocols and socks5 is with high priority. >>> 3. SOCKS5 is failed to establish a stream. >>> 4. What we have to do next? Send again a SI request with only IBB >>> included as our stream-methods? Should the recipient to ask again about >>> the file transfer? How should it determine that it should not, if it's >>> not? That's really unclear with the current XEP. >>> >>> The second thing is: maybe we should to remove the requirement to >>> support both socks5 and ibb? Because it's not carried out de-facto by >>> several implementations and not each platform can easily implement both >>> bytestreams. >>> >>> >> >> You should probably use JingleFT if you're implementing something new >> today. Hopefully it will gain more popularity. >> With Jingle this scenario is covered. >> If you want to implement SI transfer as well (to maintain legacy >> compatibility) you might do like you described above. There's also some >> extension to SI that is used by telepathy to handle the fallback >> scenario. > > I am familiar with the JingleFT specification and I like it but the > thing is that I need some specification that can be used right now to > make it possible to inter operate with majority of clients. The > situation with file transfer now is not the best and I don't think that > it's a good choice now to force the transition to another specification. > > Despite of everything, the standard has a fallback mechanism in it's > requirements. But I can't find it. And I can't decide how to implement > the XEP right at all. Should it be fixed? I think, yes. It should be > fixed or marked as obsolete.
The fallback mechanisms for SI:FT were never codified. I think there are implementations that tried to do something, but they barely interoperate with themselves. At this point, I'd rather focus protocol effort on improving JingleFT. However, marking SI:FT as Deprecated before JingleFT is Draft is a mistake. - m&m <http://goo.gl/LK55L>
smime.p7s
Description: S/MIME cryptographic signature
