I'm +1 for removing Section 2.4.
After taking a glance through existing implementations I'm aware of, I'm not
seeing that anyone has implemented this feature.
To clarify on-list for future reference, here is why Section 2.4 is problematic:
The Jingle IBB transport is limited in only being able to signal a single IBB
channel at a time, like so:
<transport xmlns='urn:xmpp:jingle:transports:ibb:1' sid='12345'
block-size='4096' stanza='iq' />
Well, if I'm trying to signal an application type that wants to use multiple
channels, I'm now stuck with a problem: I can only send one of the channels in
my session-initiate or content-add (so which channel?) and have to send the
rest via transport-info (before or after the other side accepts?). My initial
offer will always be incomplete due to this protocol design, which makes IBB
different from other transport types.
But why do I want to use multiple channels under one transport? That's
generally only needed if the application type needs to use 'components' (like
how the RTP application needs a socket for RTP and optionally a second for
RTCP). The trick with components is that they need predefined names so that
application instances can reliably identify them. E.g., RTP uses component "0"
for RTP and component "1" for RTCP. Can we do that with Jingle IBB and its
multi-session feature? No, we can't reliably identify components. There is a
'sid' attribute which comes close, but can't be reliable since we're using that
in the XEP-0047 IBB layer, running the risk of multiple IBB sessions with the
same sid between the same two peers.
Consider an application type that needs a component named "A". If we tried to
use the 'sid' attribute, and I have a single session with two contents with
this application, there will be a collision trying to open an IBB session with
a sid of "A" twice.
There are three ways of addressing these problems:
1) Ignore it
2) Remove the section (as Peter and I are proposing)
3) Update the spec to fix the problem
While I would like to go with option 3, the fact that Jingle IBB is meant to be
the common fallback of last resort makes me extremely hesitant to introduce a
new version.
That said, an ibb:2 protocol that fixed these issues would look something like
this:
<transport xmlns='urn:xmpp:jingle:transports:ibb:2'>
<candidate component="A" sid="12345" block-size="4096" stanza="iq" />
<candidate component="B" sid="67890" block-size="4096" stanza="message" />
</transport>
/Lance
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
