On 01/12/2012 09:43 PM, Matthew Miller wrote: > > 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.
Maybe, we should at least remove the "Mandatory-to-implement technologies" section? Because, otherwise it's not clear at all why to negotiate a stream-method. > > > - m&m > <http://goo.gl/LK55L> > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
