Robert McQueen
07-23-2008, 02:55 AM
At the summit we discussed how to fall back between things like SOCKS 5,
direct TCP connections[1] 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.
Regards,
Rob
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. :)
direct TCP connections[1] 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.
Regards,
Rob
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. :)