[Jingle] transport fallbacks for stream transports
stpeter at stpeter.im
Sun Jul 27 20:47:43 CDT 2008
Robert McQueen wrote:
> At the summit we discussed how to fall back between things like SOCKS 5,
> direct TCP connections and IBB in order to find the most desirable
> working stream transport between the two parties. Note that this is not
> the same problem as negotiation (knowing before calling which transports
> you have in common with the endpoint). We've got a separate idea for that.
> My personal opinion is that "content-replace" action which is included
> in XEP-0166, and shown in XEP-0234 is overkill, as well as having pretty
> complicated/unclear semantics. It requires re-signalling the file
> transfer metadata, when really all you're doing is trying to find a
> working transport.
> The proposal is to remove the "content-replace" action, and instead add
> "transport-replace" to replace the transport *only* for an already
> accepted content, and "transport-accept" so that the other party can
> agree to this change.
As discussed at the XMPP Summit, I'm +1 on this change.
> 1: I think we want a Jingle transport description for direct TCP
> connections, because we'll need it on link-local XMPP, and if we have
> working fallbacks then trying a direct connection first isn't going to
> cost much.
> 2: I think we should rename "reliable" and "unreliable" in XEP-0166 to
> "stream" and "datagram", in the same vein as BSD socket type. I wanted
> to talk about the dependability (whether the transport can be expected
> to work at all, ie direct TCP is undependable, but IBB is very
> dependable) separate to the reliability guarantees, without ending up
> saying "reliable unreliable" or "unreliable reliable" transports. :)
+1, will fix.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jingle/attachments/20080727/b243b4c3/attachment.bin
More information about the Jingle